Ship it 책중에서 12

1. 습관을 고르세요
2. 모래 상자 안에 머무세요
3. 필요한 거라면 체크인 하세요
4. 첫날에 빌드를 스크립트화 하세요
5. 어떤 컴퓨터에서라도 빌드가 되게 하세요
6. 지속적으로 빌드하세요
7. 지속적으로 테스트 하세요
8. 모두가 잊어버리를 사태는 피해야 합니다.
9. 제품을 작동시켜보세요-테스트를 자동화 해야 합니다.
10. 유연하고 많은 사람이 사용하는 테스트 장비를 이용하세요
11. 업무에 가장 적합한 도구를 사용하세요
12. 공개된 포멧을 사용해서 여러 도구를 통합하세요
13. 임계 경로 기술에 친숙해지세요
14. 목록에 따라 일하세요
15. 기술 리더가 알아서 하게 놔두세요
16. 일일 회의를 해서 진행방향을 수시로 바로 잡으세요
17. 나중에 라고 말해도 됩니다.
18. 항상 모든 코드를 재검토 하세요
19. 소프트웨어가 목표지, 순응이 목표는 아닙니다.
20. 그룹 전체가 아키텍트입니다.
21. 제품에서 사용하는 거라면, 여러분도 사용해야 합니다.
22. 가장 어려운 문제부터 해결하세요.
23. 캡슐화된 아키텍처야말로 확장성 있는 아키텍처입니다.
24. 보트가 움직이기 전에 보트를 조정할 수가 없습니다.
25. 테스트하기 전에는 다른 사람이 물려준 코드를 변경하지 마세요
26. 테스트 주도 리팩토링으로 테스트할 수 없는 코드를 깨긋이 정리하세요
27. 가짜 클라이언트로 최소한의 노력으로 최대한의 성과를 거둘 수 있습니다.
28. 변경된 코드를 지속적으로 테스트하세요
29. 모두에게 통하는 방법이어야 합니다.
30. 자주 통합하고, 지속적으로 빌드하고 테스트 하세요.
31. 동작하는 데모를 일찍 그리고 자주 전달하세요.
32. 여러분이 무서을, 왜 하고 있는지 공개 하세요.
33. 얼굴을 많이 마추칠수록 팀워크가 단단해집니다.
34. 고쳐야 하는 것만 고치세요
35. 파괴적인 우수한 업무처리기법은 진정한 업무처리기법이라 할 수 없습니다.
36. 밑에서부터 혁신해야 합니다.
37. 말만하지 말고 보여주세요
38. 관리층의 지지를 이끌어 내세요
39. 버그가 있는 곳을 테스트 하세요
40. 목록은 살아있는 문서입니다. 변화가 목록의 생명입니다.
41. 목록에 없다면, 그것은 프로젝트의 일부가 아닙니다.
42. 항상 피드백을 빨리 해주세요.

Ship it 책중에서 11

• 모두 통틀어

1. 목록

• 누구나 이용할 수 있게 하자.
• 우선 순위를 부여하자
• 예상 일정에 따르자
• 살아 있는 문서가 되어야 한다.

1. 기술리더

• 프로젝트의 기능 목록을 관리
• 개발자의 현재 작업과 상태를 추적
• 각 기능에 우선 순위를 매기는 일을 돕는다.
• 외부의 방해로 부터 팀을 보호

1. 일일회의

• 회의를 짧게 하자
• 세부 내역이 있어야 한다.
• 문제를 열거하되 되풀이 하지 말자

1. 코드검토

• 코드를 조금씩 검토하자
• 검토자는 한두 명만 있으면 된다.
• 자주 한다.
• 검토하지 않은 코드는 공포하지 않는다.

1. 코드 변경 통지

• 통지내역을 이메일로 보내고 통지 하세요
• 검토자의 이름을 열거한다.
• 코드를 변경하거나 추가한 목절을 열거한다.
• 용량이 지나치게 크지 않으면, 원본 파일이나 차이점 명세서를 포함시킨다

Ship it 책중에서 10

• 시작

1. 계획한 코드 검토 건이 어떤 건인지 모든 사람이 이해 해야함
2. 작은 코드 블럭 단위로 자주 검토
3. 몇 주씩 검토 하거나 수백 수천 줄의 변경 내역을 쌓아 놓지 말아야함
4. 처음얼마간은 선임 개발자가 코드검토에 매번 참석
5. 코드 검토는 가벼워야함
6. 코드변경 통지 시스템 도입
7. 팀 구성원의 참여 이전에 관리자의 지지를 유도

• 점검

1. 코드 검토가 무조건 통과 되서는 않됨
2. 코드 검토가 코드가 대대적으로 수정되는가
3. 코드 검토가 자주 이루어 지고 있는가 신속한 검토가 필요함
4. 검토자의 역할은 교대로 하고 있는가
5. 코드검토를 통해 배우는 것이 있는가

• 경고

1. 코드검토를 거의 하지 않음
2. 코드검토가 매번 고통 스러움
3. 코드검토를 싫어해서 코드 체크를 기피함
4. 코드 검토를 했던 구성원이 코드가 무슨일을 했는지 코드의 작성이유등을 모름
5. 신참 팀 구성원이 다른 신참 코드만 검토
6. 고참 팀 구성원이 다른 고참 코드만 검코
7. 모든 사람이 한사람에게 검토를 맡김

• 코드 통지

1. 통지는 규칙적이며 믿을만해야 한다.
2. 통지 서비스의 신뢰도가 높아야 한다.

Ship it 책중에서 9

• 시작

1.  모든 사람이 회의 형식을 알게 함
2.  모든 사람이 질문에 답함
3.  처음엔 느긋하게 시간을 제한
4.  회의는 같은시각, 같은 장소
5.  일일회의를 습관처럼 만듬
6.  일일회의 논의 주제를 웹 페이지나, 플로그에 기제
7.  한사람을 골라 발표

• 점검

1.  회의의 유요성
2.  매일 같은 시간 같은 장소에서 회의 진행
3.  회의를 열지 않으면 사람들이 불평하는가?

• 경고

1.  10분이상 사용
2.  한명이 전체 인원 만큼 시간을 소요
3.  서로를 비열하게 야유
4.  늦게 시작 되거나 늦게 끝나는 회의의 반복
5.  단순한 주장만 있고 알맹이가 없는 회의
6.  자신의 할일을 잊고 보고하지 않거나 두서가 없음

Ship it 책중에서 8

기술 리더의 책임

1. 팀이 나아갈 방향을 설정

2. 프로젝트의 기능 목록 관리

3. 기능 요구사항에 우선순위 부여

4. 정신을 산만하게 하는 외적 요소로 부터 팀원을 보호

점검

1. 팀 구성원이 무슨일을 하고 있는지 파악 여부

2. 5분내에 프로젝트 현 상황 개요 작성 가능 여부

3. 다음에 추가 할 기능을 5~10정도 인지

4. 우선순위가 높은 결함의 열거

5. 팀 구성원을 위해 해결할 가장 최근의 문제 인지

6. 해결할 중요한 이슈가 있는 경우 기술리더를 찾아오는가?

경고

1. 팀 구성원 각자가 업무 방향에 대한 큰 그림을 가지고 있지 않음

2. 기술리더가 나타나면 일이 중단됨

3. 팀의 성과를 가로챔

4. 문제를 해결하는데 실패 하거나, 더 심각한 문제를 유발

5. 업무 일정의 부정확한 예측

6. 팀 구성원의 업무 역량 파악이 부정확, 원한는 기술에 대한 미 인지

7. 팀원간의 충돌여부를 감지하지 못함

Ship it 책중에서 7

시작

1. 하루 통째로 잡아 모든 작업 목록을 작성

2. 일일 업무 목록이 있는 경우 공적적인 목록 사본으로 체계화

3. 기술리더에게 업무의 우선순위 요청 및 시간 예측값을 추가 할 수 있도록 지원 요청

4. 목록에성 우선 순위가 높은 항목 먼저 처리

5. 우선 순위가 낮은 항목을 상향해야 하는 경우 상황을 기록

6. 새로운 일을 모두 목록에 추가

7. 작업 완수시 해당 항목을 완료 목록으로 옮김

점검

1. 현재 작업이 모두 목록에 존재

2. 목록이 현재 작업을 정확이 묘사

3. 기술 리더나 고객이 목록 우선순위 부여에 협조 여부

4. 목록을 누구나 사용 가능 한가

5. 목록을 통한 다음 업무 결정

6. 목록의 신속한 갱신 및 발표 여부

경고

1. 너무 바빠 목록을 작업에 넣지 못함

2. 작업을 끝내는 일보다 목록을 갱신하는데 더 많은 시간을 소모

3. 개인용 목록에 있는 항목을 끝내는데 몇주 이상 소요

4. 목록에 일주일에 한번도 갱신 되지 않음

5. 목록에 적힌 우선순위가 진짜 우선 순위와 동일 하지 않음

6. 목록이 비밀로 유지되어 외부에 공개 할수 없음

7. 팀의 목록과 다른 버전이 공개 되어 있음

Ship it 책중에서 7

시작

1. 테스트 도구와 툴킷을 선택

2. 문제 영역에 테스트 추가

3. 테스트가 자동 빌드 시스템 내에서 동작

점검

1. 테스트 수트가 효율적인가 (버그를 잡아 내고 있나?)

2. 코드 적용 범위의 숫자는 얼마 인가? (시간이 지남에 따라 숫자가 커지는가?)

3. 테스트 제품의 안정성

4. 테스트 자동 실행 여부

5. 테스트 결과 통보 여부

6. 모든 사람이 테스트 추가 가능 여부

경고

1. 작동하지 않음

2. 어떤 문제도 잡아내지 못함

3. 너무 오래 실행

4. 유지보수에 엄청난 노력이 듬

Ship it 책중에서 6

점검

1. 다음에 출시할 기능 목록을 작성시 이 시스템이 첫

2. 제품에 대한 새로운 아이디어를 정기적으로 시스템에 기록

3. 제출한 기능 중 상당수가 받아 들여지지 않음 ( 기능 입력전에 선별 하고 있음)

4. 시스템을 통한 보고서가 지난 제품 버전의 새 기능을 목록을 생성

5. 이해관계자들의 기능 상태 파악 용이

경고

1. 새 기능이 추가 되지 않음

2. 모든것이 우선순위 1

3. 기능은 추가되는 구현은 되지 않음

4. 적절하지 않은 기능 추가

Ship it 책중에서 5

시작

1. 이슈 추적 시스템 선택

2. 테스트 시스템 구축 사용법을 익힘

3. 내부 사용자에게 퀵스타트 가이드 제공

4. 구축된 시스템에 새 이슈를 보관

5. 시간이 되면 이전 이슈를 새 시스템으로 이전

점검

1. 미해결의 최우선 목록 생성 여부

2. 지난주에 수정한 목록 생성 여부

3. 시스템이 해당 이슈를 수정한 코드 참조 가능 여부

4. 기술리더가 시스템을 통해 개발팀의 할일 목록 출력 가능 여부

5. 시스템에서 정보를 가져오는 방법의 기술지원팀 인지 여부

6. 이슈가 고쳐 졌을시 기술지원팀 이하 시스템에 관심있는 사람에게 통지 할수 있는지 여부

경고

1. 시스템을 사용하지 않음

2. 시스템에 작은 이슈들이 너무 많음

3. 이슈 관력 측정 자료가 팀 구성원을 평가 하는 자료로 사용됨

Ship it 책중에서 4

시작

1. 사용할 빌드 시스템 선택

2. 빌드 시스템을 돌릴 깨끗한 컴퓨터

3. 자동빌드 시스템을 설치 환경에 맞춰 설정

4. 설정 과정을 문서화

점검

1. 시스템 테스트 포함 여부

2. 시스템에 신경 쓰는 사람 존재 여부

3. 빌드가 깨지면 신속한 수정 여부

4. 합리적인 빌드시간 여부

경고

1. 자동 빌드가 자주 깨짐

2. 팀이 깨진 빌드를 무시

3. 빌드가 멈추고 누구도 인지 하지 않음

Ship it 책중에서 3

시작

1. 스크립트 작성하는동안 팀원 한명에게 수동으로 시스템 빌드 요청

2. 각 빌드 단계 정의

3. 빌드도구를 선택 빌드도구가 짐이 되면 다른선택사항을 다시 검토

4. 각 단계를 점진적으로 스크립트화, 수작업을 하나 하나 제거

5. 다양한 컴퓨터에서 스크립트를 동작

6. 팀원 누구나 스크립트를 통한 빌드가 가능한지 확인

제대로 사용?

1. 명령어 하나면 빌드

2. 소스 코드 관리 시스템 에서 코드를 받아 빌드

3. 어떤 컴퓨터라도 빌드

4. 외부환경에 의존하지 않고 빌드

경고

1. 빌드에 수작업단계 포함

2. 다른 컴퓨터에서 빌드시 스크립트 수정

3. 팀 원중 일부만이 빌드 스크립트를 수행

Ship it 책중에서 2

시작

1. scm 시스템 평가

2. scm 사용법 익히기

3. 퀵스타트 가이드 작성

4. 팀원에게 시스템

5. 코드와 지원파일을 임포트

6. 모든파일을 scm으로 관리

경고

1. 활동 없는 저장소 (사용되지 않는 저장소는 쓸모없는 저장소)

2. 완전하지 못한 저장소 (제품을 빌드하는데 필요한 파일의 일부만 갖고 있다면 제역할을 못함)

3. 느린접근 (파일 체크인/아웃이 오래 걸리면 사람들이 시스템을 사용하지 않음)

4. 잃어버리거나 손상된 파일이 존대

Ship it 책중에서 1

기술

기술리더 - 업무목록 - 코드검토 - 코드변경 통지 -일일회의

인프라스트럭처

버전관리 - 빌드스크립트 만들기 - 시속적인 빌드 - 이슈 추적하기 - 기능 추적하기 - 테스트 작성하고 돌리기

프로세스

시스템 객체 제안하기 - 인터페이스 제안하기 - 인터페이스 연결하기 - 함수구하기 - 리팩토링, 다듬기, 반복하기