https://book.naver.com/bookdb/book_detail.nhn?bid=7010768
새롭게 소프트웨어 개발자로 입문한 친구뿐 아니라 경험많은 개발자한테도 권해주고 싶은 책이다. 팀을 구성하면 팀원들한테 한권씩 사주고 읽어보라고 권하고 싶다. 책에서 나오는 중요한 문장을 옮겨보고 코맨트를 달아보자.
chapter 13 개발 일정을 맞추는 방법
- 여러 새로운 기능의 개발이 공통적인 구성 요소에 많이 얽혀있을수록 많은 프로그래머가 서로 상대방의 코드를 건드리게 되며, 더 중요한 것은 서로 상대방의 설계 시 가정사항을 건드릴 일이 많아지게 된다. - 라이트스톤의 복잡성 원리(Lightstone's convolution principle)
1. 범위 변경 문제
//요구사항의 항상 25% 이상 변경 된다고 가정하는게 맞다. 팀원들한테도 요구사항이 변경될 수 있음을 끊임없이 알려야 하고 그것이 당연하다고 인식시켜야 한다. 그렇지 않으면 요구사항이 변경될때마다 부당함을 어필하는 팀원들로 머리가 아파질 수 있다.
2. 인력 수준의 문제
//5 ~ 28배의 일인당 생산성의 차이 발생한다고 하는데 대개의 팀은 최악과 최고의 사이 어딘가에 위치해 있어 실제로는 2 - 3배 정도의 차이를 내는 것으로 생각된다. 물론 2,3배도 엄청난 거지만.
3. 지연된 프로젝트에 사람이 더 붙으면 오히려 더 느려지는 문제
//프레드 브룩스의 맨먼스의 신화를 통해 많이 알려진 이야기지
4. 개발팀의 목표가 불분명한 문제
//이부분은 성당을 만드는 석공의 이야기를 비유로 하면 좋을 듯
5. 의존성 관리: 기능별 예상치를 그냥 더해서 생기는 문제
//결합도와 응집도에 최대한 신경을 쓰는게 해결책 아닐까?
6. 잘못된 추정치 문제(비율 주의)
//코딩의 전체 개발 사이클의 1/6에 불과한데 코딩에 대한 일정으로만 추정하는 경향이 있다고 하는데 이것은 팀장이 팀원의 추정을 지속적으로 보정해 주면 된다. 멍청한 팀장이 아니라면 팀원에게 그가 말한 추정치의 근거를 물어보아야 한다. 그러면 그가 개발 사이클의 포함했는지 단순 코딩만 넣었는지 확인할 수 있다.
7. 공격적인 추정치 문제
//마치 팀을 이상적인 개발팀으로 생각하여 일정을 잡곤하지
8. 난 임계 경로에 들어있지 앟아 라고 생각하는 문제
//이건 생각 못했던건데 다른 팀원의 기능 구현때문에 일정이 늦어질때 자기가 구현해야할 기능도 일정을 지연시키는 현상을 말한다. 오 참신한데. 게으름 피우기 딱 좋은 상황
9. 소프트웨어의 엔지니어링 개념을 말아먹는 문제
//개발 방법론이 없거나 지켜지지 않는 경우 개발자들은 프로젝트 후반부에서 죽음의 행진을 하게 되는건 명확하다. 1인 개발이 아닌 팀인 경우 개발 방법론이 없다는 것은 나침반 없이 바다로 나가는 것이다.
10. 직원이 해야하는 다른 일을 고려하지 않는 경우.
//휴가, 발표 준비 등등의 일을 고려하지 않고 일정을 짠다는 말인데, 대략 1년에 20정도의 일정을 버퍼로 넣어야 맞아 보인다.
11. 바람의 변화
1. 기능 줄이기
//내가 제일 좋아하는 방법이다. 프로젝트 초반에는 중요했다고 생각하는 기능들이 후반에는 불필요하거나 중요하지 않게 되곤 한다.
2. 기능 쪼개기
//기능 줄이기와 같은 맥락
3. 재협상
//일정을 다시 논의 하는 것인데 이렇게 하려면 일정에 대해 납득할 만한 근거가 있어야만 통하지, 안그러면 무능해보일 우려가 있다.
chapter 17소프트웨어 혁신 리더쉽
1. 주변에 최대한 뛰어난 사람들만 골라서 배치하라
//맞는 말이긴 하지만 뛰어난 인재를 고르기란 대단히 어렵다. 마치 서울대 가려면 공부 열심히 하라는 말처럼 공허하다. 가지고 있는 인재 풀 중에서 최대한 적절한 인재를 골라야 하겠지. 최대한 지연, 혈연, 학연등을 배제한채로 말이다.
2. 혁신에 보상하라
//오래전에 읽은 책중에 데모를 준비하려고 2주간 야근한 개발자에게 피자 한판으로 보상하는 것은 개발자를 모욕하는 것이라고 했다. 적절한 보상은 팀장으로써 반드시 쟁취할 분분이다. 그래야 리더쉽을 발휘할 수 있다.
3. 영역주의를 없애라
//음 용어적으로 적절하지 않은 표현같지만 팀워크를 중시해라 정도로 이해해야 할듯
4. 반복하라
//반복 개발하며 피드백을 받는 것은 팀 개발 방법론의 기본중의 기본
5. 해결책이 아니라 문제를 안겨줘라.
//생각해 볼 문제다. 이전까지 팀원이나 동료가 문제를 가져오면 같이 해결하는 것을 나의 큰 장점으로 생각해 왔는데 질문을 던지고 문제의 본질에 대해서 더 분명히 파악할 수 있도록 도와주라고 한다. 쉽게 말해 물고기를 주기보다 잡는 법을 알려주라는 건데. 두가지 방식을 잘 조율해야겠다.
6. 데이터는 중립적이다
//물론 그렇다 데이터는 중립적이지만 그것을 해석할때 외곡이 발생한다. 책에서는 확실한 데이터를 근간으로 사내 정치에 휘둘리지 말라고 하지만 같은 데이터를 가지고 상반된 해석으로 피터지게 싸우면 이런말 안할텐데..... ㅋ
7. 주어진 상황 내에서 문제를 해결하라
//이건 중요한 말이다. 현실을 직시하고 조건 내에서 최대한 해결하려고 노력해야 한다. 안그러면 끊임없는 불평에 계속된다.
8. 친화도를 높여라
//성공하는 사람의 7가지 습관에 나오는 것처럼 상대방의 감정계좌에 충분이 내가 쌓여 있다면 일을 하기는 편해진다. 방법은? 무조건 도와주자. 내가 필요할때 도움을 받을 수 있도록
9. "저것은 남의 것" 증후군에 걸리지 않도록 주의하라
//바퀴를 다시 발명하지 말라!
10. 다른 분야에 대한 지식을 쌓아라
//이종분야에 대한 융합역량은 생각보다 중요한 것 같다. IT뿐 아니라 경제, 문화등 다양한 지식을 쌓을 필요가 있다.
11. 현재 최신 기술을 이해하라
//익숙한 기술이 아니라 현재 최신 트랜드가 어떤지 최소한 이해는 하고 있어야 한다. 무엇이 있는지 알아야 나중에 필요할때 깊이 학습하여 적용할 수 있기 때문이다.
12. 일하는 방법에 있어서 사용자와 시장에 휘둘리지 말아라
//혁신적인 아이디어는 시장에서 나오지 않는다. 시장을 분석하는 것은 필요하지만, 분석만 하고 통찰력이 없다면 핸리 포드는 더 빠른 말을 기르는데 주력했을 것이다.
chapter 18 빅 리그: 거물에서 선지자로
1. 내가 아는 것을 쓴다
2. 질에 초점을 맞춘다
3. 나라면 이걸 읽을지 자문해 본다
4. 가능하면 다른 공저자들과 함께 일하자
5. 문체도 중요하다.
6. 글 써서 부자가 될 생각은 금물이다.
1. 청중을 이해하라
//청중이 누구인지에 따라 다른 내용으로 발표를 해야한다.
2. (내용뿐 아니라) 스타일로 청중에 맞춰라
//청중이 경영진인지, 학생인지, 기술자인지에 따라 다른 스타일로 발표하는 것은 생각 못한 부분이다. 경영진한테 발표할때는 좀더 진중하게 해야겠다.
3. 알아듣기 좋게, 적당한 빠르기로 발표하라
//긴장하며 발표하다 보면 점점 말이 빨라지기도 하는데 의도적으로 속돌르 조절할 필요가 있다.
4. 청중을 사로잡아라
//보통 처음 발표를 시작할 때 주제와 관련된 잘 알려지지 않은 재미있는 이야기로 시작하곤 하는데 그런 방식은 발표에 집중하게 되는 좋은 효과를 내곤 했다.
5. 손동작을 절제하라
//오바마나 클린턴 연설을 유투브에서 보고 어느정도 해야하는지 참조하란다. 나중에 함 봐야지. 애매하면 그냥 두손 맞잡고 하자..
6. 웃어라
//웃는 표정으로 하고 가끔 청중과 눈도 마주치자. 근데 자꾸 까먹음. ㅠ ㅠ
7. 차트가 아니라 내가 발표한다는 점을 기억하라
//발표자료 죽죽 읽는 것은 최악이다.
8. 내가 주인공이 아니다
//스토리텔링을 할때는 나를 쓰지만 그 이외의 경우에는 안쓰는 것이 좋다고 한다.
9. 그래서?
//발표를 하고 나면 커다란 주제에 대한 메세지를 전달해야 한다. 또한 각 페이지 마다 그에 관련된 작은 메세지를 알려주어야 한다.
10. 적수를 만들어라.
//선명한 대비 구조를 만들어 지금 발표가 악(?)과의 싸움임을 보여주어라. 적수가 없다면 이발표가 얼마나 필요한지 꼭 인식시켜 주어야 한다.
chapter 22 성공하기
1. 목표 지향적이다.
2. 감성 지능이 높다.
3. 엄청나게 똑똑하다.
4. 자기 분야의 전문성을 가지고 있다.
5. 놀랄 만큼 집요하면서도 예의를 갖출 줄 안다.
최고 자리에 올라간 사람의 공통점은 초창기에 그 분야에 뛰어들었다. 최신 트랜드와 경향을 파악할 필요가 있다. IT역사에서 무엇이 새롭게 태동하고 있는가
