LevelUp Week3 Readings

Week 3 Readings
PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Wed, 27 Mar 2013 04:06:29 UTC
Contents
Articles
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
References
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)
2
Tools

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".
History
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)
Roles
There are three core roles[5] and a range of ancillary rolescore 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 processthey 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 39 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 processbut 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.
Sprint
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
Scrum (development) During each sprint, the team creates finished portions of a product. The set of features that go into a sprint come from the product backlog, which is an ordered list of requirements. Which backlog items go into the sprint (the sprint goals) is determined during the sprint planning meeting. During this meeting, 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). The team then determines how much of this they can commit to complete during the next sprint, and records this in the sprint backlog.[] The sprint backlog is property of the development team, i.e. during a sprint, no one is allowed to edit the sprint backlog except for the development team. The sprint goals should not be changed during the sprint. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software. Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication between all team members and disciplines in the project. 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), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approachaccepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements. Like other agile development methodologies, Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the sprint backlog. There are also open-source and proprietary packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools, and maintain their artifacts in hard-copy forms such as paper, whiteboards, and sticky notes.[6]
Meetings
Daily Scrum
Each day during the sprint, a project team communication meeting occurs. This is called a daily scrum, or the daily standup. 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, but normally only the core roles speak During the meeting, 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. No detailed discussions shall happen in this meeting.
A daily scrum meeting in the computing room. This choice of location lets the team start on time
Scrum (development)
Backlog grooming: storytime

The team should spend time during a sprint doing product backlog grooming. This is the process of estimating the existing backlog using effort/points, refining the acceptance criteria for individual stories, 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. 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, focusing especially on areas of overlap and integration. A designated person from each team attends. The agenda will be the same as the Daily Scrum, 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 730 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, 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, resulting in the Sprint Backlog
End of cycle
At the end of a sprint cycle, two meetings are held: the "Sprint Review Meeting" and the "Sprint Retrospective". At the Sprint Review Meeting:[11] Review the work that was completed and not completed Present the completed work to the stakeholders (a.k.a. "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
Scrum (development)
Artifacts
Product Backlog
The product backlog is an ordered list of "requirements" that is maintained for a product. It contains Product Backlog Items that are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc. The features added to the backlog are commonly written in story format (See terminology below). The product backlog is the "What" that will be built, sorted in the relative order it should be built in. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the stories on the backlog for the Development Team. The product backlog contains rough estimates of both business value and development effort, these values are often stated in story points using a rounded Fibonacci sequence. Those estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items. For example, if the "add spellcheck" and "add table support" features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI (Return on Investment) is higher. The Product Backlog, and business value of each listed item is the responsibility of the Product Owner. The estimated effort to complete each backlog item is, however, determined by the Development Team. The team contributes by estimating Items and User-Stories, either in Story-points or in estimated hours.
Sprint Backlog
The sprint backlog is the list of work the Development Team must address during the next sprint. 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. This is done by the Development Team asking "Can we also do this?" and adding stories/features to the sprint backlog. 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, and use this number as a guide line of how much "effort" they can complete. The stories/features are broken down into tasks by the Development Team, which, as a best practice, should normally be between four and sixteen hours of work. With this level of detail the Development Team understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint backlog are never assigned; rather, A scrum task board tasks are signed up for by the team members as needed during the daily scrum, according to the set priority and the Development Team member skills. This promotes self-organization of the Development Team, and developer buy-in. The sprint backlog is the property of the Development Team, and all included estimates are provided by the Development Team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like "to do", "in progress" and "done".
Scrum (development)
Increment
The increment is the sum of all the Product Backlog Items completed during a sprint and all previous sprints. At the end of a sprint, the Increment must be done according to the Scrum Team's definition of done. The increment must be in usable condition regardless of whether the Product Owner decides to actually release it.
Burn down
The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burndown, 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,[13] which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline. It should not be confused with an earned value chart.
A sample burn down chart for a completed iteration, 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, ScrumMaster and Development Team Product Owner The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders, and ensuring the value of the work the Development Team does. ScrumMaster The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits. Development Team A cross-functional group of people responsible for delivering potentially shippable increments of Product at the end of every Sprint. Sprint burn down chart Daily progress for a Sprint over the sprint's length. Release burn down chart Sprint level progress of completed stories in the Product Backlog. Product backlog A prioritized list of high-level requirements. Sprint backlog A prioritized list of tasks to be completed during the sprint. Sprint A time period (typically 14 weeks) in which development occurs on a set of backlog items that the team has committed to. Also commonly referred to as a Time-box or iteration. (User) Story
Scrum (development) A feature that is added to the backlog is commonly referred to as a story and has a specific suggested structure. 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, action and required result in a request and is a simple way of writing requests that anyone can understand. Example: As a wiki user I want a tools menu on the edit screen so that I can easily apply font formatting. A story is an independent, negotiable, valuable, estimable, small, testable requirement ("INVEST"). Despite being independent i.e. they have no direct dependencies with other requirements, stories may be clustered into epics when represented on a product roadmap or further down in the backlog. Theme A theme is a top-level objective that may span projects and products. Themes may be broken down into sub-themes, which are more likely to be product-specific. Themes can be used at both program and project level to drive strategic alignment and communicate a clear direction. Epic An epic is a group of related stories, mainly used in product roadmaps and the backlog for features that have not yet been analyzed enough to break down into component stories, which should be done before bringing it into a sprint so to reduce uncertainty. Epics can also be used at a both program and project level. Spike A time boxed period used to research a concept and/or create a simple prototype. Spikes can either be planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many sprint delivery objectives. Spikes are often introduced before the delivery of large epics or user stories in order to secure budget, expand knowledge, and/or produce a proof of concept. The duration and objective(s) of a spike will be agreed between the Product Owner and Delivery Team before the start. Unlike sprint commitments, spikes may or may not deliver tangible, shippable, valuable functionality. For example, the objective of a spike might be to successfully reach a decision on a course of action. The spike is over when the time is up, not necessarily when the objective has been delivered. Tracer Bullet The tracer bullet is a spike with the current architecture, current technology set, current set of best practices which results in production quality code. It might just be a very narrow implementation of the functionality but is not throw away code. It is of production quality and the rest of the iterations can build on this code. The name has military origins as ammunition that makes the path of the weapon visible, allowing for corrections. Often these implementations are a 'quick shot' through all layers of an application, such as connecting a single form's input field to the back-end, to prove the layers will connect as expected. Point Scale/Effort/Story points Relates to an abstract point system, used to discuss the difficulty of the story, without assigning actual hours. The most common scale used is a rounded Fibonacci sequence (1,2,3,5,8,13,20,40,100), although some teams use linear scale (1,2,3,4...), powers of two (1,2,4,8...), and clothes size (XS, S, M, L, XL).[] Tasks Added to the story at the beginning of a sprint and broken down into hours. Each task should not exceed 12 hours, but it's common for teams to insist that a task take no more than a day to finish. Definition of Done (DoD) The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful. Velocity
Scrum (development) The total effort a team is capable of in a sprint. The number is derived by adding all the story points from the last sprint's stories/features. This is a guideline for the team and assists them in understanding how many stories they can do in a sprint. Impediment Anything that prevents a team member from performing work as efficiently as possible.[15] Sashimi A report that something is "done". The definition of "done" may vary from one Scrum team to another, but must be consistent within one team. Abnormal Termination The Product Owner can cancel a Sprint if necessary.[16] The Product Owner may do so with input from the team, ScrumMaster or management. For instance, management may wish to cancel a sprint if external circumstances negate the value of the sprint goal. If a sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed. Planning Poker In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on the team's velocity.[] ScrumBut A ScrumBut (or Scrum But) is an exception to the "pure" Scrum methodology, where a team has changed the methodology to adapt it to their own needs.[17][18]
Scrum-ban
Scrum-ban is a software production model based on Scrum and Kanban. Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected user stories or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrum's daily meetings and other practices can be applied, depending on the team and the situation at hand. Visualization of the work stages and limitations for simultaneous unfinished user stories and defects are familiar from the Kanban model. Using these methods, the team's workflow is directed in a way that allows for minimum completion time for each user story or programming error, and on the other hand ensures each team member is constantly employed.[19] To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard.[20] In the case of decentralized teams, stage-illustration such as Assembla, ScrumWorks, Rational Team Concert or JIRA in combination with GreenHopper can be used to visualize each team's user stories, defects and tasks divided into separate phases. In their simplest, the tasks or usage stories are categorized into the work stages: Unstarted Ongoing Completed If desired, though, the teams can add more stages of work (such as "defined", "designed", "tested" or "delivered"). 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. A more specific task division also makes it possible for employees to specialize in a certain phase of work.[] There are no set limiting values for unfinished work. Instead, each team has to define them individually by trial and error; a value too small results in workers standing idle for lack of work, whereas values too high tend to accumulate large amounts of unfinished work, which in turn hinders completion times.[21] A rule of thumb worth bearing in
Scrum (development) mind is that no team member should have more than two simultaneous selected tasks, and that on the other hand not all team members should have two tasks simultaneously.[] The major differences between Scrum and Kanban are derived from the fact that, in Scrum, work is divided into sprints that last a certain amount of time, whereas in Kanban the workflow is continuous. This is visible in work stage tables, which in Scrum are emptied after each sprint. In Kanban all tasks are marked on the same table. Scrum focuses on teams with multifaceted know-how, whereas Kanban makes specialized, functional teams possible.[22] Since Scrum-ban is such a new development model, there is not much reference material. Kanban, on the other hand, has been applied by Microsoft and Corbis.[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, by Axosoft Pivotal Tracker Redmine and ChiliProject, with a plug-in (several are available) Microsoft Visual Studio 2010/2012, Team Foundation Server 2010/2012 YouTrack, by Jetbrains[24]
Notes
[7] Schwaber, p. 135 [8] Schwaber, p. 133 [11] Schwaber, p. 137 [12] Schwaber, p. 138 [14] Schwaber, pp. 141143 [24] Tools that also offer optional horizontal "swimlanes" or "pipelines" across the vertical columns of the board for different dimensions of work, such as sub-projects or features, allowing a scrum or Kanban board to be a two-dimensional matrix.
References Further reading

"The Scrum Guide" (http://www.scrum.org/Portals/0/Documents/Scrum Guides/Scrum_Guide.pdf). 2011. Retrieved December 3, 2011. "The Scrum Software Development Process for Small Teams" (http://members.cox.net/risingl1/Articles/ IEEEScrum.pdf). 2000. Retrieved March 15, 2007. Deemer, Pete; Benefield, Gabrielle; Larman, Craig; Vodde, Bas (2009). "The Scrum Primer" (http:// scrumtraininginstitute.com/home/stream_download/scrumprimer). Retrieved June 1, 2009. Kniberg, Henrik. "Scrum and XP from the Trenches" (http://www.infoq.com/minibooks/ scrum-xp-from-the-trenches). Retrieved August 9, 2010. Mnch, Jrgen; Armbrust, Ove; Soto, Martn; Kowalczyk, Martin (2012). "Software Process Definition and Management" (http://www.springer.com/computer/swe/book/978-3-642-24290-8). Retrieved July 16, 2012.
Scrum (development)
11
External links
ImplementingScrum.com (http://www.implementingscrum.com/) Starting Tough Conversations about Agile Software Development Scrum.org (http://www.scrum.org/) the home for Scrum Guides in multiple languages (http://www.scrum. org/Scrum-Guides) Scrum Alliance, non-profit (http://www.scrumalliance.org/) Agile Alliance's Scrum library (http://cf.agilealliance.org/articles/article_list.cfm?CategoryID=17) A Scrum Process Description (http://epf.eclipse.org/wikis/scrum/) by the Eclipse Process Framework (EPF) Project (http://www.eclipse.org/epf) BPMN process diagram of Scrum (http://www.ariscommunity.com/users/sstein/ 2010-08-09-bpm-view-scrum) A six-page illustrated Scrum reference (http://ScrumReferenceCard.com/) Burn Down Chart Tutorial: Simple Agile Project Tracking (Scrum) (http://joel.inpointform.net/ software-development/burn-down-charts-tutorial-simple-agile-project-tracking/) Scrum Development Interview Questions and Answers (http://www.questions-interviews.com/ software-development-testing-models/scrum.aspx) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google (http://video.google. com/videoplay?docid=8795214308797356840) Retrieved 2007-12-15 Ken Schwaber in Scrum et al. (http://video.google.com/videoplay?docid=2531954797594836634) Retrieved 2008-01-19 Jeff Sutherland in Hyperproductive Distributed Scrum Teams (http://www.youtube.com/ watch?v=Ht2xcIJrAXo) Jeff Sutherland in Self-Organization: The Secret Sauce for Improving your Scrum team (http://www.youtube. com/watch?v=M1q6b9JI2Wc) Bruno Sbille and his team in Scrum applied on a real-world project (HD) (http://www.vimeo.com/4587652) Retrieved 2009-05-19 Scrum at Large: Managing 100 People and More (http://www.tvagile.com/2009/07/24/ scrum-at-large-managing-100-people-and-more/) Andrea Tomasini's keynote about Agile in an Enterprise (http://www.slideshare.net/lourenh1/ adopting-scrum-an-enterprise-transformation) Scrum Training Series: Scrum Tutorial (http://ScrumTrainingSeries.com)
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 methodology. Crystal Clear can be applied to teams of up to 6 or 8 co-located developers working on systems that are not life-critical. The Crystal family of methodologies focus on efficiency and habitability as components of project safety.[1] Crystal Clear focuses on people, not processes or artifacts. 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, configuration management, and frequent integration
References
[1] http:/ / www. mariosalexandrou. com/ methodologies/ crystal-methods. asp
Further reading
Crystal Clear, A Human-Powered Methodology for Small Teams, Alistair Cockburn, October 2004, pages 336, paperback, Addison-Wesley Professional, ISBN 0-201-69947-8. Alistair Cockburn's introduction (http://alistair.cockburn.us/Crystal+light+methods) to the Crystal family of methodologies A quick overview (http://www.agilekiwi.com/crystal_clear.htm) with links to sample chapters from the book
Lean software development
13


14
Tools

Lean software development is a translation of lean manufacturing and lean IT principles and practices to the software development domain. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community.
Origin
The term lean software development originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck. The book presents the traditional lean principles in a modified form, as well as a set of 22 tools and compares the tools to agile practices. The Poppendiecks' involvement in the Agile software development community, including talks at several Agile conferences has resulted in such concepts being more widely accepted within the Agile community.
Lean principles
Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles: 1. 2. 3. 4. 5. 6. 7. 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). This includes: unnecessary code and functionality delay in the software development process unclear requirements insufficient testing, leading to avoidable process repetition bureaucracy slow internal communication
In order to be able to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Extra processes and features not often used by customers are waste. Waiting for other activities, teams, processes is waste. Defects and lower quality are waste. Managerial overhead not producing real value is waste. A value stream mapping technique is used to distinguish and recognize waste. The second step is to point out sources of waste and eliminate them. The same should be done iteratively until even essential-seeming processes and procedures are liquidated.
15
Amplify learning
Software development is a continuous learning process with the additional challenge of development teams and end product sizes. The best approach for improving a software development environment is to amplify learning. The accumulation of defects should be prevented by running tests as soon as the code is written. Instead of adding more documentation or detailed planning, different ideas could be tried by writing code and building. The process of user requirements gathering could be simplified by presenting screens to the end-users and getting their input. The learning process is sped up by usage of short iteration cycles each one coupled with refactoring and integration testing. Increasing feedback via short feedback sessions with customers helps when determining the current phase of development and adjusting efforts for future improvements. 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. Thus the customers better understand their needs, based on the existing result of development efforts, and the developers learn how to better satisfy those needs. 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, thus promoting the birth of the solution via dialogue with the customer.
Decide as late as possible

As software development is always associated with some uncertainty, better results should be achieved with an options-based approach, delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions. The more complex a system is, the more capacity for change should be built into it, thus enabling the delay of important and crucial commitments. The iterative approach promotes this principle the ability to adapt to changes and correct mistakes, which might be very costly if discovered after the release of the system. An agile software development approach can move the building of options earlier for customers, thus delaying certain crucial decisions until customers have realized their needs better. This also allows later adaptation to changes and the prevention of costly earlier technology-bounded decisions. This does not mean that no planning should be involved on the contrary, planning activities should be concentrated on the different options and adapting to the current situation, as well as clarifying confusing situations by establishing patterns for rapid action. Evaluating different options is effective as soon as it is realized that they are not free, but provide the needed flexibility for late decision making.
Deliver as fast as possible

In the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The sooner the end product is delivered without considerable defect, the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better the learning and communication within the team. Without speed, decisions cannot be delayed. Speed assures the fulfilling of the customer's present needs and not what they required yesterday. This gives them the opportunity to delay making up their minds about what they really require until they gain better knowledge. Customers value rapid delivery of a quality product. The just-in-time production ideology could be applied to software development, recognizing its specific requirements and environment. 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. At the beginning, 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. Thus the work organization changes into self-pulling system each morning during a stand-up meeting, each member of the team reviews what has been done yesterday, what is to be done today and tomorrow, and prompts for any inputs needed from colleagues or the customer. This requires transparency of the process, which is also beneficial for team communication. Another key idea in Toyota's Product
Lean software development Development System is set-based design. If a new brake system is needed for a car, for example, three teams may design solutions to the same problem. Each team learns about the problem space and designs a potential solution. As a solution is deemed unreasonable, it is cut. At the end of a period, the surviving designs are compared and one is chosen, perhaps with some modifications based on learning from the others - a great example of deferring commitment until the last possible moment. Software decisions could also benefit from this practice to minimize the risk brought on by big up-front design.
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. In a Work-Out technique, the roles are turned the managers are taught how to listen to the developers, so they can explain better what actions might be taken, as well as provide suggestions for improvements. The lean approach favors the aphorism "find good people and let them do their own job," encouraging progress, catching errors, and removing impediments, but not micro-managing. Another mistaken belief has been the consideration of people as resources. People might be resources from the point of view of a statistical data sheet, but in software development, as well as any organizational business, 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. People need motivation and a higher purpose to work for purpose within the reachable reality, with the assurance that the team might choose its own commitments. The developers should be given access to the customer; the team leader should provide support and help in difficult situations, as well as ensure that skepticism does not ruin the teams spirit.
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, delivered, deployed, accessed, how intuitive its use is, price and how well it solves problems. Conceptual integrity means that the systems separate components work well together as a whole with balance between flexibility, maintainability, efficiency, and responsiveness. This could be achieved by understanding the problem domain and solving it at the same time, not sequentially. 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. The information flow should be constant in both directions from customer to developers and back, thus avoiding the large stressful amount of information after long development in isolation. One of the healthy ways towards integral architecture is refactoring. The more features are added to the System, the more loose the starting code base for further improvements. Refactoring is about keeping simplicity, clarity, minimum amount of features in the code. Repetitions in the code are signs for bad code designs and should be avoided. The complete and automated building process should be accompanied by a complete and automated suite of developer and customer tests, having the same versioning, synchronization and semantics as the current state of the System. At the end the integrity should be verified with thorough testing, thus ensuring the System does what the customer expects it to. Automated tests are also considered part of the production process, and therefore if they do not add value they should be considered waste. Automated testing should not be a goal, but rather a means to an end, specifically the reduction of defects.
See the whole

Software systems nowadays are not simply the sum of their parts, but also the product of their interactions. Defects in software tend to accumulate during the development process by decomposing the big tasks into smaller tasks, and by standardizing different stages of development, the root causes of defects should be found and eliminated. The larger the system, the more organisations that are involved in its development and the more parts are developed by different teams, the greater the importance of having well defined relationships between different vendors, in order
Lean software development to produce a system with smoothly interacting components. During a longer period of development, a stronger subcontractor network is far more beneficial than short-term profit optimizing, which does not enable win-win relationships. Lean thinking has to be understood well by all members of a project, before implementing in a concrete, real-life situation. "Think big, act small, fail fast; 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, combined with strong "common sense" with respect to the working environment, is there a basis for success in software development.
17
Lean software practices

Lean software development practices, or what the Poppendiecks call "tools" are expressed slightly differently from their equivalents in agile software development, but there are parallels. 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. Lean Workcells, for example are expressed in Agile methods as cross-functional teams.
References
Yasuhiro Monden (1998), Toyota Production System, An Integrated Approach to Just-In-Time, Third edition, Norcross, GA: Engineering & Management Press, ISBN 0-412-83930-X. Mary Poppendieck, Tom Poppendieck (2003), "Lean Software Development: An Agile Toolkit", Addison-Wesley Professional, ISBN 0-321-15078-3 Ladas, Corey (January 2008). Scrumban: Essays on Kanban Systems for Lean Software Development (http:// moduscooperandi.com/modus-cooperandi-press/). Modus Cooperandi Press. ISBN0-578-00214-0.
Extreme programming
18
Extreme programming
Planning and feedback loops in Extreme Programming.

Waterfall Prototype model Incremental Iterative V-Model Spiral Scrum Cleanroom
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
Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,[1][2][3] it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. Other elements of Extreme Programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.[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.Wikipedia:Please clarify Critics have noted several potential drawbacks,[5] including problems with unstable requirements, no documented compromises of user conflicts, and a lack of an overall design specification or document.
History
Extreme Programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project.[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 Explained was published).[5] Chrysler cancelled the C3 project in February 2000, after 7 years, when the company was acquired by Daimler-Benz.[] Although extreme programming itself is relatively new, many of its practices have been around for some time; the methodology, after all, takes "best practices" to extreme levels. For example, the "practice of test-first development, planning and writing tests before each micro-increment" was used as early as NASA's Project Mercury, in the early 1960s (Larman 2003). To shorten the total development time, some formal test documents (such as for acceptance testing) have been developed in parallel (or shortly before) the software is ready for testing. A NASA independent test group can write the test procedures, based on formal requirements and logical limits, before the software has
Extreme programming been written and integrated with the hardware. In XP, 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, rather than only testing the larger features.
20
Origins
Software development in the 1990s was shaped by two major influences: internally, object-oriented programming replaced procedural programming as the programming paradigm favored by some in the industry; externally, the rise of the Internet and the dot-com boom emphasized speed-to-market and company-growth as competitive business factors. Rapidly-changing requirements demanded shorter product life-cycles, and were often incompatible with traditional methods of software development. The Chrysler Comprehensive Compensation System (C3) was started in order to determine the best way to use object technologies, using the payroll systems at Chrysler as the object of research, with Smalltalk as the language and GemStone as the data access layer. They brought in Kent Beck,[5] a prominent Smalltalk practitioner, to do performance tuning on the system, but his role expanded as he noted several problems they were having with their development process. He took this opportunity to propose and implement some changes in their practices based on his work with his frequent collaborator, Ward Cunningham. Beck describes the early conception of the methods:[6] The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else. Beck invited Ron Jeffries to the project to help develop and refine these methods. Jeffries thereafter acted as a coach to instill the practices as habits in the C3 team. Information about the principles and practices behind XP was disseminated to the wider world through discussions on the original Wiki, Cunningham's WikiWikiWeb. Various contributors discussed and expanded upon the ideas, and some spin-off methodologies resulted (see agile software development). Also, XP concepts have been explained, for several years, using a hypertext system map on the XP website at "http:/ / www. extremeprogramming. org" circa 1999. Beck edited a series of books on XP, beginning with his own Extreme Programming Explained (1999, ISBN 0-201-61641-6), spreading his ideas to a much larger, yet very receptive, audience. Authors in the series went through various aspects attending XP and its practices. The series included a book that was critical of the practices.
Current state
XP created quite a buzz in the late 1990s and early 2000s, seeing adoption in a number of environments radically different from its origins. The high discipline required by the original practices often went by the wayside, causing some of these practices, such as those thought too rigid, to be deprecated or reduced, or even left unfinished, on individual sites. For example, the practice of end-of-day integration tests, for a particular project, could be changed to an end-of-week schedule, or simply reduced to mutually agreed dates. Such a more relaxed schedule could avoid people feeling rushed to generate artificial stubs just to pass the end-of-day testing. A less-rigid schedule allows, instead, for some complex features to be more fully developed over a several-day period. However, some level of periodic integration testing can detect groups of people working in non-compatible, tangent efforts before too much work is invested in divergent, wrong directions. Meanwhile, other agile development practices have not stood still, and XP is still evolving, assimilating more lessons from experiences in the field, to use other practices. In the second edition of Extreme Programming Explained (November 2004), five years after the first edition, Beck added more values and practices and differentiated between
Extreme programming primary and corollary practices.
21
Concept
Goals
Extreme Programming Explained describes Extreme Programming as a software-development discipline that organizes people to produce higher-quality software more productively. XP attempts to reduce the cost of changes in requirements by having multiple short development cycles, rather than a long one. In this doctrine, changes are a natural, inescapable and desirable aspect of software-development projects, and should be planned for, instead of attempting to define a stable set of requirements. Extreme programming also introduces a number of basic values, principles and practices on top of the agile programming framework.
Activities
XP describes four basic activities that are performed within the software development process: coding, testing, listening, and designing. Each of those activities is described below. 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. Without code, there is no working product. Coding can also be used to figure out the most suitable solution. Coding can also help to communicate thoughts about programming problems. A programmer dealing with a complex programming problem, or finding it hard to explain the solution to fellow programmers, might code it in a simplified manner and use the code to demonstrate what he or she means. Code, say the proponents of this position, is always clear and concise and cannot be interpreted in more than one way. Other programmers can give feedback on this code by also coding their thoughts. Testing Extreme programming's approach is that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws. Unit tests determine whether a given feature works as intended. A programmer writes as many automated tests as they can think of that might "break" the code; if all tests run successfully, then the coding is complete. Every piece of code that is written is tested before moving on to the next feature. Acceptance tests verify that the requirements as understood by the programmers satisfy the customer's actual requirements. System-wide integration testing was encouraged, initially, as a daily end-of-day activity, for early detection of incompatible interfaces, to reconnect before the separate sections diverged widely from coherent functionality. However, system-wide integration testing has been reduced, to weekly, or less often, depending on the stability of the overall interfaces in the system.[citation needed]
Extreme programming Listening Programmers must listen to what the customers need the system to do, what "business logic" is needed. They must understand these needs well enough to give the customer feedback about the technical aspects of how the problem might be solved, or cannot be solved. Communication between the customer and programmer is further addressed in the Planning Game. Designing From the point of view of simplicity, of course one could say that system development doesn't need more than coding, testing and listening. If those activities are performed well, the result should always be a system that works. In practice, this will not work. One can come a long way without designing but at a given time one will get stuck. The system becomes too complex and the dependencies within the system cease to be clear. One can avoid this by creating a design structure that organizes the logic in the system. Good design will avoid lots of dependencies within a system; this means that changing one part of the system will not affect other parts of the system.[citation needed]
22
Values
Extreme Programming initially recognized four values in 1999: Communication, Simplicity, Feedback, and Courage. A new value, Respect, was added in the second edition of Extreme Programming Explained. Those five values are described below. Communication Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, extreme programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback. Simplicity Extreme programming encourages starting with the simplest solution. Extra functionality can then be added later. 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, next week, or next month. This is sometimes summed up as the "You aren't gonna need it" (YAGNI) approach.[7] Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; 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. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed, while perhaps delaying crucial features. Related to the "communication" value, simplicity in design and coding should improve the quality of communication. A simple design with very simple code could be easily understood by most programmers in the team.
Extreme programming Feedback Within extreme programming, feedback relates to different dimensions of the system development: Feedback from the system: by writing unit tests,[5] or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes. Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development. 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. Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements, known as user stories.[5] To quote Kent Beck, "Optimism is an occupational hazard of programming. Feedback is the treatment." [] Courage Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary.[5] This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, but only if they are persistent. Respect The respect value includes respect for others as well as self-respect. Programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring. Adopting the four earlier values leads to respect gained from others in the team. Nobody on the team should feel unappreciated or ignored. This ensures a high level of motivation and encourages loyalty toward the team and toward the goal of the project. This value is very dependent upon the other values, and is very much oriented toward people in a team.
23
Rules
The first version of rules for XP was published in 1999 by Don Wells[8] at the XP website. 29 rules are given in the categories of planning, managing, designing, coding, and testing. Planning, managing and designing are called out explicitly to counter claims that XP doesn't support those activities. Another version of XP rules was proposed by Ken Auer[9] in XP/Agile Universe 2003. He felt XP was defined by its rules, not its practices (which are subject to more variation and ambiguity). He defined two categories: "Rules of Engagement" which dictate the environment in which software development can take place effectively, and "Rules of Play" which define the minute-by-minute activities and rules within the framework of the Rules of Engagement.
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. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation. Feedback Extreme programming sees feedback as most useful if it is done frequently and promptly. It stresses that minimal delay between an action and its feedback is critical to learning and making changes. Unlike traditional system development methods, contact with the customer occurs in more frequent iterations. The customer has clear insight into the system that is being developed. He or she can give feedback and steer the development as needed. With frequent feedback from the customer, a mistaken design decision made by the developer will be noticed and corrected quickly, before the developer spends much time implementing it. Unit tests also contribute to the rapid feedback principle. When writing code, running the unit test provides direct feedback as to how the system reacts to the changes one has made. This includes running not only the unit tests that test the developer's code, but running in addition all unit tests against all the software, using an automated process that can be initiated by a single command. That way, If the developer's changes cause a failure in some other portion of the system, that the developer knows little or nothing about, the automated all-unit-test suite will reveal the failure immediately, alerting the developer of the incompatibility of his change with other parts of the system, and the necessity of removing or modifying his change. Under traditional development practices, the absence of an automated, comprehensive unit-test suite meant that such a code change, assumed harmless by the developer, would have been left in place, appearing only during integration testing--or worse, only in production; and determining which code change caused the problem, among all the changes made by all the developers during the weeks or even months previous to integration testing, was a formidable task. Assuming simplicity This is about treating every problem as if its solution were "extremely simple". Traditional system development methods say to plan for the future and to code for reusability. Extreme programming rejects these ideas. The advocates of extreme programming say that making big changes all at once does not work. Extreme programming applies incremental changes: for example, a system might have small releases every three weeks. When many little steps are made, the customer has more control over the development process and the system that is being developed. Embracing change The principle of embracing change is about not working against changes but embracing them. For instance, if at one of the iterative meetings it appears that the customer's requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration.
Practices
Extreme programming has been described as having 12 practices, grouped into four areas:
Fine scale feedback

Pair programming[5] Planning game Test-driven development Whole team
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. When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic, 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.[5] Proponents of extreme programming claim that by having the on-site customer[5] request changes informally, the process becomes flexible, and saves the cost of formal overhead. Critics of XP claim this can lead to costly rework and project scope creep beyond what was previously agreed or funded. Change-control boards are a sign that there are potential conflicts in project objectives and constraints between multiple users. XP's expedited methods are somewhat dependent on programmers being able to assume a unified client viewpoint so the programmer can concentrate on coding, rather than documentation of compromise objectives and constraints. This also applies when multiple programming organizations are involved, particularly organizations which compete for shares of projects.[citation needed] Other potentially controversial aspects of extreme programming include: Requirements are expressed as automated acceptance tests rather than specification documents. Requirements are defined incrementally, rather than trying to get them all in advance. Software developers are usually required to work in pairs. There is no Big Design Up Front. Most of the design activity takes place on the fly and incrementally, starting with "the simplest thing that could possibly work" and adding complexity only when it's required by failing tests. Critics compare this to "debugging a system into appearance" and fear this will result in more re-design effort
Extreme programming than only re-designing when requirements change. A customer representative is attached to the project. This role can become a single-point-of-failure for the project, and some people have found it to be a source of stress. Also, there is the danger of micro-management by a non-technical representative trying to dictate the use of technical software features and architecture. Dependence upon all other aspects of XP: "XP is like a ring of poisonous snakes, daisy-chained together. All it takes is for one of them to wriggle loose, and you've got a very angry, poisonous snake heading your way."[10]
26
Scalability
Historically, XP only works on teams of twelve or fewer people. One way to circumvent this limitation is to break up the project into smaller pieces and the team into smaller groups. It has been claimed that XP has been used successfully on teams of over a hundred developers.[citation needed] ThoughtWorks has claimed reasonable success on distributed XP projects with up to sixty people.[citation needed] In 2004, Industrial Extreme Programming (IXP)[11] was introduced as an evolution of XP. It is intended to bring the ability to work in large and distributed teams. It now has 23 practices and flexible values. As it is a new member of the Agile family, there is not enough data to prove its usability; however it claims to be an answer to what it sees as XP's imperfections.
Severability and responses

In 2003, Matt Stephens and Doug Rosenberg published Extreme Programming Refactored: The Case Against XP, which questioned the value of the XP process and suggested ways in which it could be improved.[] This triggered a lengthy debate in articles, Internet newsgroups, and web-site chat areas. 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; therefore the entire process fails. The book also makes other criticisms, and it draws a likeness of XP's "collective ownership" model to socialism in a negative manner. Certain aspects of XP have changed since the book Extreme Programming Refactored (2003) was published; in particular, XP now accommodates modifications to the practices as long as the required objectives are still met. XP also uses increasingly generic terms for processes. Some argue that these changes invalidate previous criticisms; others claim that this is simply watering the process down. Other authors have tried to reconcile XP with the older methodologies in order to form a unified methodology. Some of these XP sought to replace, such as the waterfall methodology; example: Project Lifecycles: Waterfall, Rapid Application Development, and All That [12]. JPMorgan Chase & Co. tried combining XP with the computer programming methods of Capability Maturity Model Integration (CMMI), and Six Sigma. They found that the three systems reinforced each other well, leading to better development, and did not mutually contradict.[13]
Criticism
Extreme programming's initial buzz and controversial tenets, such as pair programming and continuous design, have attracted particular criticisms, such as the ones coming from McBreen[] and Boehm and Turner.[] Many of the criticisms, however, are believed by Agile practitioners to be misunderstandings of agile development.[14] In particular, extreme programming has been reviewed and critiqued by Matt Stephens's and Doug Rosenberg's Extreme Programming Refactored.[][15] Criticisms include: a methodology is only as effective as the people involved, 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
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; if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. Whereas if a plan were there to be followed, a single area of code is expected to be written once. impossible to develop realistic estimates of work effort needed to provide a quote, 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; non-functional quality attributes are hard to be placed as user stories.
27
References
[1] "Human Centred Technology Workshop 2005", 2005, PDF webpage: Informatics-UK-report-cdrp585 (ftp:/ / ftp. informatics. sussex. ac. uk/ pub/ reports/ csrp/ csrp585. pdf). [2] "Design Patterns and Refactoring", University of Pennsylvania, 2003, webpage: UPenn-Lectures-design-patterns (http:/ / www. cis. upenn. edu/ ~matuszek/ cit591-2003/ Lectures/ 49-design-patterns. ppt). [3] "Extreme Programming" USFCA-edu-601-lecture (http:/ / www. cs. usfca. edu/ ~parrt/ course/ 601/ lectures/ xp. html). [4] "Manifesto for Agile Software Development", Agile Alliance, 2001, webpage: Manifesto-for-Agile-Software-Dev (http:/ / agilemanifesto. org/ ) [5] "Extreme Programming", Computerworld (online), December 2001, webpage: Computerworld-appdev-92 (http:/ / www. computerworld. com/ softwaretopics/ software/ appdev/ story/ 0,10801,66192,00. html). [6] Interview with Kent Beck and Martin Fowler (http:/ / www. informit. com/ articles/ article. aspx?p=20972) [7] "Everyone's a Programmer" by Clair Tristram. Technology Review, November 2003. p. 39. [8] Don Wells (http:/ / www. extremeprogramming. org/ rules. html) [9] Ken Auer (http:/ / www. rolemodelsoftware. com/ moreAboutUs/ publications/ rulesOfXp. php) [10] The Case Against Extreme Programming: A Self-Referential Safety Net (http:/ / www. softwarereality. com/ lifecycle/ xp/ safety_net. jsp) [11] Cutter Consortium :: Industrial XP: Making XP Work in Large Organizations (http:/ / www. cutter. com/ content-and-analysis/ resource-centers/ agile-project-management/ sample-our-research/ apmr0502. html) [12] http:/ / www. lux-seattle. com/ resources/ whitepapers/ waterfall. htm [13] Extreme Programming (XP) Six Sigma CMMI (http:/ / www. sei. cmu. edu/ library/ assets/ jarvis-gristock. pdf). [14] sdmagazine (http:/ / www. sdmagazine. com/ documents/ s=1811/ sdm0112h/ 0112h. htm) [15] Extreme Programming Refactored (http:/ / www. softwarereality. com/ ExtremeProgrammingRefactored. jsp), Matt Stephens and Doug Rosenberg, Publisher: Apress L.P.
Further reading
Ken Auer and Roy Miller. Extreme Programming Applied: Playing To Win, AddisonWesley. Kent Beck: Extreme Programming Explained: Embrace Change, AddisonWesley. Kent Beck and Martin Fowler: Planning Extreme Programming, AddisonWesley. Kent Beck and Cynthia Andres. Extreme Programming Explained: Embrace Change, Second Edition, AddisonWesley. Alistair Cockburn: Agile Software Development, AddisonWesley. Martin Fowler: Refactoring: Improving the Design of Existing Code, AddisonWesley. Harvey Herela (2005). Case Study: The Chrysler Comprehensive Compensation System (http://calla.ics.uci. edu/histories/ccc/). Galen Lab, U.C. Irvine. Jim Highsmith. Agile Software Development Ecosystems, AddisonWesley. Ron Jeffries, Ann Anderson and Chet Hendrickson (2000), Extreme Programming Installed, AddisonWesley.
Craig Larman & V. Basili (2003). "Iterative and Incremental Development: A Brief History", Computer (IEEE Computer Society) 36 (6): 4756. Matt Stephens and Doug Rosenberg (2003). Extreme Programming Refactored: The Case Against XP, Apress.
Extreme programming Waldner, JB. (2008). "Nanocomputers and Swarm Intelligence". In: ISTE, 225256.
28
External links
Extreme Programming A gentle introduction (http://www.extremeprogramming.org) Industrial eXtreme Programming (http://www.IndustrialXP.org/) XP magazine (http://www.xprogramming.com) Problems and Solutions to XP implementation (http://c2.com/cgi/ wiki?ExtremeProgrammingImplementationIssues) Using an Agile Software Process with Offshore Development (http://www.martinfowler.com/articles/ agileOffshore.html) ThoughtWorks' experiences with implementing XP in large distributed projects
Feature-driven development

Waterfall Prototype model Incremental Iterative V-Model Spiral Scrum Cleanroom RAD DSDM

29
RUP XP Agile Lean Dual Vee Model TDD FDD Supporting disciplines

Configuration management Documentation Quality assurance (SQA) Project management User experience design Tools
Feature-driven development (FDD) is an iterative and incremental software development process. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner.
History
FDD was initially devised by Jeff De Luca, to meet the specific needs of a 15-month, 50-person software development project at a large Singapore bank in 1997. Jeff De Luca delivered a set of five processes that covered the development of an overall model and the listing, planning, design and building of features. The first process is heavily influenced by Peter Coad's approach to object modeling. The second process incorporates Peter Coad's ideas of using a feature list to manage functional requirements and development tasks. The other processes and the blending of the processes into a cohesive whole is a result of Jeff De Luca's experience. Since its successful use on the Singapore project, there have been several implementations of FDD. 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, Eric Lefebvre and Jeff De Luca in 1999. Later, in Stephen Palmer and Mac Felsing's book A Practical Guide to Feature-Driven Development[2] (published in 2002), a more general description of FDD was given, as decoupled from Java modeling in color. The original and latest FDD processes can be found on Jeff De Lucas website [3] under the Article area. There is also a Community website [4] available at which people can learn more about FDD, questions can be asked, and experiences and the processes themselves are discussed.
30
Overview
FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined. This section gives a high level overview of the activities. In the figure on the right, the meta-process model for these activities is displayed. During the first two sequential activities, an overall model shape is established. The final three activities are iterated for each feature. 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 Lucas website [3]). The concepts involved in these activities are explained in Table 3.
Develop overall model

The project started with a high-level walkthrough of the scope of the system and its context. Next, detailed domain walkthroughs were held for each modeling area. In support of each domain, walkthrough models were then composed by small groups, which were presented for peer review and discussion. One of the proposed models, or a merge of them, was selected which became the model for that particular domain area. Domain area models were merged into an overall model, and the overall model shape was adjusted along the way.
Build feature list

The knowledge that was gathered during the initial modeling was used to identify a list of features. This was done by functionally decomposing the domain into subject areas. Subject areas each contain business activities, the steps within each business activity formed the categorized feature list. Features in this respect were small pieces of client-valued functions expressed in the form "<action> <result> <object>", for example: 'Calculate the total of a sale' or 'Validate the password of a user'. Features should not take more than two weeks to complete, else they should be broken down into smaller pieces.
Plan by feature
After the feature list had been completed, the next step was to produce the development plan. Class ownership has been done by ordering and assigning features (or feature sets) as classes to chief programmers.
Process model for FDD
Design by feature
A design package was produced for each feature. A chief programmer selected a small group of features that are to be developed within two weeks. Together with the corresponding class owners, the chief programmer worked out detailed sequence diagrams for each feature and refines the overall model. Next, the class and method prologues are written and finally a design inspection is held.
Build by feature
After a successful design inspection a per feature activity to produce a completed client-valued function (feature) is being produced. The class owners develop the actual code for their classes. After a unit test and a successful code inspection, the completed feature is promoted to the main build.
31
Milestones
Since features are small, completing a feature is a relatively small task. For accurate state reporting and keeping track of the software development project it is however important to mark the progress made on each feature. FDD therefore defines six milestones per feature that are to be completed sequentially. The first three milestones are completed during the Design By Feature activity, the last three are completed during the Build By Feature activity. To help with tracking progress, a percentage complete is assigned to each milestone. 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%, Design 40% and Design Inspection 3% = 44%).
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, derived from software engineering. These practices are all driven from a client-valued feature perspective. It is the combination of these practices and techniques that makes FDD so compelling. The best practices that make up FDD are shortly described below. For each best practice a short description will be given. Domain Object Modeling. Domain Object Modeling consists of exploring and explaining the domain of the problem to be solved. The resulting domain object model provides an overall framework in which to add features. Developing by Feature. 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. This makes it easier to deliver correct functions and to extend or modify the system. Individual Class (Code) Ownership. Individual class ownership means that distinct pieces or grouping of code are assigned to a single owner. The owner is responsible for the consistency, performance, and conceptual integrity of the class. Feature Teams. A feature team is a small, dynamically formed team that develops a small activity. By doing so, multiple minds are always applied to each design decision and also multiple design options are always evaluated before one is chosen. Inspections. Inspections are carried out to ensure good quality design and code, primarily by detection of defects. Configuration Management. 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. Regular Builds. 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. Visibility of progress and results. By frequent, appropriate, and accurate progress reporting at all levels inside and outside the project, based on completed work, managers are helped at steering a project correctly.
32
Metamodel (MetaModeling)
Metamodeling helps visualizing both the processes and the data of a method, such that methods can be compared and method fragments in the method engineering process can easily be reused. The advantage of the technique is that it is clear, compact, and consistent with UML standards. The left side of the metadata model, depicted on the right, shows the five basic activities involved in a software development project using FDD. The activities all contain sub-activities that correspond to the sub-activities in the FDD process description on Jeff De Lucas website [3]. The right side of the model shows the concepts involved. These concepts originate from the activities depicted in the left side of the diagram. A definition of the concepts is given in Table 3.
Process-Data Model for FDD
Tools used for Feature Driven Development

CASE Spec [5]. CASE Spec is a commercial enterprise tool for Feature-Driven development. TechExcel DevSuite [6]. TechExcel DevSuite is a commercial suite of applications to enable Feature-Driven development. FDD Tools [7]. The FDD Tools project aims to produce an open source, cross-platform toolkit supporting the Feature Driven Development methodology. FDD Viewer [8]. FDD Viewer is a utility to display and print parking lots.
References
1. ^ Coad, P., Lefebvre, E. & De Luca, J. (1999). Java Modeling In Color With UML: Enterprise Components and Process. Prentice Hall International. (ISBN 0-13-011510-X) 2. ^ Palmer, S.R., & Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development. Prentice Hall. (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] - Nebulon is the consulting practice of Jeff De Luca Successful Web Development Methodologies [11] - Use of FDD for Web Development projects Delivering Real Business Value using Feature Driven Development [12] - Article gives basic overview of FDD FDD and Agile Modeling [13] Better Software Faster [14] - Another book in the Coad Series referencing Feature Driven Development. Authors Andy Carmichael and Dan Haywood ISBN 0-13-008752-1 Interview with FDD-Creator Jeff DeLuca [15] (Podcast)
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, specifically the domain experts and the chief programmers. 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.
Conduct Domain A domain expert gives a DOMAIN OVERVIEW of the domain area to be modeled. This should also include Walk-through information that is related to this DOMAIN AREA but not necessarily a part of its implementation. Study Documents Develop Small Group Models Optionally the team studies available REFERENCE or REFERENCED REQUIREMENTS documents such as object models, functional requirements (traditional or use-case format), data models, and user guides. Forming groups of no more than three, 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. A member from each small group presents that groups proposed model for the domain area. The Chief Architect may also propose further model alternatives. The MODELING TEAM selects a proposed TEAM MODEL or composes a model by merging ideas from the proposed models. Every so often, the OVERALL MODEL, consisting of an overall SEQUENCE DIAGRAM and a CLASS DIAGRAM, is REFINED with the new model shapes produced by iterations of the Develop Team Model task above. EXPLANATORY NOTES on detailed or complex model shapes and on significant model alternatives are made for future reference by the project. The FEATURE LIST TEAM comprises the chief programmers from the MODELING TEAM in the process Develop Overall Model. The FEATURE LIST TEAM shall identify the FEATURE LIST using the knowledge obtained from the process Develop Overall Model. 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. It is decomposed into SUBJECT AREAS that comprise BUSINESS ACTIVITIES that comprise BUSINESS ACTIVITY steps (FEATURES).
Develop Team Model Refine Overall Object Model
Write Model Notes Build Feature List Form Features List Team Build Features List
34
The PLANNING TEAM comprises the development manager plus the chief programmers.
Plan By Feature
Form Planning Team Determine Development Sequence
The main tasks in the process Plan By Feature are not a strict sequence. Like many PLANNING activities they are considered together, with REFINEMENTS made from one or more tasks and then considering the others again. 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; Balancing load across CLASS OWNERS; The complexity of the FEATURES to be implemented; Bringing forward high-risk or complex BUSINESS ACTIVITIES; Consideration of any external (visible) milestones such as betas, previews, feedback checkpoints and the "whole products" that satisfy such milestones.
Assign Business Activities to Chief Programmers
The PLANNING TEAM shall assign chief programmers as owners of BUSINESS ACTIVITIES. The assignment is based on: The DEVELOPMENT SEQUENCE; Dependencies between FEATURES in terms of CLASSES involved; Balancing load across CLASS OWNERS (remember that chief programmers are also CLASS OWNERS); The complexity of the FEATURES to be implemented.
Assign Classes to Developers
The PLANNING TEAM shall assign developers as CLASS OWNERS. Developers own multiple CLASSES. The assignment of CLASSES to developers is based on: Balancing load across developers; The complexity of the CLASSES; The usage (e.g. high-use) of the CLASSES; The DEVELOPMENT SEQUENCE.
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. From the CLASS OWNER LIST, the Chief Programmer identifies the developers needed to form the FEATURE TEAM. As part of this step, the Chief Programmer creates a new DESIGN PACKAGE for the FEATURES(S) as part of the work package.
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. This Walk-through should also include domain information that is related to the FEATURE but not necessarily a part of its implementation. This is an optional task based on the complexity of the FEATURE and/or its interactions. Study Referenced Documents Develop Sequence Diagram(s) The FEATURE TEAM studies the REFERENCED REQUIREMENT(S) for the feature to be designed, all COVERING MEMOS, screen designs, external system interface specifications and any other supporting documentation. This is an optional task based on the complexity of the FEATURE and/or its interactions. Develop the SEQUENCE DIAGRAM(S) required for the FEATURE to be designed. The diagram files should be checked into the version control system. Any ALTERNATIVE DESIGNS, design decisions, requirements clarifications and EXPLANATORY NOTES are also recorded and written up in the DESIGN ALTERNATIVES section of the DESIGN PACKAGE. 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. 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. The Chief Programmer makes some REFINEMENTS on the model to add new / updated CLASSES, methods, attributes and/or to make changes to existing CLASSES, methods or attributes based on the SEQUENCE DIAGRAM(S) defined for the FEATURE(S). This results in the implementation language source files being updated in the FEATURE TEAM Area. The Chief Programmer creates model diagrams in a publishable format. These files should be checked into the version control system and submitted for publishing on the project intranet. Using the updated implementation language source files from the Refine Object Model task in the shared FEATURE TEAM Area, the development owner of each CLASS writes the CLASS AND METHOD PROLOGUE for each item defined by the FEATURE and SEQUENCE DIAGRAM(S). This includes parameter types, return types, exceptions and messages. Once each developer has completed this task, the Chief Programmer generates the API documentation using <your tool> and submits it for publication on the project intranet. A design inspection with the FEATURE TEAM members or with other project members is held. The decision to inspect within the FEATURE TEAM or with other project team members is that of the Chief Programmer. On acceptance a TODO TASK LIST is generated per affected CLASS, and each team member adds their tasks to their calendar task list. The Chief Programmer must also merge changes from the shared FEATURE TEAM Area into the change control system. The development CLASS owners will perform the IMPLEMENTATION of the items necessary to satisfy the requirements of their CLASS for this FEATURE.
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. The decision to inspect within the FEATURE TEAM or with other project team members is that of the Chief Programmer. The decision to inspect before or after unit test is that of the Chief Programmer. The development CLASS owner tests their code to ensure all requirements of their CLASS are satisfied. The Chief Programmer determines what FEATURE TEAM-level unit testing is required (if any). That is, if any testing across the CLASSES developed for this FEATURE is required.
Conduct Unit Test
Promote to Build PROMOTION to the BUILD of CLASSES is only possible after a successful CODE INSPECTION. The Chief Programmer tracks the individual CLASSES being promoted, through feedback from the developers, and is the integration point for the entire FEATURE.
36
Table 3: Concepts
CONCEPT BUILD PROMOTION Wiki: Software build Definition (source)
BUSINESS ACTIVITY Activity undertaken as part of a commercial enterprise. ([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. ([17]
Wiki: Class diagram A class owner is someone responsible for the design and implementation of a class. ([18] A class owner list is a list of class owners. ([18] Wiki: Code review A paper that integrates and describes the design package such that it stands on its own for reviewers. ([17] Wiki: Calendar date Section of the Design Package containing the diagram files in the version control system, alternative designs, design decisions, requirements clarifications and notes. ([17] Package containing: A covering memo, or paper, that integrates and describes the design package such that it stands on its own for reviewers. The referenced requirements (if any) in the form of documents and all related confirmation memos and supporting documentation. The Sequence diagram(s). Design alternatives (if any) The object model with new/updated classes, methods and attributes. The <your tool> generated output for the class and method prologues created or modified by this design. Calendar/To-Do task-list entries for action items on affected classes for each team member.
([17] DEVELOPMENT SEQUENCE The planned order for completion of each business activity. The planning team shall assign a date (month and year only) for completion of each business activity. ([17]
DOMAIN OVERVIEW The domain expert gives an overview of the domain area for the feature to be designed. This should also include domain information that is related to the feature but not necessarily a part of its implementation. This is an optional task based on the complexity of the feature and/or its interactions. ([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. ([17] Features are granular functions expressed in client-valued terms using this naming template: <action> <result> <object>. For example, calculate the total of a sale, calculate the total quantity sold by a retail outlet for an item description. Features are granular in accordance with the rule that a feature will take no more than two weeks to complete, but not so granular as to be at the level of getters and setters. Two weeks is an upper limit; most features take less than this time. When a business activity step looks larger than two weeks, the step is broken into smaller steps that then become features. ([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. ([19] The team comprises the chief programmers from the modeling team in process. Their task is to make a Feature list. ([17]
A feature team is a small, dynamically formed team that develops the feature(s) that a Chief Programmer selects for development. ([17]
37
IMPLEMENTATION MODELING TEAM
Wiki: Implementation The modeling team comprises permanent members from the domain and development areas, specifically the domain experts and the chief programmers. ([17] A merged domain area model. ([17] Wiki: Planning The planning team comprises the development manager plus the chief programmers for making a planning. ([17] Wiki: Reference (work) Need or expectation that is stated, generally implied or obligatory. (www.finnevo.fi/eng/contents/iso9000_terms.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. ([17]
An area of major interest or importance to the enterprise. It is centered on a major resource, product or activity. The subject areas provide reference information when conducting detailed requirements gathering. (www.georgetown.edu/uis/ia/dw/GLOSSARY0816.html) A proposed model selected by the modeling team or composed by merging ideas from the proposed models. ([17] Wiki: Todo list
TEAM MODEL TODO TASK LIST
References
[1] [2] [3] [4] [5] [6] http:/ / en. wikipedia. org/ wiki/ Feature-driven_development#endnote_Coad http:/ / en. wikipedia. org/ wiki/ Feature-driven_development#endnote_Palmer http:/ / www. nebulon. com/ http:/ / www. featuredrivendevelopment. com/ http:/ / www. casespec. net http:/ / www. techexcel. com/ solutions/ alm/ fdd. html
[7] http:/ / fddtools. sourceforge. net/ [8] http:/ / www. featuredrivendevelopment. com/ node/ 687 [9] http:/ / www. dmoz. org/ Computers/ Programming/ Methodologies/ Agile/ Feature_Driven_Development/ [10] http:/ / www. nebulon. com/ fdd/ index. html [11] http:/ / www. sitepoint. com/ article/ successful-development [12] http:/ / www. methodsandtools. com/ archive/ archive. php?id=19 [13] http:/ / www. agilemodeling. com/ essays/ fdd. htm [14] http:/ / www. bettersoftwarefaster. com/ index. htm [15] http:/ / www. se-radio. net/ 2008/ 01/ episode-83-jeff-deluca-on-feature-driven-development/ [16] http:/ / www. thefreedictionary. com/ ) [17] http:/ / www. featuredrivendevelopment. com/ files/ fddprocessesA4. pdf) [18] http:/ / www. hst. fhso. ch/ Archiv/ 2000/ swe/ otherResources/ ch03/ fdd. PDF) [19] http:/ / www. uidesign. net/ 2001/ papers/ fddui. html)
Test-driven development
38

39
Tools

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, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.[1] Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,[5] but more recently has created more general interest in its own right.[2] Programmers also apply the concept to improving and debugging legacy code developed with older techniques.[3]
Test-driven development cycle

The following sequence is based on the book Test-Driven Development by Example.[1]
Add a test
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's A graphical representation of the development cycle, using a basic flowchart specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing 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, a subtle but important difference.
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. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
Write some code

The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it. It is important that the code written is only designed to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
Run the automated tests and see them succeed

If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
Refactor code
Now the code can be cleaned up as necessary. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality. The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production codefor example magic numbers or strings repeated in both to make the test pass in step 3.
Repeat
Starting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps should always be small, with as few as 1 to 10 edits between each test run. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to excessive debugging. Continuous integration helps by providing revertible checkpoints. When using external libraries it is important not to make increments that are so small as to be effectively merely testing the library itself,[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.
Development style
There are various aspects to using test-driven development, for example the principles of "keep it simple stupid" (KISS) and "You aren't gonna need it" (YAGNI). By focusing on writing only the code necessary to pass tests, designs can be cleaner and clearer than is often achieved by other methods.[1] In Test-Driven Development by Example, Kent Beck also suggests the principle "Fake it till you make it". To achieve some advanced design concept (such as a design pattern), tests are written that generate that design. The code may remain simpler than the target pattern, but still pass all required tests. This can be unsettling at first but it allows the developer to focus only on what is important. Write the tests first. The tests should be written before the functionality that is being tested. This has been claimed to have many benefits. It helps ensure that the application is written for testability, as the developers must consider how to test the application from the outset, rather than worrying about it later. It also ensures that tests for every feature get written. Additionally, writing the tests first drives a deeper and earlier understanding of the product requirements, ensures the effectiveness of the test code, and maintains a continual focus on the quality of the product.[] When writing feature-first code, there is a tendency by developers and the development organisations to
Test-driven development push the developer on to the next feature, neglecting testing entirely. The first test might not even compile, at first, because all of the classes and methods it requires may not yet exist. Nevertheless, that first test functions as an executable specification.[4] First fail the test cases. The idea is to ensure that the test really works and can catch an error. Once this is shown, the underlying functionality can be implemented. This has been coined the "test-driven development mantra", known as red/green/refactor where red means fail and green is pass. Test-driven development constantly repeats the steps of adding test cases that fail, passing them, and refactoring. Receiving the expected test results at each stage reinforces the programmer's mental model of the code, boosts confidence and increases productivity. Keep the unit small. For TDD, a unit is most commonly defined as a class or group of related functions, often called a module. Keeping units relatively small is claimed to provide critical benefits, including: Reduced Debugging Effort When test failures are detected, having smaller units aids in tracking down errors. Self-Documenting Tests Small test cases have improved readability and facilitate rapid understandability.[] 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, which then drive the traditional unit test-driven development (UTDD) process.[5] This process ensures the customer has an automated mechanism to decide whether the software meets their requirements. With ATDD, the development team now has a specific target to satisfy, the acceptance tests, which keeps them continuously focused on what the customer really wants from that user story.
41
Best practices
Test structure
Effective layout of a test case ensures all required actions are completed, improves the readability of the test case, and smooths the flow of execution. Consistent structure helps in building a self-documenting test case. A commonly applied structure for test cases has (1) setup, (2) execution, (3) validation, and (4) cleanup. Setup: Put the Unit Under Test (UUT) or the overall test system in the state needed to run the test. Execution: Trigger/drive the UUT to perform the target behavior and capture all output, such as return values and output parameters. This step is usually very simple. Validation: Ensure the results of the test are correct. These results may include explicit outputs captured during Execution or state changes in the UUT. Cleanup: Restore the UUT or the overall test system to the pre-test state. This restoration permits another test to execute immediately after this one.[]
Individual best practices

Separate common set up and teardown logic into test support services utilized by the appropriate test cases. Keep each test oracle focused on only the results necessary to validate its test. Design time-related tests to allow tolerance for execution in non-real time operating systems. The common practice of allowing a 5-10 percent margin for late execution reduces the potential number of false negatives in test execution. Treat your test code with the same respect as your production code. It also must work correctly for both positive and negative cases, last a long time, and be readable and maintainable. Get together with your team and review your tests and test practices to share effective techniques and catch bad habits. It may be helpful to review this section during your discussion.[]
42
Practices to avoid, or "anti-patterns"

Do not have test cases depend on system state manipulated from previously executed test cases. A test suite where test cases are dependent upon each other is brittle and complex. Execution order has to be specifiable and/or constant. Basic refactoring of the initial test cases or structure of the UUT causes a spiral of increasingly pervasive impacts in associated tests. Interdependent tests can cause cascading false negatives. A failure in an early test case breaks a later test case even if no actual fault exists in the UUT, increasing defect analysis and debug efforts. Do not test precise execution behavior timing or performance. Do not try to build all-knowing oracles. An oracle that inspects more than necessary is more expensive and brittle over time than it needs to be. This very common error is dangerous because it causes a subtle but pervasive time sink across the complex project.[]
Benefits
A 2005 study found that using TDD meant writing more tests and, in turn, programmers who wrote more tests tended to be more productive.[6] Hypotheses relating to code quality and a more direct correlation between TDD and productivity were inconclusive.[7] Programmers using pure TDD on new ("greenfield") projects reported they only rarely felt the need to invoke a debugger. Used in conjunction with a version control system, when tests fail unexpectedly, reverting the code to the last version that passed all tests may often be more productive than debugging.[8] Test-driven development offers more than just simple validation of correctness, but can also drive the design of a program.[citation needed] By focusing on the test cases first, one must imagine how the functionality is used by clients (in the first case, the test cases). So, the programmer is concerned with the interface before the implementation. This benefit is complementary to Design by Contract as it approaches code through test cases rather than through mathematical assertions or preconceptions. Test-driven development offers the ability to take small steps when required. It allows a programmer to focus on the task at hand as the first goal is to make the test pass. Exceptional cases and error handling are not considered initially, and tests to create these extraneous circumstances are implemented separately. Test-driven development ensures in this way that all written code is covered by at least one test. This gives the programming team, and subsequent users, a greater level of confidence in the code. While it is true that more code is required with TDD than without TDD because of the unit test code, the total code implementation time could be shorter based on a model by Mller and Padberg.[9] Large numbers of tests help to limit the number of defects in the code. The early and frequent nature of the testing helps to catch defects early in the development cycle, preventing them from becoming endemic and expensive problems. Eliminating defects early in the process usually avoids lengthy and tedious debugging later in the project. TDD can lead to more modularized, flexible, and extensible code. 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 leads to smaller, more focused classes, looser coupling, and cleaner interfaces. 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. Because no more code is written than necessary to pass a failing test case, automated tests tend to cover every code path. For example, for a TDD developer to add an else branch to an existing if statement, the developer would first have to write a failing test case that motivates the branch. As a result, the automated tests resulting from TDD tend to be very thorough: they detect any unexpected changes in the code's behaviour. This detects problems that can arise where a change later in the development cycle unexpectedly alters other functionality.
43
Shortcomings
Test-driven development is difficult to use in situations where full functional tests are required to determine success or failure. Examples of these are user interfaces, programs that work with databases, and some that depend on specific network configurations. TDD encourages developers to put the minimum amount of code into such modules and to maximize the logic that is in testable library code, using fakes and mocks to represent the outside world. Management support is essential. Without the entire organization believing that test-driven development is going to improve the product, management may feel that time spent writing tests is wasted.[10] Unit tests created in a test-driven development environment are typically created by the developer who is writing the code being tested. The tests may therefore share the same blind spots with the code: If, for example, a developer does not realize that certain input parameters must be checked, 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, both the tests and the code will be wrong, as giving a false sense of correctness. The high number of passing unit tests may bring a false sense of security, resulting in fewer additional software testing activities, such as integration testing and compliance testing. Tests become part of the maintenance overhead of a project. Badly written tests, for example ones that include hard-coded error strings or are themselves prone to failure, are expensive to maintain. This is especially the case with fragile tests.[11] There is a risk that tests that regularly generate false failures will be ignored, so that when a real failure occurs, it may not be detected. It is possible to write tests for low and easy maintenance, for example by the reuse of error strings, and this should be a goal during the code refactoring phase described above. Overtesting can consume time both to write the excessive tests, and later, to rewrite the tests when requirements change. Also, more-flexible modules (with limited tests) might accept new requirements without the need for changing the tests. For those reasons, testing for only extreme conditions, or a small sample of data, can be easier to adjust than a set of highly detailed tests. However, developers could be warned about overtesting to avoid the excessive work, but it might require advanced skills in sampling or factor analysis. The level of coverage and testing detail achieved during repeated TDD cycles cannot easily be re-created at a later date. Therefore these original, or early, tests become increasingly precious as time goes by. The tactic is to fix it early. Also, if a poor architecture, a poor design, or a poor testing strategy leads to a late change that makes dozens of existing tests fail, then it is important that they are individually fixed. Merely deleting, disabling or rashly altering them can lead to undetectable holes in the test coverage.
Code visibility
Test suite code clearly has to be able to access the code it is testing. On the other hand, normal design criteria such as information hiding, encapsulation and the separation of concerns should not be compromised. Therefore unit test code for TDD is usually written within the same project or module as the code being tested. In object oriented design this still does not provide access to private data and methods. Therefore, extra work may be necessary for unit tests. In Java and other languages, a developer can use reflection to access fields that are marked private.[12] Alternatively, an inner class can be used to hold the unit tests so they have visibility of the enclosing class's members and attributes. In the .NET Framework and some other programming languages, partial classes may be used to expose private methods and data for the tests to access. It is important that such testing hacks do not remain in the production code. In C and other languages, compiler directives such as #if DEBUG ... #endif can be placed around such additional classes and indeed all other test-related code to prevent them being compiled into the released code. This means the released code is not exactly the same as what was unit tested. The regular running of fewer but more comprehensive, end-to-end, 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.
Test-driven development There is some debate among practitioners of TDD, documented in their blogs and other writings, as to whether it is wise to test private methods and data anyway. Some argue that private members are a mere implementation detail that may change, and should be allowed to do so without breaking numbers of tests. Thus it should be sufficient to test any class through its public interface or through its subclass interface, which some languages call the "protected" interface.[13] Others say that crucial aspects of functionality may be implemented in private methods, 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.[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, such as xUnit, to create and automatically run sets of test cases. Xunit frameworks provide assertion-style test validation capabilities and result reporting. 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. 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.[16]
Fakes, mocks and integration tests

Unit tests are so named because they each test one unit of code. A complex module may have a thousand unit tests and a simple module may have only ten. The tests used for TDD should never cross process boundaries in a program, let alone network connections. Doing so introduces delays that make tests run slowly and discourage developers from running the whole suite. Introducing dependencies on external modules or data also turns unit tests into integration tests. If one module misbehaves in a chain of interrelated modules, it is not so immediately clear where to look for the cause of the failure. When code under development relies on a database, a web service, or any other external process or service, enforcing a unit-testable separation is also an opportunity and a driving force to design more modular, more testable and more reusable code.[17] Two steps are necessary: 1. Whenever external access is needed in the final design, an interface should be defined that describes the access available. See the dependency inversion principle for a discussion of the benefits of doing this regardless of TDD. 2. The interface should be implemented in two ways, one of which really accesses the external process, and the other of which is a fake or mock. Fake objects need do little more than add a message such as Person object saved to a trace log, against which a test assertion can be run to verify correct behaviour. Mock objects differ in that they themselves contain test assertions that can make the test fail, for example, if the person's name and other data are not as expected. Fake and mock object methods that return data, ostensibly from a data store or user, can help the test process by always returning the same, realistic data that tests can rely upon. They can also be set into predefined fault modes so that error-handling routines can be developed and reliably tested. In a fault mode, a method may return an invalid,
Test-driven development incomplete or null response, or may throw an exception. Fake services other than data stores may also be useful in TDD: A fake encryption service may not, in fact, encrypt the data passed; a fake random number service may always return 1. Fake or mock implementations are examples of dependency injection. A Test Double is a test-specific capability that substitutes for a system capability, typically a class or function, that the UUT depends on. There are two times at which test doubles can be introduced into a system: link and execution. Link time substitution is when the test double is compiled into the load module, which is executed to validate testing. 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. The alternative to linker substitution is run-time substitution in which the real functionality is replaced during the execution of a test cases. This substitution is typically done through the reassignment of known function pointers or object replacement. Test doubles are of a number of different types and varying complexities: Dummy A dummy is the simplest form of a test double. It facilitates linker time substitution by providing a default return value where required. Stub A stub adds simplistic logic to a dummy, providing different outputs. Spy A spy captures and makes available parameter and state information, publishing accessors to test code for private information allowing for more advanced state validation. Mock A mock is specified by an individual test case to validate test-specific behavior, checking parameter values and call sequencing. Simulator A simulator is a comprehensive component providing a higher-fidelity approximation of the target capability (the thing being doubled). A simulator typically requires significant additional development effort.[] A corollary of such dependency injection is that the actual database or other external-access code is never tested by the TDD process itself. To avoid errors that may arise from this, other tests are needed that instantiate the test-driven code with the "real" implementations of the interfaces discussed above. These are integration tests and are quite separate from the TDD unit tests. There are fewer of them, and they must be run less often than the unit tests. They can nonetheless be implemented using the same testing framework, such as xUnit. 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, even if any test fails. This is often achieved using some combination of the following techniques: The TearDown method, which is integral to many test frameworks. try...catch...finally exception handling structures where available. Database transactions where a transaction atomically includes perhaps a write, a read and a matching delete operation. Taking a "snapshot" of the database before running any tests and rolling back to the snapshot after each test run. This may be automated using a framework such as Ant or NAnt or a continuous integration system such as CruiseControl. Initialising the database to a clean state before tests, rather than cleaning up after them. 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.
45
46
TDD for complex systems

Exercising TDD on large, challenging systems requires: A modular architecture. Well-defined components with published interfaces. Disciplined system layering with maximization of platform independence. These proven practices yield increased testability and facilitate the application of build and test automation.[]
Designing for testability

Complex systems require an architecture that meets a range of requirements. A key subset of these requirements includes support for the complete and effective testing of the system. Effective modular design yields components that share traits essential for effective TDD. High Cohesion ensures each unit provides a set of related capabilities and makes the tests of those capabilities easier to maintain. Low Coupling allows each unit to be effectively tested in isolation. Published Interfaces restrict Component access and serve as contact points for tests, facilitating test creation and ensuring the highest fidelity between test and production unit configuration. A key technique for building effective modular architecture is Scenario Modeling where a set of sequence chart is constructed, each one focusing on a single system-level execution scenario. The Scenario Model provides an excellent vehicle for creating the strategy of interactions between components in response to a specific stimulus. Each of these Scenario Models serves as a rich set of requirements for the services or functions that a component must provide, and it also dictates the order that these components and services interact together. 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. This magnification makes the benefits of TDD accrue even faster in the context of larger projects. However, the complexity of the total population of tests can become a problem in itself, eroding potential gains. It sounds simple, 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. Creating and managing the architecture of test software within a complex system is just as important as the core product architecture. Test drivers interact with the UUT, test doubles and the unit test framework.[]
References
[1] [2] [3] [5] Beck, K. Test-Driven Development by Example, Addison Wesley - Vaseem, 2003 Newkirk, JW and Vorontsov, AA. Test-Driven Development in Microsoft .NET, Microsoft Press, 2004. Feathers, M. Working Effectively with Legacy Code, Prentice Hall, 2004 Koskela, L. "Test Driven: TDD and Acceptance TDD for Java Developers", Manning Publications, 2007
External links
TestDrivenDevelopment on WikiWikiWeb Test or spec? Test and spec? Test from spec! (http://www.eiffel.com/general/monthly_column/2004/ september.html), by Bertrand Meyer (September 2004) Microsoft Visual Studio Team Test from a TDD approach (http://msdn.microsoft.com/en-us/library/ ms379625(VS.80).aspx)
Test-driven development Write Maintainable Unit Tests That Will Save You Time And Tears (http://msdn.microsoft.com/en-us/ magazine/cc163665.aspx) Improving Application Quality Using Test-Driven Development (TDD) (http://www.methodsandtools.com/ archive/archive.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, Sen, Juan
Shane is a masculine given name. It is an Anglicised version of the Irish name Sen, which itself is cognate to the name John.[1] Shane comes from the way the name Sen is pronounced in the Ulster dialect of the Irish language, as opposed to Shaun or Shawn. Shane is also a popular surname with the prefix "Mc", "Mac", or "O'", to form Anglicized Irish surname patronyms.[2] The surname was first recorded in Petty's census of Ireland (1659), which lists a Dermot McShane (i.e. Son of Shane).[3] The name Shane became popular through the novel Shane (1949) by Jack Schaefer and its movie adaptation (1953), directed by George Stevens from a screenplay by A.B. Guthrie Jr.. Shane is sometimes used as a feminine given name, derived not from the Irish name but from the Yiddish name Shayna, meaning "beautiful".
Variants
Variant forms include Shayne and Shain.[citation needed]
Given name
This list is incomplete. You can help by adding people entries to it.
Men
Shane Acker (b. 1971), American filmmaker Shane Alexander, 2nd Earl Alexander of Tunis (b. 1935), British peer Shane Battier (b. 1978), American basketball player Shane Bond (b. 1970), New Zealand cricketer Shane Briant (b. 1946), British-Australian actor and novelist Shane Byrne (b. 1971), Irish rugby union player Shane Carwin (b. 1975), American MMA fighter Shane Claiborne (b. 1975), American Christian activist Shayne Corson (b. 1966), Canadian retired hockey player
Shane (name) Shane Crawford (b. 1974), retired AFL football player and premiership player with Hawthorn Shane Doan (b. 1976), Canadian NHL hockey player Shane Dorian (b. 1972), professional surfer Shane Dawson (b. 1988), YouTube comedian and actor Shane Embury (b. 1967), bassist of the British band Napalm Death Shane Filan (b. 1979), lead singer of the Irish band Westlife Shane Haboucha (b. 1990), American child actor Shane Harper (b. 1993), American actor, singer, dancer Shane Horgan (b. 1978), Irish rugby union player Shane Kippel (b. 1986), Canadian actor Shane Lee (b. 1973), Australian former cricketer Shane Leslie (18851971), Irish-born diplomat and writer Shane Lynch (b. 1971), Irish singer in the band Boyzone Shane MacGowan (b. 1957), singer/songwriter for the Irish music group The Pogues Shane Matthews (b. 1970), American football player Shane McKenzie (b. 1973), Australian athlete Shane McMahon (b. 1970), former WWE executive and wrestler Shane Meadows (b. 1972), British film director Shane Mosley (b. 1971), Professional Boxer Shane Niemi (b. 1978), Canadian track and field athlete Shane O'Neill (ca. 15301567), Irish warrior, "The O' Neill" Shane O'Neill (disambiguation) Shane Reynolds (b. 1968), American former baseball player Shane Richie (b. 1964), British actor and TV presenter Shane Scott (b. 1966), American film director and producer Shane Sparks (b. 1974), American hip-hop choreographer Shane Stant (b. 1971), the known assailant who attacked Nancy Kerrigan Shane Tilton (b. 1978), American media scholar Shayne Topp, American actor Shane Tutmarc, American singer/songwriter Shane Victorino (b. 1980), American baseball player Shayne Ward (b. 1984). British pop singer Shane Warne (b. 1969), Australian cricketer Shane Watson (b. 1981), Australian cricketer Shane Webcke (b. 1974), Australian rugby league footballer Shane West (b. 1978), American actor Shane Williams (b. 1977), Welsh rugby union player Shane White (b. 1970), American comic book artist Shane Woewodin (b. 1976), retired AFL football player and Brownlow Medal
48
Shane (name)
49
Women
Shane Gould (b. 1956), Australian swimmer
Fictional characters
Shane, the eponymous hero of a novel (1949) by Jack Schaefer, which was adapted to film (1953) Shane Vendrell, a detective on the FX Networks police drama television series The Shield Shane Dooiney, Locomotive Number 5 on the Culdee Fell Railway in the Railway Series by the Reverend W. Awdry Shane McCutcheon from The L Word Captain Shane Schofield, central character in Matthew Reilly's novels Ice Station, Area 7, 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, principal character in the Showtime series 'Weeds'
Surname
Shane
Family name Pronunciation shayn Related names McShane, MacShane, O'Shane
Alex Shane (b. 1979), British former wrestler Bob Shane (b. 1934), American folk singer, co-founder and lead singer of The Kingston Trio Doug Shane, test pilot Paul Shane (b. 1940), English actor Shane Twins (b. 1967), the twin brothers Mike and Todd Shane, professional wrestlers Tom Shane, founder of the Shane Company, the largest family-owned jeweler in the United States
References
Article Sources and Contributors
50
Article Sources and Contributors

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

file:Coding Shots Annual Plan high res-5.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Coding_Shots_Annual_Plan_high_res-5.jpg License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:Matthew (WMF) File:Scrum process.svg Source: http://en.wikipedia.org/w/index.php?title=File:Scrum_process.svg License: unknown Contributors: Bruce1ee, KTo288, Lakeworks, Mdd, Sebastian Wallroth, 2 anonymous edits File:Daily sprint meeting.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Daily_sprint_meeting.jpg License: Creative Commons Attribution-Sharealike 2.0 Contributors: FlickreviewR, Ftiercel File:Scrum task board.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Scrum_task_board.jpg License: Creative Commons Attribution 2.0 Contributors: FlickreviewR, Ftiercel, Mattes, Ww2censor File:SampleBurndownChart.png Source: http://en.wikipedia.org/w/index.php?title=File:SampleBurndownChart.png License: Public Domain Contributors: Pablo Straub Image:XP-feedback.gif Source: http://en.wikipedia.org/w/index.php?title=File:XP-feedback.gif License: Creative Commons Attribution 3.0 Contributors: DonWells Image:Fdd process diagram.png Source: http://en.wikipedia.org/w/index.php?title=File:Fdd_process_diagram.png License: GNU Free Documentation License Contributors: Dgerwe at en.wikipedia Image:Fdd process data diagram.png Source: http://en.wikipedia.org/w/index.php?title=File:Fdd_process_data_diagram.png License: GNU Free Documentation License Contributors: D. van Gerwe Dgerwe Image:Test-driven development.PNG Source: http://en.wikipedia.org/w/index.php?title=File:Test-driven_development.PNG License: Creative Commons Attribution-Sharealike 3.0 Contributors: Excirial (Contact me, Contribs)
License
52
License
Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/

LevelUp Week3 Readings

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

LevelUp Week3 Readings

Загружено:

Авторское право:

Доступные форматы

Week 3 Readings

A software developer at work Activities and steps

Compiler Debugger Profiler GUI designer IDE Build automation

The Scrum process

Backlog grooming: storytime

Sprint planning meeting

Project management tools that support scrum

References Further reading

Crystal Clear (software development)

Crystal Clear (software development)

Lean software development

Lean software development

A software developer at work Activities and steps

Lean software development

Compiler Debugger Profiler GUI designer IDE Build automation

Lean software development

Decide as late as possible

Deliver as fast as possible

Empower the team

See the whole

Lean software practices

Planning and feedback loops in Extreme Programming.

Software development process

A software developer at work Activities and steps

Waterfall Prototype model Incremental Iterative V-Model Spiral Scrum Cleanroom

Compiler Debugger Profiler GUI designer IDE Build automation

Extreme programming primary and corollary practices.

Fine scale feedback

Severability and responses

A software developer at work Activities and steps

Compiler Debugger Profiler GUI designer IDE Build automation

Develop overall model

Build feature list

Tools used for Feature Driven Development

Table 2: Activities and sub-activities

Develop Team Model Refine Overall Object Model

Form Planning Team Determine Development Sequence

Assign Business Activities to Chief Programmers

Assign Classes to Developers

Form Feature Team

Refine Object Model

Write Class and Method Prologue

Implement Classes and Methods Inspect Code

Conduct Unit Test

IMPLEMENTATION MODELING TEAM

Wiki: Refinement Wiki: Sequence diagram

TEAM MODEL TODO TASK LIST

A software developer at work Activities and steps

Compiler Debugger Profiler GUI designer IDE Build automation

Test-driven development cycle

Run all tests and see if the new one fails

Write some code

Run the automated tests and see them succeed

Individual best practices

Practices to avoid, or "anti-patterns"

Software for TDD

Fakes, mocks and integration tests

TDD for complex systems

Designing for testability

Managing tests for large teams

Article Sources and Contributors

Article Sources and Contributors

Image Sources, Licenses and Contributors