Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
- The Agile Alliance -
애자일의 역사, 이유, 실천 방법과 가치 그리고 소프트웨어 장인 정신에 대해 담백하게 이야기 식으로 풀어낸 책입니다.
책을 읽고 계속 기억하고 싶은 내용을 편하게 요약해 보았습니다.
애자일의 실천 방법¶
1장 애자일 소개¶
- 이 책은 애자일의 근본적인 내용을 다룬다.
애자일의 역사¶
- 애자일은?
- 중간 단계의 작은 목표를 고르고, 그 진행 상황을 측정하는것
- 너무 직관적이고 인간적이다. 5만년은 되었을듯
- 소프트웨어 세계에서 에자일은?
-
1970
- pre-Agile vs Scientific Management(Waterfall)
- 폭포수 dominates!
- pre-Agile도 waterfall도 아닌 개판 5분전 모델에서 waterfall이 유행하게됨
-
분석 → 설계 → 구현!!!!!!
- 1980 후 ~ 1990 초
-
초기 애자일 개혁
-
켄트 벡과 XP 그리고 TDD 의 등장
- 2001년
-
스노버드 회의
- 경량 프로세스와 소프트웨어 개발 전반에 걸친 믿음!
Manifesto for Agile Software Development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
- The Agile Alliance -
-
애자일 개요¶
- 마감 기한 - 프로젝트에 대해서 가장 먼저 알게 되는 것
- 마감 기한은 바뀌지 않지만, 요구사항은 계속 해서 바뀐다.
- 애자일 하는 법
- 프로젝트의 일정을 일정한 크기로 더 작게 나눔 : iteration(sprint)
- iteration 0
- 짧은 기능 목록을 만든다 (story)
- 스토리의 크기를 추산하고 대충 밑그림을 그린다.
- iteration 1~
- 스토리를 수행하고 남은 날짜와 포인트를 저울질해서 계속해서 데이터를 얻어내자.
- 목표 보다 낮다고 절대 실패가 아니다.
- 관리자는 데이터를 바탕으로 일의 범위나 일정, 사람, 품질을 조절해야한다.
삶의 순환¶
XP의 실천 방법을 설명하는 론 제프리즈의 그림
- 이것들 중 몇개만 해야지 라는 생각은 접어야 한다.
- 에자일이 정말로 무엇인지 이해하고 싶다면 XP를 공부하는 것이 최선의 방법이다.
2장 왜 애자일인가¶
애자일 개발이 중요한 이유 - 직업의식과 고객의 당연한 기대
직업의식¶
- 소프트웨어 업계는 직업의식을 정말 많이 높여야 한다.
- 우리는 너무 자주 실패한다. 너무 많은 결함을 용인한다.
- 세상는 소프트웨어가 지배하고 소프트웨어는 프로그래머가 지배한다.
- 프로그래머는 세상을 지배한다. 아주 엉망으로
고객과 관리자의 당연한 기대¶
- 쓰레기는 내보내지 않는다.
- 기술적 준비 상태 유지
- 안정적인 생산성
- 낮은 수정 비용
- 바뀌는 요구사항 때문에 아키텍처가 망가진다면, 아키텍처가 엉망인 것
- 개발자는 변경 사항을 축복으로 여겨야 함
- 지속적인 개선
권리 장전 - Bill of Rights¶
결론¶
- 애자일은 프로세스가 아니다. 애자일은 단순히 규칙을 모아 놓은 것이 아니다.
- 윤리적인 직업의 기반을 이루는 권리, 기대, 규율을 한데 모은 것이 애자일이다.
3장 비즈니스 실천 방법¶
계획 게임 - Planning Game¶
프로젝트를 정밀하고 확실하게 추정하고 싶다면?
→ 코드 한 줄 한 줄 까지 쪼개면 됨
→ 추정 시간을 구했더니 프로젝트가 완성됨
삼변량 분석 → 정밀도가 너무 낮다¶
- 최선의 경우
- 일반적인 경우
- 최악의 경우
스토리 포인트 → 엄격한 피드백 루프¶
- 스토리 = 시스템의 기능을 간략하게 설명한 것
- 단순한 스토리 문구를 가지고 개발자와 이해관계짜는 논의함
- 스토리에 포인트를 매기고 몇 정도의 포인트를 처리 할지 짐작
- 스토리는 약속이 아님
- 이번 반복주기에 30을 하기로 짐작하고 18만큼 완수했다
- 이번 반복주기는 망했나? 아니다! 반복주기에 실패란 없다.
- 반복주기의 목표는 관리자에게 데이터를 제공하는 것
- 반복 주기를 마치며 속도 그래프와 번다운 차트를 기록
- 포인트 인플레이션을 주의하라
작은 릴리스 - Small Release¶
팀이 일을 조그만 크기로 나누어서 하도록 이끌어라 - 2 pizza team
최대한 자주 릴리스 하라 -지속적 배포!
릴리스 = 소프트웨어가 기술적으로는 배포 가능하다는 것
배포 = 사업부서가 결정하는 것
인수 테스트 - Acceptance Test¶
- 사업 부서가 요구 사항을 명시해야 한다.
- ‘명세'의 본질은 ‘테스트'!
- 인수 테스트는 가능한 한 시스템의 요구 사항을 자동화된 테스트 형태로 작성해야 한다는 것이다.
- 이걸 개발자가? 사업 부서가?
- 사업 부서(업무 분석가 + QA)에서 각 사용자 스토리의 동작을 설명하는 테스트를 형식에 맞게 작성
- 개발자는 이를 자동화
- 스토리의 완료 여부는 인수 테스트로 판가름
전체 팀 - Whole Team¶
전체 팀
- 고객 (사용자가 필요하느 것을 잘 알면서 개발팀과 같은 곳에서 일하는 사람이나 그룹)
- 개발자
- 관리자, 테스터, 테크니컬 라이터 ...
의 물리적 거리를 최소화 하라
4장 팀 실천 방법¶
메타포 - Metaphor¶
개념을 나타내는 어휘와 용어를 명확하게 정의하여 일관되게 사용해야 한다.
팀 내 의사소통을 효율적으로 만든다.
DDD의 Ubiquitous Language
UL은 사업부서, 개발자, QA,운영팀 DevOps 고객 경영사례... 프로젝트의 모든 단계에 걸쳐서 사용되어 전체 프로젝트를 일관성 있게 연결한다.
지속 가능한 속도 - Sustainable Pace¶
- 소프트웨어 프로젝트는 단거리 경주가 아니라 마라톤
- 쉴땐 쉬어라
공동 소유 - Collective Ownership¶
- 팀 구성원 누구나, 언제든지, 프로젝트의 어느 모듈이든 checkout 해서 개선할 수 있다.
- 팀 전체가 코드를 공동으로 소유한다.
지속적 통합 - Continuous Integration¶
- 많은 의미적 변화를 통해 지속적 통합은 지속적 빌드, 지속적 체크인의 의미를 가지게 되었다. Jenkins 등.
- 절대 깨지지 말아야 한다.
- 체크인 전에 모든 인수 테스트와 단위 테스트를 수행해 보아야 한다.
스탠드업 미팅 - Stand-up Meeting¶
- 참석은 필수가 아님
- 매일 안해도 됨
- 10분이 넘으면 안됨
- 뭐했는지, 뭐할지, 뭐가 어려운지? + 누구에게 감사한지
5장 기술 실천 방법¶
테스트 주도 개발 - Test-Driven Development, TDD¶
테스트 주도 개발의 세 가지 단순한 규칙¶
- 해당 코드가 없어서 실패하는 테스트 코드를 쓰기 전에 제품 코드를 먼저 쓰면 안 된다.
- 테스트 코드를 쓸 때 실패하도록 만들기 위해 필요한 것 보다 더 많이 쓰면 안 된다. 컴파일 실패도 실패로 간주한다.
- 실패하는 테스트를 통과시키기 위해 필요한 코드보다 더 많은 제품 코드를 쓰면 안 된다.
테스트 주도 개발의 좋은 점¶
- 작업하던 코드는 아무리 길어도 1분 전까지는 실행 가능했고, 테스트를 모두 통과한다. 디버깅이 필요없다. 디버깅은 선망할 만한 기술이 아니다.
- 테스트는 전체 시스템의 코드 예제가 된다.
- 제품 코드 → 테스트/ 테스트 → 제품 코드 : 전자는 재미없다. 후자는 재미 있다.
- 테스트 코드는 개발자의 설계에 대한 고민을 유도 하고 더 잘 분리된 설계로 이끈다.
- 테스트 코드는 과감한 리팩토링을 위한 용기를 준다.
리팩터링 - Refactoring¶
- 코드의 구조를 개선하면서 동작은 바꾸지 않는 실천 방법
- 프로그램의 동작 = 테스트!
단순한 설계 - Simple Design¶
- 최대한 단순하고, 작고, 표현력이 뛰어난 구조를 바탕으로 최소한의 코드만 작성하는 실천 방법
- 켄트 벡이 세운 단순한 설계의 규칙
- 모든 테스트를 통과 할 것
- 의도를 드러낼 것
- 중복을 없앨 것
- 구성 요소를 줄일 것
짝 프로그래밍 - Pair Programming¶
- 프로그래밍 문제 하나를 두 사람이 함께 해결하는 행위
하는법¶
- 컴퓨터 한대를 놓고 모니터 키보드 마우스를 함께 사용할 수도 있고
- 각자의 컴퓨터 앞에서 네트워크로 연결하여 같은 코드를 고치는 식으로 작업할 수도 있음
역할을 나누기도함¶
- 한명이 코딩, 한명은 제안 (운전자 + 항해사)
- 한명이 테스트 작성 -> 다른 한명이 테스트를 통과하게 하고 다른 기능 테스트 -> 반복 (핑퐁)
- 특별한 구분없이 동등한 입장에서 하는 경우가 제일 많다
시간은 짧아야함¶
- 대부분 1~2시간 이내 끝나야함 15분 or 30분도 좋음 길어야 하루
조합¶
- 고급 프로그래머 + 초급 프로그래머가 좋다.
목표¶
- 지식을 모으는 것이 아니라 퍼트리고 교환하는것
- 지식의 칸막이가 생기지 않도록 하는것
비용¶
- 연구에 따르면 15%정도 증가
- 하지만 얻을 수 있는 효과는 정량적으로 측정 불가능하지만 많은 경우 의미가 있음
둘이서만?¶
- 할 필요는 없다
- 셋 넷 이서 가능 (mob 프로그래밍)
6장 애자일해지기¶
애자일의 네 가지 가치
- 용기
- 소통
- 피드백
- 단순함
애자일로의 전환은 어렵다.
애자일 코치, 스크럼 마스터
애자일 인증
대규모 애자일 같은건없다.
- 애자일은 ‘작은‘ ‘소프트웨어팀‘을 운영할 때 적용하는 규칙 모음
7장 장인정신¶
많은 기업, 회사에서 애자일은 변형되었고 애자일의 가치를 오해하고 있다.
일부 책이나 기업이 컨설턴트, 애자일 코치 등을 통해 스크럼, 스탠드 미팅, 백로그 관리툴, 조직 구조 개편 등만 강조를 하며 애자일 전환 이라는 표현을 하고 있다.
애자일 도입이 더 좋은 소프트웨어를 만들기 위함이지만 실제 개발자 등의 역량을 높이는 노력 없이 단순히 절차를 변경하는 수준에 그친다면 실제로 소프트웨어 품질이 좋아지거나 애자일이 정착될 수 없다. 백명석 - 애자일과 소프트웨어 장인 정신
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration, but also productive partnerships
개발자에게 가능한 한 최고가 되라고 격려하는 운동!!!
이 운동은 실천 방법이 없다. 가치에 집중하라!
소프트웨어 장인 정신은 개인과 산업, 기업에 좋은 영향을 준다!
장인 정신 vs 애자일 ?
- 다양한 의견
- 밥 : 두 운동은 분리되어서는 안 된다.
Created: December 13, 2022