Extreme Programming

1. 익스트림 프로그래밍
2014.11.12
ITSM 팀
정희찬

2. 켄트 벡, 신시아 안드레스 지음
김창준, 정지호 옮김
인사이트
초판 3쇄 (2009년 9월 4일)

3. Agile
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

4. Agile
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

5. 가치 (Values)
• 의사소통 (Communication)
• 단순성 (Simplicity)
• 피드백 (Feedback)
• 용기 (Courage)
• 존중 (Respect)
 지식의 부족? 의사소통의 부족?
 의사소통의 부재로 인한 문제인가 자문
 의사소통에 대한 지속적인 개선
 단순성 < 복잡성의 제거
 프로세스, 프로그램, 의사소통 등
 제대로 하는 것이 어떻게 하는 것인지 모른다.
 오늘 제대로가 내일을 보장하지 않는다.
 점진적 개선
 최대한 빠르게, 최대한 많이
 의사소통의 핵심
 단순함, 피드백 등에 대한 근본적인 가치
 행동? 인내? 용기의 발현의 다른 형태
 다른 이 보다 본질적으로 더 가치 있는 사람은 없다.
팀이 신봉하는 가치에 팀의 행동이 어울리도록 만드는 것이 가장 중요!

6. 원칙 (Rules)
 인간성 (Humanity)
소프트웨어는 사람이 개발한다.
 경제성 (Economics)
기술적 성공 < 비즈니스 목표와 필요
 상호이익 (Mutual Benefit)
사용자, 발주자(Sponsor), 개발자 등 관련된 모든 사람에게 이익이 되어야 함.
 자기 유사성 (Self Similarity)
해결책의 구조를 다른 맥락, 다른 사이즈에도 적용.
정답이 아닌 해답을 적용
 개선 (Improvement)
일단 시작 후 지속적인 개선. 현실과 이상의 간극을 좁히기 위한 매일 같은 노력
 다양성 (Diversity)
문제를 해결하기 위한 다양한 기술, 사고방식, 관점들의 존재를 인정.
갈등을 부정하는 것이 아니라 인정하고 생산적으로 풀어내는 방식
 반성 (Reflection)
왜 일하는지, 왜 성공했는지, 왜 실패했는지 분석하고 배우는 팀.

7. 원칙 (Rules)
 흐름 (Flow)
가치 있는 SW를 끊임없이 제공하기 위한 점진적, 계속, 자주 개발의 단계를 동시에 작업함.
 기회 (Opportunity)
문제를 기회로 전환할 사고방식과 접근 자세. 강점을 늘리고 약점을 최소화.
 잉여 (redundancy)
Plan B. 소모적인 중복과 잉여가 되지 않도록 함.
 실패 (Failure)
실패는 허비된 시간과 노력이 아니고 항상 감수 해야할 가장 짧은 길.
 품질 (Quality)
품질을 희생하면 프로젝트가 성공하는가? 더 이상 제로섬 게임이 아님.
 아기 발걸음 (Baby Step)
단계를 작게 하고 실패해도 다시 시작하자. 느리게 하자는 말은 아님.
 받아들인 책임 (Accepted Responsibility)
책임과 권한은 항상 같이 한다는 점.

8. 실천 방법 (Practices)
 함께 앉기 (Sit Together)
물리적 공간의 중요성, 의사소통을 위한 고민
 전체 팀 (Whole Team)
팀의 정체성, 기술과 시야를 지난 모든 관련된 사람을 팀에 포함. 팀의 규모?
 정보를 제공하는 작업 공간 (Informative Workspace)
팀 공간은 팀의 프로젝트로 채워라. 스토리 카드, 차트. 살아있는 정보?
 활기찬 작업 (Energized Work)
생산성의 최대치를 위한 근무 시간.
 짝 프로그래밍 (Pair Programming)
두 사람이 한대의 컴퓨터. 자주 바꾸고 혼자 생각할 시간도 주고…
 스토리 (Story)
요구사항과 다른 개념. 기능단위로 짧은 글, 그림, 설명, 이름 등 필요
 여유 (Slack)
일정을 느슨하게 잡는다는 의미가 아님. 약속한 시간 내에 작업을 마치는 것을 뜻함. 포기할 수 있는
Task를 가지도록 함.

9. 실천 방법 (Practices)
 일주일별 주기 (Weekly Cycle)
한번에 일주일 분량의 계획, 주간회의, 구현 스토리 채택, 스토리에 따른 Task 할당
 분기별 주기 (Quarterly Cycle)
한번에 한 분기 분량의 계획, 팀과 프로젝트 방향성, 목표 검토. 제약조건, 병목 등을 검토.
 10분 빌드 (Ten-minute Build)
10분안에 시스템을 빌드하고 테스트를 돌릴 수 있도록 자동화. 자주할 수 있도록 최소한의 시간동안
자동화하는 점이 중요.
 지속적 통합 (Continuous Integration)
구성원들의 작업을 자주 통합. 통함과 빌드의 결과는 완제품.
 테스트 우선 프로그래밍 (Test Driven Development)
프로그램 구현 전에 테스트를 먼저 작성. TDD는 Testing과 다름.
 점진적 설계 (Incremental Design)
설계는 매일, 점진적으로. 최대한 설계를 뒤로 미룸.

10. Really possible?
 팀의 미션, 비전, 핵심 가치
 함께 앉기 (Sit Together) ●
 전체 팀 (Whole Team) ○ - Role 정의
 정보를 제공하는 작업 공간 (Informative Workspace) ○ - 방법 고민
 활기찬 작업 (Energized Work) ○ - 근무시간 준수
 짝 프로그래밍 (Pair Programming)
 스토리 (Story)
 여유 (Slack) ○ - 우선순위 선별
 일주일별 주기 (Weekly Cycle) ○ - 주간회의
 분기별 주기 (Quarterly Cycle) ○ - 분기별 목표 수립
 10분 빌드 (Ten-minute Build) ○ - 자동화
 지속적 통합 (Continuous Integration) ○ - 자동화
 테스트 우선 프로그래밍 (Test Driven Development) ○ - 가장 중요
 점진적 설계 (Incremental Design) ○ - 가장 중요

11. Constraints
?