“Ship It 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드“를 다시 읽었습니다.
새로 시작하는 과제에 개발과 함께 SCM, Process, SQE를 담당하기로 하였습니다.
Scrum 적용부터 제가 하고 싶은 것을 함께 적용할 기회를 가지게 되었습니다.
팀원들에게 어느 정도 호응도 얻었습니다. ^,.^;
그래서 과제를 진행하는데 있어 몇 가지 정리할 것이 있어 Ship It을 다시 읽게 되었습니다. 그래서 부록에 있는 Tip 조언 요약을 정리해 봅니다. 아래의 글에서 나중에 글들이 링크될 수 있습니다. 어떻게 인프라와 프로세스를 구축했고 어떻게 팀원들을 설득했으며 어떤 문제로 어려워하고 있는지를 이 글을 기준으로 시작하려고 합니다.
앞으로 재발행될 요지가 큰 포스트입니다.ㅎㅎ
- TIP 조언 요약 -
- 습관을 고르세요.
- 모래 상자 안에 머무세요.
- 필요한 거라면 체크인하세요.
- 첫날에 빌드를 스크립트화 하세요.
- 어떤 컴퓨터에서라도 빌드가 되어야 합니다.
- 지속적으로 빌드하세요.
- 지속적으로 테스트하세요.
- 모두가 잊어버리는 사태는 피해야 합니다.
- 제품을 작동시켜보세요 – 테스트를 자동화하세요.
- 유연하고 많은 사람이 사용하는 테스트 장비를 사용하세요.
- 업무에 가장 적합한 도구를 사용하세요.
- 공개된 포맷을 사용해서 여러 도구를 통합하세요.
- 임계 경로 기술에 친숙해지세요.
- 목록에 따라 일하세요.
- 기술 리더가 알아서 하게 놔두세요.
- 일일 회의를 해서 진행 방향을 수시로 바로 잡으세요.
- “나중에”라고 말해도 됩니다.
- 항상 모든 코드를 재검토하세요.
- 소프트웨어가 목표지, 순응이 목표는 아닙니다.
- 그룹 전체가 아키텍트입니다.
- 제품에서 사용하는 거라면, 여러분도 사용해야 합니다.
- 가장 어려운 문제부터 해결하세요.
- 캡슐화된 아키텍처야말로 확장성 있는 아키텍처입니다.
- 보트가 움직이기 전엔 보트를 조정할 수가 없습니다.
- 테스트하기 전에는 다른 사람이 물려준 코드를 변경하지 마세요.
- 테스트 주도 리팩토링으로 테스트할 수 없는 코드를 깨끗이 정리하세요.
- 가짜 클라이언트로 최소한의 노력으로 최대의 성과를 거둘 수 있습니다.
- 변경되는 코드를 지속적으로 테스트하세요.
- 모두에게 통하는 방법이어야 합니다.
- 자주 통합하고, 지속적으로 빌드하고 테스트하세요.
- 동작하는 데모를 일찍 그리고 자주 전달하세요.
- 여러분이 무엇을, 왜 하고 있는지 공개하세요.
- 얼굴을 많이 마주칠수록 팀워크가 단단해집니다.
- 고쳐야 하는 것만 고치세요.
- 파괴적인 ‘우수한 업무처리기법’은 진정한 의미의 업무처리기법이라 할 수 없습니다.
- 밑에서부터 혁신해야 합니다.
- 말만 하지 말고 보여주세요.
- 관리층의 지지를 이끌어내세요.
- 버그가 있는 곳을 테스트하세요.
- 목록은 살아있는 문서입니다. 변화가 목록의 생명입니다.
- 목록에 없다면, 그것은 프로젝트 일부가 아닙니다.
- 항상 피드백을 빨리해 주세요.
