성공적인 소프트웨어 개발을 위해 반드시 알아야 할 57가지 법칙

제1부 1995
들어가기
생각해보자
프로젝트의 각 단계들

전초전
조직
닭장에서의 QA?
그런데, 이건 누가 디자인한 거야?
#1: 비전을 공유해라
#2: 팀이 게임에 몰입하게 한다
#3: 여러 개의 릴리스 기술 계획을 만든다
#4: 무책임한 비난을 하지 않는다
대머리가 되는 죽음의 행진
#5: 정찰을 한다
#6: 비율에 신경 쓴다
#7: 기능 팀(Feature Team)을 사용한다
#8: 프로그램 관리자를 사용한다
집단 심리
#9: 권위 자체가 되어야지, 권위적인 인물이 되어서는 안 된다
경쟁
소 인류학(A Little Anthropology)
소프트웨어 경쟁
#10: 혼자라고? 경쟁자 없는 시장은 없다
#11: 막상막하? 기능 대결에서 벗어난다
#12: 뒤쳐져 있는가? 새로운 기능으로 더 자주 출시한다
#13: 앞서고 있는가? 절대로 뒤는 돌아보지도 말아라
#14: 숨쉬고 살자
고객
단순 구매 모델
#15: 고객을 흥분시킨다
#16: 최적점(sweet spot)을 찾는다
#17: 영업이 아니라 관계구축이 중요하다
#18: 신속하게 사이클을 순환한다
디자인
#19: 위대함을 추구한다
#20: 주제를 확실하게 얘기한다
#21: 종속성을 최소화한다
#22: 신의 뜻을 거슬리지 말라
#23: 무의미한 플랫폼 지원을 줄인다
#24: 디자인 시점에서 시간을 디자인한다
개발
#25: 지시를 받아들이지 않는다
#26: 이제 놀러 가자

중반전(Middle Game)
#27: 의사처럼 행동한다
#28: 기능, 리소스, 시간이라는 삼각형을 기억할 것
#29: 모르는 것은 그대로 인정한다
#30: 어둡게 만들지 않는다
#31: 다른 사람의 상황을 안다
#32: 빌드를 한다면 결국에는 출시할 것이다
#33: 알려진 상태를 유지한다
전진하기 위해 여러분이 해야 할 일
#34: ZD 마일스톤을 사용한다
#35: 모든 사람이 ZD 마일스톤에 도달하기 전에는 아무도 도달한 것이 아니다
#36: 모든 마일스톤은 비난 없는 사후 검토를 받아야 한다
#37: 마일스톤의 정의와 정신을 고수한다
#38: 규범을 만든다
#39: 마일스톤을 지나치게 세분화시키지 않는다
#40: 모든 작은 마일스톤은 자신만의 의미(이야기)를 가진다
#41: 자연스러운 마일스톤을 모색한다
#42: 뒤쳐지되, 낙오되지는 말라
#43: 나쁜 날짜끼리 바꾸지 않는다
#44: 일정지연 후에는, 어떻게 해서라도 다음 마일스톤을 지킨다
#45: 일정지연을 잘 활용하도록 한다
#46: 숲을 본다
#47: 세상은 변한다, 여러분도 변해야 한다

출시 모드
출시 모드: 시작
출시 모드: 전환
출시 모드: 종료
#48: 최소한 하나 정도의 신성모독 행위를 한다
#49: 베타에서 변경해서는 안 된다
#50: 베타는 나선식 개발을 위한 것
#51: 냉정하게 구원순위를 정한다
#52: 묽은 젤리는 한 번에 흔들지 않는다

제품 출시
#53: 멋진 이야기를 가지고 경쟁한다
#54: 멋진 이미지를 만든다
최종 결론

부록: 좋은 사람 고용하고 유지하기
똑똑한 사람을 고용하기
좋은 사람들이 일할 곳을 마련하기
경주마는 달려야 한다
초과달성자는 격려가 필요하다
소프트웨어 개발 리더를 위한 리소스 목록

제2부 2006
새로운 황금 규칙
#55: 완벽한 보스가 되도록 한다
#56: 보스는 여러분의 가장 중요한 고객이다
더 좋은 방법
보스를 바라보는 방법의 변화
#57: 상납세(lumber tax)를 지불하고 알파 몫을 찾는다
알파(또는 알파 에너지, Alpha Energy)

핵심 시스템 V. 3.0의 요소들
비전 공유를 향한 네 단계
1부: 체크인의 요소
2부: 결정자의 요소
3부: 일체감의 요소들
4부: 공유 비전의 요소들

핵심 프로토콜 V. 3.0
핵심 약속 실행(Commitments)
핵심 프로토콜
통과 (통과취소, Unpass)
체크인
체크아웃
도움 요청하기
프로토콜 확인
의도 확인
결정자
해결
완전 게임
개인적 일체감
검사

찾아보기