A release planning meeting is used to create a release plan, which lays out the overall project. The release plan is then used to create iteration plans for each individual iteration.
릴리즈 계획은 프로젝트의 전반적인 계획을 다룬다. 릴리즈 계획은 개별 반복에 대한 반복 계획을 포함한다.
It is important for technical people to make the technical decisions and business people to make the business decisions. Release planning has a set of rules that allows everyone involved with the project to make their own decisions. The rules define a method to negotiate a schedule everyone can commit to.
기술자들이 기술적인 결정을 내리고 현업 사람이 업무에 대한 결정을 내리는 것은 매우 중요한 일이다. 릴리즈 계획은 몇가지 규칙을 갖고 있는데 이것은 프로젝트에 참여한 모든 사람이 자신의 결정을 내리게 한다. 이러한 규칙은 각각이 수행할 계획을 협상하는 방법을 담고 있다.
The essence of the release planning meeting is for the development team to estimate each user story in terms of ideal programming weeks. An ideal week is how long you imagine it would take to implement that story if you had absolutely nothing else to do.
No dependencies, no extra work, but do include tests. The customer then decides what story is the most important or has the highest priority to be completed.
No dependencies, no extra work, but do include tests. The customer then decides what story is the most important or has the highest priority to be completed.
릴리즈 계획 회의의 핵심은 개발팀이 각 사용자 스토리에 대하여 이상적으로 프로그래밍 했을때 소요되는 시간을 예측하는 것이다.
이상적인 기간은 다른 업무 없이 이 스토리를 구현하기 위하여 필요한 일정을 개발자가 추정하는 것이다.
다른 것에 종속되지 않고, 다른 없무도 없이 테스트를 포함한다. 고객은 어떤 스토리가 가장 중요한지 또는 우선순위가 높은지를 결정한다.
이상적인 기간은 다른 업무 없이 이 스토리를 구현하기 위하여 필요한 일정을 개발자가 추정하는 것이다.
다른 것에 종속되지 않고, 다른 없무도 없이 테스트를 포함한다. 고객은 어떤 스토리가 가장 중요한지 또는 우선순위가 높은지를 결정한다.
User stories are printed or written on cards. Together developers and customers move the cards around on a large table to create a set
of stories to be implemented as the first (or next) release. A useable, testable system that makes good business sense delivered early is desired.You may plan by time or by scope. The project velocity is used to determine either how many stories can be implemented before a given date (time) or how long a set of stories will take to finish (scope). When planning by time multiply the number of iterations by the project velocity to determine how many user stories can be completed. When planning by scope divide the total weeks of estimated user stories by the project velocity to determine how many iterations till the release is ready.
of stories to be implemented as the first (or next) release. A useable, testable system that makes good business sense delivered early is desired.You may plan by time or by scope. The project velocity is used to determine either how many stories can be implemented before a given date (time) or how long a set of stories will take to finish (scope). When planning by time multiply the number of iterations by the project velocity to determine how many user stories can be completed. When planning by scope divide the total weeks of estimated user stories by the project velocity to determine how many iterations till the release is ready.
사용자 스토리는 출력하던지 아니면 카드위에 쓴다. 고객과 개발자는 함께 카드들을 테이블에서 이리저리 옮기면서 첫번째 또는 다음 릴리즈시 구현될 스토리를 만든다.
Individual iterations are planned in detail just before each iteration begins and not in advance. The release planning meeting was called the planning game and the rules can be found at the Portland Pattern Repository.
When the final release plan is created and is displeasing to management it is tempting to just change the estimates for the user stories. You must not do this. The estimates are valid and will be required as-is during the iteration planning meetings. Underestimating now will cause problems later. Instead negotiate an acceptable release plan. Negotiate until the developers, customers, and managers can all agree to the release plan.The base philosophy of release planning is that a project may be quantified by four variables; scope, resources, time, and quality. Scope is how much is to be done. Resources are
Management can only choose 3 of the 4 project variables to dictate, development always gets the remaining variable. Note that lowering quality less than excellent has unforeseen impact on the other 3. In essence there are only 3 variables that you actually want to change. Also let the developers moderate the customers desire to have the project done immediately by hiring too many people at one time.
