클린 소프트웨어 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) 버퍼 시스템
- 쓰레기를 운반하는 덤프트럭
Comments