“Ship It 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드“를 다시 읽었습니다.

새로 시작하는 과제에 개발과 함께 SCM, Process, SQE를 담당하기로 하였습니다.
Scrum 적용부터 제가 하고 싶은 것을 함께 적용할 기회를 가지게 되었습니다.
팀원들에게 어느 정도 호응도 얻었습니다. ^,.^;

그래서 과제를 진행하는데 있어 몇 가지 정리할 것이 있어 Ship It을 다시 읽게 되었습니다. 그래서 부록에 있는 Tip 조언 요약을 정리해 봅니다. 아래의 글에서 나중에 글들이 링크될 수 있습니다. 어떻게 인프라와 프로세스를 구축했고 어떻게 팀원들을 설득했으며 어떤 문제로 어려워하고 있는지를 이 글을 기준으로 시작하려고 합니다.

앞으로 재발행될 요지가 큰 포스트입니다.ㅎㅎ

- TIP 조언 요약 -

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. 항상 피드백을 빨리해 주세요.

Related posts:

1. Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

k16wire님께서 소개해 주신 “Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드“를 살펴 보고 오늘 장바구니에 담았습니다. (필요한 책 몇 권을 더 한꺼번에 주문하려고 기다리고 있습니다.)

k16wire님의 말씀처럼 책 목차만 보더라도 개발자나 프로젝트 리더에게 얼마나 필요한 지 알 수 있습니다.

[#M_목차 열기|목차 닫기| 도서목차

머리말
서문
1 서론
1.1 습관적인 탁월함
1.2 실용주의적 관점
1.3 로드맵
1.4 앞으로 나아가기
1.5 이 책을 어떻게 읽어야 하나?

2 도구와 인프라스트럭처
[1]. 모래 상자(Sandbox) 안에서 개발하기
[2]. 자산을 관리하세요
[3]. 빌드를 스트립트화하세요.
[4]. 자동으로 빌드하세요.
[5]. 이슈를 추적하세요.
[6]. 기능을 추적하세요.
[7]. 테스트 장비를 사용하세요.
[8]. 도구를 선택하는 방법
[9]. 실험하지 말아야 할 때

3 실용주의적 프로젝트 기술
[10]. 목록에 따라 일하세요.
[11]. 기술 리더
[12]. 매일 협력하고 의사소통하기
[13]. 코드를 모두 검토하세요
[14]. 코드 변경 통지 보내기
[15]. 모두 통틀어서

4 예광탄 개발
예광탄 개발
프로세스 상의 흔한 문제들
프로세스 정의하기
TBD는 어떻게 작동할까요
시스템 객체를 정의하세요
협동해서 인터페이스 정의하세요
인터페이스 스텁을 작성하세요
계층끼리 대화할 수 있게 만드세요
스텁에 기능적 코드를 채워 넣으세요
리팩토링하고 다듬으세요
간단한 사례
예광탄 개발 방법론 홍보하기
이렇게 시작하세요
이렇게 하고 있다면 제대로 하고 있는 겁니다
경고 신호

5 일반적인 문제와 해결방법
[16]. 도와주세요! 코드를 인수 받았어요.
[17]. 테스트할 수 없는 코드를 테스트하기
[18]. 기능에 문제가 계속 발생합니다.
[19]. 테스트? 우리는 더 이상 테스트를 활용하지 않습니다.
[20]. 하지만 저는 된다구요!
[21]. 코드를 통합할 때 골치 아픕니다.
[22]. 제품을 안정적으로 빌드하지 못합니다.
[23]. 고객이 불만을 표출합니다.
[24]. 불한당 개발자가 있습니다.
[25]. 관리자가 불만스러워 합니다.
[26]. 팀이 협동을 못합니다.
[27]. 핵심적인 부분에 대한 “내부의 지지”를 얻지 못합니다.
[28]. 새로운 실천방법이 도움이 안 됩니다
[29]. 자동화된 테스트가 없습니다.
[30]. 우리는 신참 개발자들이고 이끌어줄 사람이 없습니다.
[31]. “죽음의 행진” 프로젝트에 참여하고 있습니다.
[32]. 피쳐 크리프(Feature Creep) 현상이 일어납니다.
[33]. 프로젝트가 끝날 기미가 안 보입니다.

A 조언 요약
B 소스 코드 관리
C 빌드 스크립트 도구
D 지속적인 통합 시스템 (Continuous Integration System)
E 이슈 추적 소프트웨어
F 개발 방법론
G 테스트 프레임워크
H 추천 도서 목록
H.1 참고 문헌_M#]

“프로젝트에 도움이 되는 거라면 무엇이든 실험해보고 받아들이라”는 저자의 말이 최근의 저의 모습인 것 같습니다. 아직은 윗 분들이 딴지?를 걸지는 않는데… 뭔가 개선되는 것이 보이지 않으면 분명히 제지하겠지요? ㅡ,.ㅡ;

저는 Agile이나 특정 프로세스를 신봉?하거나 선호하는 것은 아닙니다. 현재 처한 모든 상황에 가장? 합리적이고 도움이 되는 것은 무엇인지를 빨리 집어 내어 실천 할 수 있는 프로세스와 환경을 꾸미는 것이 목표이자 꿈? 입니다. 그러한 문화를 만드는 일에도 앞장서고 싶습니다.

아직 공부 중이고 내공이 부족한 관계로 현재 프로젝트에 많은 개선을 이루어 내고 있지는 못하지만, 언젠가는 변화의 첫 걸음 시작했다고 자신있게 이야기 할 날을 기대하면서 내공 증진에 힘써 봅니다.

프로젝트에 도움이 되는 거라면 무엇이든 실험해보고 받아들이라는 자레드와 윌의 유연한 사고 방식은 자칫 교조주의적으로 흐르기 쉬운
특정 프로세스 선호론과는 다릅니다. 무엇이 옳고 그른지보다는 무엇이 실용주의적인지 이 책을 통해 알아보세요.
 - 강컴 도서 특징 中

책의 각 섹션을 다 읽고 나면, 잠시 멈추고 5분 정도 투자해서 오늘 하는 일에 각 개념을 적용할 방법을 찾으려 애써보세요.
잊지 마세요. 애써 생각하지 않아도 나오는 가장 쉬운 해답은 ‘그건 할 수 없어’라는 말입니다. 그보단 더 노력하세요! 새
개념을 적용할 방법을 찾지 못했다면, 동료를 붙잡고 물어보세요. 자신의 눈으로 보지 못한다면, 다른 사람의 눈으로 보면 됩니다.
동료의 경험을 활용하는 법을 배우는 것은 어느 분야에서든 장인의 보증수표입니다. -본문 중에서

이것은 훌륭한
생각입니다. 하지만 최고이면서 똑똑한 사람 중에서도 정말 최고인 사람과 직접 만나기는 힘듭니다. 마틴 파울러, 켄트 벡, 그리고
실용주의 프로그래머들과 같은 사람은 우리 대부분에게 시간을 내주지 못합니다. 하지만 그 사람들의 책, 기사, 그리고
프리젠테이션은 그럴 수 있습니다. 그러니 책을 읽으세요. 한 달에 한 권이라면 그렇게 힘들진 않습니다. 하지만 거기서 멈추진
마세요. 새로운 프로그래밍 언어를 배우거나 다른 개발 프로세스를 연구해보세요. 그리고 뭔가를 배우는 중간이나 책을 읽는
와중에도, 새로운 아이디어를 지금 업무에 적용할 방법을 찾아보세요. 새 아이디어를 본업에 적용해보세요. 그렇게 하면 회사를
개선시키는 데 도움이 될 뿐만 아니라 (더 중요한 일인데) 여러분 자신 또한 개선시키게 됩니다. -본문 중에서

주변여
건과 프로세스를 분석하고 비판하면 약점을 찾아낼 수 있습니다. 어쩌면 지금 프로젝트를 개선시키는 데 도움이 될지도 모릅니다.
아니면 다음 프로젝트에서라도요. 어떻게 되든 생각하는 법을 새로 배우게 될 텐데, 여러분이 어디서 일하든 쓸모있을 겁니다.
대부분의 사람은 이런 개념을 결코 배우지 못하고, 훨씬 적은 수의 사람만 잘 해냅니다. -본문 중에서
- 알라딘 책 소개 中

최고이면서 똑똑한 사람 중에서도 정말 최고인 사람과 직접 만나기는 힘듭니다. 마틴 파울러, 켄트 벡, 그리고 실용주의
프로그래머들과 같은 사람은 우리 대부분에게 시간을 내주지 못합니다. 하지만 그 사람들의 책, 기사, 그리고 프리젠테이션은 그럴
수 있습니다. 그러니 책을 읽으세요. 한 달에 한 권이라면 그렇게 힘들진 않습니다. 하지만 거기서 멈추진 마세요. 새로운
프로그래밍 언어를 배우거나 다른 개발 프로세스를 연구해보세요. 그리고 뭔가를 배우는 중간이나 책을 읽는 와중에도, 새로운
아이디어를 지금 업무에 적용할 방법을 찾아보세요. 새 아이디어를 본업에 적용해보세요. 그렇게 하면 회사를 개선시키는 데 도움이
될 뿐만 아니라 (더 중요한 일인데) 여러분 자신 또한 개선시키게 됩니다.
- 저자의 말

Related posts:

1. [Ship it] Tip 조언 요약
2. 소프트웨어 테스팅 법칙 293가지
3. 프로젝트를 성공시키는 지름길「테스트 용이성」