Are you committed or involved?
As I mentioned in the previous post Scrum primarily focuses on management issues and in contrary XP mainly focuses on best practices which should be employed by team members to reach Agility goals. The combination is a better solution as Gabrielle Benefield have mentioned in his interview
[http://adtmag.com/articles/2008/01/31/lessons-from-a-yahoo-scrum-rollout.aspx]
"Agile is an umbrella of values and practices that different methods and practices live under. The most popular current is Scrum. Extreme programming is also popular and, when combined with Scrum, makes for a very powerful combination"
So I name this post as XP best practices.
Extreme Programming has been described as having 12 practices, grouped into four areas:
Fine scale feedback
* Pair programming
Pair programming is a development technique in which two programmers work together at one work station. One types code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer or navigator. The two programmers switch roles frequently (possibly every 30 minutes).
While reviewing, the observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide. Pair programming has its own drawbacks especially for novice developers.
The main planning process within Extreme Programming is called the planning game. The game is a meeting that occurs once per iteration, typically once a week. The planning process is divided into two parts:
- 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.
- Exploration Phase: Within this phase the requirement will be translated to different tasks. The tasks are recorded on task cards.
- Commitment Phase: The tasks will be assigned to the programmers and the time it takes to complete will be estimated.
- Steering Phase: The tasks are performed and the end result is matched with the original user story
Test-driven development (TDD) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration's tests. Finally, the programmer or team refactors the code to accommodate changes. A key TDD concept is that preparing tests before coding facilitates rapid feedback changes. Note that test-driven development is a software development method, not merely a method of testing
The sequence is as follows:
1) Add a test:In test-driven development, each new feature begins with writing a test
2) Run all tests and see if the new one fails
3) Write some code
4)Run the automated tests and see them succeed
5)Refactor code
* Whole team
Within XP, the "customer" is not the one who pays the bill, but the one who really uses the system. XP says that the customer should be on hand at all times and available for questions. For instance, the team developing a financial administration system should include a financial administrator.
Continuous process
* Continuous integration
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.
* Refactoring or 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 refactor your code by changing the architecture, making it simpler and more generic.
* Small releases
The delivery of the software is done in predetermined releases (sometimes called 'Builds'). The release plan is determined when initiating the project. Usually each release will carry a small segment of the total software, which can run without depending on components that will be built in the future. The small releases help the customer to gain confidence in the progress of the project. The small releases are only alpha releases and are not intended to go live. This helps maintain the concept of the whole team as the customer can now come up with his suggestions on the project.
Shared understanding
* Coding standards
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[2]. The coding standard may be a standard conventions specified by the language vendor (e.g The Code Conventions for the Java Programming Language, recommended by Sun), or custom defined by the development team
* Collective code ownership
Collective code ownership means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code. Pair programming contributes to this practice: by working in different pairs, all the programmers get to see all the parts of the code. A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it.
By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies. Sufficiently well defined unit tests address this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures.
* Simple design
Programmers should take a "simple is best" approach to software design. Whenever a new piece of code is written, the author should ask themselves 'is there a simpler way to introduce the same functionality?'. If the answer is yes, the simpler course should be chosen. Refactoring should also be used, to make complex code simpler.
* System metaphor
The system metaphor is a story that everyone - customers, programmers, and managers - can tell about how the system works. It's a naming concept for classes and methods that should make it easy for a team member to guess the functionality of a particular class/method, from its name only. For example a library system may create loan_records(class) for borrowers(class), and if the item were to become overdue it may perform a make_overdue operation on a catalogue (class). For each class or operation the functionality is obvious to the entire team.
Programmer welfare
* Sustainable pace
The concept is that programmers or software developers should not work more than 40 hour weeks, and if there is overtime one week, that the next week should not include more overtime. Since the development cycles are short cycles of continuous integration, and full development (release) cycles are more frequent, the projects in XP do not follow the typical crunch time that other projects require (requiring overtime).
Also, included in this concept is that people perform best and most creatively if they are rested.
A key enabler to achieve sustainable pace is frequent code-merge and always executable & test covered high quality code. The constant refactoring way of working enforces team members with fresh and alert minds. The intense collaborative way of working within the team drives a need to recharge over weekends.
Well-tested, continuously integrated, frequently deployed code and environments also minimize the frequency of unexpected production problems and outages, and the associated after-hours nights and weekends work that is required.
Coding
* The customer is always available
* Code the Unit test first
* Only one pair integrates code at a time
* Leave Optimization till last
* No Overtime
Testing
* All code must have Unit tests
* All code must pass all Unit tests before it can be released.
* When a Bug is found tests are created
* Acceptance tests are run often and the results
No comments:
Post a Comment