Content deleted Content added
Closeapple (talk | contribs) |
m WP:CHECKWIKI error fixes + general fixes using AWB (7507) |
||
Line 10:
*Release Planning: This is focused on determining what requirements are included in which near-term releases, and when they should be delivered. The customers and developers are both part of this. Release Planning consists of three phases:
**Exploration Phase: In this phase the customer will provide a short list of high-value requirements for the system. These will be written down on [[user story]] cards.
**Commitment Phase: Within the commitment phase business and developers will commit themselves to the functionality that will be included and the date of the next release.
**Steering Phase: In the steering phase the plan can be adjusted, new requirements can be added and/or existing requirements can be changed or removed.
Line 54:
The business side sorts the user stories by business value. They will arrange them into three piles:
*Critical: stories without which the system cannot function or has no meaning.
*Significant [[Business Value]]: Non-critical user stories that have significant business value.
*Nice to have: User stories that do not have significant business value.
Line 62:
*Determine Risk Index: Give each user story an index from 0 to 2 on each of the following factors:
**Completeness (do we know all of the story details?)
***Complete (0)
***Incomplete (1)
***Unknown (2)
**Volatility (is it likely to change?)
***low (0)
Line 97:
*Programmer estimates the task: Because the programmer is now responsible for the task, he or she should give the eventual estimation of the task.
*Set load factor: The load factor represents the ideal amount of hands-on development time per programmer within one iteration. For example, in a 40-hour week, with 5 hours dedicated to meetings, this would be no more than 35 hours.
*Balancing: When all programmers within the team have been assigned tasks, a comparison is made between the estimated time of the tasks and the load factor. Then the tasks are balanced out among the programmers. If a programmer is overcommitted, other programmers must take over some of his or her tasks and vice versa.
===== Steering phase =====
Line 120:
==Continuous process==
=== Continuous integration ===
The development team should always be working on the latest version of the software. Since different team members may have versions saved locally with various changes and improvements, they should try to upload their current version to the code repository every few hours, or when a significant break presents itself. Continuous integration will avoid delays later on in the project cycle, caused by integration problems.
=== Design improvement ===
Because XP doctrine advocates programming only what is needed today, and implementing it as simply as possible, at times this may result in a system that is stuck. One of the symptoms of this is the need for dual (or multiple) maintenance: functional changes start requiring changes to multiple copies of the same (or similar) code. Another symptom is that changes in one part of the code affect lots of other parts. XP doctrine says that when this occurs, the system is telling you to [[refactoring|refactor]] your code by changing the architecture, making it simpler and more generic.
Line 129 ⟶ 130:
==Shared understanding==
=== Coding standard ===
Coding standard is an agreed upon set of rules that the entire development team agree to adhere to throughout the project. The standard specifies a consistent style and format for source code, within the chosen programming language, as well as various programming constructs and patterns that should be avoided in order to reduce the probability of defects.<ref>{{cite book | last = Kolawa | first = Adam | coauthors = Huizinga, Dorota | title = Automated Defect Prevention: Best Practices in Software Management | url = http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | year = 2007 | publisher = Wiley-IEEE Computer Society Press | ___location =| page=75| pages =426 | isbn = 0470042125 }}</ref>
=== Collective code ownership ===
Line 167 ⟶ 168:
*[http://www.xprogramming.com/xpmag/whatisxp.htm Ron Jeffries XP Practices]
{{DEFAULTSORT:Extreme Programming Practices}}
[[Category:Software development process]]
[[Category:Extreme Programming]]
| |||