25836
58
64
제목 : 도와주세요 팀장이 됐어요.
저자 : 신승환 - root@talk-with-hani.com
== 방법론 ==
* 언제나 베일에 가려져있는 요구사항 : 소프트웨어의 본질 어쩔수 없다.
* 스탠드업 미팅 -> (인지부조화 : 행동에 따라 믿음을 바꾼다) -> 진행할 계획을 팀원들에게 이야기 함으로서 실천을 동반한다.
* 지속적인 통합 continuous integration : 기능에 대한 단위 테스트 가 필수다, 그 이후 시스템 테스트(기능 테스트)가 뒷 따라야 한다.
* 간략스토리 카드 : 파워포인트 화면 설계서를 축소 프린트(한장에 여섯페이지) 하여 오려낸 후 유사한 내용과 그룹핑 한다. 해당 결과물을 모두가 보이는 장소에 다음의 분류로 게시한다(todo, doing, done)
* TDD 는 설계를 고려 하는것이 핵심 , 개발자가 목표 지향적이 된다
* 개발 범위 및 체크시간을 짧게 가져가서 %완료의 불확실성을 줄여라
* 언제나 베일에 가려져있는 요구사항 : 소프트웨어의 본질 어쩔수 없다.
== 협상 ==
* 다양한 가치관의 충돌 어떻게 통합하나 : 정치력 = 무조건 따르기보다는 프로젝트가 올바르게 가도록 긍정적인 생각속에서도 합리적인 선택
* 협상은 모두의 이익이다, 따라서 최종적으로 거절할 수 도 있다. 먼저 경청하여 핵심정보를 파악하고 결정하라.
* 무조건 거부 하거나, 들어주지 말아라. 장기적으로 협상의 범위를 좁힌다. 정량적인 정보를 수집하여 판단
* 때쓰는 고객 대처 : 못된아이 달래는 심정으로, 최대한 사실을 기반으로 설명. 그래도 때쓰면 정치이슈. 정치 이슈는 정치로 해결(차상위 계급자를 통해)
== 관리와 병행된 개발 ==
* 핵심경로 : 가장 오래걸리는 선후행 작업
* 관리자는 핵심경로를 피하여 개발 업무를 할당 한다.
* 관리자는 팀원의 핵심경로를 파악하여, 짝 프로그래밍 및 태스크 할당 변경 등으로 조절
== Humanity ==
* 자애로움에서 악랄함으로 변신하는것은 물이 아래에서 위로 흐르는 것 만큼 부자연 스러운 일이다
* 해결책을 찾기 위한 "왜?"를 사용하라 비난이 없는 "왜?"를 사용하라 하지만 팀의 분위기가 받아 들여지기 어렵다면, 표현을 달리하라.
* 다양한 관점을 보라. 경험은 때로는 더 낳은 해결책을 찾는것을 방해한다. 팀원과 다양한 관점에서 해결책을 찾아라
* 관계를 중요시하라 나의 의견이 상대방의 감정필터에 걸린다면 의견의 정당성은 뒷 전이 된다.
* 우루루 몰려 다니는 동내축구 보다는 A매치의 프로선수 같이 자기몫을 하고, 또한 팀의 전체 이익을 위해 노력하는 팀
* 관리자의 힘은 팀원과의 작은 신뢰로 쌓여간다.
* 예지력, 통찰력, 회고력 : 계획과 현실이 어긋나는 시점은 배움의 시작 이다.
* 프로젝트의 진정한가치는? : 표현하지 않는다고 욕망이 없지 않다. 어떤 사람은 다른 사람과의 관계를 더 중요하게 생각한다. 또 어떤 사람은 의사결정에 주도적이고 자기가 좋아하는 것을 관철 시킨다.
== Good Team ==
* 실수을 인정하는 조직이 성장하는 조직.
* 생산성에 문제를 잃으키는 원인 :
: 꼭 할일을 안 한다
: 하지 않아도 될 일을 많이 한다
: 업무 시간 동안 집중하지 않는다
* 0.5man month 는 존재 하지 않는다
: 범위측정이 쉽지않다
: 컨텍스트 스위칭이 쉽지 않다
* 프로젝트가 할당 되면 팀원은 부분 최적화에 몰두 한다. 하지만 관리자는 전체를 봐야한다
* 관리자는 촉매 : 촉매는 자신을 감소 시키지 않고 특정한 현상이 더 잘 되도록 돕는 물질
* 콘웨어의 법칙 : 시스템 설계조직은 자신들의 조직 사이에 의사소통 구조를 모방한 형태의 설계를 만들곤 한다
== 팀이란? ==
* SI :
* Solution :
* Service :
* 24/7 RM :
저자 : 신승환 - root@talk-with-hani.com
== 방법론 ==
* 언제나 베일에 가려져있는 요구사항 : 소프트웨어의 본질 어쩔수 없다.
* 스탠드업 미팅 -> (인지부조화 : 행동에 따라 믿음을 바꾼다) -> 진행할 계획을 팀원들에게 이야기 함으로서 실천을 동반한다.
* 지속적인 통합 continuous integration : 기능에 대한 단위 테스트 가 필수다, 그 이후 시스템 테스트(기능 테스트)가 뒷 따라야 한다.
* 간략스토리 카드 : 파워포인트 화면 설계서를 축소 프린트(한장에 여섯페이지) 하여 오려낸 후 유사한 내용과 그룹핑 한다. 해당 결과물을 모두가 보이는 장소에 다음의 분류로 게시한다(todo, doing, done)
* TDD 는 설계를 고려 하는것이 핵심 , 개발자가 목표 지향적이 된다
* 개발 범위 및 체크시간을 짧게 가져가서 %완료의 불확실성을 줄여라
* 언제나 베일에 가려져있는 요구사항 : 소프트웨어의 본질 어쩔수 없다.
== 협상 ==
* 다양한 가치관의 충돌 어떻게 통합하나 : 정치력 = 무조건 따르기보다는 프로젝트가 올바르게 가도록 긍정적인 생각속에서도 합리적인 선택
* 협상은 모두의 이익이다, 따라서 최종적으로 거절할 수 도 있다. 먼저 경청하여 핵심정보를 파악하고 결정하라.
* 무조건 거부 하거나, 들어주지 말아라. 장기적으로 협상의 범위를 좁힌다. 정량적인 정보를 수집하여 판단
* 때쓰는 고객 대처 : 못된아이 달래는 심정으로, 최대한 사실을 기반으로 설명. 그래도 때쓰면 정치이슈. 정치 이슈는 정치로 해결(차상위 계급자를 통해)
== 관리와 병행된 개발 ==
* 핵심경로 : 가장 오래걸리는 선후행 작업
* 관리자는 핵심경로를 피하여 개발 업무를 할당 한다.
* 관리자는 팀원의 핵심경로를 파악하여, 짝 프로그래밍 및 태스크 할당 변경 등으로 조절
== Humanity ==
* 자애로움에서 악랄함으로 변신하는것은 물이 아래에서 위로 흐르는 것 만큼 부자연 스러운 일이다
* 해결책을 찾기 위한 "왜?"를 사용하라 비난이 없는 "왜?"를 사용하라 하지만 팀의 분위기가 받아 들여지기 어렵다면, 표현을 달리하라.
* 다양한 관점을 보라. 경험은 때로는 더 낳은 해결책을 찾는것을 방해한다. 팀원과 다양한 관점에서 해결책을 찾아라
* 관계를 중요시하라 나의 의견이 상대방의 감정필터에 걸린다면 의견의 정당성은 뒷 전이 된다.
* 우루루 몰려 다니는 동내축구 보다는 A매치의 프로선수 같이 자기몫을 하고, 또한 팀의 전체 이익을 위해 노력하는 팀
* 관리자의 힘은 팀원과의 작은 신뢰로 쌓여간다.
* 예지력, 통찰력, 회고력 : 계획과 현실이 어긋나는 시점은 배움의 시작 이다.
* 프로젝트의 진정한가치는? : 표현하지 않는다고 욕망이 없지 않다. 어떤 사람은 다른 사람과의 관계를 더 중요하게 생각한다. 또 어떤 사람은 의사결정에 주도적이고 자기가 좋아하는 것을 관철 시킨다.
== Good Team ==
* 실수을 인정하는 조직이 성장하는 조직.
* 생산성에 문제를 잃으키는 원인 :
: 꼭 할일을 안 한다
: 하지 않아도 될 일을 많이 한다
: 업무 시간 동안 집중하지 않는다
* 0.5man month 는 존재 하지 않는다
: 범위측정이 쉽지않다
: 컨텍스트 스위칭이 쉽지 않다
* 프로젝트가 할당 되면 팀원은 부분 최적화에 몰두 한다. 하지만 관리자는 전체를 봐야한다
* 관리자는 촉매 : 촉매는 자신을 감소 시키지 않고 특정한 현상이 더 잘 되도록 돕는 물질
* 콘웨어의 법칙 : 시스템 설계조직은 자신들의 조직 사이에 의사소통 구조를 모방한 형태의 설계를 만들곤 한다
== 팀이란? ==
* SI :
* Solution :
* Service :
* 24/7 RM :
"독후감" 카테고리의 다른 글
- 도와주세요 팀장이 됐어요. 2009/04/28
- 글쓰기의 공중부양 2008/07/25
- 프로그래밍 면접 이렇게 준비한다 2008/07/25
- 애자일 프랙티스 2008/07/25
- 열씨미와 게을러의 리눅스 개발 노하우 탐험기 2008/07/25
- Head First Design Patterns 2008/07/25
- 실용주의 프로그래머 2008/07/25
댓글을 달아 주세요