클린 애자일 다시 읽기 - 2장 왜 애자일인가
개요
관련 링크
- 마틴 파울러가 말하는 디자인 스테미나 가설
본문 시작
애자일 개발이 중요한 것은 더 깊은 철학적, 윤리적 이유 때문이다. 바로 직업의식과 고객의 당연한 기대 때문이다. - p42
- 철학적 이유는 직업의식이다. 의사나 건축가가 직업의식이 없다면 무슨 일이 벌어질까?
- 윤리적 이유는 당연한 기대에 부응해야 한다는 것이다. 자동차 정비를 맡기면 고쳐줄 것을 기대하고, 미용실에 가면 머리를 잘 깎아줄 것을 기대할 것이다.
직업의식
소프트웨어 업계는 직업의식을 정말 많이 높여야 한다. - p43
생각해보면 부끄러울 따름이다. 살면서 접하는 수많은 직업을 가진 분들의 자신의 직업에 대한 의식에 비해 개발자는 얼마나 비루한가?
요즘 사회에서는 소프트웨어 시스템과 상호작용하지 않으면 아무것도 할 수 없다. - p45
우리 프로그래머가 세상을 지배한다. 그리고 아주 엉망으로 (지배)하고 있다. - p46
우리의 소프트웨어가 지금 사람을 죽이고 있다. - p47
소프트웨어는 우리의 삶 속에 깊숙히 들어와 있는데, 그 소프트웨어는 너무나 엉망으로 만들어지고 있다.
내가 애자일에 큰 희망을 품었던 것도 이런 생각에서였다. 나는 꿈꾸었고, 지금도 꿈꾼다. 애자일 소프트웨어 개발의 규율이 컴퓨터 프로그래밍을 진정한 직업, 명예로운 직업으로 바꾸는 첫 단추가 될 거라고. - p48
부끄럽지 않은 개발자가 되는데 애자일이 희망이 될 수 있다.
당연한 기대
1. 우리는 쓰레기를 내보내지 않겠다!
관리자, 고객, 사용자가 품질이 높고 결함이 적은 시스템을 받으리라고 기대하는 것은 완벽하게 타당하다. - p50
애자일: TDD, Refactoring, Simple Design, customer feedback
2. 기술적 준비 상태 유지하기
사업부서와 고객의 입장에서는 당연히 언제나 기술적으로 준비된 상태일 거라고 기대한다. -p52
시스템은 각 반복 주기가 끝날 때마다 기술적으로는 배포 가능해야 한다. - p51
반복 주기 동안 스토리를 구현한다는 것은 스토리의 모든 코딩과 모든 테스트와 모든 문서와 모든 안정화를 다 끝낸다는 것이다. - p51
애자일: 반복 주기에 구현하는 스토리는 배포 가능한 수준이 되어야 한다.
3. 안정적인 생산성
고객이나 관리자는 소프트웨어팀이 점점 느려질 것이라 생각하지 않는다. - p55
빨라질거라 기대한다.
개발자도 똑같이 생각해야 한다. 아키텍처, 설계, 코드를 가능한 한 계속해서 깨끗하게 관리하여 생산성을 높게 유지해야 한다. - p55
제대로 하지 않으면 점점 코드가 엉키고 꼬여서 생산성이 느려지게 된다.
마틴 파울러가 말하는 디자인 스테미나 가설 동영상을 보자.
애자일: Test, Pair Programming, Refactoring, Simple Design, Planning Game
4. 낮은 수정 비용
고객, 사용자, 관리자는 모두 소프트웨어 시스템이 바꾸기 쉬울 거라 기대한다. - p56
애자일: TDD, Refactoring, Simple Design → 싸고 쉬운 유지보수
5. 지속적인 개선
사용자나 고객, 관리자는 지속적이고 꾸준한 개선이 이루어질 거라 기대한다. 초기의 문제는 사라지고 시스템이 점점 더 좋아질 것이라고 기대한다. - p57
우리는 “무책임” 해서는 안된다.
애자일: Pair Programming, TDD, Refactoring, Simple Design
6. 두려움을 이기는 능력
고객과 사용자, 관리자는 두려움을 이기는 능력을 기대한다. 당신이 무언가 잘못되었거나 지저분한 것을 보면, 고치고 정리하리라 기대한다. (중략) 당신이 코드를 훤히 꿰뚫고 있으면서 최대한 깨끗하고 명확하게 유지할 거라 기대한다. - p57
애자일: Test Driven Development
7. QA는 아무것도 찾지 못해야 한다.
QA는 시스템에서 아무 문제도 찾지 못해야 한다. - p58
애자일: Acceptance Test, TDD, Continuous Integration(CI)
8. 테스트 자동화
고객과 사용자는 우리가 모든 릴리스를 철저하게 테스트할 거라 기대한다. - p60
수동 테스트는 돈과 시간이 들고 실수를 할 수도 있다. 최대한 자동화해야 한다.
애자일: TDD, Continuous Integration, Acceptance Test
9. 우리는 서로를 대신한다.
소프트웨어팀의 구성원들은 필요할 때 서로를 대신해야 한다. - p61
지식을 칸막이 안에 가두어서는 안된다. - p61
지식이 물처럼 흐르게 해야 한다.
애자일: Pair Programming, Whole Team, Collective Ownership
10. 정직한 추정
이런 추정은 여러분이 모은 아는 것과 모르는 것을 관리자에게 필요한 정직한 확률로 바꾸어 준다. - p62
작업들간의 상대적인 추정, 확률적인 추정을 관리자에게 알려주어야 한다.
애자일: Planning Game, Whole Team
11. “아니요”라고 말해야 한다.
프로그래머는 무엇이 가능한지를 아는 사람이다. - p62
애자일: Whole Team
12. 지속적이고 적극적인 학습
우리 산업은 빠르게 변한다. 우리도 발맞추어 변해야 한다. 그러니 배우고, 배우고, 또 배워라!
애자일: Whole Team
13. 멘토링
사실 가장 좋은 공부 방법은 가르치는 것이다. - p63
애자일: Whole Team
권리 장전
여기서 고객은 사업부서라는 내부 고객을 의미하고,
여기서 개발자는 프로그래머, QA 테스터, 업무 분석가를 의미한다.
고객 권리 장전(Customer Bill of Rights)
You have the right to an overall plan and to know what can be accomplished when and at what cost.
고객은 무엇이, 언제, 얼마의 비용으로 완성될지 알 권리가 있다.
→ 개발자는 불확실성과 대처수단을 제시하고 확률적인 추정을 제시할 수 있어야 한다.
You have the right to get the most possible value out of every iteration.
고객은 매 반복주기마다 가능한 최선의 가치를 얻어낼 권리가 있다.
You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify.
고객은 고객이 명시한 테스트를 통과한, 그래서 동작이 검증된 시스템에서의 진행사항을 볼 권리가 있다.
You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.
고객은 추가 비용 없이도 마음을 바꿔서 기능을 대체하거나, 우선순위를 바꿀 권리가 있다.
You have the right to be informed of schedule and estimate changes, in time to choose how to reduce the scope to meet a required date.
고객은 일정의 추정과 변경사항을 알 권리가 있다. 그래야 일정을 맞추기 위한 선택을 할 수 있다.
You can cancel at any time and be left with a useful working system reflecting investment to date.
고객은 언제든 개발을 멈추게 할 수 있고, 그때까지의 동작하는 결과물을 받을 수 있다.
고객에게는 일정의 맞출 것을 요구할 권리가 없음을 주지하기 바란다. 고객의 권리는 업무 범위를 바꾸어 일정을 관리하는 것으로 한정된다. 여기서 가장 중요한 권리는 일정이 어긋나려고 할 때 알 수 있는 권리다. - p66
일정을 강요할 권리는 없다. 일정이 어긋날 것을 알 권리와 일정을 관리할 권리가 있을 뿐이다.
개발자 권리 장전(Developer Bill of Rights)
You have the right to know what is needed with clear declarations of priority.
개발자는 요구사항과 우선순위를 알 권리가 있다. 반복주기 내에서는 (거의) 변경되지 않아야 한다.
→ 고객은 가능한 반복주기 내에서의 변경은 하지 않는다.
You have the right to produce high-quality work at all times.
개발자는 최고의 품질을 추구할 권리가 있다. 이것은 직업 윤리이다.
→ 가장 심오한 권리이다. 개발자는 일을 잘 할 권리가 있다.
→ 사업 부서가 개발자에게 직업 윤리를 어기도록 강요할 수 없다.
You have the right to ask for and receive help from peers, managers, and customers.
개발자는 동료, 매니저, 고객에게 도움을 요청하고, 도움을 받을 권리가 있다.
→ 개발자가 의사소통을 할 권리이다. 애자일 매니페스토의 “공정과 도구보다 개인과 상호작용을”
You have the right to make and update your own estimates.
개발자는 업무를 추정하고, 그 추정을 업데이트할 권리가 있다.
→ 추정은 약속이 아님을 잊지 말자.
You have the right to accept your responsibilities instead of having them assigned to you.
개발자는 책임을 받아들일 권리가 있다. 누군가가 개발자에게 할당하는 것이 아니다.
수락은 책임을 뜻한다. 일단 수락했다면, 업무의 품질과 실행에 책임을 져야 한다. - p68
결론: 애자일은 무엇일까?
애자일은 프로세스가 아니다. 애자일은 지나가는 유행이 아니다. 애자일은 단순히 규칙을 모아놓은 것이 아니다. "윤리적인 직업의 기반을 이루는 권리, 기대, 규율을 한데 모은 것이 애자일이다." - p69
이제, 3, 4, 5 장을 통해 XP의 실천 방법을 둘러볼 것이다. 많은 애자일 프로세스 중에서 왜 XP인가?
"모든 애자일 프로세스 중에서 XP가 가장 잘 정의되어 있고, 가장 완전하며, 가장 덜 혼란스럽기 때문이다." 37p