CSC/ECE 517 Fall 2012/ch2a 2w5 dp: Difference between revisions
No edit summary |
|||
(59 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
== Agile Software Development == | == Agile Software Development == | ||
=== | === Introduction === | ||
=== Why Agile? === | ==== Why Agile? ==== | ||
James Shore and Shane Warden <ref>Shore, James and Warden, Shane. ''The Art of Agile Development''. O’Reilly Media, Inc., 2008, p. 4.</ref> state that the benefit for developers to follow a Agile software development process is to deliver successful products to the client or customer. | James Shore and Shane Warden <ref>Shore, James and Warden, Shane. ''The Art of Agile Development''. O’Reilly Media, Inc., 2008, p. 4.</ref> state that the benefit for developers to follow a Agile software development process is to deliver successful products to the client or customer. | ||
He defines success into 3 types: | He defines success into 3 types: | ||
Line 11: | Line 11: | ||
#* Developers find the project fun and rewarding which lead them to be intrinsically motivated and devote passion to the work. | #* Developers find the project fun and rewarding which lead them to be intrinsically motivated and devote passion to the work. | ||
=== The Agile Manifesto === | ==== The Agile Manifesto ==== | ||
The Agile Manifesto is a set of [http://agilemanifesto.org/principles.html 12 principles] that provide a foundation for agile methodologies. | The Agile Manifesto is a set of [http://agilemanifesto.org/principles.html 12 principles] that provide a foundation for agile methodologies. | ||
The core principles of the manifesto are as follows <ref>Manifesto for Agile Software Development http://agilemanifesto.org/ </ref> : | The core principles of the manifesto are as follows <ref name="Agile Manifesto">Manifesto for Agile Software Development http://agilemanifesto.org/ </ref> : | ||
* Individuals and interactions over processes and tools | * Individuals and interactions over processes and tools | ||
Line 30: | Line 30: | ||
[[File:Agile_poster.png]] | [[File:Agile_poster.png]] | ||
==== Adaptability ==== | ==== Adaptability ==== | ||
Adaptability is purported to be the most important value <ref>The Agile Leader: Adaptability | |||
http://blogs.forrester.com/tom_grant/11-04-19-adaptability_may_turn_out_to_be_agiles_most_important_virtue</ref> of Agile methodologies. | |||
This value forces teams to plan for inevitable change in a mindful manner. | |||
The focus for Adaptability can be summarized by these two principles stated in the Agile manifesto. | |||
*''"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."'' | |||
*''"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."'' | |||
There are three components in Adaptability <ref>Adaptation in project management through agile http://searchsoftwarequality.techtarget.com/feature/Adaptation-in-project-management-through-agile</ref> These three components must ALL be open to change in order to have a fully adaptable agile environment. | |||
#Product - quality code and adequate testing will ensure product functionality after changes have been made. | |||
#Process - practices that allow the team to adapt must be in place. | |||
#People - developers, management, and stakeholders must have the proper attitude that is accepting of change and want to work in a collaborative way. If people don't collaborate, the full advantages of an adaptive process are lost. | |||
==== Transparency ==== | ==== Transparency ==== | ||
Transparency in an Agile environment extends from simple communication between individuals working on the project to the project's definition and mission statement itself.<ref>The Concept of Transparency in Agile Project Management http://p-a-m.org/2012/03/the-concept-of-transparency-in-agile-project-management/</ref> | |||
The high value on ''Transparency'' can be summarized by these two principles stated in the Agile manifesto. | |||
* ''Individuals and interactions over processes and tools'' | |||
* ''Customer collaboration over contract negotiation'' | |||
Transparency in Agile project management is intended to create an open environment where communication and accountability are highly prized. | |||
Agile does not limit embracing this value simply to interaction between developers and project managers. As the second bullet point alludes to, this value extends to customer interaction as well. | |||
The idea is to generate a unifying project goal that the developers, project managers and, customer can all identify with. | |||
==== Simplicity ==== | ==== Simplicity ==== | ||
The Agile Manifesto refers to simplicity as, the art of maximizing the amount of work not done is essential. <ref name="Agile Manifesto"/> | |||
Simplicity is generally referred to as a little bit less than just enough process. | |||
The Agile methodologies attempt to keep the project focused on progressing to the project while eliminating process that can unintentionally slow development. | |||
This all plays into the Agile Manifesto's statement of "Working software over comprehensive documentation" | |||
There are three aspects or faces to simplicity <ref>Agile Software Development and the Three Faces of Simplicity http://www.informit.com/articles/article.aspx?p=25944</ref> | |||
* Do less - This facet refers to doing fewer activities, producing fewer documents and, reducing management reports. | |||
* Do better - A simple, straight forward model for the project helps the team be sure their design is correct. | |||
* Do swarms - An appropriate set of simple rules helps a highly motivated group of interactive individuals encourages higher level functions like innovation and creativity. | |||
==== Unity ==== | ==== Unity ==== | ||
Unity is a pervading ideal through most everything the Agile method is intended to accomplish. The value placed on unity is reflected in how Agile strives to create a team of customers, developers and project managers that have a single goal of completing a specific project. In addition it is focused on bringing the product team's understanding, goals and, communication in line with the customer's expectations and goals for the project itself. By working together while sharing experiences, knowledge and ideas Agile strives to provide a product that accomplishes the goal that the project was intended to accomplish. | |||
=== Best Practices === | === Best Practices === | ||
These are some of today's most common Agile practices <ref>Professional Management: Top ten agile best practices http://profmgmt.wordpress.com/2007/01/11/top-ten-agile-best-practices/</ref>. Before adopting a practice, teams must be able understand their priorities and problems affecting the product before you can decide which practices will be the solutions to those problems <ref>Professional Management: Which best practice to implement first? http://profmgmt.wordpress.com/2007/01/11/which-best-practice-to-implement-first/</ref>. | |||
*Common coding guidelines | |||
*Refactoring | |||
*Regression testing | |||
*Continuous integration | |||
*Test driven development | |||
*Active stakeholder participation | |||
*Pair programming | |||
=== Popular Agile Methods === | === Popular Agile Methods === | ||
Martin Fowler refers to Agile Software Development as a philosophy from which several different types of methodologies inherit their characteristics. Thus, it should be considered as an umbrella for the agile methods organizations choose to implement in their software projects <ref name="Agile Flavors">Flavors of Agile Development http://martinfowler.com/articles/newMethodology.html#FlavorsOfAgileDevelopment</ref>. | |||
The following are some of the most common Agile Methods practiced by industry organizations. | |||
==== Extreme Programming (XP) ==== | |||
Extreme Programming (XP) is one of the most practiced and well-known Agile methods and it is characterized by four core values <ref>A Practical Guide to Seven Agile Methodologies, Part 1 http://www.devx.com/architect/Article/32761/0</ref>: | |||
*Communication | |||
*Simplicity | |||
*Feedback | |||
*Courage | |||
XP's emphasis is on technical practices to ensure frequent delivery of functional software through skillful development. | |||
The practice of constant code reviews plays a big part in XP to ensure that development is skillful and code is fully functioning. This requires a high level of teamwork from team members and, therefore, a large fous on pair programming and refactoring must be in place. All three components allow teams to develop designs that increase business value in a simple and effective manner. | |||
XP is characterized by short iterations that last anywhere between one and four weeks. | |||
==== Scrum ==== | |||
Scrum is an agile method for product development that focuses on individuals and teams. | |||
Project development generally occurs in small iterative pieces. The intention is to encourage creativity while providing built in design time for feedback analysis. Scrum provides a simple framework to guide developers and managers during product development. The goal of the simple framework is to provide just enough structure for empirical process control based off of feedback loops.<ref>Scrum - Wikipedia http://en.wikipedia.org/wiki/Scrum_(development)</ref> | |||
The fundamental process is defined by the three following roles<ref>Scrum.org http://www.scrum.org/Resources/What-is-Scrum</ref> | |||
* Product Owners responsible for deciding on what will be built in the upcoming time frame | |||
* Development Teams - responsible for building the product defined by the Product Owners in the allotted time frame. This is followed by a demonstration to the Product Owners. | |||
* Scrum Masters - responsible for smoothing out and improving the process. | |||
==== Crystal ==== | |||
Crystal is a a variety of sets of methods developed by Alistair Cockburn in the '90s. Each variation's primary focus on improving performance is done through communication between people and their talents over the process in which a team follows <ref name="Agile Paper">An Introduction to Agile Methods http://www.cs.umd.edu/~mvz/cmsc435-s09/pdf/agile-paper.pdf</ref>. | |||
The Crystal methods prioritize safety in a project's outcome, efficiency, and habitability. These priorities motivate a focus on frequent delivery, reflective improvement, and close communication <ref name="Agile Flavors"/>. | |||
The name Crystal represents the different facets (like that of a gemstone) or methods available that focus around a central core. The belief that different approaches are required as the criticality <ref name="Agile Flavors"/> and the following of a project vary <ref name="Agile Paper"/>: | |||
*Team Size: teams can be of any size but in choosing members, focus on talented people | |||
*Iteration Length: iterations can be up to 4 months in length for highly critical projects | |||
*Distributed Teams: teams can be distributed across different locations | |||
Criticality can be classified as defects causing the loss or affecting the state of <ref name="Agile Paper"/>: | |||
#Comfort | |||
#Discretionary money | |||
#Essential money | |||
#Life | |||
Each version is assigned a color and it represents intensity of the degree of communication required among size of the team to get the job done. The different colors include Crystal Clear, Yellow, Orange and Red <ref name="Agile Paper"/>. The Crystal methods present an outline of what teams should focus on instead of a comprehensive guide <ref name="Agile Flavors"/>. | |||
As teams grow, the method hardens and more restraints must be put in place. Some agility may be lost, but because of a team's common mindset and understanding, the method remains Agile <ref name="Agile Paper"/>. | |||
==== Lean Development ==== | |||
Lean Development is a top-down approach based on lean processes (also referred to as the Toyota Production System <ref name="Agile Flavors"/>) used in the automotive industry of the 1980s. It was started by Bob Charette and its focus is to provide a set management ideas and reasonings while the development process (team size, iteration length, team distribution, and criticality) is left untouched. The management guidelines Lean Development provides are <ref name="Agile Paper"/>: | |||
#Customer Satisfaction is the top priority | |||
#Provide the biggest value for the money | |||
#Active customer participation will lead to success | |||
#Projects are a team effort | |||
#Everything is changeable | |||
#Domain, not point, solutions | |||
#Don't just construct, complete a project | |||
#80% solution today is better than a 100% solution tomorrow | |||
#Be minimalist | |||
#Needs determine technology | |||
#Product growth is feature growth, not size growth. | |||
#Never try to go beyond the limits of Lean Development | |||
== References == | == References == | ||
<references /> | <references /> |
Latest revision as of 22:10, 26 October 2012
Agile Software Development
Introduction
Why Agile?
James Shore and Shane Warden <ref>Shore, James and Warden, Shane. The Art of Agile Development. O’Reilly Media, Inc., 2008, p. 4.</ref> state that the benefit for developers to follow a Agile software development process is to deliver successful products to the client or customer. He defines success into 3 types:
- Organizational
- Deliver value and decrease costs to increase return on investment.
- Technical
- Elegant and maintainable code is produced.
- Personal
- Developers find the project fun and rewarding which lead them to be intrinsically motivated and devote passion to the work.
The Agile Manifesto
The Agile Manifesto is a set of 12 principles that provide a foundation for agile methodologies.
The core principles of the manifesto are as follows <ref name="Agile Manifesto">Manifesto for Agile Software Development http://agilemanifesto.org/ </ref> :
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Values
There are four concepts that represent the main values of Agile software development.
- Adaptability
- Transparency
- Simplicity
- Unity
Adaptability
Adaptability is purported to be the most important value <ref>The Agile Leader: Adaptability
http://blogs.forrester.com/tom_grant/11-04-19-adaptability_may_turn_out_to_be_agiles_most_important_virtue</ref> of Agile methodologies.
This value forces teams to plan for inevitable change in a mindful manner.
The focus for Adaptability can be summarized by these two principles stated in the Agile manifesto.
- "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
- "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
There are three components in Adaptability <ref>Adaptation in project management through agile http://searchsoftwarequality.techtarget.com/feature/Adaptation-in-project-management-through-agile</ref> These three components must ALL be open to change in order to have a fully adaptable agile environment.
- Product - quality code and adequate testing will ensure product functionality after changes have been made.
- Process - practices that allow the team to adapt must be in place.
- People - developers, management, and stakeholders must have the proper attitude that is accepting of change and want to work in a collaborative way. If people don't collaborate, the full advantages of an adaptive process are lost.
Transparency
Transparency in an Agile environment extends from simple communication between individuals working on the project to the project's definition and mission statement itself.<ref>The Concept of Transparency in Agile Project Management http://p-a-m.org/2012/03/the-concept-of-transparency-in-agile-project-management/</ref>
The high value on Transparency can be summarized by these two principles stated in the Agile manifesto.
- Individuals and interactions over processes and tools
- Customer collaboration over contract negotiation
Transparency in Agile project management is intended to create an open environment where communication and accountability are highly prized. Agile does not limit embracing this value simply to interaction between developers and project managers. As the second bullet point alludes to, this value extends to customer interaction as well. The idea is to generate a unifying project goal that the developers, project managers and, customer can all identify with.
Simplicity
The Agile Manifesto refers to simplicity as, the art of maximizing the amount of work not done is essential. <ref name="Agile Manifesto"/>
Simplicity is generally referred to as a little bit less than just enough process. The Agile methodologies attempt to keep the project focused on progressing to the project while eliminating process that can unintentionally slow development. This all plays into the Agile Manifesto's statement of "Working software over comprehensive documentation"
There are three aspects or faces to simplicity <ref>Agile Software Development and the Three Faces of Simplicity http://www.informit.com/articles/article.aspx?p=25944</ref>
- Do less - This facet refers to doing fewer activities, producing fewer documents and, reducing management reports.
- Do better - A simple, straight forward model for the project helps the team be sure their design is correct.
- Do swarms - An appropriate set of simple rules helps a highly motivated group of interactive individuals encourages higher level functions like innovation and creativity.
Unity
Unity is a pervading ideal through most everything the Agile method is intended to accomplish. The value placed on unity is reflected in how Agile strives to create a team of customers, developers and project managers that have a single goal of completing a specific project. In addition it is focused on bringing the product team's understanding, goals and, communication in line with the customer's expectations and goals for the project itself. By working together while sharing experiences, knowledge and ideas Agile strives to provide a product that accomplishes the goal that the project was intended to accomplish.
Best Practices
These are some of today's most common Agile practices <ref>Professional Management: Top ten agile best practices http://profmgmt.wordpress.com/2007/01/11/top-ten-agile-best-practices/</ref>. Before adopting a practice, teams must be able understand their priorities and problems affecting the product before you can decide which practices will be the solutions to those problems <ref>Professional Management: Which best practice to implement first? http://profmgmt.wordpress.com/2007/01/11/which-best-practice-to-implement-first/</ref>.
- Common coding guidelines
- Refactoring
- Regression testing
- Continuous integration
- Test driven development
- Active stakeholder participation
- Pair programming
Popular Agile Methods
Martin Fowler refers to Agile Software Development as a philosophy from which several different types of methodologies inherit their characteristics. Thus, it should be considered as an umbrella for the agile methods organizations choose to implement in their software projects <ref name="Agile Flavors">Flavors of Agile Development http://martinfowler.com/articles/newMethodology.html#FlavorsOfAgileDevelopment</ref>.
The following are some of the most common Agile Methods practiced by industry organizations.
Extreme Programming (XP)
Extreme Programming (XP) is one of the most practiced and well-known Agile methods and it is characterized by four core values <ref>A Practical Guide to Seven Agile Methodologies, Part 1 http://www.devx.com/architect/Article/32761/0</ref>:
- Communication
- Simplicity
- Feedback
- Courage
XP's emphasis is on technical practices to ensure frequent delivery of functional software through skillful development. The practice of constant code reviews plays a big part in XP to ensure that development is skillful and code is fully functioning. This requires a high level of teamwork from team members and, therefore, a large fous on pair programming and refactoring must be in place. All three components allow teams to develop designs that increase business value in a simple and effective manner. XP is characterized by short iterations that last anywhere between one and four weeks.
Scrum
Scrum is an agile method for product development that focuses on individuals and teams.
Project development generally occurs in small iterative pieces. The intention is to encourage creativity while providing built in design time for feedback analysis. Scrum provides a simple framework to guide developers and managers during product development. The goal of the simple framework is to provide just enough structure for empirical process control based off of feedback loops.<ref>Scrum - Wikipedia http://en.wikipedia.org/wiki/Scrum_(development)</ref>
The fundamental process is defined by the three following roles<ref>Scrum.org http://www.scrum.org/Resources/What-is-Scrum</ref>
- Product Owners responsible for deciding on what will be built in the upcoming time frame
- Development Teams - responsible for building the product defined by the Product Owners in the allotted time frame. This is followed by a demonstration to the Product Owners.
- Scrum Masters - responsible for smoothing out and improving the process.
Crystal
Crystal is a a variety of sets of methods developed by Alistair Cockburn in the '90s. Each variation's primary focus on improving performance is done through communication between people and their talents over the process in which a team follows <ref name="Agile Paper">An Introduction to Agile Methods http://www.cs.umd.edu/~mvz/cmsc435-s09/pdf/agile-paper.pdf</ref>.
The Crystal methods prioritize safety in a project's outcome, efficiency, and habitability. These priorities motivate a focus on frequent delivery, reflective improvement, and close communication <ref name="Agile Flavors"/>.
The name Crystal represents the different facets (like that of a gemstone) or methods available that focus around a central core. The belief that different approaches are required as the criticality <ref name="Agile Flavors"/> and the following of a project vary <ref name="Agile Paper"/>:
- Team Size: teams can be of any size but in choosing members, focus on talented people
- Iteration Length: iterations can be up to 4 months in length for highly critical projects
- Distributed Teams: teams can be distributed across different locations
Criticality can be classified as defects causing the loss or affecting the state of <ref name="Agile Paper"/>:
- Comfort
- Discretionary money
- Essential money
- Life
Each version is assigned a color and it represents intensity of the degree of communication required among size of the team to get the job done. The different colors include Crystal Clear, Yellow, Orange and Red <ref name="Agile Paper"/>. The Crystal methods present an outline of what teams should focus on instead of a comprehensive guide <ref name="Agile Flavors"/>.
As teams grow, the method hardens and more restraints must be put in place. Some agility may be lost, but because of a team's common mindset and understanding, the method remains Agile <ref name="Agile Paper"/>.
Lean Development
Lean Development is a top-down approach based on lean processes (also referred to as the Toyota Production System <ref name="Agile Flavors"/>) used in the automotive industry of the 1980s. It was started by Bob Charette and its focus is to provide a set management ideas and reasonings while the development process (team size, iteration length, team distribution, and criticality) is left untouched. The management guidelines Lean Development provides are <ref name="Agile Paper"/>:
- Customer Satisfaction is the top priority
- Provide the biggest value for the money
- Active customer participation will lead to success
- Projects are a team effort
- Everything is changeable
- Domain, not point, solutions
- Don't just construct, complete a project
- 80% solution today is better than a 100% solution tomorrow
- Be minimalist
- Needs determine technology
- Product growth is feature growth, not size growth.
- Never try to go beyond the limits of Lean Development
References
<references />