Flylib.com

Books Software

 
 
 

eXtreme Programming (XP)


eXtreme Programming (XP)

eXtreme Programming (XP) is one of the best-known agile processes. Created by Kent Beck, [22] it is considered by many to be " glorified hacking," but that is far from the case. XP is a disciplined approach, requiring skilled people who are committed to adhering closely to a core set of principles.

[22] Beck 2004.

XP is a disciplined approach, requiring skilled people adhering to a core set of principles.


XP articulates five values to guide you in your project: communication, simplicity, feedback, courage, and respect . Further, it prescribes a set of practices to make these values concrete. Although it may be unclear whether somebody really adheres to a value, you can easily tell whether somebody adheres to the practice. XP practices are divided into primary and secondary . The primary practices are listed below.

  • Sit together helps you to communicate more effectively by being physically collocated in the same room or office space.

  • Whole team talks about the importance of building a cohesive team with a diverse set of skills required to complete the project.

  • Informative workspace tells you that if an outsider spends 15 seconds in your workspace, he or she should be able to get a general idea of how the project is going. What are the issues you are facing and items you are working on?

  • Energized work guides you in adjusting your work hours so that you function effectively when working and avoid burnout.

  • Pair programming tells you to write all production code in pairs, with each person taking turns watching and assisting the other programmer write code.

  • Stories allow you to specify, in one or two sentences, capabilities that typically take one or two days to implement. The customer prioritizes which stories to implement and in what order.

  • Weekly cycle means that at the beginning of each week you plan what should be accomplished for that week by assessing status, prioritizing user stories, and dividing user stories into tasks that programmers sign up for.

  • Quarterly cycle allows you to step back and determine how to improve process, remove bottlenecks, focus on the big picture of where to take the projects, and do coarse-grained planning for the next quarter.

  • Slack is built in to the schedule as tasks that can be dropped or by assigning certain time slots as slack time.

  • Ten-minute build forces you to trim your automated build and automated tests so that they take no more than 10 minutes.

  • Continuous integration aims at reducing the overall cost of integration by forcing it to happen at least once every couple of hours.

  • Test-first programming tells you to write automated tests before writing the code to be tested .

  • Incremental design guides you in doing a little bit of design every day, but designing only for what you need today rather than for future possibilities.

XP also articulates a set of fourteen principles that function as the bridge between values and practices, guiding you in how to apply the practices effectively in order to adhere to the values. The principles are humanity, economics, mutual benefit, self-similarity , improvement, diversity, reflection, flow, opportunity, redundancy, failure, quality, baby steps, and accepted responsibility.



Scrum

Scrum [23] was introduced in 1996 by Ken Schwaber and Jeff Sutherland. [24] The term scrum is derived from rugby, in which it refers to restarting play after the game is stuck in a so-called maul. Scrum focuses on the management of a project without describing the specifics of how to undertake design, implementation, or testing. Consequently, it can be combined with a number of different processes, such as XP or RUP.

[23] Schwaber 2002.

[24] Scrum was formalized and presented at OOPSLA'96.

Scrum focuses on the management of a project.


Each iteration is 30 days long and is referred to as a sprint. The sprint starts with a half-day planning meeting to determine what should be done within the sprint. During the planning meeting, the Product Owner provides a prioritized Product Backlog , which is an evolving list containing all requirements, defects, tasks , and change requests . The development team will then determine how many of the high-priority items they can take on within that sprint, which constitutes the Sprint Backlog , and a sprint goal is crafted. The sprint goal provides the team with a clear focus by establishing an objective that will be met by implementing the backlog.

After the planning meeting, the team spends 29 days developing an executable that delivers incremental functionality. The sprint ends with a half-day Sprint Review Meeting, at which the team and management inspect the product increment together and capture lessons learned. The team will then start the next sprint, delivering an executable every 30 days that is one step closer to the final product.

During a sprint the team will get together for a daily 15-minute meeting, also called scrum. During the scrum, each team member will briefly answer three (and only three) questions:

  1. What have you done since last meeting?

  2. What will you do between now and next meeting?

  3. What obstacles stood in the way of doing work?

The "scrum master" makes sure that the meeting is kept on track, makes decisions as appropriate, and is also responsible for ensuring that identified obstacles are addressed as soon as possible. As issues arise that need further discussion, the scrum master sets up additional meetings with involved parties to continue the discussion, to ensure that the daily scrum is kept to 15 minutes. The scrum master also makes sure that no outside changes are imposed on the plan during a sprint, so that the team can focus on executing the plan without any distracting interruptions.

The team in scrum should have seven (give or take two) members . If your team has more, split the team into several teams and divide their work so that they can operate semi-independently. Scrum teams should be cross-functional so that each team can do the necessary analysis, design, implementation, testing, and documentation.

Scrum teams are self-organized, meaning that the team is left loose during the sprint to use whatever approach is considered appropriate to convert the Sprint Backlog to a product increment. Management should not intervene. At the end of the sprint, management can assess what was done and make changes as necessary.

Scrum focuses on collaboration. Open workspaces are preferred, and each team member should attend the daily scrum meeting in person. No titles or job descriptions are used, and people are asked to leave their egos at home.

Scrum focuses on collaboration. Each team member attends the daily scrum meeting.