내 남자의 길~!

책 소개
이 책은 소프트웨어 개발 분야의 창의력에 관한 책이다. 저자는 소프트웨어 개발이 근본적으로 복잡한 문제를 해결하는 활동이며, 복잡한 문제를 해결하려면 창의력이 필요하다는 생각을 바탕으로 소프트웨어 창의력을 얘기한다.

체계를 중시하는 관리자와 학계, 그리고 자유로움을 중시하는 실무자 측면에서 바라보는 소프트웨어 개발을 창의력이라는 주제로 탐구해보고 정의한다. 또, 창의력이 조직과 소프트웨어 분야에서 차지하는 비중과 역할을 살펴보고, 다른 분야에서 배우는 창의력과 창의력을 기르는 방법도 소개한다.

이 책은 다음과 같은 저자의 개인적인 절실한 느낌과 신념을 담고 있다.
-소프트웨어 개발이 근본적으로 문제를 해결하는 활동이라 믿는다.
-어떤 문제든 해결하려면 창의력이 필요하다고 믿는다.
-소프트웨어 문제를 해결하는 활동은 어떤 활동보다도 아주 복잡하다고 믿는다.
-그러므로 소프트웨어 문제 해결에 있어 창의력은 절대적이라고 믿는다.

'소프트웨어 크리에이티비티 2.0'에서, 인기 있는 저자인 로버트 L. 글래스는 중요하지만 이상하게도 외면받는 질문을 하나 던진다. 도대체 소프트웨어 공학과 컴퓨터 프로그래밍에서 창의력이 차지하는 역할은 무엇일까? 글래스는 자신의 전매특허인 평이한 문체와 연구와 개인 경험에 기반한 실질적인 접근 방법을 사용해서 함축적이면서도 광범위한 연구 주제를 다룬다. 몇 가지 예는 다음과 같다.

-체계나 정형화는 유연성이나 애자일과 조화를 이루지 못할까?
-소프트웨어 제작 과정에서 통제 방식과 실험 방식이 어떤 때 가장 효과적일까?
-소프트웨어 조직에서 창의력을 발현할 수 있을까?
-프로세스와 제품 중 무엇이 더 중요할까?
-소프트웨어 분야에서 이론과 실제가 어떻게 상호 작용할까? 실무자와 학자가 좀 더 효과적으로 서로를 보완할 수 없을까?
-창의력과 소프트웨어 설계 사이에 끊어진 연결 고리가 있을까?
-소프트웨어 작업에서 '지적인' 작업과 '사무적인' 작업 사이에 균형은 무엇일까?
-요즘에도 옛날에 느꼈던 즐거움을 찾을 수 있을까?

'소프트웨어 크리에이티비티 2.0'에서는 '피플웨어'와 '소프트웨어 프로젝트에서의 리스크 관리'를 공동 집필한 톰 드마르코가 쓴 추천글과 로버트 L. 글래스가 새로 쓴 서문도 포함한다.

//2009.06.19
블로그를 돌아다니던 중에 자주 방문하던 블로그에 이 책이 올라왔더군요.
몇일전 생일이였는데 생일 선물로 사달라고 해야겠습니다. 표지가 맘에 들고 서평도 좋더군요.

//2009.06.23
ㅎㅎ 후배인 티엘로에게 필살 조르기 스킬 작렬!! 했더니 구매완료.
곧 배송 되겠네요. 티엘로 쌩유~!! 잘 읽을께..

   <====  후배인 티엘로!! 스샷 ㅋㅋ

//2009.08.20
시간적 여유가 다시 없어진 탓일까 아니면 다시 마음의 여유가 없어진 탓일까 므튼
이러저러한 이유로 블로그에 포스팅을 하는게 꽤 오래간만인거 같다.
프로젝트가 이동하면서 출퇴근 시간에 여유가 생겼고 시간도 짧아졌다. 그 탓인지
이동 시간이 짧기 때문에 그만큼 책을 읽는 시간도 적어졌다.ㅡㅡ;
내가 게으른 탓이다. 이동시간 외에 더 여유로워진 시간을 그냥 허비하고 있는것이다.
므튼 책을 다 읽은지 꽤 흘렀지만 포스팅을 하지 않고 시간이 흘러버렸다.
머릿속에는 그저 그 의미만이 맴돌고 있고 책의 내용이 주르륵 흐르지는 않는다.
개발자의 창의력에 포커스를 맞춘 이야기가 중점이 된 내용이었던거 같다.
그리고 개발자의 마음도 잘 헤아리면서 관리자, 그리고 실무자와 학계사이의 간극을
좁히고자 중용의 입장에 초점을 맞추고 효율적인 방안에 대한 모색등..이 인상깊었다.
다시금 읽어 볼만한 책이다. 그리고 IT에 종사하는 개발자 그리고 관리자들이 읽었으면 싶다.
특히 개발자의 입장에 서있는 나는 PM을 맏고 있는 중간관리자들이 꼭 읽어보길 바란다.

책 소개

사용자가 필요로 하는 소프트웨어를 개발하기 위해 '사용자의 이야기'를 듣는 것부터 시작하는 것은 당연하다. 사용자 스토리는 실제 사용자들에게 정말 가치 있는 기능을 간단명료하게 기술한 것이다. 이 책의 저자 사용자 스토리를 작성하는 것은 물론이고, 사용자 스토리를 여러분의 개발 프로세스에 접목시킬 수 있도록 하나에서 열까지 충실히 설명한다. 스토리를 잘 작성하기 위한 포인트뿐만 아니라 조심해야 할 사항들까지 배우게 될 것이다. 사용자 스토리를 수집하는 현실적 방법들도 배우게 된다. 실제 사용자를 만나볼 수 없는 상황에 대한 대처 방법도 배울 것이다. 사용자 스토리를 수집한 다음 조직화하고 우선순위를 부여하여 계획, 관리, 테스트 단계에 활용하는 방법을 설명한다. 사용자 역할 모델링 - 사용자들의 공통점과 차이점을 이해 스토리 수집 - 사용자 인터뷰, 설문, 관찰, 워크숍 대리 사용자(proxy)와 작업 - 관리자, 교육담당, 영업 등 인수 테스트 작성 스토리를 이용한 우선순위, 일정계획, 비용추정 각 장 끝에 연습 문제 포함   <출처 : 네이버 책 > 웹서핑중 눈에 들어온 책이 있어서 구입예정도서 목록으로 올려놓게 되었다. 사용자스토리 라는 책 이름을 보고 별 관심이 없었지만 책소개를 읽다가 멀리서 지켜보던 지름신이 강림 한것이다. 하지만 아직 집에 읽지 않은 책이 있기에 지름신의 신탁을 거절하고 훗날을 기약하기로 마음을 먹을수 밖에... 현재 SI업체에서 일을 하고 있기에 현업들 즉 사용자와 접할 기회가 많이있는 편이지만 커뮤니케이션 부분에서 많은 부족함을 느끼고 있기 때문에 구입예정도서로 찜! 만 했다. 책 이름을 보니 얼마전에 읽었던 "아키텍트 이야기"란 책에 나온 문구가 생각난다. 그리고 "아키텍트 이야기" 中 "기술자라면 자신의 기술을 충분히 활용하고 또한 넓히고 싶은 게 당연하다. 사용자의 웃는 얼굴을 보고 싶고 거기에서 보람을 느낄 것이다." 위 문구가 번뜩 떠오르게 되서 이렇게 포스팅을 하고 잊지 않고 나중에 구입하려고 한다. 처음 프로그래밍에 입문때 상상하던 것이 내가 만든 프로그램을 사용하는 사용자의 모습이다. 물론 감탄하고 편하다 이거 잘만들었네! 하는 모습을 상상하면서.. 정작 개발자로 일하면서 무엇이 중요한지 자꾸 잊어먹고 일을 하게 되는거 같다. 일정에 치여 정작 사용자의 편의성은 뒤로한채 개발 편의만을 생각하게 되는건 아닌지 하는 생각이... 빠른시일내에 구매하여 읽고 서평을 올리도록 해야겠다.^^ ---- 문득 포스트를 올리고 다시 수정하면서 생각이 든것이 있다. 이번 포스트를 올리면서 아니 최근 들어 포스트를 올리면서 내가 쓴 글에 많은 어색함이 느껴진다. 그것은 말투의 어색함이 감돌기 시작한것이다. 이전부터 내 블로그는 나만의 작은 공간이라고 생각했지만 어느 순간부터 인지 내 블로그를 자주 방문해 주시는 분들이 계시기 때문이다. 그래서 인지 아직도 많이 부족하지만 글 하나에도 조금 더 신경이 쓰이게 되어가는 것이다. 그러한 상황에서 오는 포스트의 어색함은 아직 부족한 블로거가 더 발전하는 과도기라 생각한다. 어느샌가 내 블로그에 글들은 다른 사람을 향한 이야기와 같이 변화해 가는거 같다. 블로그를 통해 다른 사람들과 커뮤니케이션을 하고 있는것이다. 이것이 블로그를 하는 이유가 아닐까 생각한다. ^^ 내가 찾은 블로그의 매력!!

//2009.06.23
10년지기 친구인 찐이에게 필살 조르기 어택!! ㅎㅎ 득했습니다. 갑자기 책이 너무 많아졌네요.
참고로 형석 ♡ 진이 커플에게 각각 책 선물 받았습니다. 둘의 첫 만남에 아주 조그만 기여를 했기에..
고맙다.. 친구들아~!! 내가 조르기는 했지만 잘 읽을께..ㅋㅋ 둘이 행복해라..^^

//2009.07.18
책을 선물받고 한번 훑어 보는데 3주 가량의 시간이 걸린거 같다. 흠.. 꽤 걸렸군..
책을 읽는데 얼마간의 시간이 걸렸는지는 중요하지 않을 것이다. 하지만 틈틈히 짬을 내어 읽다보니
머리속에서 그 내용이 쭈욱 연결되지 않는 것 같다.  조금 읽다 몇일 뒤에 이어서 읽고 하다보니.
책의 내용은 내가 생각했던 것과 다른 내용이여서 조금 난감하기도 하였다.
사전지식 없이 그저 책 이름과 대충 추정했으니.. 이책은 개발방법론에 관한 책이다.
애자일 방법론과 부합하는 내용의 방법론의 일종이고 읽으면서도 흠 이렇게 하면 괜찮겠군..하고
생각도 하면서 읽었지만 아직 초급 개발자인 나에게는 조금 맞지 않는 책인듯 하다.
책의 내용을 내가 적용해 볼수도 없는 입장이니 말이다. 그리고 내가 겪은 프로젝트에 대해 적용한다고
생각했을때 한국에서 하는 프로젝트에 적용하기엔 문제가 있을꺼 같다는 생각이 들었다.
작은 소규모의 프로젝트에는 적용해 볼수 있지만 대규모 프로젝트나 거의 대부분의 SI 프로젝트에서는
한국의 특성상 수시로 바뀌는 요구사항의 변경/추가를 커버하기에는 무리 일듯하다.
책의 내용이 잘못됫다거나 부족한것은 절대 아니다. 한국과 서양의 특성이나 관점의 차이일듯 하다.
개발방법론에 관한 책인지 모르고 읽었지만 이슈가 되었던 애자일 이라던가 익스트리밍 이라던가 에 대한
약간의 맛을 보았다는 데에 나름대로 만족하고 있다. 여유가 된다면 소규모 프로젝트에 적용하고픈..
개인적으로 아는 지인들과 함깨 작은 프로젝트를 같이 해보고 싶다. 거기에 여러가지 배운 것들을 적용해서
개발 방법론이라던가  디자인 패턴, 지속적인 통합(Continuous Integration), 등등...