실용주의 프로그래머 - 10 (TIL)

범위

~9장 실용주의 프로젝트

내용

요약

• 내가 이걸 만들었고, 내 작품의 품질을 보증합니다.

9장. 실용주의 프로젝트

실용주의 팀

실용주의 팀은 작다. 구성원이 대략 10~12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다. 모두가 서로 잘 알고, 신뢰하며, 의존해야한다

작고 안정적인 팀을 유지하라

깨진 창문을 없애라

팀 전체가 깨진 창문을 용납하지 않아야 한다. 반드시 제품의 품질에 책임을 져야한다.

품질은 팀원 모두가 제각기 기여할 때만 보장된다.

삶은 개구리

팀은 개인보다 더 삶은 개구리가 되기 쉽다. 적극적으로 환경 변화를 감시하도록 권장하라

여러분의 지식 포트폴리오를 계획하라

성공을 원하는 팀이라면 자신들의 지식과 기술에 투자하는 것을 고려해야한다.

• 구형시스템유지보수
• 프로세스 회고와 개선
• 새로운 기술 탐험
• 학습 및 기술 닦기

실현하려면 계획하라

팀의 존재를 소통하라

외부 사람들에게 무뚝뚝하고 과묵해 보이는 프로젝트 팀이야 말로 최악이다. 그런 팀의 회의는 아무런 체계가 없고 침묵만 가득하다. 이메일과 프로젝트 문서는 엉망진창이다. 문서마다 생김새도 제각각이고, 서로 다른 용어를 사용한다.

훌륭한 프로젝트팀은 뚜렸한 특성이 있다. 모든 사람이 좋아할 만한 잘 준비된 퍼포먼스를 보게 될것이며, 문서는 깔끔하고 정확하며 일관적이다.

반복하지마라

좋은 의사소통이란 즉각적이고 매끄러운 것을 말한다.

팀예광탄

예광탄 접근 방법을 사용하면 기능의 아주 조그만 부분을 빠르게 개발 할 수 있다.

또한 즉각적인 피드백을 받을 수 있으며, 쉽게 바꾸고 조율할 수 있는 환경이 만들어진다.

코드를 끝에서 끝까지 점진적이고 반복적으로 쌓아 올릴 수 있는 팀을 만들어라

자동화

멈춰야 할 때를 알라

코코넛만으로는 부족하다

유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라

진짜 목표

필요할 때마다 출시한다는 것이 끊임 없이 1분에 한 번씩 배포한다는 뜻은 아니다. 사용자가 필요로 할 때마다, 사업적으로 배포가 의미 있을때마다 배포하는 것이다.

실용주의 시작 도구

• 버전관리
• 회귀 테스트
• 전체 자동화

버전관리 시스템으로 빌드, 테스트, 릴리스를 운용하라

가차 없고 지속적인 테스트

일찍 테스트 하고, 자주 테스트하라, 자동으로 테스트하라 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다.

• 단위 테스트
• 통합 테스트
• 유효성 평가 및 검증
• 성능 테스트
• 테스트를 테스트 하기

버그를 심어 놓고 테스트를 테스트하라

• 철저한 테스트
• 속성 기반 테스트

그물 조이기

버그는 한 번만 잡아라.

전체 자동화

수작업 절차를 사용하지 말라

사용자를 기쁘게 하라

이 프로젝트가 끝나고 한 달(혹은 일년이라든지) 후에 우리가 성공했는지 어떻게 알 수 있을까요?

• 모든 팀 구성원이 사용자가 기대하는 바를 완전히 이해해야 한다.
• 결정을 내릴 때면 어떤 선택이 사용자의 기대에 더 가깝게 가는 길인지 생각하라.
• 사용자 요구 사항을 비판적으로 분석하라
• 프로젝트를 진행하면서도 계속 사용자의 기대에 대하여 생각하라.

오만과 편견

자신의 작품의 서명하라

마치며

내가 이걸 만들었고, 내 작품의 품질을 보증합니다.