클린소프트웨어 Part 1. 애자일 개발
Chapter 1. 애자일 실천방법(practice)
계속되는 악순환
- 많은 프로젝트가 실천방법 없이 프로젝트를 진행한다.
- 그로 인해 실패를 경험하게 되고 결과물을 요구하는 프로세스가 생긴다.
- 하지만 까다롭고 많은 프로세스는 오히려 복잡하게 만드는 계속되는 악순환 이 생긴다.
- 이는 소프트웨어 위기 와 연결된다.
- 아이러니 하게도 위와 같은 프로세스를 채택하는 회사가 빠르게 늘어낫다 - 큰 회사일 수록 더 심함
애자일 연합
애자일 소프트웨어 개발 선언문
- 프로세스와 툴보다 개인과 상호작용이우선이다.
- 프로그래밍 실력은 평범하지만 서로 잘 대화하는 팀이 성공할 가능성이 높다.
- 팀을 만들기 위해 노력하고 그런 뒤에 팀의 필요를 기반으로 환경을 구축하자.
- 포괄적인 문서보다 동작하는 소프트웨어가 우선이다.
- 설계 원리와 구조에 대한 문서를 쓰고 유지하되, 짧고 요약적 이어야 한다.
- 그 필요가 급박하고 중요하지 않다면 아무 문서도 만들지 마라
- 계약 협상보다 고객 협력이 우선이다.
- 자주 고객의 피드백을 받아야 한다.
- 하지만 일반적인 갑을 관계에서 고객 협력이 우선되면 그로 인한 피해는 어떻게 해야할까?
- 계획에 따르는 것 보다 변화에 대한 반응이 우선이다
- 우선순위 변경에 따라서 변화가 우선한 경우에는 이에 따라야 하는 것이 우선이다.
- 계약 협상보다 고객 협력이 우선이다 와 연결되는 내용인 것 같다.
원칙
- 우리의 최고 가치는 유용한 소프트웨의 빠르고 지속적인 공개를 통해 고객을 만족시키는 것이다.
- 첫 공개본에서 기능하는 부분이 적을수록 최종 공개본의 품질이 높이진다. : ?? 하지만 애자일에는 위배되는 것 같다.
- 자주 공개할 수록 최종 품질도 좋았다. - OK
- 개발 후반부에 접어들었다 할지라도, 요구사항 변경을 환영하라
- 팀은 소프트웨어의 구조를 탄력적으로 유지하기 위해서 노력한다.
- 개발 중인 소프트웨어를 자주 공개하라
- 2주에서 2달사이, 혹은 더 짧은 시간 간격으로
- 업무를 하는 사람과 개발자는 계속 함께 일해야 한다.
- 의욕적인 개인들을 중심으로 프로젝트를 구성하라. 환경과 필요로 하는 지원을 제공하고 그들이 그 일을 해낼 것이라 믿고 맡겨둬라.
- 개발 팀 내에서 정보를 전달하고 옹유하는 가장 효율적이고 효과적인 방법은 직접 일대일로 대화하는 것이다.
- 개발 중인 소프트웨어가 진척 상황의 일차적 척도다.
- 애자일 프로세스는 지속 가능한 개발을 촉진한다. 스폰서, 개발자, 사용자는 무한히 지속적인 pace를 유지할 수 있어야 한다.
- 애자일 프로젝트는 마라톤이다.
- 우수 기술과 좋은 설계에 대한 지속적인 관심은 속도를 향상한다.
- 단순성(아직 끝내지 않은 일의 양을 최대화하는 예술)은 필수적이다.
- 최고의 아키텍쳐, 요구사항, 설계는 자기 조직적인 팀에서 나온다.
- 규칙적으로 팀은 좀 더 효과적인 방법을 반영해야 하고, 적절히 그 행위를 조율하고 조정해야 한다.
결론
- 프로세스가 늘어나는 악순환은 실패의 원인이다.
- 애자일은 간단한 테크닉에 초점을 맞추는 것을 돕기 위한 방법으로서 만들어졌다.
Chapter 2. 익스트림 프로그래밍 소개
XP 실천방법
고객 팀 구성원
고객도 팀의 일원이여야 한다.
사용자 스토리
- 현재 진행 중인 요구사항에 관한 대화의 연상 기호
- 고객이 우선순위와 추정 비용에 근거해 요구사항의 구현 일정을 구립하게 해주는 계획 툴
짧은 반복
XP 프로젝트는 일반적으로 개발 중인 소프트웨어를 2주마다 공개한다.
- 반복 계획 : Minor delivery : 보통 2주
- 릴리즈 계획 : Major delivery : Iteration(2주) * 6 = 보통 3개월
인수 테스트
짝 프로그래밍
- 짝 프로그래밍을 하면 당장 투입되는 시간은 늘어나지만 그로 인해서 결함이 적고 더 나은 프로그램을 만들 수 있어서 전체적으로 효율성은 좋아진다.
- 누군가 짝 프로그래밍을 요구하면 거부할 수 없다.
TDD
- 회귀테스트를 가능하게 한다.
- 리팩토링을 용이하게 한다.
- 설계에 도움을 준다. - 일례로 결합도가 낮아짐
공동 소유권
도메인이나 구조 별로 담당자를 특별하게 구분하지 않는다.
CI(지속적 통합)
- 언제나 편하게 코드를 check-in(push), check-out(pull) 할 수 있어야한다.
- 하루에도 여러 번 처음부터 끝까지 전체 시스템을 빌드 한다.
지속 가능한 속도
소프트웨어 프로젝트는 마라톤이다.
열린 작업 공간
팀 내 소통은 언제나 열려 있어야 한다.
계획 세우기 게임
짧은 반복을 통해서 프로젝트 리듬에 익숙해 지면 사용자 스토리에 대해서 빠르게 기간과 비용을 측정할 수 있게 된다.
단순한 설계
최대한 단순하게 요구사항을 구현한다. 만약 요구사항이 필요로 할 때만 인프라가 추가된다.
- 어떻게든 동작하는 가장 단순한 것을 생각한다.
- 필요하지 않을 것이라는 가정에서 시작한다.
- 코드를 중복해서 쓰지 않는다.
리팩토링
- 코드는 부패하기 쉽다(Bad smell)
- 언제나 잦은 리팩토링으로 이를 극복해야 한다.
메타포
- 사전적으로는 은유 또는 비유
- 전체 시스템을 하나로 묶는 큰 그림
ex) 버퍼 시스템
- 쓰레기를 운반하는 덤프트럭
Chapter 3. 계획 세우기
초기 탐색
사용자 스토리에 포인트를 할당해서 가능한 객관적으로 구현에 필요한 시간을 확인할 수 있다.
스파이크, 분할, 속도
적정 포인트로 사용자 스토르를 분할 또는 취합해야 한다.
스토리의 정확한 크기를 알기 위해서는 속도(Velocity)라는 요소가 필요하다.
- 예를 들어 속도가 ‘스토리 포인트당 2일’이고 어떤 스토리가 상대적인 추정결과 4개의 포인트를 갖는다면 그 스토리를 구현하는 데는 8일 이 걸릴 것이다.
스파이크 : 대개 며칠만 투자해도 한 두개의 스토리로 프로토타입을 만들어보면서 팀의 속도를 알 수 있다. 이런 프로토타입 단계를 스파이크라 한다.
릴리즈 계획 세우기
속도(Velocity)가 파악되면 릴리즈 계획을 세울 수 있다. 보통 3달로 한다.
반복 계획 세우기
- 보통 2주가 된다.
- 스토리를 우선순위는 기술적 결정, 즉 개발자가 정한다.
- 모든 계획된 스토리가 구현되지 않더라도 반복은 정해진 날짜에 끝난다.
- 미완료 된 기능은 다음 반복으로 미루는 것이 가능하지만 가능하면 계획에 맞춰서 끝내도록 노력해야 한다.
- 반복 별로 사용되는 스토리 포인트는 일정해야 한다.
태스크 계획 세우기
- 사용자 스토리 = 태스크 * N
- 1 태스크 = 4 ~ 16 시간
- 개발자는 그 태스크를 임의의 태스크 포인트로 추정한다.
- 공동 소유권 으로 인해 개발자 누구나 어떤 종류의 태스크에든 참여할 수 있다.
- 이는 프로젝트 전체를 파악할 수 있으므로 단점 보다는 장점이 더 많다.?!
적절하게 태스크를 남은 예산(포인트)내에서 개발자로 별로 할당한다.
반환점
- 반복이 반쯤 진행됐을 때 팀은 미팅을 갖으며, 스토리의 반 정도 완료되어 있어야 한다.
- 적절하게 태스크를 재분배해서 반복이 끝날 때까지 모든 스토리가 완료될 수 있도록 해야 한다.
- 만약 불가능하다면 고객에게 이를 보고하고 계획 수정에 대한 양해를 구해야 한다.
반복
- 반복의 마지막에는 결과물을 시연한다.
- 새로운 사용자 스토리를 위한 피드백
속도를 측정할 수 있고, 프로젝트 진행을 예측할 수 있고 그로 인해 고객은 프로젝트를 관리할 수 있는 제어권을 가질 수 있다.
결론
반복과 릴리즈를 통해서 프로젝트는 예측 가능하고 안정적인 리듬을 찾아간다.
- 개발자는 스스로 소요시간 관리 가능
- 관리자는 기한을 제어할 수 있음
하지만 이상적으로 돌아가는 것은 힘들다. 애자일은 그저 최소의 비용으로 최대의 사업상 가치를 얻을 수 있도록 팀을 제어할 수 있음을 의미할 뿐이다.
