You are on page 1of 54

Week 3 Readings

PDF generated using the open source mwlib toolkit. See for more information. PDF generated at: Wed, 27 Mar 2013 04:06:29 UTC

Scrum (development) Crystal Clear (software development) Lean software development Extreme programming Feature-driven development Test-driven development Shane (name) 1 12 13 18 28 38 47

Article Sources and Contributors Image Sources, Licenses and Contributors 50 51

Article Licenses
License 52

Scrum (development)


Scrum (development)
Software development process

A software developer at work Activities and steps
• • • • • • • • •

Requirements Specification Architecture Construction Design Testing Debugging Deployment Maintenance Methodologies

• • • • • • • • • • • • • • • • •

Waterfall Prototype model Incremental Iterative V-Model Spiral Scrum Cleanroom RAD DSDM RUP XP Agile Lean Dual Vee Model TDD FDD Supporting disciplines

• • • • •

Configuration management Documentation Quality assurance (SQA) Project management User experience design

Scrum (development)

• • • • • •

Compiler Debugger Profiler GUI designer IDE Build automation

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Its focus is on "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach".

Scrum was first defined as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach" in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the "New New Product Development Game".[1] Hirotaka Takeuchi and Ikujiro Nonaka later argued in "The Knowledge Creating Company"[2] both by Ikujiro Nonaka and Hirotaka Takeuchi that it is a form of "organizational knowledge creation, [...] especially good at bringing about innovation continuously, incrementally and spirally". The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier and printer industries.[] They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team "tries to go the distance as a unit, passing the ball back and forth".[] In rugby football, a scrum refers to the manner of restarting the game after a minor infraction. In the early 1990s, Ken Schwaber used what would become Scrum at his company, Advanced Development Methods, and Jeff Sutherland, with John Scumniotales and Jeff McKenna, developed a similar approach at Easel Corporation, and were the first to refer to it using the single word Scrum.[] In 1995, Sutherland and Schwaber jointly presented a paper describing the Scrum methodology at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) in Austin, Texas, its first public presentation.[3] Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum. In 2001, Schwaber worked with Mike Beedle to describe the method in the book Agile Software Development with Scrum.[4] Its approach to planning and managing projects is by bringing decision-making authority to the level of operation properties and certainties.[] Although the word is not an acronym, some companies implementing the process have been known to spell it with capital letters as SCRUM. This may be due to one of Ken Schwaber's early papers, which capitalized SCRUM in the title.[]

Scrum (development)


There are three core roles[5] and a range of ancillary roles—core roles are often referred to as pigs and ancillary roles as chickens (after the story The Chicken and the Pig). The core roles are those committed to the project in the Scrum process—they are the ones producing the product (objective of the project). They represent the scrum team. Product Owner The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and while they may also be a member of the development team, it is recommended that this role not be combined with that of ScrumMaster. Development Team The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.). The Development Team in Scrum is self-organizing, even though they may interface with project management organizations (PMOs). ScrumMaster Scrum is facilitated by a ScrumMaster, who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the team leader, but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster's role is to protect the Development Team and keep it focused on the tasks at hand. The role has also been referred to as a servant-leader to reinforce these dual perspectives. The ScrumMaster differs from a Project Manager in that the latter may have people management responsibilities unrelated to the role of ScrumMaster. The ScrumMaster role excludes any such additional people responsibilities. The ancillary roles in Scrum teams are those with no formal role and infrequent involvement in the Scrum process—but nonetheless, they must be taken into account. Stakeholders The stakeholders are the customers, vendors. They are people who enable the project and for whom the project produces the agreed-upon benefit[s] that justify its production. They are only directly involved in the process during the sprint reviews. Managers People who control the work environment.

A sprint is the basic unit of development in Scrum. The sprint is a "timeboxed" effort, i.e. it is restricted to a specific duration.[] The duration is fixed in advance for each sprint and is normally between one week and one month.[] Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and followed by a review or retrospective meeting,[] where the progress is reviewed and lessons for the next sprint are identified.

The Scrum process

This is called a daily scrum. the team demonstrates how to use the software. Like other agile development methodologies. each team member answers three questions:[7] • What have you done since yesterday? • What are you planning to do today? • Any impediments/stumbling blocks? Any impediment/stumbling block identified in this meeting is documented by the ScrumMaster and worked towards resolution outside of this meeting. and records this in the sprint backlog. As such. The sprint goals should not be changed during the sprint.[] The sprint backlog is property of the development team. and verbal communication between all team members and disciplines in the project. This choice of location lets the team start on time . but normally only the core roles speak During the meeting.e. i. During this meeting. Which backlog items go into the sprint (the sprint goals) is determined during the sprint planning meeting. whiteboards. No detailed discussions shall happen in this meeting. Development is timeboxed such that the sprint must end on time. and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn). Scrum enables the creation of self-organizing teams by encouraging co-location of all team members. a project team communication meeting occurs. Other organizations implement Scrum without the use of any tools. and sticky notes. The team then determines how much of this they can commit to complete during the next sprint. There are also open-source and proprietary packages dedicated to management of products under the Scrum process. This meeting has specific guidelines: • All members of the development Team come prepared with the updates for the meeting • The meeting starts precisely on time even if some development team members are missing • The meeting should happen at the same location and same time every day • The meeting length is set (timeboxed) to 15 minutes • All are welcome. the Product Owner informs the team of the items in the product backlog that he or she wants completed (the ones with the highest priority). such as spreadsheets to build and maintain artifacts such as the sprint backlog. A daily scrum meeting in the computing room. during a sprint. no one is allowed to edit the sprint backlog except for the development team.Scrum (development) During each sprint. or the daily standup. Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined.[6] 4 Meetings Daily Scrum Each day during the sprint. if requirements are not completed for any reason they are left out and returned to the product backlog. which is an ordered list of requirements. The set of features that go into a sprint come from the product backlog. focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements. and maintain their artifacts in hard-copy forms such as paper. the team creates finished portions of a product. After a sprint is completed. Scrum can be implemented through a wide range of tools. Many companies use universal tools.

plus the following four questions: • What has your team done since we last met? • What will your team do before we meet again? • Is anything slowing your team down or getting in their way? • Are you about to put something in another team's way? Sprint planning meeting At the beginning of the sprint cycle (every 7–30 days). a "Sprint planning meeting" is held:[][8] • • • • Select what work is to be done Prepare the Sprint Backlog that details the time it will take to do that work. This is the process of estimating the existing backlog using effort/points.a. two meetings are held: the "Sprint Review Meeting" and the "Sprint Retrospective". The most commonly used method is the planning poker. Scrum of Scrums Each day normally after the Daily Scrum: • These meetings allow clusters of teams to discuss their work. "the demo") Incomplete work cannot be demonstrated Four-hour time limit At the Sprint Retrospective:[12] • All team members reflect on the past sprint • Make continuous process improvements • Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint? • Three-hour time limit • This meeting is facilitated by the ScrumMaster . At the Sprint Review Meeting:[11] • • • • Review the work that was completed and not completed Present the completed work to the stakeholders (a. and breaking larger stories into smaller stories: • Meetings should not be longer than an hour • Meeting does not include breaking stories into tasks • The team can decide how many meetings are needed per week. focusing especially on areas of overlap and integration. refining the acceptance criteria for individual stories. resulting in the Sprint Backlog End of cycle At the end of a sprint cycle. • A designated person from each team attends.Scrum (development) 5 Backlog grooming: storytime The team should spend time during a sprint doing product backlog grooming. The agenda will be the same as the Daily Scrum. with the entire team Identify and communicate how much of the work is likely to be done during the current sprint Eight-hour time limit • (1st four hours) Entire team:[9] dialog for prioritizing the Product Backlog • (2nd four hours) Development Team:[10] hashing out a plan for the Sprint.k.

business value. sorted in the relative order it should be built in. Often an accompanying task board is used to see and change the state of the tasks of the current sprint. however. and all included estimates are provided by the Development Team. determined by the Development Team. the one with the smallest development effort will probably have higher priority. dependencies. The Product Backlog. as a best practice. anyone can pick a task from the list. which. etc. The sprint backlog is the property of the Development Team. . The stories/features are broken down into tasks by the Development Team. Sprint Backlog The sprint backlog is the list of work the Development Team must address during the next sprint. because the ROI (Return on Investment) is higher. The Development Team should keep in mind the velocity of its previous Sprints (total story points completed from each of the last sprints stories) when selecting stories/features for the new sprint. but the Product Owner is ultimately responsible for ordering the stories on the backlog for the Development Team. For example. This promotes self-organization of the Development Team. like "to do". With this level of detail the Development Team understands exactly what to do. The list is derived by selecting stories/features from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. It is open and editable by anyone. Tasks on the sprint backlog are never assigned. and business value of each listed item is the responsibility of the Product Owner. The features added to the backlog are commonly written in story format (See terminology below). It contains Product Backlog Items that are ordered by the Product Owner based on considerations like risk. should normally be between four and sixteen hours of work. date needed. and use this number as a guide line of how much "effort" they can complete. either in Story-points or in estimated hours. The product backlog contains rough estimates of both business value and development effort. rather. and developer buy-in. and potentially. The product backlog is the "What" that will be built. Those estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items. these values are often stated in story points using a rounded Fibonacci sequence. The estimated effort to complete each backlog item is. "in progress" and "done". This is done by the Development Team asking "Can we also do this?" and adding stories/features to the sprint backlog. if the "add spellcheck" and "add table support" features have the same business value. according to the set priority and the Development Team member skills. The team contributes by estimating Items and User-Stories. A scrum task board tasks are signed up for by the team members as needed during the daily scrum.Scrum (development) 6 Artifacts Product Backlog The product backlog is an ordered list of "requirements" that is maintained for a product.

Updated every day. ScrumMaster The person responsible for the Scrum process. (User) Story . Burn down The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. ScrumMaster and Development Team Product Owner The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders. it gives a simple view of the sprint progress. Sprint backlog A prioritized list of tasks to be completed during the sprint. but clearly shows scope changes to Release Content. Release burn down chart Sprint level progress of completed stories in the Product Backlog.[13] which basically does the same. There are also other types of burndown.Scrum (development) 7 Increment The increment is the sum of all the Product Backlog Items completed during a sprint and all previous sprints. showing remaining effort and tasks for each of the 21 work days of the 1-month iteration Terminology The following terminology is used in Scrum:[14] Scrum Team Product Owner. Sprint A time period (typically 1–4 weeks) in which development occurs on a set of backlog items that the team has committed to. The increment must be in usable condition regardless of whether the Product Owner decides to actually release it. for example the release burndown chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the alternative release burndown chart. Development Team A cross-functional group of people responsible for delivering potentially shippable increments of Product at the end of every Sprint. At the end of a sprint. the Increment must be done according to the Scrum Team's definition of done. by resetting the baseline. It also provides quick visualizations for reference. It should not be confused with an earned value chart. and ensuring the value of the work the Development Team does. Product backlog A prioritized list of high-level requirements. making sure it is used correctly and maximizing its benefits. Also commonly referred to as a Time-box or iteration. A sample burn down chart for a completed iteration. Sprint burn down chart Daily progress for a Sprint over the sprint's length.

negotiable. testable requirement ("INVEST"). current technology set. Velocity 8 .20. Each task should not exceed 12 hours. valuable. Spikes can either be planned to take place in between sprints or.8. S. For example. It is of production quality and the rest of the iterations can build on this code. Spikes are often introduced before the delivery of large epics or user stories in order to secure budget. Often these implementations are a 'quick shot' through all layers of an application. shippable.3.2.8. Theme A theme is a top-level objective that may span projects and products.13. Point Scale/Effort/Story points Relates to an abstract point system. which are more likely to be product-specific.4. estimable. Unlike sprint commitments.5.3. but it's common for teams to insist that a task take no more than a day to finish. although some teams use linear scale (1. L. action and required result in a request and is a simple way of writing requests that anyone can understand. Definition of Done (DoD) The exit-criteria to determine whether a product backlog item is complete. It might just be a very narrow implementation of the functionality but is not throw away code. Example: As a wiki user I want a tools menu on the edit screen so that I can easily apply font formatting. the objective of a spike might be to successfully reach a decision on a course of action. such as connecting a single form's input field to the back-end. Despite being independent i. powers of two (1. Themes may be broken down into sub-themes. The most common scale used is a rounded Fibonacci sequence (1. spikes may or may not deliver tangible..e. and clothes size (XS. to prove the layers will connect as expected. mainly used in product roadmaps and the backlog for features that have not yet been analyzed enough to break down into component stories. Themes can be used at both program and project level to drive strategic alignment and communicate a clear direction. for larger teams. The structure of a story is: "As a <user type> I want to <do some action> so that <desired result>" This is done so that the development team can identify the user. The spike is over when the time is up. which should be done before bringing it into a sprint so to reduce uncertainty. small. The duration and objective(s) of a spike will be agreed between the Product Owner and Delivery Team before the start.).4. stories may be clustered into epics when represented on a product roadmap or further down in the backlog.2. valuable functionality. M..). expand knowledge. The name has military origins as ammunition that makes the path of the weapon visible. Spike A time boxed period used to research a concept and/or create a simple prototype. current set of best practices which results in production quality code. they have no direct dependencies with other requirements.100)...Scrum (development) A feature that is added to the backlog is commonly referred to as a story and has a specific suggested structure. allowing for corrections. not necessarily when the objective has been delivered. without assigning actual hours. Tracer Bullet The tracer bullet is a spike with the current architecture. used to discuss the difficulty of the story. Epic An epic is a group of related stories.40. Epics can also be used at a both program and project level.[] Tasks Added to the story at the beginning of a sprint and broken down into hours. In many cases the DoD requires that all regression tests should be successful. A story is an independent.2. XL). a spike might be accepted as one of many sprint delivery objectives. and/or produce a proof of concept.

as a result. the tasks or usage stories are categorized into the work stages: • Unstarted • Ongoing • Completed If desired. The definition of "done" may vary from one Scrum team to another. The Product Owner needs these estimates.[] There are no set limiting values for unfinished work.[15] Sashimi A report that something is "done". which in turn hinders completion times. management may wish to cancel a sprint if external circumstances negate the value of the sprint goal. the teams can add more stages of work (such as "defined". so that he or she is empowered to effectively prioritize items in the backlog and. For instance. but Scrum's daily meetings and other practices can be applied. If a sprint is abnormally terminated. Planning Poker In the Sprint Planning Meeting. Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected user stories or programming errors. ScrumWorks.[] ScrumBut A ScrumBut (or Scrum But) is an exception to the "pure" Scrum methodology. ScrumMaster or management. and on the other hand ensures each team member is constantly employed.[21] A rule of thumb worth bearing in . teams working in the same space often use post-it notes or a large whiteboard. In such cases the time-limited sprints of the Scrum model are of no appreciable use. Visualization of the work stages and limitations for simultaneous unfinished user stories and defects are familiar from the Kanban model.[16] The Product Owner may do so with input from the team. The number is derived by adding all the story points from the last sprint's stories/features. In their simplest. Using these methods. "designed". where a team has changed the methodology to adapt it to their own needs. This is a guideline for the team and assists them in understanding how many stories they can do in a sprint. where the reason for the termination is reviewed. Abnormal Termination The Product Owner can cancel a Sprint if necessary. a value too small results in workers standing idle for lack of work. Rational Team Concert or JIRA in combination with GreenHopper can be used to visualize each team's user stories. the team sits down to estimate its effort for the stories in the backlog. but must be consistent within one team.[17][18] 9 Scrum-ban Scrum-ban is a software production model based on Scrum and Kanban. defects and tasks divided into separate phases. the next step is to conduct a new Sprint planning meeting. though. stage-illustration such as Assembla. A more specific task division also makes it possible for employees to specialize in a certain phase of work. These additional phases can be of assistance if a certain part of the work becomes a bottleneck and the limiting values of the unfinished work cannot be raised. forecast releases based on the team's velocity.Scrum (development) The total effort a team is capable of in a sprint. Instead.[20] In the case of decentralized teams. each team has to define them individually by trial and error. whereas values too high tend to accumulate large amounts of unfinished work. Impediment Anything that prevents a team member from performing work as efficiently as possible.[19] To illustrate each stage of work. "tested" or "delivered"). depending on the team and the situation at hand. the team's workflow is directed in a way that allows for minimum completion time for each user story or programming error.

scrum. work is divided into sprints that last a certain amount of time. whereas Kanban makes specialized. Benefield. Larman.[] The major differences between Scrum and Kanban are derived from the fact that. Scrum focuses on teams with multifaceted know-how.pdf). "Software Process Definition and Management" (http://www.cox. This is visible in work stage tables. 137 [12] Schwaber. • Münch. Armbrust. "The Scrum Primer" (http:// scrumtraininginstitute. 2009. 2000. IEEEScrum. Retrieved December 3. 133 [11] Schwaber. Gabrielle. 2011. Martín. Henrik. with a plug-in (several are available) Microsoft Visual Studio 2010/2012. Jürgen. Kanban. whereas in Kanban the workflow is continuous. Soto. such as sub-projects or features. • Deemer. • Kniberg. Retrieved July 2011. Pete. by Jetbrains[24] Notes [7] Schwaber. Retrieved June 1. p. "Scrum and XP from the Trenches" (http://www. Retrieved March 15. on the other hand. 2010. p. Bas (2009). 2007.[23] 10 Project management tools that support scrum Tools that support Scrum include: • • • • • • • • • • • Agilo for Trac Assembla codeBeamer IBM Rational Team Concert JIRA using GreenHopper[24] plugin[25] Mingle[24] OnTime. In Kanban all tasks are marked on the same table.infoq. and that on the other hand not all team members should have two tasks simultaneously. 141–143 [24] Tools that also offer optional horizontal "swimlanes" or "pipelines" across the vertical columns of the board for different dimensions of work. pp. Ove. p. Retrieved August 9. functional teams possible.springer.Scrum (development) mind is that no team member should have more than two simultaneous selected scrum-xp-from-the-trenches). by Axosoft Pivotal Tracker Redmine and ChiliProject. p.[22] Since Scrum-ban is such a new development model. 2012. there is not much reference material. allowing a scrum or Kanban board to be a two-dimensional matrix. Kowalczyk. has been applied by Microsoft and Corbis. . in Scrum. which in Scrum are emptied after each sprint. 138 [14] Schwaber. Team Foundation Server 2010/2012 YouTrack. 135 [8] Schwaber. References Further reading • "The Scrum Guide" (http://www. Vodde. • "The Scrum Software Development Process for Small Teams" ( Guides/ Martin (2012). software-development/burn-down-charts-tutorial-simple-agile-project-tracking/) • Scrum Development Interview Questions and Answers ( • Agile Alliance's Scrum library ( • Burn Down Chart Tutorial: Simple Agile Project Tracking (Scrum) ( Starting Tough Conversations about Agile Software Development • ( software-development-testing-models/scrum. org/Scrum-Guides) • Scrum scrum-at-large-managing-100-people-and-more/) • Andrea Tomasini's keynote about Agile in an Enterprise ( 2010-08-09-bpm-view-scrum) • A six-page illustrated Scrum reference ( non-profit ( .cfm?CategoryID=17) • A Scrum Process Description (http://epf.Scrum (development) 11 External links • ImplementingScrum.aspx) • Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google ( watch?v=Ht2xcIJrAXo) • Jeff Sutherland in Self-Organization: The Secret Sauce for Improving your Scrum team ( ( • BPMN process diagram of Scrum ( the home for Scrum Guides in multiple languages ( adopting-scrum-an-enterprise-transformation) • Scrum Training Series: Scrum Tutorial ( by the Eclipse Process Framework (EPF) Project ( ( Retrieved 2009-05-19 • Scrum at Large: Managing 100 People and More (http://www. com/videoplay?docid=8795214308797356840) Retrieved 2007-12-15 • Ken Schwaber in Scrum et al. com/watch?v=M1q6b9JI2Wc) • Bruno Sbille and his team in Scrum applied on a real-world project (HD) ( Retrieved 2008-01-19 • Jeff Sutherland in Hyperproductive Distributed Scrum Teams (http://www.

com/ methodologies/ crystal-methods. ISBN to the Crystal family of methodologies • A quick overview (http://www.Crystal Clear (software development) 12 Crystal Clear (software development) Crystal Clear is a member of the Crystal family of methodologies as described by Alistair Cockburn and is considered an example of an agile or lightweight A Human-Powered Methodology for Small Teams. Addison-Wesley Professional. The Crystal family of methodologies focus on efficiency and habitability as components of project safety.agilekiwi. • Alistair Cockburn's introduction (http://alistair. October 2004. Crystal Clear requires the following properties: • Frequent delivery of usable code to users • Reflective improvement • Osmotic communication preferably by being co-located Crystal Clear additionally includes these optional properties: • • • • Personal safety Focus Easy access to expert users Automated tests.cockburn. mariosalexandrou. Alistair Cockburn. pages 336. not processes or artifacts.htm) with links to sample chapters from the book . and frequent integration References [1] http:/ / www. configuration management. asp Further reading • Crystal Clear.[1] Crystal Clear focuses on people. Crystal Clear can be applied to teams of up to 6 or 8 co-located developers working on systems that are not life-critical. paperback.

Lean software development 13 Lean software development Software development process A software developer at work Activities and steps • • • • • • • • • Requirements Specification Architecture Construction Design Testing Debugging Deployment Maintenance Methodologies • • • • • • • • • • • • • • • • • Waterfall Prototype model Incremental Iterative V-Model Spiral Scrum Cleanroom RAD DSDM RUP XP Agile Lean Dual Vee Model TDD FDD Supporting disciplines • • • • • Configuration management Documentation Quality assurance (SQA) Project management User experience design .

leading to avoidable process repetition bureaucracy slow internal communication In order to be able to eliminate waste. . Eliminate waste Amplify learning Decide as late as possible Deliver as fast as possible Empower the team Build integrity in See the whole Eliminate waste Everything not adding value to the customer is considered to be waste (muda). 2. one should be able to recognize it. The second step is to point out sources of waste and eliminate them. The book presents the traditional lean principles in a modified form. 6. 3. Origin The term lean software development originated in a book by the same name. including talks at several Agile conferences has resulted in such concepts being more widely accepted within the Agile community. 7. teams. a pro-lean subculture is emerging from within the Agile community. A value stream mapping technique is used to distinguish and recognize waste. Extra processes and features not often used by customers are waste. The Poppendiecks' involvement in the Agile software development community. This includes: • • • • • • unnecessary code and functionality delay in the software development process unclear requirements insufficient testing. 5. Lean principles Lean development can be summarized by seven principles. Managerial overhead not producing real value is waste. it is waste. very close in concept to lean manufacturing principles: 1. Defects and lower quality are waste. Waiting for other activities. Partially done coding eventually abandoned during the development process is waste. Adapted from the Toyota Production System. as well as a set of 22 tools and compares the tools to agile practices. If some activity could be bypassed or the result could be achieved without it. written by Mary Poppendieck and Tom Poppendieck. The same should be done iteratively until even essential-seeming processes and procedures are liquidated. processes is waste.Lean software development 14 Tools • • • • • • Compiler Debugger Profiler GUI designer IDE Build automation Lean software development is a translation of lean manufacturing and lean IT principles and practices to the software development domain. 4.

Customers value rapid delivery of a quality product. This requires transparency of the process. what is to be done today and tomorrow. decisions cannot be delayed. The shorter the iterations. different ideas could be tried by writing code and building. The accumulation of defects should be prevented by running tests as soon as the code is written. delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions. each member of the team reviews what has been done yesterday. The best approach for improving a software development environment is to amplify learning. Increasing feedback via short feedback sessions with customers helps when determining the current phase of development and adjusting efforts for future improvements. recognizing its specific requirements and environment. This also allows later adaptation to changes and the prevention of costly earlier technology-bounded decisions. thus delaying certain crucial decisions until customers have realized their needs better. At the beginning. the more capacity for change should be built into it. and incorporated into the next iteration. the customer provides the needed input. This could be simply presented in small cards or stories – the developers estimate the time needed for the implementation of each card. as well as clarifying confusing situations by establishing patterns for rapid action. the sooner feedback can be received. but provide the needed flexibility for late decision making. Instead of adding more documentation or detailed planning. Without speed. thus enabling the delay of important and crucial commitments. The iterative approach promotes this principle – the ability to adapt to changes and correct mistakes. but the fastest. planning activities should be concentrated on the different options and adapting to the current situation. Evaluating different options is effective as soon as it is realized that they are not free. and prompts for any inputs needed from colleagues or the customer. Thus the work organization changes into self-pulling system – each morning during a stand-up meeting. An agile software development approach can move the building of options earlier for customers. Thus the customers better understand their needs. based on the existing result of development efforts. This does not mean that no planning should be involved – on the contrary. The sooner the end product is delivered without considerable defect. This gives them the opportunity to delay making up their minds about what they really require until they gain better knowledge. During those short sessions both customer representatives and the development team learn more about the domain problem and figure out possible solutions for further development. Another key idea in Toyota's Product . The more complex a system is. The learning process is sped up by usage of short iteration cycles – each one coupled with refactoring and integration testing. The just-in-time production ideology could be applied to software development. which is also beneficial for team communication. Decide as late as possible As software development is always associated with some uncertainty. and the developers learn how to better satisfy those needs. which might be very costly if discovered after the release of the system. The process of user requirements gathering could be simplified by presenting screens to the end-users and getting their input. better results should be achieved with an options-based approach. the better the learning and communication within the team. This is achieved by presenting the needed result and letting the team organize itself and divide the tasks for accomplishing the needed result for a specific iteration.Lean software development 15 Amplify learning Software development is a continuous learning process with the additional challenge of development teams and end product sizes. Another idea in the communication and learning process with a customer is set-based development – this concentrates on communicating the constraints of the future solution and not the possible solutions. Speed assures the fulfilling of the customer's present needs and not what they required yesterday. thus promoting the birth of the solution via dialogue with the customer. Deliver as fast as possible In the era of rapid technology evolution. it is not the biggest that survives.

The more features are added to the System. The complete and automated building process should be accompanied by a complete and automated suite of developer and customer tests. perhaps with some modifications based on learning from the others ." encouraging progress. and therefore if they do not add value they should be considered waste. and by standardizing different stages of development. as well as any organizational business. clarity. At the end the integrity should be verified with thorough testing. The information flow should be constant in both directions – from customer to developers and back. and responsiveness. thus ensuring the System does what the customer expects it to. but in software development. the greater the importance of having well defined relationships between different vendors. Another mistaken belief has been the consideration of people as resources. the more organisations that are involved in its development and the more parts are developed by different teams. delivered. The needed information is received in small batch pieces – not in one vast chunk with preferable face-to-face communication and not any written documentation. accessed. having the same versioning. the roles are turned – the managers are taught how to listen to the developers. so they can explain better what actions might be taken. At the end of a period. See the whole Software systems nowadays are not simply the sum of their parts. 16 Empower the team There has been a traditional belief in most businesses about the decision-making in the organization – the managers tell the workers how to do their own job. not sequentially.a great example of deferring commitment until the last possible moment. efficiency. deployed. price and how well it solves problems. it is cut.Lean software development Development System is set-based design. thus avoiding the large stressful amount of information after long development in isolation. but rather a means to an end. and removing impediments. The developers should be given access to the customer. the root causes of defects should be found and eliminated. the more loose the starting code base for further improvements. Build integrity in The customer needs to have an overall experience of the System – this is the so called perceived integrity: how it is being advertised. People might be resources from the point of view of a statistical data sheet. Defects in software tend to accumulate during the development process – by decomposing the big tasks into smaller tasks. In a Work-Out technique. Repetitions in the code are signs for bad code designs and should be avoided. Refactoring is about keeping simplicity. Each team learns about the problem space and designs a potential solution. As a solution is deemed unreasonable. People need motivation and a higher purpose to work for – purpose within the reachable reality. but also the product of their interactions. Automated testing should not be a goal. catching errors. synchronization and semantics as the current state of the System. minimum amount of features in the code. The lean approach favors the aphorism "find good people and let them do their own job. as well as provide suggestions for improvements. Conceptual integrity means that the system’s separate components work well together as a whole with balance between flexibility. the surviving designs are compared and one is chosen. as well as ensure that skepticism does not ruin the team’s spirit. in order . Automated tests are also considered part of the production process. The larger the system. Software decisions could also benefit from this practice to minimize the risk brought on by big up-front design. If a new brake system is needed for a car. three teams may design solutions to the same problem. how intuitive its use is. for example. people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks. with the assurance that the team might choose its own commitments. This could be achieved by understanding the problem domain and solving it at the same time. maintainability. specifically the reduction of defects. the team leader should provide support and help in difficult situations. but not micro-managing. One of the healthy ways towards integral architecture is refactoring.

"Think big. References • Yasuhiro Monden (1998). for example are expressed in Agile methods as cross-functional teams. Scrumban: Essays on Kanban Systems for Lean Software Development (http:// moduscooperandi. ISBN 0-412-83930-X. Third edition. Examples of such practices include: • • • • Seeing waste Value stream mapping Set-based development Pull systems • Queuing theory • Motivation • Measurements Some of the tools map quite easily to agile methods. Tom Poppendieck (2003). During a longer period of development. combined with strong "common sense" with respect to the working environment. 17 Lean software practices Lean software development practices. ISBN 0-578-00214-0. Modus Cooperandi Press. Lean thinking has to be understood well by all members of a project. real-life situation. before implementing in a concrete. is there a basis for success in software development. or what the Poppendiecks call "tools" are expressed slightly differently from their equivalents in agile software development. ISBN 0-321-15078-3 • Ladas. Addison-Wesley Professional. An Integrated Approach to which does not enable win-win relationships. • Mary Poppendieck. Lean Workcells. Toyota Production System. "Lean Software Development: An Agile Toolkit". act small. Norcross. GA: Engineering & Management Press.Lean software development to produce a system with smoothly interacting components. . a stronger subcontractor network is far more beneficial than short-term profit optimizing. fail fast. Corey (January 2008). but there are parallels. learn rapidly" – these slogans summarize the importance of understanding the field and the suitability of implementing lean principles along the whole software development process. Only when all of the lean principles are implemented together.

Extreme programming 18 Extreme programming Planning and feedback loops in Extreme Programming. Software development process A software developer at work Activities and steps • • • • • • • • • Requirements Specification Architecture Construction Design Testing Debugging Deployment Maintenance Methodologies • • • • • • • • Waterfall Prototype model Incremental Iterative V-Model Spiral Scrum Cleanroom .

Other elements of Extreme Programming include: programming in pairs or doing extensive code review.[5] including problems with unstable requirements.[1][2][3] it advocates frequent "releases" in short development cycles.[] Although extreme programming itself is relatively new. after all. A NASA independent test group can write the test procedures.[5] Beck became the C3 project leader in March 1996 and began to refine the development methodology used in the project and wrote a book on the methodology (in October 1999.Extreme programming • • • • • • • • • 19 RAD DSDM RUP XP Agile Lean Dual Vee Model TDD FDD Supporting disciplines • • • • • Configuration management Documentation Quality assurance (SQA) Project management User experience design Tools • • • • • • Compiler Debugger Profiler GUI designer IDE Build automation Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. based on formal requirements and logical limits. before the software has . To shorten the total development time. avoiding programming of features until they are actually needed. the methodology. takes "best practices" to extreme levels. expecting changes in the customer's requirements as time passes and the problem is better understood. For example.[2][3][4] The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels. many of its practices have been around for some time. and frequent communication with the customer and among programmers. which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.Wikipedia:Please clarify Critics have noted several potential drawbacks. when the company was acquired by Daimler-Benz.[5] Chrysler cancelled the C3 project in February 2000. Extreme Programming Explained was published). simplicity and clarity in code. in the early 1960s (Larman 2003). planning and writing tests before each micro-increment" was used as early as NASA's Project Mercury. after 7 years. History Extreme Programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project. some formal test documents (such as for acceptance testing) have been developed in parallel (or shortly before) the software is ready for testing. no documented compromises of user conflicts. a flat management structure. As a type of agile software development. unit testing of all code. and a lack of an overall design specification or document. the "practice of test-first development.

Extreme programming been written and integrated with the hardware. Cunningham's WikiWikiWeb. object-oriented programming replaced procedural programming as the programming paradigm favored by some in the industry. this concept is taken to the extreme level by writing automated tests (perhaps inside of software modules) which validate the operation of even small sections of software coding. for a particular project. using the payroll systems at Chrysler as the object of research. However. I asked them to do a little bit of the things I thought were sensible. tangent efforts before too much work is invested in divergent.[5] a prominent Smalltalk practitioner. assimilating more lessons from experiences in the field. Current state XP created quite a buzz in the late 1990s and early 2000s. XP concepts have been explained. yet very receptive. 20 Origins Software development in the 1990s was shaped by two major influences: internally. and XP is still evolving. Rapidly-changing requirements demanded shorter product life-cycles." [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else. or even left unfinished. for some complex features to be more fully developed over a several-day period. with Smalltalk as the language and GemStone as the data access layer. like testing and reviews. to use other practices. some level of periodic integration testing can detect groups of people working in non-compatible. to be deprecated or reduced. spreading his ideas to a much larger. audience. five years after the first edition. beginning with his own Extreme Programming Explained (1999. could be changed to an end-of-week schedule. Beck edited a series of books on XP. and some spin-off methodologies resulted (see agile software development). In the second edition of Extreme Programming Explained (November 2004). extremeprogramming. The high discipline required by the original practices often went by the wayside. the practice of end-of-day integration tests. They brought in Kent Beck. for several years. Ward Cunningham. seeing adoption in a number of environments radically different from its origins. other agile development practices have not stood still. Meanwhile. The series included a book that was critical of the practices. In XP. Jeffries thereafter acted as a coach to instill the practices as habits in the C3 team. instead. The Chrysler Comprehensive Compensation System (C3) was started in order to determine the best way to use object technologies. He took this opportunity to propose and implement some changes in their practices based on his work with his frequent collaborator. such as those thought too rigid. causing some of these practices. or simply reduced to mutually agreed dates. and were often incompatible with traditional methods of software development. wrong directions. Beck invited Ron Jeffries to the project to help develop and refine these methods. rather than only testing the larger features. to do performance tuning on the system. Information about the principles and practices behind XP was disseminated to the wider world through discussions on the original Wiki. "Damn the torpedoes. Beck describes the early conception of the methods:[6] The first time I was asked to lead a team. Authors in the series went through various aspects attending XP and its practices. externally. the rise of the Internet and the dot-com boom emphasized speed-to-market and company-growth as competitive business factors. but his role expanded as he noted several problems they were having with their development process. Various contributors discussed and expanded upon the ideas. Such a more relaxed schedule could avoid people feeling rushed to generate artificial stubs just to pass the end-of-day testing. ISBN 0-201-61641-6). The second time there was a lot more on the line. Beck added more values and practices and differentiated between . at least this will make a good article. using a hypertext system map on the XP website at "http:/ / www. I thought. A less-rigid schedule allows. For example. on individual sites. Also. org" circa 1999.

might code it in a simplified manner and use the code to demonstrate what he or she means. inescapable and desirable aspect of software-development projects. 21 Concept Goals Extreme Programming Explained describes Extreme Programming as a software-development discipline that organizes people to produce higher-quality software more productively.[citation needed] . changes are a natural. System-wide integration testing was encouraged. instead of attempting to define a stable set of requirements. Testing Extreme programming's approach is that if a little testing can eliminate a few flaws. Other programmers can give feedback on this code by also coding their thoughts. XP attempts to reduce the cost of changes in requirements by having multiple short development cycles. and should be planned for. • Acceptance tests verify that the requirements as understood by the programmers satisfy the customer's actual requirements. Activities XP describes four basic activities that are performed within the software development process: coding. say the proponents of this position. for early detection of incompatible interfaces. In this doctrine. listening. or finding it hard to explain the solution to fellow programmers. Extreme programming also introduces a number of basic values. principles and practices on top of the agile programming framework. Every piece of code that is written is tested before moving on to the next feature. A programmer writes as many automated tests as they can think of that might "break" the code. Code. However. a lot of testing can eliminate many more flaws. depending on the stability of the overall interfaces in the system. then the coding is complete. to weekly. there is no working product.Extreme programming primary and corollary practices. • Unit tests determine whether a given feature works as intended. Without code. is always clear and concise and cannot be interpreted in more than one way. Coding can also be used to figure out the most suitable solution. as a daily end-of-day activity. if all tests run successfully. or less often. Coding can also help to communicate thoughts about programming problems. to reconnect before the separate sections diverged widely from coherent functionality. system-wide integration testing has been reduced. rather than a long one. Coding The advocates of XP argue that the only truly important product of the system development process is code – software instructions that a computer can interpret. testing. A programmer dealing with a complex programming problem. Each of those activities is described below. initially. and designing.

They must understand these needs well enough to give the customer feedback about the technical aspects of how the problem might be solved. of course one could say that system development doesn't need more than coding. Good design will avoid lots of dependencies within a system. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow.[citation needed] 22 Values Extreme Programming initially recognized four values in 1999: Communication. common metaphors. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. this means that changing one part of the system will not affect other parts of the system. One can come a long way without designing but at a given time one will get stuck. . collaboration of users and programmers. The system becomes too complex and the dependencies within the system cease to be clear. testing and listening. If those activities are performed well. Communication between the customer and programmer is further addressed in the Planning Game. Extreme programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. In practice. Respect. frequent verbal communication. extreme programming favors simple designs. A new value. Extra functionality can then be added later. this will not work. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. what "business logic" is needed. while perhaps delaying crucial features. Feedback. next week. This is sometimes summed up as the "You aren't gonna need it" (YAGNI) approach. Simplicity Extreme programming encourages starting with the simplest solution.[7] Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system. Related to the "communication" value. their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. or next month. Communication Building software systems requires communicating system requirements to the developers of the system. this task is accomplished through documentation. Those five values are described below. or cannot be solved. In formal software development methodologies. Simplicity. the result should always be a system that works.Extreme programming Listening Programmers must listen to what the customers need the system to do. To this end. A simple design with very simple code could be easily understood by most programmers in the team. Designing From the point of view of simplicity. and Courage. and feedback. One can avoid this by creating a design structure that organizes the logic in the system. simplicity in design and coding should improve the quality of communication. was added in the second edition of Extreme Programming Explained.

Nobody on the team should feel unappreciated or ignored. feedback relates to different dimensions of the system development: • Feedback from the system: by writing unit tests. but only if they are persistent. . This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. no matter how much effort was used to create that source code. designing. managing. not its practices (which are subject to more variation and ambiguity). This ensures a high level of motivation and encourages loyalty toward the team and toward the goal of the project. Another version of XP rules was proposed by Ken Auer[9] in XP/Agile Universe 2003. Adopting the four earlier values leads to respect gained from others in the team.Extreme programming Feedback Within extreme programming. He defined two categories: "Rules of Engagement" which dictate the environment in which software development can take place effectively. Planning. "Optimism is an occupational hazard of programming. or that otherwise delay the work of their peers. Also. courage means persistence: A programmer might be stuck on a complex problem for an entire day. • Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. and testing. Programmers should never commit changes that break compilation.[5] This means reviewing the existing system and modifying it so that future changes can be implemented more easily. The direct feedback from the system tells programmers to recode this part. that make existing unit-tests fail." [] Courage Several practices embody courage. known as user stories. managing and designing are called out explicitly to counter claims that XP doesn't support those activities. Feedback is the treatment. the programmers have direct feedback from the state of the system after implementing changes. This value is very dependent upon the other values. 29 rules are given in the categories of planning. and is very much oriented toward people in a team.[5] or running periodic integration tests. then solve the problem quickly the next day. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete. He felt XP was defined by its rules. 23 Rules The first version of rules for XP was published in 1999 by Don Wells[8] at the XP website. A customer is able to test the system periodically according to the functional requirements. coding. • Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. Respect The respect value includes respect for others as well as self-respect. Courage enables developers to feel comfortable with refactoring their code when necessary. Members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring. One is the commandment to always design and code for today and not for tomorrow. They will get concrete feedback about the current state of their system. Feedback is closely related to communication and simplicity. This review is planned once in every two or three weeks so the customer can easily steer the development. and "Rules of Play" which define the minute-by-minute activities and rules within the framework of the Rules of Engagement.[5] To quote Kent Beck.

It stresses that minimal delay between an action and its feedback is critical to learning and making changes. The customer has clear insight into the system that is being developed. He or she can give feedback and steer the development as needed. If the developer's changes cause a failure in some other portion of the system. When many little steps are made. Traditional system development methods say to plan for the future and to code for reusability. With frequent feedback from the customer. Assuming simplicity This is about treating every problem as if its solution were "extremely simple". Feedback Extreme programming sees feedback as most useful if it is done frequently and promptly. Under traditional development practices. appearing only during integration testing--or worse. Practices Extreme programming has been described as having 12 practices. programmers are to embrace this and plan the new requirements for the next iteration. The advocates of extreme programming say that making big changes all at once does not work. alerting the developer of the incompatibility of his change with other parts of the system. For instance. and determining which code change caused the problem. This includes running not only the unit tests that test the developer's code.Extreme programming 24 Principles The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project. grouped into four areas: Fine scale feedback • Pair programming[5] • Planning game • Test-driven development • Whole team . comprehensive unit-test suite meant that such a code change. the customer has more control over the development process and the system that is being developed. if at one of the iterative meetings it appears that the customer's requirements have changed dramatically. the automated all-unit-test suite will reveal the failure immediately. Extreme programming rejects these ideas. among all the changes made by all the developers during the weeks or even months previous to integration testing. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation. When writing code. before the developer spends much time implementing it. Unlike traditional system development methods. running the unit test provides direct feedback as to how the system reacts to the changes one has made. a system might have small releases every three weeks. using an automated process that can be initiated by a single command. assumed harmless by the developer. contact with the customer occurs in more frequent iterations. would have been left in place. the absence of an automated. was a formidable task. Extreme programming applies incremental changes: for example. a mistaken design decision made by the developer will be noticed and corrected quickly. but running in addition all unit tests against all the software. only in production. that the developer knows little or nothing about. Embracing change The principle of embracing change is about not working against changes but embracing them. Unit tests also contribute to the rapid feedback principle. and the necessity of removing or modifying his change. That way.

rather than documentation of compromise objectives and constraints.Extreme programming 25 Continuous process • Continuous integration • Refactoring or design improvement[5] • Small releases Shared understanding • • • • Coding standards Collective code ownership[5] Simple design[5] System metaphor Programmer welfare • Sustainable pace Coding • The customer is always available • • • • Code the Unit test first Only one pair integrates code at a time Leave Optimization until last No Overtime Testing • All code must have Unit tests • All code must pass all Unit tests before it can be released. • Requirements are defined incrementally.[5] Proponents of extreme programming claim that by having the on-site customer[5] request changes informally. it is a test you forgot to write) • Acceptance tests are run often and the results are published Controversial aspects The practices in XP have been heavily debated. This also applies when multiple programming organizations are involved. Most of the design activity takes place on the fly and incrementally. Change-control boards are a sign that there are potential conflicts in project objectives and constraints between multiple users. • When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic. • Software developers are usually required to work in pairs. rather than trying to get them all in advance. starting with "the simplest thing that could possibly work" and adding complexity only when it's required by failing tests. XP's expedited methods are somewhat dependent on programmers being able to assume a unified client viewpoint so the programmer can concentrate on coding. Critics compare this to "debugging a system into appearance" and fear this will result in more re-design effort .[citation needed] Other potentially controversial aspects of extreme programming include: • Requirements are expressed as automated acceptance tests rather than specification documents. Critics of XP claim this can lead to costly rework and project scope creep beyond what was previously agreed or funded. and saves the cost of formal overhead. particularly organizations which compete for shares of projects. • There is no Big Design Up Front. the process becomes flexible.

XP only works on teams of twelve or fewer people. poisonous snake heading your way.[14] In particular.[citation needed] ThoughtWorks has claimed reasonable success on distributed XP projects with up to sixty people.[] This triggered a lengthy debate in articles. Severability and responses In 2003. Other authors have tried to reconcile XP with the older methodologies in order to form a unified methodology. This role can become a single-point-of-failure for the project. such as the ones coming from McBreen[] and Boehm and Turner. Certain aspects of XP have changed since the book Extreme Programming Refactored (2003) was published.[citation needed] In 2004. example: Project Lifecycles: Waterfall. have attracted particular criticisms. Industrial Extreme Programming (IXP)[11] was introduced as an evolution of XP. and Six Sigma.[13] Criticism Extreme programming's initial buzz and controversial tenets. They found that the three systems reinforced each other well. The core argument of the book is that XP's practices are interdependent but that few practical organizations are willing/able to adopt all the practices. As it is a new member of the Agile family. Some argue that these changes invalidate previous criticisms. extreme programming has been reviewed and critiqued by Matt Stephens's and Doug Rosenberg's Extreme Programming Refactored. tried combining XP with the computer programming methods of Capability Maturity Model Integration (CMMI). such as pair programming and continuous design. Matt Stephens and Doug Rosenberg published Extreme Programming Refactored: The Case Against XP. Internet newsgroups. are believed by Agile practitioners to be misunderstandings of agile development. in particular."[10] 26 Scalability Historically. All it takes is for one of them to wriggle loose. • Dependence upon all other aspects of XP: "XP is like a ring of poisonous snakes. XP also uses increasingly generic terms for processes. there is not enough data to prove its usability. there is the danger of micro-management by a non-technical representative trying to dictate the use of technical software features and architecture. JPMorgan Chase & Co. and you've got a very angry. and it draws a likeness of XP's "collective ownership" model to socialism in a negative manner. leading to better development. XP now accommodates modifications to the practices as long as the required objectives are still met.[][15] Criticisms include: • a methodology is only as effective as the people involved. and All That [12]. daisy-chained together. Rapid Application Development. One way to circumvent this limitation is to break up the project into smaller pieces and the team into smaller groups. therefore the entire process fails. and some people have found it to be a source of stress. Agile does not solve this • often used as a means to bleed money from customers through lack of defining a deliverable product • lack of structure and necessary documentation • only works with senior-level developers . The book also makes other criticisms. • A customer representative is attached to the project. however. such as the waterfall methodology. It now has 23 practices and flexible values. Some of these XP sought to replace. It has been claimed that XP has been used successfully on teams of over a hundred developers. and did not mutually contradict. and web-site chat areas. It is intended to bring the ability to work in large and distributed teams.Extreme programming than only re-designing when requirements change. Also. which questioned the value of the XP process and suggested ways in which it could be improved. however it claims to be an answer to what it sees as XP's imperfections. others claim that this is simply watering the process down.[] Many of the criticisms.

[14] sdmagazine (http:/ / www. Extreme Programming Explained: Embrace Change. Technology Review. Galen Lab. com/ softwaretopics/ software/ appdev/ story/ 0. cis. [3] "Extreme Programming" USFCA-edu-601-lecture (http:/ / www. Addison–Wesley.uci. 2005. jsp) [11] Cutter Consortium :: Industrial XP: Making XP Work in Large Organizations (http:/ / www. com/ articles/ article. University of Pennsylvania. html) [12] http:/ / www. html). webpage: Manifesto-for-Agile-Software-Dev (http:/ / agilemanifesto. Publisher: Apress L. softwarereality. com/ moreAboutUs/ publications/ rulesOfXp. 2001.10801. sussex. pdf). Addison–Wesley. Addison–Wesley. usfca. Addison–Wesley. [8] Don Wells (http:/ / www. extremeprogramming. Agile Alliance. Further reading • • • • • • • • • Ken Auer and Roy Miller. "Iterative and Incremental Development: A Brief History". ac. edu/ ~matuszek/ cit591-2003/ Lectures/ 49-design-patterns. com/ documents/ s=1811/ sdm0112h/ 0112h. Alistair Cockburn: Agile Software Development. informatics. November 2003. php) [10] The Case Against Extreme Programming: A Self-Referential Safety Net (http:/ / www. rolemodelsoftware. edu/ ~parrt/ course/ 601/ lectures/ xp. ppt). com/ lifecycle/ xp/ safety_net. aspx?p=20972) [7] "Everyone's a Programmer" by Clair Tristram. computerworld. Computerworld (online). htm) [15] Extreme Programming Refactored (http:/ / www. [6] Interview with Kent Beck and Martin Fowler (http:/ / www. • Matt Stephens and Doug Rosenberg (2003). • Craig Larman & V. cutter. Basili (2003). edu/histories/ccc/). Case Study: The Chrysler Comprehensive Compensation System (http://calla. because at the beginning of the project no one knows the entire scope/requirements • can increase the risk of scope creep due to the lack of detailed requirements documentation • Agile is feature-driven. Apress. Extreme Programming Installed. Ron Jeffries. Addison–Wesley. html). jsp).C. sei. U. 39. Addison–Wesley. Irvine. com/ content-and-analysis/ resource-centers/ agile-project-management/ sample-our-research/ apmr0502. 27 References [1] "Human Centred Technology Workshop 2005". Second Edition. sdmagazine. a single area of code is expected to be written once. Addison–Wesley. p.P. Extreme Programming Refactored: The Case Against XP.00. Kent Beck: Extreme Programming Explained: Embrace Change. PDF webpage: Informatics-UK-report-cdrp585 (ftp:/ / ftp. Addison–Wesley. Whereas if a plan were there to be followed. Martin Fowler: Refactoring: Improving the Design of Existing Code. [2] "Design Patterns and Refactoring".Extreme programming • • • • • incorporates insufficient software design requires meetings at frequent intervals at enormous expense to customers requires too much cultural change to adopt can lead to more difficult contractual negotiations can be very inefficient. edu/ library/ assets/ jarvis-gristock. html) [9] Ken Auer (http:/ / www.66192. cmu. softwarereality. lux-seattle. • impossible to develop realistic estimates of work effort needed to provide a quote. webpage: Computerworld-appdev-92 (http:/ / www. informit. uk/ pub/ reports/ csrp/ csrp585. . com/ resources/ whitepapers/ waterfall. Matt Stephens and Doug Rosenberg. Agile Software Development Ecosystems. pdf). if the requirements for one area of code change through various iterations. Extreme Programming Applied: Playing To Win. December 2001. cs. the same programming may need to be done several times over. webpage: UPenn-Lectures-design-patterns (http:/ / www. Kent Beck and Martin Fowler: Planning Extreme Programming. non-functional quality attributes are hard to be placed as user stories.ics. Ann Anderson and Chet Hendrickson (2000). Jim Highsmith. [4] "Manifesto for Agile Software Development". Kent Beck and Cynthia Andres. 2003. org/ ) [5] "Extreme Programming". htm [13] Extreme Programming (XP) Six Sigma CMMI (http:/ / www. Harvey Herela (2005). upenn. com/ ExtremeProgrammingRefactored. org/ rules. Computer (IEEE Computer Society) 36 (6): 47–56.

In: ISTE.IndustrialXP.martinfowler. "Nanocomputers and Swarm Intelligence".org) Industrial eXtreme Programming ( XP magazine (http://www.xprogramming.html) – ThoughtWorks' experiences with implementing XP in large distributed projects Feature-driven development Software development process A software developer at work Activities and steps • • • • • • • • • Requirements Specification Architecture Construction Design Testing Debugging Deployment Maintenance Methodologies • • • • • • • • • • Waterfall Prototype model Incremental Iterative V-Model Spiral Scrum Cleanroom RAD DSDM .Extreme programming • Waldner. 28 External links • • • • • Extreme Programming A gentle introduction (http://www. (2008).com/articles/ agileOffshore. 225– Problems and Solutions to XP implementation ( wiki?ExtremeProgrammingImplementationIssues) • Using an Agile Software Process with Offshore Development (http://www. JB.

There is also a Community website [4] available at which people can learn more about FDD. design and building of features. and experiences and the processes themselves are discussed. The description of FDD was first introduced to the world in Chapter 6 of the book Java Modeling in Color with UML[1] by Peter Coad. Since its successful use on the Singapore project. 50-person software development project at a large Singapore bank in 1997. in Stephen Palmer and Mac Felsing's book A Practical Guide to Feature-Driven Development[2] (published in 2002). to meet the specific needs of a 15-month. planning. . working software repeatedly in a timely manner. as decoupled from Java modeling in color. a more general description of FDD was given. The second process incorporates Peter Coad's ideas of using a feature list to manage functional requirements and development tasks. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance. The other processes and the blending of the processes into a cohesive whole is a result of Jeff De Luca's experience. questions can be asked. Later. Jeff De Luca delivered a set of five processes that covered the development of an overall model and the listing. there have been several implementations of FDD. Its main purpose is to deliver tangible. The original and latest FDD processes can be found on Jeff De Luca´s website [3] under the ´Article´ area. History FDD was initially devised by Jeff De Luca.Feature-driven development • • • • • • • 29 RUP XP Agile Lean Dual Vee Model TDD FDD Supporting disciplines • • • • • Configuration management Documentation Quality assurance (SQA) Project management User experience design Tools • • • • • • Compiler Debugger Profiler GUI designer IDE Build automation Feature-driven development (FDD) is an iterative and incremental software development process. These practices are all driven from a client-valued functionality (feature) perspective. FDD blends a number of industry-recognized best practices into a cohesive whole. The first process is heavily influenced by Peter Coad's approach to object modeling. Eric Lefebvre and Jeff De Luca in 1999.

The concepts involved in these activities are explained in Table 3. In support of each domain. Domain area models were merged into an overall model. During the first two sequential activities.Feature-driven development 30 Overview FDD is a model-driven short-iteration process that consists of five basic activities. which were presented for peer review and discussion. Subject areas each contain business activities. For more detailed information about the individual sub-activities have a look at Table 2 (derived from the process description in the ´Article´ section of Jeff De Luca´s website [3]). was selected which became the model for that particular domain area. In the figure on the right. the next step was to produce the development plan. Develop overall model The project started with a high-level walkthrough of the scope of the system and its context. This section gives a high level overview of the activities. milestones that mark the progress made on each feature are defined. After a unit test and a successful code inspection. the meta-process model for these activities is displayed. Plan by feature After the feature list had been completed. One of the proposed models. the chief programmer worked out detailed sequence diagrams for each feature and refines the overall model. the class and method prologues are written and finally a design inspection is held. Next. Features should not take more than two weeks to complete. Build feature list The knowledge that was gathered during the initial modeling was used to identify a list of features. an overall model shape is established. . or a merge of them. walkthrough models were then composed by small groups. the completed feature is promoted to the main build. Build by feature After a successful design inspection a per feature activity to produce a completed client-valued function (feature) is being produced. Together with the corresponding class owners. for example: 'Calculate the total of a sale' or 'Validate the password of a user'. Class ownership has been done by ordering and assigning features (or feature sets) as classes to chief programmers. detailed domain walkthroughs were held for each modeling area. the steps within each business activity formed the categorized feature list. Next. For accurate state reporting and keeping track of the software development project. The class owners develop the actual code for their classes. A chief programmer selected a small group of features that are to be developed within two weeks. This was done by functionally decomposing the domain into subject areas. Process model for FDD Design by feature A design package was produced for each feature. and the overall model shape was adjusted along the way. Features in this respect were small pieces of client-valued functions expressed in the form "<action> <result> <object>". The final three activities are iterated for each feature. else they should be broken down into smaller pieces.

Regular builds ensure there is always an up to date system that can be demonstrated to the client and helps highlighting integration errors of source code for the features early. Inspections are carried out to ensure good quality design and code. • Inspections. Configuration management helps with identifying the source code for all features that have been completed to date and to maintain a history of changes to classes as feature teams enhance them. and conceptual integrity of the class. • Configuration Management. performance. The resulting domain object model provides an overall framework in which to add features. a percentage complete is assigned to each milestone. Design 40% and Design Inspection 3% = 44%). managers are helped at steering a project correctly. In the table below the milestones (and their completion percentage) are shown. A feature that is still being coded is 44% complete (Domain Walkthrough 1%. • Developing by Feature. The owner is responsible for the consistency. Table 1: Milestones Domain Walkthrough Design Design Inspection Code Code Inspection Promote To Build 1% 40% 3% 45% 10% 1% Best practices Feature-Driven Development is built around a core set of industry-recognized best practices. Individual class ownership means that distinct pieces or grouping of code are assigned to a single owner. based on completed work. completing a feature is a relatively small task. appropriate. • Domain Object Modeling. For each best practice a short description will be given. By frequent. It is the combination of these practices and techniques that makes FDD so compelling. multiple minds are always applied to each design decision and also multiple design options are always evaluated before one is chosen.Feature-driven development 31 Milestones Since features are small. The first three milestones are completed during the Design By Feature activity. the last three are completed during the Build By Feature activity. . FDD therefore defines six milestones per feature that are to be completed sequentially. These practices are all driven from a client-valued feature perspective. and accurate progress reporting at all levels inside and outside the project. By doing so. Domain Object Modeling consists of exploring and explaining the domain of the problem to be solved. • Visibility of progress and results. • Individual Class (Code) Ownership. The best practices that make up FDD are shortly described below. A feature team is a small. This makes it easier to deliver correct functions and to extend or modify the system. dynamically formed team that develops a small activity. Any function that is too complex to be implemented within two weeks is further decomposed into smaller functions until each sub-problem is small enough to be called a feature. To help with tracking progress. • Feature Teams. primarily by detection of defects. • Regular Builds. derived from software engineering. For accurate state reporting and keeping track of the software development project it is however important to mark the progress made on each feature.

(2002).Use of FDD for Web Development projects Delivering Real Business Value using Feature Driven Development [12] .. The activities all contain sub-activities that correspond to the sub-activities in the FDD process description on Jeff De Luca´s website [3].. • FDD Tools [7].Another book in the Coad Series referencing Feature Driven Development.Feature-driven development 32 Metamodel (MetaModeling) Metamodeling helps visualizing both the processes and the data of a method. (ISBN 0-13-011510-X) • 2. Process-Data Model for FDD Tools used for Feature Driven Development • CASE Spec [5].Nebulon is the consulting practice of Jeff De Luca Successful Web Development Methodologies [11] . S. (1999).Article gives basic overview of FDD FDD and Agile Modeling [13] Better Software Faster [14] . Lefebvre. The FDD Tools project aims to produce an open source. The left side of the metadata model. ^ Palmer. ^ Coad. such that methods can be compared and method fragments in the method engineering process can easily be reused. References • 1. & Felsing. compact. Prentice Hall International. CASE Spec is a commercial enterprise tool for Feature-Driven development. FDD Viewer is a utility to display and print parking lots. (ISBN 0-13-067615-2) External links Feature Driven Development Community [4] Feature-driven development [9] at the Open Directory Project Nebulon FDD Page [10] . TechExcel DevSuite is a commercial suite of applications to enable Feature-Driven development. • TechExcel DevSuite [6]. P. A definition of the concepts is given in Table 3. shows the five basic activities involved in a software development project using FDD. • FDD Viewer [8].R. & De Luca.M. Prentice Hall. The advantage of the technique is that it is clear. Authors Andy Carmichael and Dan Haywood ISBN 0-13-008752-1 • Interview with FDD-Creator Jeff DeLuca [15] (Podcast) • • • • • • • . cross-platform toolkit supporting the Feature Driven Development methodology. depicted on the right. J. These concepts originate from the activities depicted in the left side of the diagram. A Practical Guide to Feature-Driven Development. J. Java Modeling In Color With UML: Enterprise Components and Process. The right side of the model shows the concepts involved. and consistent with UML standards. E.

specifically the domain experts and the chief programmers. data models. Study Documents Develop Small Group Models Optionally the team studies available REFERENCE or REFERENCED REQUIREMENTS documents such as object models. each SMALL GROUP will compose a SMALL GROUP MODEL in support of the domain area. The Chief Architect may propose a ´strawman´ model to facilitate the progress of the teams. and user guides. is REFINED with the new model shapes produced by iterations of the ‘Develop Team Model’ task above. Forming groups of no more than three. Develop Team Model Refine Overall Object Model Write Model Notes Build Feature List Form Features List Team Build Features List . The FEATURE LIST TEAM shall identify the FEATURE LIST using the knowledge obtained from the process ‘Develop Overall Model’. Conduct Domain A domain expert gives a DOMAIN OVERVIEW of the domain area to be modeled. Every so often. The Chief Architect may also propose further model alternatives. functional requirements (traditional or use-case format). This is a simple functional decomposition into SUBJECT AREAS that come from the partitioning of the domain by the domain experts for their domain area walkthroughs in the process ‘Develop Overall Model’. A member from each small group presents that groups proposed model for the domain area. It is decomposed into SUBJECT AREAS that comprise BUSINESS ACTIVITIES that comprise BUSINESS ACTIVITY steps (FEATURES). EXPLANATORY NOTES on detailed or complex model shapes and on significant model alternatives are made for future reference by the project.Feature-driven development 33 Table 2: Activities and sub-activities Activity Develop Overall Model Sub-activity Form Modeling Team Description The MODELING TEAM comprises permanent members from the domain and development areas. The MODELING TEAM selects a proposed TEAM MODEL or composes a model by merging ideas from the proposed models. Other project staff members are then rotated through the modeling sessions so that everyone gets a chance to participate and to see the process in action. The FEATURE LIST TEAM comprises the chief programmers from the MODELING TEAM in the process ‘Develop Overall Model’. consisting of an overall SEQUENCE DIAGRAM and a CLASS DIAGRAM. This should also include Walk-through information that is related to this DOMAIN AREA but not necessarily a part of its implementation. the OVERALL MODEL.

The complexity of the CLASSES. The complexity of the FEATURES to be implemented. with REFINEMENTS made from one or more tasks and then considering the others again. previews. Balancing load across CLASS OWNERS (remember that chief programmers are also CLASS OWNERS). The assignment of CLASSES to developers is based on: • • • • Balancing load across developers.g. Assign Business Activities to Chief Programmers The PLANNING TEAM shall assign chief programmers as owners of BUSINESS ACTIVITIES. Balancing load across CLASS OWNERS. The complexity of the FEATURES to be implemented. high-use) of the CLASSES. Consideration of any external (visible) milestones such as betas. Bringing forward high-risk or complex BUSINESS ACTIVITIES. Assign Classes to Developers The PLANNING TEAM shall assign developers as CLASS OWNERS. Developers own multiple CLASSES. The assignment is based on: • • • • The DEVELOPMENT SEQUENCE. Plan By Feature Form Planning Team Determine Development Sequence The main tasks in the process ‘Plan By Feature’ are not a strict sequence.Feature-driven development 34 The PLANNING TEAM comprises the development manager plus the chief programmers. Like many PLANNING activities they are considered together. . The PLANNING TEAM shall assign a DATE (month and year only) for completion of each BUSINESS ACTIVITY. The identification of the BUSINESS ACTIVITY and the completion DATE (and thus the DEVELOPMENT SEQUENCE) is based on: • • • • • Dependencies between FEATURES in terms of CLASSES involved. Dependencies between FEATURES in terms of CLASSES involved. The DEVELOPMENT SEQUENCE. feedback checkpoints and the "whole products" that satisfy such milestones. The usage (e.

Any ALTERNATIVE DESIGNS. requirements clarifications and EXPLANATORY NOTES are also recorded and written up in the DESIGN ALTERNATIVES section of the DESIGN PACKAGE. exceptions and messages. The decision to inspect within the FEATURE TEAM or with other project team members is that of the Chief Programmer. Develop the SEQUENCE DIAGRAM(S) required for the FEATURE to be designed. Study Referenced Documents Develop Sequence Diagram(s) The FEATURE TEAM studies the REFERENCED REQUIREMENT(S) for the feature to be designed. design decisions. The Chief Programmer tracks the individual CLASSES being promoted. From the CLASS OWNER LIST. the Chief Programmer creates a new DESIGN PACKAGE for the FEATURES(S) as part of the work package. and is the integration point for the entire FEATURE. A design inspection with the FEATURE TEAM members or with other project members is held. The Chief Programmer determines what FEATURE TEAM-level unit testing is required (if any). if any testing across the CLASSES developed for this FEATURE is required. the Chief Programmer identifies the developers needed to form the FEATURE TEAM. The purpose of the FEATURE TEAM Area is that work in progress by the FEATURE TEAM can be shared and is visible amongst the FEATURE TEAM but is not visible to the rest of the project. This is an optional task based on the complexity of the FEATURE and/or its interactions. the Chief Programmer generates the API documentation using <your tool> and submits it for publication on the project intranet. The development CLASS owners will perform the IMPLEMENTATION of the items necessary to satisfy the requirements of their CLASS for this FEATURE. Design By Feature Form Feature Team Conduct Domain The domain expert gives a DOMAIN OVERVIEW of the domain area for the FEATURE to be designed. Using the updated implementation language source files from the ‘Refine Object Model’ task in the shared FEATURE TEAM Area. The Chief Programmer creates model diagrams in a publishable format. The Chief Programmer makes some REFINEMENTS on the model to add new / updated CLASSES. The Chief Programmer must also merge changes from the shared FEATURE TEAM Area into the change control system. The diagram files should be checked into the version control system. These files should be checked into the version control system and submitted for publishing on the project intranet. through feedback from the developers. This includes parameter types. The Chief Programmer creates a FEATURE TEAM Area for the FEATURE(S). . This area is either a directory on the file server or a directory on their PC that is backed up to the server by the Chief Programmer as required or utilizes work area support in your version control system. and each team member adds their tasks to their calendar task list. methods. On acceptance a TODO TASK LIST is generated per affected CLASS. return types. As part of this step.Feature-driven development 35 The Chief Programmer identifies the CLASSES likely to be involved in the design of this set of FEATURES and updates the FEATURE database accordingly. The decision to inspect before or after unit test is that of the Chief Programmer. methods or attributes based on the SEQUENCE DIAGRAM(S) defined for the FEATURE(S). This Walk-through should also include domain information that is related to the FEATURE but not necessarily a part of its implementation. Once each developer has completed this task. This results in the implementation language source files being updated in the FEATURE TEAM Area. The decision to inspect within the FEATURE TEAM or with other project team members is that of the Chief Programmer. Refine Object Model Write Class and Method Prologue Design Inspection Build By Feature Implement Classes and Methods Inspect Code A CODE INSPECTION with the FEATURE TEAM members or with other project members is held either before or after the unit test task. external system interface specifications and any other supporting documentation. The development CLASS owner tests their code to ensure all requirements of their CLASS are satisfied. This is an optional task based on the complexity of the FEATURE and/or its interactions. attributes and/or to make changes to existing CLASSES. That is. all COVERING MEMOS. screen designs. Conduct Unit Test Promote to Build PROMOTION to the BUILD of CLASSES is only possible after a successful CODE INSPECTION. the development owner of each CLASS writes the CLASS AND METHOD PROLOGUE for each item defined by the FEATURE and SEQUENCE DIAGRAM(S).

([17] A feature team is a small. ([17] Wiki: Feature Driven Development FEATURE DRIVEN DEVELOPMENT FEATURE LIST FEATURE LIST TEAM FEATURE TEAM A Feature list is intended as a potentially client deliverable piece of work. ([17] Wiki: Calendar date Section of the Design Package containing the diagram files in the version control system. This should also include domain information that is related to the feature but not necessarily a part of its implementation. The referenced requirements (if any) in the form of documents and all related confirmation memos and supporting documentation. The <your tool> generated output for the class and method prologues created or modified by this design. that integrates and describes the design package such that it stands on its own for reviewers. most features take less than this time. methods and attributes. ([17] . Calendar/To-Do task-list entries for action items on affected classes for each team member. calculate the total of a sale. ([17] Package containing: • • • • • • • A covering memo. calculate the total quantity sold by a retail outlet for an item description. the step is broken into smaller steps that then become features. requirements clarifications and notes. Features are granular in accordance with the rule that a feature will take no more than two weeks to complete. Their task is to make a Feature list. Two weeks is an upper limit. ([17] Wiki: Class diagram A class owner is someone responsible for the design and implementation of a class. ([17] EXPLANATORY NOTE FEATURE Notes made on detailed or complex model shapes and on significant model alternatives are made for future reference by the project. Design alternatives (if any) The object model with new/updated classes. but not so granular as to be at the level of getters and setters. design decisions. ([17] DEVELOPMENT SEQUENCE The planned order for completion of each business activity. This is an optional task based on the complexity of the feature and/or its interactions. or paper. ([17] DOMAIN OVERVIEW The domain expert gives an overview of the domain area for the feature to be designed. ([18] A class owner list is a list of class owners. When a business activity step looks larger than two weeks. ([19] The team comprises the chief programmers from the modeling team in process.Feature-driven development 36 Table 3: Concepts CONCEPT BUILD PROMOTION Wiki: Software build Definition (source) BUSINESS ACTIVITY Activity undertaken as part of a commercial enterprise. ([18] Wiki: Code review A paper that integrates and describes the design package such that it stands on its own for reviewers. ([17] Features are granular functions expressed in client-valued terms using this naming template: <action> <result> <object>. The Sequence diagram(s). ([16] CLASS CLASS AND METHOD PROLOGUE CLASS DIAGRAM CLASS OWNER CLASS OWNER LIST CODE INSPECTION COVERING MEMO DATE DESIGN ALTERNATIVE DESIGN PACKAGE Wiki: Class The main goal of a class and method prologue is to explain the purpose of the class or method. dynamically formed team that develops the feature(s) that a Chief Programmer selects for development. alternative designs. The planning team shall assign a date (month and year only) for completion of each business activity. For example.

net/ [8] http:/ / www. (www. com/ article/ successful-development [12] http:/ / www. The subject areas provide reference information when conducting detailed requirements gathering. (www. com/ ) [17] http:/ / www. ([17] A merged domain area model. ([17] An area of major interest or importance to the enterprise. featuredrivendevelopment. com/ http:/ / www. bettersoftwarefaster. ([17] Wiki: Todo list TEAM MODEL TODO TASK LIST References [1] [2] [3] [4] [5] [6] http:/ / en.htm) OVERALL MODEL PLANNING PLANNING TEAM REFERENCE REFERENCED REQUIREMENT REFINEMENT SEQUENCE DIAGRAM SMALL GROUP SMALL GROUP MODEL SUBJECT AREA Wiki: Refinement Wiki: Sequence diagram Group of no more than three that will compose a model in support of the domain area. ([17] A model for the domain area made by a group of no more than three.html) A proposed model selected by the modeling team or composed by merging ideas from the proposed models. html [7] http:/ / com/ index. com/ archive/ nebulon. uidesign. thefreedictionary. html) . hst.finnevo. It is centered on a major resource. html [11] http:/ / www. ([17] Wiki: Reference (work) Need or expectation that is stated. PDF) [19] http:/ / www. org/ wiki/ Feature-driven_development#endnote_Coad http:/ / en. sitepoint. htm [14] http:/ / www. com/ essays/ fdd. com/ fdd/ index. pdf) [18] http:/ / www. com/ files/ fddprocessesA4. generally implied or obligatory. nebulon. featuredrivendevelopment. techexcel. org/ Computers/ Programming/ Methodologies/ Agile/ Feature_Driven_Development/ [10] http:/ / www. sourceforge. com/ node/ 687 [9] http:/ / www. agilemodeling. se-radio. specifically the domain experts and the chief programmers. wikipedia. net/ 2008/ 01/ episode-83-jeff-deluca-on-feature-driven-development/ [16] http:/ / www. ch/ Archiv/ 2000/ swe/ otherResources/ ch03/ fdd. featuredrivendevelopment. com/ solutions/ alm/ fdd. methodsandtools. org/ wiki/ Feature-driven_development#endnote_Palmer http:/ / www. casespec. htm [15] http:/ / www.Feature-driven development 37 IMPLEMENTATION MODELING TEAM Wiki: Implementation The modeling team comprises permanent members from the domain and development areas. ([17] Wiki: Planning The planning team comprises the development manager plus the chief programmers for making a planning. com/ http:/ / www. dmoz. net/ 2001/ papers/ fddui. net http:/ / www. fhso. php?id=19 [13] http:/ / www.georgetown. product or activity. wikipedia.

Test-driven development 38 Test-driven development Software development process A software developer at work Activities and steps • • • • • • • • • Requirements Specification Architecture Construction Design Testing Debugging Deployment Maintenance Methodologies • • • • • • • • • • • • • • • • • Waterfall Prototype model Incremental Iterative V-Model Spiral Scrum Cleanroom RAD DSDM RUP XP Agile Lean Dual Vee Model TDD FDD Supporting disciplines • • • • • Configuration management Documentation Quality assurance (SQA) Project management User experience design .

begun in 1999. stated in 2003 that TDD encourages simple designs and inspires confidence. then either the proposed "new" feature already exists or the test is defective. This test must inevitably fail because it is written before the feature has been implemented. then produces the minimum amount of code to pass that test.Test-driven development 39 Tools • • • • • • Compiler Debugger Profiler GUI designer IDE Build automation Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function. (If it does not fail. This could also be a modification of an existing test.[1] Test-driven development is related to the test-first programming concepts of extreme programming. a subtle but important difference. using a basic flowchart specification and requirements.[2] Programmers also apply the concept to improving and debugging legacy code developed with older techniques.[5] but more recently has created more general interest in its own right. and can write the test in whatever testing framework is appropriate to the software environment. . The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions.[1] Add a test In test-driven development. the developer must clearly understand the feature's A graphical representation of the development cycle. who is credited with having developed or 'rediscovered' the technique. Kent Beck.) To write a test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code.[3] Test-driven development cycle The following sequence is based on the book Test-Driven Development by Example. each new feature begins with writing a test. and finally refactors the new code to acceptable standards.

By re-running the test cases. but still pass all required tests. It helps ensure that the application is written for testability. pass the test in an inelegant way. Additionally. the cycle is then repeated to push forward the functionality. The new code written at this stage is not perfect. This can be unsettling at first but it allows the developer to focus only on what is important.[2] unless there is some reason to believe that the library is buggy or is not sufficiently feature-complete to serve all the needs of the main program being written.[] When writing feature-first code. the programmer should undo or revert in preference to excessive debugging. This has been claimed to have many benefits. or other tests fail unexpectedly. To achieve some advanced design concept (such as a design pattern). By focusing on writing only the code necessary to pass tests. no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage. there is a tendency by developers and the development organisations to . Write the tests first. That is acceptable because later steps improve and hone it. This step also tests the test itself. designs can be cleaner and clearer than is often achieved by other methods. tests are written that generate that design. and therefore is worthless. with as few as 1 to 10 edits between each test run. The concept of removing duplication is an important aspect of any software design. This increases confidence (though does not guarantee) that it is testing the right thing. for example the principles of "keep it simple stupid" (KISS) and "You aren't gonna need it" (YAGNI). the programmer can be confident that the code meets all the tested requirements. Refactor code Now the code can be cleaned up as necessary. rather than worrying about it later. Write some code The next step is to write some code that causes the test to pass. If new code does not rapidly satisfy a new test. Kent Beck also suggests the principle "Fake it till you make it". however. in the negative: it rules out the possibility that the new test always passes. The tests should be written before the functionality that is being tested. Development style There are various aspects to using test-driven development.Test-driven development 40 Run all tests and see if the new one fails This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. When using external libraries it is important not to make increments that are so small as to be effectively merely testing the library itself. Run the automated tests and see them succeed If all test cases now pass. for example. ensures the effectiveness of the test code. and maintains a continual focus on the quality of the product. the developer can be confident that code refactoring is not damaging any existing functionality. The code may remain simpler than the target pattern. and passes only in intended cases. The size of the steps should always be small. Repeat Starting with another new test. This is a good point from which to begin the final step of the cycle. as the developers must consider how to test the application from the outset. In this case.[1] In Test-Driven Development by Example. It also ensures that tests for every feature get written. Continuous integration helps by providing revertible checkpoints. and may. writing the tests first drives a deeper and earlier understanding of the product requirements. The new test should also fail for the expected reason. It is important that the code written is only designed to pass the test. it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

at first. Receiving the expected test results at each stage reinforces the programmer's mental model of the code. because all of the classes and methods it requires may not yet exist. and refactoring. the underlying functionality can be implemented. • Keep each test oracle focused on only the results necessary to validate its test.[] . Keeping units relatively small is claimed to provide critical benefits. having smaller units aids in tracking down errors. Consistent structure helps in building a self-documenting test case. neglecting testing entirely. passing them. including: • Reduced Debugging Effort – When test failures are detected. It may be helpful to review this section during your discussion.[4] First fail the test cases. improves the readability of the test case. • Cleanup: Restore the UUT or the overall test system to the pre-test state. which keeps them continuously focused on what the customer really wants from that user story. It also must work correctly for both positive and negative cases. the acceptance tests. This step is usually very simple. Keep the unit small. and smooths the flow of execution. Nevertheless. • Design time-related tests to allow tolerance for execution in non-real time operating systems. • Treat your test code with the same respect as your production code. a unit is most commonly defined as a class or group of related functions. • Get together with your team and review your tests and test practices to share effective techniques and catch bad habits. such as return values and output parameters. the development team now has a specific target to satisfy. that first test functions as an executable specification. • Execution: Trigger/drive the UUT to perform the target behavior and capture all output. This restoration permits another test to execute immediately after this one. (2) execution. boosts confidence and increases productivity. Once this is shown.Test-driven development push the developer on to the next feature. The idea is to ensure that the test really works and can catch an error.[] Advanced practices of test-driven development can lead to Acceptance Test-driven development (ATDD) where the criteria specified by the customer are automated into acceptance tests. 41 Best practices Test structure Effective layout of a test case ensures all required actions are completed. • Self-Documenting Tests – Small test cases have improved readability and facilitate rapid understandability. often called a module.[5] This process ensures the customer has an automated mechanism to decide whether the software meets their requirements. Test-driven development constantly repeats the steps of adding test cases that fail. and be readable and maintainable.[] Individual best practices • Separate common set up and teardown logic into test support services utilized by the appropriate test cases. and (4) cleanup. • Setup: Put the Unit Under Test (UUT) or the overall test system in the state needed to run the test. (3) validation. which then drive the traditional unit test-driven development (UTDD) process. The first test might not even compile. last a long time. A commonly applied structure for test cases has (1) setup. This has been coined the "test-driven development mantra". These results may include explicit outputs captured during Execution or state changes in the UUT. • Validation: Ensure the results of the test are correct. known as red/green/refactor where red means fail and green is pass. With ATDD. The common practice of allowing a 5-10 percent margin for late execution reduces the potential number of false negatives in test execution. For TDD.

but can also drive the design of a program. Eliminating defects early in the process usually avoids lengthy and tedious debugging later in the project. the test cases). more focused classes. and subsequent users.” An oracle that inspects more than necessary is more expensive and brittle over time than it needs to be. for a TDD developer to add an else branch to an existing if statement. Basic refactoring of the initial test cases or structure of the UUT causes a spiral of increasingly pervasive impacts in associated tests. While it is true that more code is required with TDD than without TDD because of the unit test code.[citation needed] By focusing on the test cases first. preventing them from becoming endemic and expensive problems. the developer would first have to write a failing test case that motivates the branch.[6] Hypotheses relating to code quality and a more direct correlation between TDD and productivity were inconclusive. Execution order has to be specifiable and/or constant. looser coupling. reverting the code to the last version that passed all tests may often be more productive than debugging. The use of the mock object design pattern also contributes to the overall modularization of the code because this pattern requires that the code be written so that modules can be switched easily between mock versions for unit testing and "real" versions for deployment. • Do not test precise execution behavior timing or performance. and tests to create these extraneous circumstances are implemented separately.[8] Test-driven development offers more than just simple validation of correctness. the automated tests resulting from TDD tend to be very thorough: they detect any unexpected changes in the code's behaviour. The early and frequent nature of the testing helps to catch defects early in the development cycle. It allows a programmer to focus on the task at hand as the first goal is to make the test pass. and extensible code. • Do not try to build “all-knowing oracles. TDD can lead to more modularized. flexible. • A test suite where test cases are dependent upon each other is brittle and complex. a greater level of confidence in the code. This gives the programming team. As a result. or "anti-patterns" • Do not have test cases depend on system state manipulated from previously executed test cases. This very common error is dangerous because it causes a subtle but pervasive time sink across the complex project. in turn. Test-driven development ensures in this way that all written code is covered by at least one test.[9] Large numbers of tests help to limit the number of defects in the code. Exceptional cases and error handling are not considered initially. automated tests tend to cover every code path. . So. the programmer is concerned with the interface before the implementation. Test-driven development offers the ability to take small steps when required. when tests fail unexpectedly. increasing defect analysis and debug efforts. This leads to smaller. This effect often comes about because the methodology requires that the developers think of the software in terms of small units that can be written and tested independently and integrated together later. This benefit is complementary to Design by Contract as it approaches code through test cases rather than through mathematical assertions or preconceptions. one must imagine how the functionality is used by clients (in the first case.[7] Programmers using pure TDD on new ("greenfield") projects reported they only rarely felt the need to invoke a debugger. A failure in an early test case breaks a later test case even if no actual fault exists in the UUT. Because no more code is written than necessary to pass a failing test case.Test-driven development 42 Practices to avoid. programmers who wrote more tests tended to be more productive. This detects problems that can arise where a change later in the development cycle unexpectedly alters other functionality. and cleaner interfaces. • Interdependent tests can cause cascading false negatives. the total code implementation time could be shorter based on a model by Müller and Padberg.[] Benefits A 2005 study found that using TDD meant writing more tests and. For example. Used in conjunction with a version control system.

NET Framework and some other programming languages. Also. On the other hand. a developer does not realize that certain input parameters must be checked. so that when a real failure occurs. Therefore unit test code for TDD is usually written within the same project or module as the code being tested. partial classes may be used to expose private methods and data for the tests to access.. Badly written tests. can be easier to adjust than a set of highly detailed tests. using fakes and mocks to represent the outside world. it may not be detected. compiler directives such as #if DEBUG . Therefore. It is important that such testing hacks do not remain in the production code. Merely deleting. programs that work with databases.[12] Alternatively. TDD encourages developers to put the minimum amount of code into such modules and to maximize the logic that is in testable library code. integration tests on the final release build can ensure (among other things) that no production code exists that subtly relies on aspects of the test harness. In the . more-flexible modules (with limited tests) might accept new requirements without the need for changing the tests. as giving a false sense of correctness. • The high number of passing unit tests may bring a false sense of security. to rewrite the tests when requirements change. then it is important that they are individually fixed. Without the entire organization believing that test-driven development is going to improve the product. are expensive to maintain. if a poor architecture. for example by the reuse of error strings. or early. for example ones that include hard-coded error strings or are themselves prone to failure. and later. both the tests and the code will be wrong. tests become increasingly precious as time goes by. and some that depend on specific network configurations. In C and other languages.. management may feel that time spent writing tests is wasted. a poor design. . Examples of these are user interfaces. encapsulation and the separation of concerns should not be compromised.[11] There is a risk that tests that regularly generate false failures will be ignored. #endif can be placed around such additional classes and indeed all other test-related code to prevent them being compiled into the released code.[10] • Unit tests created in a test-driven development environment are typically created by the developer who is writing the code being tested. This means the released code is not exactly the same as what was unit tested. Therefore these original. but it might require advanced skills in sampling or factor analysis. Also. It is possible to write tests for low and easy maintenance. or a poor testing strategy leads to a late change that makes dozens of existing tests fail. The regular running of fewer but more comprehensive. The tactic is to fix it early. For those reasons.Test-driven development 43 Shortcomings • Test-driven development is difficult to use in situations where full functional tests are required to determine success or failure. • Overtesting can consume time both to write the excessive tests. • Management support is essential. an inner class can be used to hold the unit tests so they have visibility of the enclosing class's members and attributes. most likely neither the test nor the code will verify these input parameters. If the developer misinterprets the requirements specification for the module being developed. disabling or rashly altering them can lead to undetectable holes in the test coverage. • Tests become part of the maintenance overhead of a project. resulting in fewer additional software testing activities. or a small sample of data. This is especially the case with fragile tests. such as integration testing and compliance testing. In object oriented design this still does not provide access to private data and methods. Code visibility Test suite code clearly has to be able to access the code it is testing. and this should be a goal during the code refactoring phase described above. developers could be warned about overtesting to avoid the excessive work. testing for only extreme conditions. • The level of coverage and testing detail achieved during repeated TDD cycles cannot easily be re-created at a later date. In Java and other languages. end-to-end. However. normal design criteria such as information hiding. extra work may be necessary for unit tests. for example. The tests may therefore share the same blind spots with the code: If. a developer can use reflection to access fields that are marked private.

Thus it should be sufficient to test any class through its public interface or through its subclass interface. Whenever external access is needed in the final design. If one module misbehaves in a chain of interrelated modules. The tests used for TDD should never cross process boundaries in a program. and should be allowed to do so without breaking numbers of tests. can help the test process by always returning the same. a method may return an invalid. They can also be set into predefined fault modes so that error-handling routines can be developed and reliably tested. let alone network connections. and that developing this while testing it indirectly via the public interface only obscures the issue: unit testing is about testing the smallest unit of functionality possible. documented in their blogs and other writings. Introducing dependencies on external modules or data also turns unit tests into integration tests. and the other of which is a fake or mock. if the person's name and other data are not as expected. more testable and more reusable code. . The interface should be implemented in two ways. See the dependency inversion principle for a discussion of the benefits of doing this regardless of TDD. or any other external process or service.[14][15] 44 Software for TDD There are many testing frameworks and tools that are useful in TDD xUnit frameworks Developers may use computer-assisted testing frameworks.[17] Two steps are necessary: 1. to create and automatically run sets of test cases.[13] Others say that crucial aspects of functionality may be implemented in private methods. These capabilities are critical for automation as they move the burden of execution validation from an independent post-processing activity to one that is included in the test execution. In a fault mode. such as xUnit. realistic data that tests can rely upon. as to whether it is wise to test private methods and data anyway. Fake and mock object methods that return data. Xunit frameworks provide assertion-style test validation capabilities and result reporting.Test-driven development There is some debate among practitioners of TDD. against which a test assertion can be run to verify correct behaviour. ostensibly from a data store or user. one of which really accesses the external process. an interface should be defined that describes the access available. Fake objects need do little more than add a message such as “Person object saved” to a trace log. enforcing a unit-testable separation is also an opportunity and a driving force to design more modular. Many popular xUnit frameworks are openly available: • • • • • • JUnit cppUnit UnitTest++ Unity (for C) NUnit PHPUnit The execution framework provided by these test frameworks allows for the automatic execution of all system test cases or various subsets along with other features. A complex module may have a thousand unit tests and a simple module may have only ten.[16] Fakes. which some languages call the "protected" interface. Some argue that private members are a mere implementation detail that may change. a web service. for example. it is not so immediately clear where to look for the cause of the failure. mocks and integration tests Unit tests are so named because they each test one unit of code. When code under development relies on a database. Mock objects differ in that they themselves contain test assertions that can make the test fail. Doing so introduces delays that make tests run slowly and discourage developers from running the whole suite. 2.

which is executed to validate testing. • Database transactions where a transaction atomically includes perhaps a write.[] A corollary of such dependency injection is that the actual database or other external-access code is never tested by the TDD process itself.catch. in fact. • Taking a "snapshot" of the database before running any tests and rolling back to the snapshot after each test run. a fake random number service may always return 1. or may throw an exception.. Integration tests that alter any persistent store or database should always be designed carefully with consideration of the initial and final state of the files or database. A simulator typically requires significant additional development effort. This substitution is typically done through the reassignment of known function pointers or object replacement. which is integral to many test frameworks. These are integration tests and are quite separate from the TDD unit tests. providing different outputs. and they must be run less often than the unit tests.. • Initialising the database to a clean state before tests.. They can nonetheless be implemented using the same testing framework. A Test Double is a test-specific capability that substitutes for a system capability. 45 . This approach is typically used when running in an environment other than the target environment that requires doubles for the hardware level code for compilation. To avoid errors that may arise from this. This may be automated using a framework such as Ant or NAnt or a continuous integration system such as CruiseControl. Fake or mock implementations are examples of dependency injection. This may be relevant where cleaning up may make it difficult to diagnose test failures by deleting the final state of the database before detailed diagnosis can be performed. There are fewer of them. This is often achieved using some combination of the following techniques: • The TearDown method. • try. Link time substitution is when the test double is compiled into the load module. other tests are needed that instantiate the test-driven code with the "real" implementations of the interfaces discussed above. There are two times at which test doubles can be introduced into a system: link and execution. typically a class or function. Fake services other than data stores may also be useful in TDD: A fake encryption service may not. It facilitates linker time substitution by providing a default return value where required. such as xUnit. encrypt the data passed. The alternative to linker substitution is run-time substitution in which the real functionality is replaced during the execution of a test cases.finally exception handling structures where available.. checking parameter values and call sequencing. even if any test fails. rather than cleaning up after them. Test doubles are of a number of different types and varying complexities: • Dummy – A dummy is the simplest form of a test double. that the UUT depends on. • Spy – A spy captures and makes available parameter and state information.Test-driven development incomplete or null response. publishing accessors to test code for private information allowing for more advanced state validation. • Simulator – A simulator is a comprehensive component providing a higher-fidelity approximation of the target capability (the thing being doubled). • Mock – A mock is specified by an individual test case to validate test-specific behavior. • Stub – A stub adds simplistic logic to a dummy. a read and a matching delete operation.

• Published Interfaces restrict Component access and serve as contact points for tests. JW and Vorontsov. A key technique for building effective modular architecture is Scenario Modeling where a set of sequence chart is constructed. K. 2003 Newkirk. Microsoft Press.aspx) .com/general/monthly_column/2004/ september. • Well-defined components with published interfaces. Addison Wesley . by Bertrand Meyer (September 2004) • Microsoft Visual Studio Team Test from a TDD approach (http://msdn. A key subset of these requirements includes support for the complete and effective testing of the system. eroding potential gains. and it also dictates the order that these components and services interact together.Vaseem. These proven practices yield increased testability and facilitate the application of build and test automation. 2007 External links • TestDrivenDevelopment on WikiWikiWeb • Test or spec? Test and spec? Test from spec! (http://www.NET. AA.Test-driven development 46 TDD for complex systems Exercising TDD on large. Test drivers interact with the UUT. 2004. Test-Driven Development in Microsoft .[] Designing for testability Complex systems require an architecture that meets a range of requirements. Feathers. Working Effectively with Legacy Code. Effective modular design yields components that share traits essential for effective TDD. • Disciplined system layering with maximization of platform independence. each one focusing on a single system-level execution Scenario modeling can greatly facilitate the construction of TDD tests for a complex system.[] Managing tests for large teams In a larger system the impact of poor component quality is magnified by the complexity of interactions. However. challenging systems requires: • A modular architecture.eiffel. Each of these Scenario Models serves as a rich set of requirements for the services or functions that a component must ms379625(VS. facilitating test creation and ensuring the highest fidelity between test and production unit configuration. but a key initial step is to recognize that test code is also important software and should be produced and maintained with the same rigor as the production code. "Test Driven: TDD and Acceptance TDD for Java Developers". Test-Driven Development by Example. The Scenario Model provides an excellent vehicle for creating the strategy of interactions between components in response to a specific stimulus. It sounds simple.html). This magnification makes the benefits of TDD accrue even faster in the context of larger projects. • Low Coupling allows each unit to be effectively tested in isolation. M. 2004 Koskela. the complexity of the total population of tests can become a problem in itself.80).[] References [1] [2] [3] [5] Beck. • High Cohesion ensures each unit provides a set of related capabilities and makes the tests of those capabilities easier to maintain. test doubles and the unit test framework. L. Manning Publications. Prentice Hall. Creating and managing the architecture of test software within a complex system is just as important as the core product architecture.

which lists a Dermot McShane (i. which itself is cognate to the name John. 2nd Earl Alexander of Tunis (b. 1971).[2] The surname was first recorded in Petty's census of Ireland (1659).[1] Shane comes from the way the name Seán is pronounced in the Ulster dialect of the Irish language. meaning "beautiful". 1971). "Mac". Seán.php?id=20) 47 Shane (name) Shane Pronunciation Gender SHAYN Male Origin Meaning 'graced by God' Region of origin Ireland Other names Related names John. Guthrie Jr. 1975). 1978). Men • • • • • • • • • Shane Acker (b.aspx) • Improving Application Quality Using Test-Driven Development (TDD) (http://www. American filmmaker Shane Alexander. It is an Anglicised version of the Irish name Seán. Shane is sometimes used as a feminine given name. Son of Shane). 1935). derived not from the Irish name but from the Yiddish name Shayna. or "O'". as opposed to Shaun or Shawn.methodsandtools. American Christian activist Shayne Corson (b.[3] The name Shane became popular through the novel Shane (1949) by Jack Schaefer and its movie adaptation (1953).. British-Australian actor and novelist Shane Byrne (b.e. American basketball player Shane Bond ( You can help by adding people entries to it.Test-driven development • Write Maintainable Unit Tests That Will Save You Time And Tears (http://msdn. Shane is also a popular surname with the prefix "Mc". 1975). 1966). to form Anglicized Irish surname archive/archive. New Zealand cricketer Shane Briant (b. directed by George Stevens from a screenplay by A. British peer Shane Battier ( magazine/cc163665. Irish rugby union player Shane Carwin (b. American MMA fighter Shane Claiborne (b.[citation needed] Given name This list is incomplete. Canadian retired hockey player . Juan Shane is a masculine given name. Variants Variant forms include Shayne and Shain. 1946). 1970).

1971). Canadian track and field athlete Shane O'Neill (ca.Shane (name) • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Shane Crawford (b. 1973). 1993). Australian cricketer Shane Watson (b. retired AFL football player and premiership player with Hawthorn Shane Doan (b. 1970). dancer Shane Horgan (b. Canadian actor Shane Lee (b. American football player Shane McKenzie (b. 1981). 1970). British film director Shane Mosley (b. 1969). 1964). 1978). lead singer of the Irish band Westlife Shane Haboucha (b. 1974). American media scholar Shayne Topp. retired AFL football player and Brownlow Medal 48 . "The O' Neill" • Shane O'Neill (disambiguation) Shane Reynolds (b. Australian former cricketer Shane Leslie (1885–1971). singer. 1978). American hip-hop choreographer Shane Stant (b. American comic book artist Shane Woewodin (b. American actor. American former baseball player Shane Richie (b. 1980). 1990). 1973). Irish warrior. professional surfer Shane Dawson (b. 1957). Canadian NHL hockey player Shane Dorian (b. 1970). Professional Boxer Shane Niemi (b. bassist of the British band Napalm Death Shane Filan (b. Australian cricketer Shane Webcke (b. 1976). 1984). British actor and TV presenter Shane Scott (b. 1978). 1972). American actor Shane Tutmarc. Australian athlete Shane McMahon (b. former WWE executive and wrestler Shane Meadows (b. 1967). 1971). 1972). 1971). Irish rugby union player Shane Kippel (b. singer/songwriter for the Irish music group The Pogues Shane Matthews (b. American child actor Shane Harper (b. 1974). 1976). 1979). American baseball player Shayne Ward (b. 1978). 1968). American singer/songwriter Shane Victorino (b. American film director and producer Shane Sparks (b. American actor Shane Williams (b. British pop singer Shane Warne (b. 1977). Welsh rugby union player Shane White (b. 1974). YouTube comedian and actor Shane Embury (b. Irish singer in the band Boyzone Shane MacGowan (b. 1988). Australian rugby league footballer Shane West (b. the known assailant who attacked Nancy Kerrigan Shane Tilton (b. 1986). 1966). 1530–1567). Irish-born diplomat and writer Shane Lynch (b.

principal character in the Showtime series 'Weeds' Surname Shane Family name Pronunciation shayn Related names McShane. 1979). the eponymous hero of a novel (1949) by Jack Schaefer. the twin brothers Mike and Todd Shane.Shane (name) 49 Women • Shane Gould (b. professional wrestlers Tom Shane. Locomotive Number 5 on the Culdee Fell Railway in the Railway Series by the Reverend W. test pilot Paul Shane (b. 1956). central character in Matthew Reilly's novels Ice Station. founder of the Shane Company. Area 7. British former wrestler Bob Shane (b. Awdry • Shane McCutcheon from The L Word • Captain Shane Schofield. MacShane. 1940). American folk singer. the largest family-owned jeweler in the United States References . 1967). English actor Shane Twins (b. co-founder and lead singer of The Kingston Trio Doug Shane. which was adapted to film (1953) • Shane Vendrell. Australian swimmer Fictional characters • Shane. Scarecrow and Hell Island • Shane Gooseman a Galaxy Rangers member • Shane Oman in Mean Girls • Shane Walsh in The Walking Dead comic series • Shane Botwin. O'Shane • • • • • • Alex Shane (b. 1934). a detective on the FX Networks police drama television series The Shield • Shane Dooiney.

Downsize43. Pinecar. Claygate. Reo46. Shepard. Geometry. Brevan. Swasden. Antonielly. Gogo Dodo. Martinig. Emurphy42. Tomb. Rklawton. Nakon. Stephenb. Petritis. Clarince63. Ninja247. Jdpipe. Quasarblue. Rignac. V6Zi34. Mesolimbo. Oligomous. William Avery. Oriondown. Lews Therin. Daniel. CFMWiki1. JohnCD. Ponyo.150. Jlederer2. Veinor. Djgandy. Coasterlover1994. Jérôme. Vrenator.237. Kurykh. Patricidio. AxelBusch. N1RK4UDSK714. Jglynn43. Trum123. Jvale. Lotje. 454 anonymous edits Shane (name)  Source: http://en. Alshall. PanderMusubi. Sardanaphalus. Olexandr Kravchuk. Banana Concoction. Mkksingha. Ronz. Attilios. Rediahs. Boomshadow. Gary King. Hooperbloob. Tassedethe. Pavel Vozenilek. Valrith. Mathew Roberson. Suruena. Mboverload. Mdd. Thumperward.d. Anupam. Espio 360. Tobych.midttun. Ed Poor.wikipedia. Martial75. Kmouly. DavidCary. Mhhanley. Jojalozzo. JBC3. Doroli. Rushbugled13. Wdfarmer.php?oldid=546881067  Contributors: 4johnny. Orborde. Polidari. Mortense. Iner22. Gigi fire. Jhertel. DARTH SIDIOUS 2. Aoineko. Disambiguator. Mark Renier. Malleus Fatuorum. ESkog. Gwern. Historyfiend2000. Kevin sh. Mdd. Rich Farmbrough. Rhundhausen. Julienchabe. Radagast83. MarkDilley. Sire TRM. Sam Hocevar. Jeff. Gil Gamesh. Tijfo098. Peripitus. NigelR. Techwizization. JaGa. Edward. Tsemii. Empiric.wikipedia.lasovski. Sjc. Xexeo. Slayerdiabolus. Torin the Chosen. Rnickel. Chi11ken. Sunil1234b. Tide rolls. Mike1234. Droob. Itairaz. Scrumone.. Marek69. Runtime. Waratah. ConchangoMaster.deepthi.php?oldid=546923109  Contributors: Andareed. Dylanfromthenorth. William Allen Simpson. Nono64. Nmehta6. Excirial. 209. Stevage. Jonkpa. MaxGuernseyIII. Amire80. Ronz. Dopetimes. Deb.northern. Andreas Kaufmann. Jed meyers. Demonkoryu. Jeff G. CYD. Bdiscoe. Jojalozzo. Diego Moya. Electriccatfish2. DonWells. Shoez. Wikid77. Tony1. Matthew0028. S M Woodall. PDX Aaron. Anorthup. Closedmouth. Lastorset. Kristen Eriksen. Jrvz. Hao2lian. Jschmidt163. Shosh3333. 2004-12-29T22:45Z. Gmcrews. Nuggetboy. Sanchom. Vincehk.alex. Stemcd. Elipongo. Dharris. Ron Richard. Homerjay. Dwanyewest. Oni king. EagleFan. Brianski. Protonk. Amanieux. Reach Out to the Truth. Anilgundogdu. Dave6. Timbertstc. Unkei. Runtime. Bryan Villacis.ndr. Xiong Chiamiov. Faught. LilHelpa. Tamfang. Franyhi. January. Timwi. Sarah. Quintote. Dwarth. AliveFreeHappy. Shaw. Rmp. Cat Parade. Osmodiar. GoingBatty. Mberteig. Shalazy. Jlgrock. Azamishaque. Vikram. M0llusk. Srlawr. Iterator12n. Edddie. McGeddon. Mdubakov. Netsnipe. Sverdrup. Magioladitis. Discospinster. XPeltier. Oicumayberight. Albtau. Renesis. Tanyajenkin. Clayoquot. Cybercobra. Walter Görlitz. Gruber76. Teh pageboy. Nigosh. ThomasOwens. Jjsladek. Walter Görlitz. Looxix. Svick. Melanmoronic. Kirrages. Huygens 25. Greyskinnedboy. Ricky stern. Patrickdepinguin. KGasso. Michael Hardy. Smokizzy. Myasuda. Fongamanda. TeunSpaans. Eric B. Baa. Madduck. Rubyuser. Jordo ex. Lwoodyiii. Blueguybur. Rebroad. Abhi3385. GregorB. PradeepArya1109. Cybercobra. Bcwhite. BBB. Arvin Schnell. Madhavan. Entropy. Tumma72. Mattdm. Sverdrup. Jmundo. Gigi fire. Garde. Bryan Derksen. Kevin Rector. Piano non troppo. Stumps. St. Introvert. William Avery. Bfalese. Alfio. Jeffnailen. Mpeisenbr. Pearle. Gegonut. Psiphiorg. Adler. Graham87.macdonald. Khargett dk. Wangi. Stephiee01. Trusilver. Zodiakos. Freedomlinux. Blowedupt. Hede2000. Ostraaten.larman. Scottwilleke. Kabir1976. Susurrus. Brainix. Kristjan Wager. Lorezsky. Ehheh. China Crisis. Etrigan. Lampak. Dougluce. JDBravo. MrOllie. Sanspeur. WookieInHeat. DRogers. Willowrising. Patrickdepinguin. Diya batti. Cybercobra. CarlManaster. Gaius Cornelius. Juraj. Ramsyam. Supreme Deliciousness. RoyOsherove. Demonkoryu. Ilja Preuß. Juanco. Closeapple. Mdd. Drunken Pirate. Jittat. Pengo. Retired username. 57 anonymous edits Test-driven development  Source: http://en. Tech vaibhav. Littlesal. Taejo. Sesoo222. Johnchapman4. Bernd in Japan. Philip Trueman. Cmccormick8. Martinig. Asarlaí. Bernburgerin. On5deu. Fayenatic london. Firien. Laterality. Humu. Akjar13. Obonicus. Knshaum. Dtmilano. Mr pand. Mfdavies. Jcjollant. DevelCuy. Timwi. Ruabat1995. Andy Dingley. SchreiberBike. Theornamentalist. Ninly. AllanBz. Breandandalton. The Wild Falcon. Jleedev. Kent Beck. Eirik. Luna Santin. Tjarrett. Bf2k. Sporti. Torrg. Zycron. Janeve. Mckaysalisbury.VisiBone. Ogennadi. Loreleine1. Cumeo89. Shadowcat231. Michig. Wdyoung. Mottzo. Sirk390. Alansohn. Debresser. Anthony Appleyard. Ed Poor. Webmaestro. Jezmck. Knutux. Az944racer. Samwashburn3. Tregoweth. Dreadstar. FeralDruid. Csshaastry. Iterator12n. Nightreaver. PradeepArya1109. Marijn. Vacation9. Wainstead. Peruvianllama. Rich257. Sean-is-over-there. SeanLegassick. Choriem. Rogerborg. Aacool. Derek. ChrisGualtieri. Phanibca. Stormie. Groovez.steve. AnthonySteele. HolgerK. Michig. Miranda. Jmlive. John. Phineas Quacrod. Tgruwell. Jonducrou. Niteowlneils.php?oldid=540470545  Contributors: AGK. UU..leonard. RobinDaniel. Taz00. Jamelan. Bates. PhilippeAntras. Kerrick Staley. Woohookitty. Chunkylover199. Lycurgus. Xsmith. Meand. Windharp. San chako. Oicumayberight. Fluffykryptonite. TakuyaMurata. Kenimaru. Series8217. PavelCurtis. Luket7. Wapcaplet. Michael miceli. 2001:470:1F0B:448:221:5AFF:FE21:1022. Underpants. N5iln. Strategy BenAveling. Dbase55. Az944racer. Canderra. Facius. Ram. Wikiloop. Virgiltrasca. Larryaustin10. Tellyaddict. David. Edward. Marcoshz. Mkarlesky. AntiMeth. N8mills. Fred Bradstadt. Mark Renier. Jpalm 98. Shancy. Calmez. Scrum2001. LiDaobing. Mberteig. SMcCandlish. Długosz. Hzhbcl. Riki. Mathiasl26. Allens. Mhartl. Lumberjake. Bownyboy. Pueywei. ElinneaG. Robinson weijman. Jbargen. Wperdue. Buzzfledderjohn. Shinmawa. Craig. Mike Cline. Andreas Kaufmann. Nifky?. Fritzpoll. Steven J.beatty. Nadia. LokiClock. Agentbla.wikipedia. MementoVivere. Gishu Pillai. Buddhikaeport. Th4n3r. Jonb ee. SimonP. Rajesh1981. Tryevenharder. Mortense. and Rakim. Futurepower(R). Neilc. Bernd in Japan. Robert. Embronne. SharShar.Koslowski. Scrumedge. Olivierhory. Arcandam. Erik9. Hritcu. Anderbubble. Lumberjake. Geni. Bongwarrior. Underpants. LOL. MLetterle. R'n'B. Ohnoitsjamie. Bliong. Jared Hunt. L Kensington. Kristof vt. Mr2001. Deuxpi. Archipelago88. Vrenator. Scrummaster. JLaTondre. Rajesh212e63. Fru1tbat. ChristianEdwardGruber. Ryan shell. Hagai Cibulski. Dougher. Shepard. Evan. Debhart. Mmpubs. MCB. CraigTreptow. Amalthea. ChrisSims. MaxSem. Chrisc666.wikipedia. Jonkpa. Zundark. Joel7687. Littlesal. Ryandaum. 622 anonymous edits Feature-driven development  Source: http://en. 260 anonymous edits . Pinkadelica.braunias. Gakrivas. N2e. Sardanaphalus. Miyako. Johannes. SAE1962. Tree Biting Conspiracy. Untruth. Metzujan. Mrh30. Mdd. Kusunose. JG17. Tsilb. KerryBuckley. Johnnybifter. Salon Essahj. Tnxman307. Mboverload. DavidShepherdson. Carlton. Plasticup. Falcn42. Themacboy. Sb789. Allecher. David-Sarah Hopwood. Mattgow. Littlesal. Drfonzerific. Superandoni. Sligocki. Fred Waltzer. WLU. S. Minna Sora no Shita. Primetime. Elecnix. SteveLoughran. Chris. 13 anonymous edits Lean software development  Source: http://en. Kurt Jansson. Tiddly Tom. Jwbecher. MrOllie. Juhko. Afternoon. Heaths. Ebacky. Shadowjams.wikipedia.constantine. Wiki3 1415. Ficell. Dannydohrmann. MaxSem. D(r)ead End. Stevertigo. NickVeys. Dodoïste. Notnoisy. JordanSamuels. Zsinj. Олександр Кравчук. Skyrail. Regentagger. Astaines. Alphamage. Picaroon. Van der Hoorn. Corprew. Stephaniefontana. Matusz. Agauthier007. Corbett. Guillom. Kazvorpal. Anirvan. Derekhuether. Szwejkc. Jensgb. SAE1962. Gaurav. Wagino 20100516. Bevo. Wikid77. Avalon. R. Jzylstra. Dogaroon. Dgerwe. M4bwav. TwilightSpirit. Cthart. Rohan Jayasekera. Gogo Dodo. Sean D Martin. LarsHolmberg. Kvdveer. Efumagalli. AbominableBob. Midnight Bliss. Bgwhite. Faller. Chwu. Vary. SlubGlub. Gdavidp. Parklandspanaway.php?oldid=546097356  Contributors: 194. Alex43223. Jgrasse2. Martinig. Grafen. Kuru. Peashy. Tobych. Lrzepecki. SDC. BD2412. EweC. Wilhkar. Rinkle gorge. Songrit. Jpverdoorn. Jmilunsky. Rulesdoc. Rjwilmsi. Andywarr.michael. Damian Shaybrooke.php?oldid=546540036  Contributors: 2aprilboy. E Wing. Ghartnett. Zzuuzz. Ojcit. Rosiestep. Kubigula. Dicklyon. Eliyahu S. Iani.wikipedia. Bookofjude. Qwirty. DrBeard. CapitalR. Codeengage. Enochlau. Pgan002. Oskilian. Avec. MarmotteNZ. I8abug. Someguy1221. Andreas Kaufmann. Iridescent. Ceyockey. Veinor. Jferman. Kellen`. Xagronaut. Peterhundermark. Canterbury Tail. Derbeth. Dysthymaeon. Krzyk2. Law. EngineerScotty. Download. Hwsd. Hajatvrc. Nohat. RickBeton. Tony1. Kristjan Wager. C. Phlip2005.fa. Mathiastck. Pigman. Abdull. SteveLoughran. Aardvark92. Influent1. Belindatee. CommonsDelinker. Elonka. Beland. Shenme. Goodrone. Ramesh. Malcohol. LedgendGamer. Ruud Koot. Breadtk. Zorakoid. Micah hainline. Hzhbcl. Zedlik. NAHID. Maslax010. Yunshui. Asgeirn. Starwiz. Darkwind. Chrislk02. Edward. Cheny com. Conti. Wesley. Furrykef. Jarble.Nevelsteen. Chrisjj3. Heirpixel. PhilipR. Chris Pickett. Esben Krag Hansen.lamb. Jesse Laanti. Dereckson. Hyad. Closedmouth. Beland.perla. Lakeworks. DixonD. Shannock9. Hydrogen Iodide. Milesibastos. Mblumber. Eurleif. Jmlive. Sleepingbull. Gmathur2k. MontrealKCD. Scrumireland. Safro Elizabeth. Zeeshanekufytfrtdytduui. SaltOfTheFlame. Die4Dixie. clown will eat me. Khalid hassani. Acontrib. Littlesal. Anderson. Dude4456dude. Robjenssen. David Waters. Shanegold123. Dfg13. Schandi.208. Dwellings. Wikid77. Rookkey. Sj26. Winterstein. On5deu. Dpcoka. MithrandirMage.php?oldid=541274395  Contributors: AGK. O. Kvng. Rscottfree. LeaveSleaves. Tobias Bergemann. DarkseidX. Jivecat. Mckoss. Teryx. The Thing That Should Not Be. Mutant. BigBen212. JaGa. Brownout. Scbomber. Ftiercel. BrianWren.t. Satsel. CometGuru.n. Xanalaska. CloudMinder. U235. Jmabel. Whytehorse1413. Hhiroshi. Goodhandyman. Albanaco. Mikiemike. Heron. Pnm. Can't sleep. Jleedev. Elcidia. Fre0n. EricEnfermero. Paul A. Poco a poco. AutumnSnow. Ikhnaton2. Neko-chan. Matt Crypto. Dally Horton. Camw. Cameltrader. Antialias. Download. JamesBrownJr. Wegra. TriSimon. Virgiltrasca. Smaines. Ohiostandard. Jorfer. BertBril. Koosabear. Ticaro. Holizz. Mh007. Vipinhari. Trevorjfitz. MeUser42. Klilidiplomus. Mathmo. 4johnny. Mistercupcake. Tlroche. Brick Thrower. Immunize. Beland. Jack in the box. DARTH SIDIOUS 2. Evolve2k. Martarius. TigerShark. Jnestorius. Magioladitis. Mosquitopsu. Vthavo. Andrewrp. William Pietri. Rlliii.munneke. Timneu22. Echofloripa. Dougluce. Radak. JacobProffitt. Gwernol. Dale Arnett. Jurr. TakuyaMurata. Pengo. Tyagisaab. Thumperward. Julesd. Ali Osmany. Lerkey. Ericclack. Srinicenthala. CLAES. RJaguar3. Simpleness. Mastamb. Markmansouraustralia. Alphachimp. Kragelund. Czpddz. CometGuru. Dougluce. Strikehold. Grafen. Ajm661023. Ctu92. Adi4094. BradBradleySecond. Merenta. Reconsider the static. OpenFuture. Di Stroppo. Cybercobra. Yaninass2. Jamiemaloneyscoreg. Gekritzl. Richard R White. Beland. Guppie. Lenin1991. Tedickey. Downeydd. Teckmx5. Longpat. Exemplar sententia. Pweemeeuw. Dharmabum420. Zombiedeity. Mnorbury. Gary King. Dspectar. Danielbutcher. Dougher. Lprichar. Lane2. Onego. Shell Kinney. Peterl. Luc Legay. Tobias Bergemann. SethTisue. Sullivan. Cverlinden. Wjhonson. Yogert96. WTF-tech.auradkar. Morphex. Swasical. Kbdank71. Topping. S. Mmeijeri. Calréfa Wéná. DanielPharos. Wizmo. Tobias Bergemann. Linusdalin. The Thing That Should Not Be. Hariharan wiki. Secarrie.nivas. ScottWAmbler. Riordanmr. Oscarthecat. Mdd.wikipedia. Sky Diva. Pm master. Ikluft. The Thing That Should Not Be. PabloStraub. Anorthup. Ishi Gustaedr. Nigelj. Kaniabi. AGK. Woohookitty. Moonriddengirl. Achorny. ComputerGeezer. Alksentrs. Mahbubur-r-aaman. Kwertii. Versus22. Craig Stuntz. Koustubh123. DVdm. Cerrol.akif. Download. Middayexpress. Jzylstra. Thumperward.239. R'n'B. Sardanaphalus. Politepunk. Joshuaprewitt. FreeRangeFrog. MDE. Keilana. Kku. Agile blog. SensuiShinobu1234.Kubelka. RSaunders. Crasshopper. Bombe. Gracefool. Shyam 48. Jtauber. Stephanvaningen. Kuru. PhilipR.matt38. Philip Trueman. Bob Stein . Razaulhaq.elango. Autarch. Rsrikanth05. Atreys. Maschreu. Gibsonf1. Mkoval. ReyBrujo. Trusilver. Anupam.Article Sources and Contributors 50 Article Sources and Contributors Scrum (development)  Source: http://en. Edaelon. Hirzel. Quantum7. Descender. KellyCoinGuy. Kbdank71. Craig Stuntz. Saforcer.cartwright. Dhdblues. 95 anonymous edits Extreme programming  Source: http://en. Valyt. Naasking. LeslieValentine.Cardenas. WikHead. K. Boogachamp. 1001 anonymous edits Crystal Clear (software development)  Source: http://en. Littlesal. Hadal. YordanGeorgiev. ChrisSteinbach. Fbeppler. Christian75. Annasw. Raghunathan.K. Michaelkourlas.General. Shane577. Jvstein. Pak21. Wgiezeman. Markbassett. Mossd. Conversion script. KF9129. Hondo77. Shadowjams. Jcarroll. Jeff. Kctucker. Frecklefoot. Axd. MelbourneStar. Moriori.php?oldid=547169246  Contributors: 1sraghavan.Mortimer. Kbdank71. Dantams. Michael98101. Ubergeekguy. Ettrig. FF2010. LFaraone. Piano non troppo. Ewlyahoocom.

wikipedia.php?title=File:SampleBurndownChart.wikipedia.svg  Source: http://en.png  Source: http://en. Sebastian Wallroth.wikipedia. KTo288.png  License: Public Domain  Contributors: Pablo Straub Image:XP-feedback. Ftiercel.png  License: GNU Free Documentation License  Contributors: Dgerwe at  Source: http://en.wikipedia.0  Contributors: FlickreviewR.wikipedia.0  Contributors: User:Matthew (WMF) File:Scrum Licenses and Contributors file:Coding Shots Annual Plan high Ftiercel File:Scrum task board.jpg  Source: http://en.0  Contributors: DonWells Image:Fdd process diagram.png  Source: Image:Fdd process data  Source: van Gerwe Dgerwe Image:Test-driven development.gif  Source: http://en.php?title=File:Fdd_process_diagram.php?title=File:Scrum_process.jpg  License: Creative Commons Attribution 2. Mdd.PNG  License: Creative Commons Attribution-Sharealike 3. Lakeworks. Licenses and Contributors 51 Image Sources.wikipedia. Mattes.Image Sources.php?title=File:Test-driven_development.php?title=File:Scrum_task_board.wikipedia. Contribs) .jpg  License: Creative Commons Attribution-Sharealike 3.jpg  Source: 2 anonymous edits File:Daily sprint meeting.svg  License: unknown  Contributors: Bruce1ee.png  License: GNU Free Documentation License  Contributors: D.jpg  License: Creative Commons Attribution-Sharealike 2.php?title=File:XP-feedback.0  Contributors: FlickreviewR.gif  License: Creative Commons Attribution Ww2censor File:SampleBurndownChart.png  Source: http://en.0  Contributors: Excirial (Contact me.wikipedia.

org/licenses/by-sa/3.License 52 License Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.0/ .