"린과 애자일 개발"이라는 책에 대한 리뷰. 본 책은 3번 이상 애자일 방법론을 통한 프로젝트 수행자에게는 지금까지 해온 길에 대해서 다시금 생각할 기회를 줄 것이다. 처음으로 애자일 방법론을 접하는 이들에게는 현재 하고 있는 것이 어떤 생각에서 유래된 것이며, 지켜야할 사상이 어떤 것인지 알려줄 것이다.

1. Review.
2012년 초판인데,
완전 오래된 책 같은.
표지부터 활자, 번역까지.
그런데 오히려 통찰력이 간혹 엿
보이는 책

2. 목차
도구 측면에서 기술된 내용들.
각종 스크럼 책들과 유사한 면들이 있다.
그래도 인사평가에 대한 새로운 관점과 같은
급직적이면서도 독특한 관점 이야기도 포함됨.
이 책이 큰 의미를 가지는 부분.
형식에 앞서서, 유래의 근원에 접근,
우리가 이루고자 했던 정신/사상을 다시 환기
이 부분 중심으로 책 리뷰 진행 예정.

3. 개선을 향한 끝 없는 실험들.
Agile, Lean, XP, Scrum 이 모든 것은 개선을 위한 것.

4. 시스템적 사고를 해보자!

5. Watch Your Thoughts, They Become Words;
Watch Your Words, They Become Actions;
Watch Your Actions, They Become Character;
Watch Your Character,
For It Becomes Your Destiny.
사고 방식에 집중하자.

6. 도요타 좌우명: 좋은 생각이 좋은 제품을 만든다.
➔ 대규모 시스템은 단순하지 않다.
➔ 행동은 의도하지 않은 결과들을 발생을 시킨다.
➔ 문제의 원인은 단순히 하나가 아니다.
➔ 전체적 해결안을 도출하지 않으면, 부분은 일시적 향상되나 전
체적으로는 오히려 퇴보를 한다.
생각을 잘 해야 한다.
시스템 역학, 멘탈 모델, 원인 분석, 국지적 최적화 인지.

7. 생각을 다 같이 해서,
놓칠 수 있는 관계들을 발견해 나가자.
이를 부담감 없이 명시화 하기 위해서,
다이어그램을 화이트보드에 그리자.
시스템 역학: 인과루프 다이어그램.
예시 상황.
높은 기능 구현 속도를 얻기 위해서, 개발자 수를 늘리자.

8. 사람들 의견을 모아서, 문제를 가시화하면
문제 뒤에 숨어있는 사실들을 발견할 수 있다. - 시스템 역학 보기
역 방향 도모임시 대응
극한 효과

9. 상황을 봤으면 숨겨진 가정들까지 찾아보자.
상황에 대한
시스템 역학 확인
숨겨진 가정 발견 자기 반성 사고

10. Stop and Fix
1. 문제를 보면 멈춰라.
2. 진짜 문제를 발견하기 위해서는 근본 원인을 분석하라.
3. 수정과 개선에 도움이 되도록,
프로세스 변경 경험을 공유하라.
from 토요타 “멈추고 수정하라" 문화
도움이 되는 도구
1. 어골도 (fishbone, Ishikawa)
2. 5 Whys
자동차 공장에서 멈춘다는 것의 의미는 상상 이상의 행동이다. 빨간 버튼 이야기.

11. 국지적 최적화를 경계하라.
조직 내부 활동에서 가장 경계가 필요한 부분
그만큼 가장 흔하게 저지르는 실수
본 문제를 해결하는 가장 중요한 방향은 전사최적화를 가장 우선 기준으로 삼는 것.
예) “고객이 행복하게 도와주는가?”라는 것을 모든 판단으로.

12. 국지적 최적화 예를 통한 공감.
나의 노력이 전체에 도움이 되는 방향인지를 매번 생각하자.
경우 따라, 나의 최선이 단지 나만을 위한 최선일 수도 있다.

13. 린 사고 방식에 다시 빠져 보자.

14. 린은 도구나 낭비 제거가 아닌 사상이다.
요약: 자발적 끊임없는 개선

15. 다시 한 번!
린 사고를 칸반, 큐 관리 또는 다른 도구로 의미를 축소하는 것
은 민주주의를 단지 투표로 의미로 축소하는 것과 같다. 투표는
좋은 것이지만, 민주주의를 투표라고 하면 민주주의 개념은 더
희미해지고 이해하기 어려워진다.

16. 생각의 구조화
형식 신봉 금물
세부 사항은 책 참고.
세부 내용에서 Scrum 방식
에서 취하고 있는 방식의 사
상을 느낄 수 있음

17. 제품 개발 측면에서 큐?
WIP 큐 역시 큐이며, 이들은 문제를 야기한다.

18. 큐는 문제이다. 왜?
● 투자 수익이 현실화되지 않는 것에 대한 투자가 된 것이다.
○ 현금화 되지 전인 투자를 상징.
○ 명세서, 설계도 등은 수익 발생되기 전이다.
○ 폐기가 될 수 있다.
● 불량/위험이 숨기거나, 복제하게 된다.
○ 큐에 있는 항목들은 잠재적 위험 요소들이며,
그 위험은 후속 작업에 영향을 줄 가능성이 높다.
○ 예를 들어, 통합되지 않은 코드, 테스트 전인 코드
● 변화 (제거/추가)에 대한 대응 능력을 떨어트린다.
○ 기존 투자에 대한, 냉정한 실패 선언은 힘들다.
○ 실패 비용 최소화를 위해서, 우선 큐를 비우려 한다.
○ 예를 들어, 바뀐 시장 상황에 대응 못 하는 기획서.

19. 큐 문제를 해결하기 위해서는
● 일반적인 접근 이면서 아쉬운 접근: 큐를 줄이자.
○ 큐에 쌓이는 내용을 줄이는 방법
○ 병목이 되는 부분을 발견, 이 부분을 해결하자.
■ 병목 부분을 줄이면, 다른 병목 발생 가능.
○ 업무 단위를 줄이고, 가변성을 줄이고, WIP 수 줄이기.
● 좀 더 적극적이면, 혁신적인 접근: 큐를 없애자.
○ 업무를 이관하지 않고, 기능을 완성할 수 있다면.
○ 기획, 분석, 프로그래밍 절차적 수행이 아닌.
○ 모든 작업이 병렬/CrossFunction하게 처리.
○ 멀티태스킹은 피한다. 가능하면 최소량 WIP 유지.
○ 스크럼이 추구하는 작업 방식

20. 작업 관리: 큐 이론.

21. 작업양에 대한 가설
현재 당신 업무 할당량은 70%이다.
당신의 업무가 100% 할당되지 않았음으로,
따라서 더 많은 일을 할당해야 한다.
30% 추가 할당을 해도, 업무 속도는 문제가 없다.
고속도로에는 차량이 100% 차기 전까지는 정체가 발생하지 않을 것이다.

22. 현실은 비선형계
세상은 비선형적이며, 확률적이다.

23. 직관과 반대되는 현상
실제 처리 가능한 양 보다 많은 양에 대한 처리를 강요받고,
특히 처리량만을 기준으로 평가를 하게 되면,
사람들은 일 처리 자체에만 집중.
품질, 개선에 대한 생각은 마음 속에서 사라지게 된다.

24. 실험 결과 사이클 타임 (대기 시간 + 서비스 시간)
-----------------------------------------------
-
서비스 시간

25. 큐 이론이 의미하는 바.
● 작업량과 작업 속도는 비선형적이다.
○ 최적의 작업량을 찾는 것이 의미 있다. velocity
○ 개개인 작업량을 채우는 접근은 복잡성으로 이상
현상을 유발한다.
● 멀티 작업을 수행하기 보다, 단일 작업 수행.
○ 멀티 작업 수행은 결과적으로 효율성을 낮춘다.
○ 하나만을 집중해서 해결하는 것을 추구.
● 작업을 작게 만들도록 한다.
○ 작업이 커질 것 같이 내부에 위험성이 잠재.
○ 작업을 작게 그리고 가능하면 균일하게 만드는 것
이 큰 덩어리 작업보다 효율적 진행.
○ 작업 전환 비용도 고려가 되어 최적 사이즈로.

26. 큐 자체 보다는 큐를 만드는 시스템에
큐는 흐르지 않는 가치이다.
흐름이 멈추지 않도록 관심을 가지더라도,
정체된 흐름 자체에만 관심을 가지지기 전에,
아예 정체를 없애버리는 방향을 고민해 보도록 하자.
국지적 최적화가 오히려 더 큰 정체를 유발할 수 있다.

27. 이러한 고민들은 Scrum에 반영되어 있다.
그렇지만, 이것은 시작일 뿐.
지속적으로 큐를 발견하고 개선해야 한다.

28. 이분법적 사고를 벗어나자.
스크럼에서 발생되는 논란에 대해서.

29. Agile이 지향하는 Empirical process control. not Defined.
The empirical model of process control provides and exercises control
through frequent inspection and adaptation for processes that are imperfectly
defined and generate unpredictable and unrepeatable outputs.
필연적 논란이나 오해 발생. 특히 이분법.

30. 출처: Why Is Scrum So Hard https://www.youtube.com/watch?v=q3t8twm3aUk

31. Agile requirements are ideally visual and should be barely sufficient, i.e. the
absolute minimum required to enable development and testing to proceed
with reasonable efficiency. The rationale for this is to minimise the time spent
on anything that doesn’t actually form part of the end product.
See more at:
http://www.allaboutagile.com/agile-principle-4-agile-requirements-are-barely-sufficient/#sthash.wJT6njYu.dpuf

32. 가지기 쉬운 이분법적 사고
Scrum Master,
Coach가 생각을 하
고, 이러한 오해들을
더욱 발굴해서 의도하
는 바를 전달하도록 노
력해 가야 할 것이다.

33. 그리고 오해들
● 추정은 추정이 아니다. 추정은 약속이다.
● 애자일은 실천 방법이다.
● 애자일은 즉 XP이다.
● 애자일은 짝 프로그래밍이다.
● 애자일은 반복적이다.
● 애자일은 소규모 개발을 위한 것이다.
● 애자일은 설계나 아키텍처도 없고, 모델링도 하지 않는다.
● 애자일은 추정, 완료 일정, 출시 계획, 출시 내용에 대한 정의가 없다.
● 애자일은 요구 사항 분석을 하지 않는다.
● 애자일은 문서를 만들지 않는다.
● 애자일은 아예 계약을 하지 않거나 시간과 범위를 정하는 계약을 하지 않음
을 의미한다.
● 애자일은 요구사항을 반드시 변경해야 한다.
● 애자일은 오직 고도로 혁신적이고 가변성이 큰 탐색적인 개발을 위한 것이
다. ‘그 외' 개발은 순차적인 생명주기(‘폭포수모델')가 가장 적합하다.
위와 같은 이분법적 사고에서 유래된 오해들이 있다. 이에 대한 구체적인 설명은
Chapter 5. 잘못된 이분법, “그 밖의 오해들" 항목을 참고 바랍니다.
물론 작가의 생각이 많이 투영된 부분들이니, 이는 참고용.

34. DO AGILE 하지 말고, BE AGILE
지금까지 사고 방법을 살펴본 이유.

35. Practice 몰입 경계! 근본 사상 접근!
달을 보라 손가락으로 가리키니,
달은 안 보고, 손가락을 보는구나.

36. 지금까지는
이 부분에 대한 이야기들.
지금 우리는 어디? 어디까지?
이제부터는 익숙한 부분.
특이한 사례들만 살펴보자.

37. 사람, 그리고 팀이 일을 한다.
좋은 결과 뒤에는 좋은 팀이 있다.

38. 훌륭한 사람. 훌륭한 제품. 성장.

39. 팀. 결국은 팀.
의외로 팀이 성과가 개개인 합보다 낮은 경우가 많다.
한 사람은 가끔은 정말 바보 같을 수 있다.
하지만, 진짜 멍청함에 있어서는.
그 어떤 것도 팀워크를 따라올 수 없다.
- 에드워드 어베이

40. 자기조직팀은 직접 상황 인식한다.

41. 자기조직팀은 의존하지 않는다.

42. 자기 조직팀은 직접 판단한다.

43. 상황 인식
상황 판단
의사 결정
행동 수행
결과 책임 팀이 직접 한다.

44. 그들만의 Agile을 넘어서,
조직적 변화가 없는 부분적 Agile은 한계

45. Agile 성공에 대한 조직 장애물 Top 10 (1)
1. 기존 투자/작업을 포기 못함
a. 기존 방식에 투자한게 있어서 포기를 못 함.
2. 국지적 최적화를 추구하는 조직들
a. 내가 담당한 영역만 잘 하려고 하고 다른 부분을 못 보는.
b. 구매 담당자가 싼 툴만 구매하기를 주장하는.
3. 학습을 경시 또는 개인에게 위임하는 문화
a. 학습이 없이는 발전도 없는데, 시간 있을 때에 하는 것이 학습이라고.
b. 여기서 학습은 단순 공부가 아닌, 생각을 깊이 하는 시간.
4. 전문화된 기능 조직.
a. 전문화된 기능만을 수행하는 조직.
5. 국지적 최적화를 촉진하는 시스템.
a. 목표 달성 관리 시스템에서 발생되는 빈번히 발생되는 오류.
b. 우리 팀 목표만 달성에 집착.

46. Agile 성공에 대한 조직 장애물 Top 10 (2)
1. 자신이 직접하는 개선. 조직 밖 시야를 구하지 않는 자세
a. 책 몇 권 보고, 우린 이제 우리는 알아라고 하는 자세
b. 조직 밖에서 바라보는 시각에 대해서 무심을 넘어서 무시하는 자세
2. 개인 성과 평가와 보상
a. 관리자를 좌절시키고 팀의 성과를 방해 평가 제도.
b. 지휘 통제 관리를 촉진을 가져오는.
3. 약속 게임. 비현실적 약속 남발과 불끄기
a. 비현실적 약속으로 자신들을 돋보이려는 시도
b. 비현실적 약속 실현을 위한 임시방편들
4. 개발자에게만 해당하고 간주하는 문화
a. Agile은 개발자에만 해당하는 이야기라는 생각
5. 애자일 형식만 따르면서, 바로 효과가 나오기를 바라는 생각.
a. 기민성과 생산성을 동일시하는 오해.
b. 형식만을 따르고, 숭배하면서 바로 효과가 나오기를 바라는.

47. 일을 둘러싼 전형적 구조들
진정 Agile 해지기 위해서는 이들을 고민해야 한다.

48. 전사적 구조에 도전.
이에 대해서는 진중한 접근 필요.
오히려 간단한 문구들만 살펴봅니다.

52. 평가가 미치는 영향에 대한 실험
http://www.ted.com/talks/dan_pink_on_motivation
평가 지표는 사람을 복합적 사고를 멈추고, 평가 지표에만 몰두한 행동을 하게 한다.

53. 지금까지는
이 부분에 대한 이야기들.
지금 우리는 어디? 어디까지?
이 부분은 생략.
다른 책들과 유사한 부분.

54. THE END
책 사서 읽어보시고, 생각 많이 하세요~~