요구사항정의서 : 유저 니즈를 정리한 문서, 개발 스펙이나 방법에 대해서는 정의하지 않는다
유저의 요구사항을 구현하는 데 걸리는 시간 계획
전제사항, 엮인일, 잡무를 제외한 시간을 예측(단, 테스트 기간 포함)
주어진 시간내에 몇개의 요구사항을 구현할 수 있고 몇개의 요구사항 세트들이 얼마나 걸리는지?
개별 반복(Individual Iteration)마다 얼마나 많은 요구사항을 처리할 수 있는지?
릴리스 계획은 대체로 4개의 quantified된 변수에 의해 결정된다. Scope(어느 범위까지 일이 완료되어야 하는지), Resources(얼마나 많은 사람이 투입되는지), Time(얼마나 많은 시간이 걸리는지), Quality(얼마나 퀄리티가 높아야 하는지, 어느 정도의 테스트가 필요한지)
고객과의 잦은 소통으로 프로젝트 방향성 잡기
개발 투명성 유지하기
서서하는 미팅, 화이트보드, 열린 토론, 브레인스토밍
실현가능한 현실적인 계획을 세운다
"인간적으로 가능한"것보다 더 많은 일이 주어질 경우 Scope 또는 Timing을 조절한다
Fred Brooks는 이미 늦은 프로젝트에 대해서 더 많은 사람을 투입하는 것은 안좋은 아이디어라고 했다. 늦기전에 릴리스 플래닝을 잘 예측하라.
프로젝트를 성공적으로 끝내기위해 팀의 적절한 속도를 찾는 것이 중요하다
모든사람이 서서하는 잠깐의 미팅이 몇명의 개발자들이 앉아서 하는 것보다 효율적이다
서서하는 미팅은 시간낭비를 줄여준다
어제 무엇을 성취했는지, 오늘 무엇을 시도할 것인지, 딜레이를 초래하는 문제는 무엇인지에 대해 이야기한다.
일정하고 예측가능한 속도(Steady Predictable Pace)를 유지하기위해 반복계획을 수정한다
사람들과 소통하면서 지식의 고립과 코딩의 병목현상을 없애도록 한다
Pair Programming을 하도록 노력한다(두명이 함께 개발/테스팅 혹은 한명이 개발 한명이 테스팅)
XP룰이 깨지면 고치도록 한다
가장 간단한 디자인으로 부터 시작한다
팀내에서 "간결"의 정의를 확실히 한다
각자 주관적 코드 평가를 한다
Testable, Understandable, Browsable, Explainable 로 퀄리티를 나눈다
Testable : Unit test와 Acceptable test를 작성할 수 있는지
Browsable : 내가 원할때 찾을 수 있는지
Understandable : (굉장히 주관적) 같이 일한 사람이 이해할 수 있는지
Explainable : 새로온 사람 또는 개발자가 아닌 사람이 이해할 수 있는지
예) 함수를 작성할때
소수점을 %로 바꿀때, cm를 m로 바꿀때 똑같이 100을 곱하는 함수를 작성하지만 convertToPercentOrMeters(x)로 작성하지 않고 converToPercent(aFraction)와 convertMetersToCentimeters(aLength)로 나누어 함수를 작성한다
스타일시트를 작성할때도 똑같다 brad-right가 아니라 small-font float-right와 같은 네이밍을 사용한다
시스템에 특별한 네이밍을 하도록 한다. 현재 완성된 프로젝트가 아니기 때문에 함수나 오브젝트의 이름을 정하기 힘들때가 있다. 이미있는 시스템 또는 사물에 비유하여 코딩을 하도록 한다.
기술적 한계 또는 어려움이 예상되면 잠재적인 해결가능성을 가지고 있는 코드를 작성해본다. 이 코드는 대부분 버려질 것이다.
이 기능을 넣어두면 시스템이 나중에 더 좋아질거야라는 생각은 접는다
실제로 기능성 추가는 정말로 필요하지 않으며 항상 우리의 자원을 낭비한다
Turn a blind eye towards future requirements and extra flexibility. Concentrate on what is scheduled for today only.
코드 재사용성과 유지때문에 리팩토링을 주저하지 않도록 한다. 이또한 자원낭비로 이어진다.
전체적 리팩토링은 프로젝트 생명주기를 늘리고 퀄리티를 높인다
항상 코드를 간결하게 깨끗하게 유지하여 이해하고, 수정하고, 확장하기 쉽도록 유지한다
리팩토링은 훌륭한 디자인을 전제로 한다
커뮤니케이션은 항상 중요하다
집단 오너쉽을 가질수 있도록 표준을 정하고 따른다
실제 코드보다 유닛 테스트 코드를 먼저 작성하면 코딩이 쉽다(TDD의 개념)
무엇이 완성되야하는지 확실히 보인다
완성된 스펙에 대해 오해를 피할 수 있다(커뮤니케이션도 쉽다)
즉각적인 피드백을 얻기 쉽다
나중에 테스트하기 쉽다
두 사람이 한 컴퓨터로 코딩한다
지식을 공유하고 온도차를 없앤다
새로운 방식을 도입하기 쉽고 "지식의 섬(Knowledge Island)"에 갇히는 것을 방지한다
가장 좋은 페어 프로그래머는 "너의 아이디어를 먼저 해보자"라고 말하는 사람이다
페어 프로그래밍은 멘토링이 아니다. 절대 "선생과 학생"의 관계가 아니다
프로그램에 문제가 생겼을때, 각자 맡은 파트 또는 클래스가 엮여있을 경우 순서대로 해결하도록 한다. 엮여있는 팀은 앞의 팀이 문제를 해결할때까지 기다린다
모든 문제는 한 페어가 하나씩 커밋하도록 하고 최신 버전은 그 문제가 해결된 버전이어야 한다
저장소에 자주 커밋하도록 한다
분기되고 조각화된 개발에서 노력을 반으로 줄여준다
자주 공유함으로써 다른 팀원들이 최신 버전으로 작업할 수 있게 한다
인테그레이션은 유닛 테스트에도 영향을 준다
호환성 문제를 미리 방지할 수 있다
누가 언제 릴리스했는지 기록을 남겨둔다
모든 사람이 새로운 아이디어를 기여하고 함께 코드를 바꾸는 방식
릴리스 플래닝(Release Planning) : 요구사항정의서를 개발 언어로 바꾸는 작업, 테스팅 계획 및 리팩토링을 포함한다.
반복(Iteration) : 1~3주 정도의 개발 결과물을 보이는 기간, 개발일정을 여러개의 "반복"으로 나누어 민첩성을 높임(심장박동과 같다). 너무 먼 미래의 계획을 잡지말고 "반복 미팅"을 통해 "Just-in-time planning"을 세워라.
반복 플래닝(Iteration Planning) : 1 ~ 3일(필요하다면 1/2도 추가)동안 개발할 수 있는 단위로 쪼개서 계획을 세우는 것. 3일을 초과하는 개발은 세부적으로 쪼개도록 한다. 쪼개는 과정을 통해 Project velocity(프로젝트 진행속도)를 조절할 필요가 있다.
약속한 것을 확실히 실현하는 것
Because we have great control over our own destiny, we are more committed to success.
왜냐하면 우리는 우리의 운명을 훌륭하게 컨트롤할 수 있기 때문에, 성공을 더 확신할 수 있다
확약한 것의 실현에 전념하는 것
Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
왜냐하면 우리는 한번에 몇가지 적은 일에 집중하기 때문에, 함께 열심히 일하고 가치있는 제품을 빨리 내놓는다
어떤 것이 자신에게 불리해도 숨기지 않는 것
As we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed.
우리는 함께 일하기 때문에, 우리가 어떻게 일을 하고 있고, 앞으로 무엇이 예상되며, 어떻게 자리잡을 것인지에 대한 염려를 표현한다
자신과 다른 사람에게 경의를 표하는 것
As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.
우리는 함께 일하기 때문에, 성공과 실패를 공유하고, 서로를 존중하며, 서로를 돕는 것이 존중의 가치가 된다
위의 사항을 언제든지 지킬 수 있는 용기
Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
왜냐하면 우리는 팀으로 일하고, 서로 도움을 받으며, 우리의 재량권에 더 많은 가치를 둔다
http://www.agilemanifesto.org/iso/ko/
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
가입하기
