Agile software development describes approaches to software development where requirements and solutions evolve through self-organizing and cross-functional teamwork efforts and their end users. It supports adaptive planning, evolutionary development, early delivery, and continuous improvement, and encourages quick and flexible responses to change.
The term agile (sometimes written Agile ) was popularized, in this context, by the Manifesto for Agile Software Development . The values ​​and principles adopted in this manifesto come from and support a variety of software development frameworks, including Scrum and Kanban.
There is significant anecdotal evidence that adopting lively practices and values ​​increases the agility of software professionals, teams and organizations; However, some empirical studies have found no scientific evidence.
Video Agile software development
History
Iterative and incremental development methods can be traced back to 1957, with evolutionary project management and adaptive software development emerging in the early 1970s.
During the 1990s, a number of lightweight software development methods evolved in reaction to the prevailing heavyweight methods that critics say are highly regulated, planned, and micro-managed. These include: rapid application development (RAD), from 1991; integrated processes (UP) and dynamic system development methods (DSDM), both from 1994; Scrum, from 1995; Crystal Clear and extreme programs (XP), both from 1996; and feature-driven development, from 1997. Although these all originated before the publication of the Agile Manifesto, they are now collectively referred to as agile software development methods. At the same time, similar changes are taking place in manufacturing and aerospace.
In 2001, seventeen software developers met at a resort in Snowbird, Utah to discuss this lightweight development method, among others Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, and Bob Martin. Together they publish the Manifesto for Agile Software Development .
In 2005, a group led by Cockburn and Highsmith wrote an addendum to the project management principle, the Interdependence Declaration, to guide the management of software projects in accordance with agile software development methods.
In 2009, a group working with Martin wrote an expansion of software development principles, the Software Expertise Manifesto, to guide the development of agile software in accordance with professional conduct and mastery.
In 2011, Agile Alliance created a Guide to Agile Practices (renamed Agile Glossary in 2016), an open-source summary that evolved from the working definition of nimble practice, the term , and elements, along with interpretations and experience guides from practitioners worldwide around the world.
Maps Agile software development
Manifesto for Agile Software Development
The value of agile software development
Based on their combined experience developing software and helping others do that, the seventeen signatories of the manifesto state that they value:
- Individuals and Interactions through processes and tools
- Working Software above comprehensive documentation
- Customer Collaboration through contract negotiation
- Respond to Changes after following the plan
That is, while there is a value in the item on the right, they rate the items on the left more.
As Scott Ambler explains:
- Tools and processes are important, but more important is for competent people to work together effectively.
- Good documentation is useful to help people understand how software is created and how to use it, but the main point of development is making software, not documentation.
- Contracts are important but not a substitute for working with customers to find what they need.
- The project plan is important, but should not be too rigid to accommodate changes in technology or the environment, stakeholder priorities, and people's understanding of the problem and its solutions.
Some authors formed the Grease Alliance, a nonprofit organization that promotes software development in accordance with the values ​​and principles of the manifesto. Introducing a manifesto on behalf of the Agile Alliance, Jim Highsmith said,
The Agile Movement is not an anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore balance. We accept modeling, but not to file multiple charts in the dusty company repository. We embrace documentation, but not hundreds of pages of books that have never been maintained and rarely used. We plan, but recognize the boundaries of planning in turbulent environments. Those who will advertise XP or SCRUM supporters or any of the other Agile Methodologies as "hackers" do not know anything about the original methodology and definition of hacker terms.
The principle of agile software development
The Manifesto for Agile Software Development is based on twelve principles:
- Customer satisfaction with initial and ongoing delivery of valuable software
- Congratulations change the terms, even in the final development
- The functioning software is often sent (weeks and not months)
- Close, daily cooperation between business and developers
- The project is built around motivated individuals, who must be trusted
- The face-to-face conversation is the best form of communication (co-location)
- Working software is a key measure of progress
- Sustainable development, able to maintain a constant speed
- Continuous attention to good technical and design excellence
- Simplicity - the art of maximizing the amount of work that is not done - is very important
- The best architecture, requirements, and designs come from self-organizing teams
- Regularly, the team reflects on how to be more effective, and adjust accordingly
Overview
Iterative, incremental and evolutionary
The most agile development methods break down the work of product development into piecemeal that minimizes the amount of advance planning and design. Iteration, or sprint, is a timebox that usually lasts from one to four weeks. Each iteration involves a cross-functional team working across all functions: planning, analysis, design, coding, unit testing, and acceptance testing. At the end of the iteration, a functioning product is shown to the stakeholders. It minimizes overall risk and allows the product to adapt to changes quickly. Iterations may not add enough functionality to ensure market release, but the goal is to have available releases (with minimal bugs) at each end of the iteration. Multiple iterations may be required to release new products or features. Working software is a key measure of progress.
Efficient and face-to-face communication
No matter what development method is followed, each team must include a customer representative (Product Owner at Scrum). This person is approved by the stakeholders to act on their behalf and make a personal commitment to become available for the developer to answer questions throughout the iteration. At the end of each iteration, stakeholders and customer representatives review progress and re-evaluate priorities with a view to optimizing return on investment (ROI) and ensuring alignment with customer needs and company goals.
In agile software development, the information radiator is a physical (usually large) screen located close to the development team, where passers-by can see it. This presents the latest summary of product development status. The build light indicator can also be used to inform the team about their current product development status. Very short feedback loops and adaptation cycles
A common characteristic in agile software development is daily stand-up (also known as daily scrum) . In short sessions, team members report to each other what they did the previous day toward the goal of their team's iterations, what they are doing today to achieve goals, and any obstacles or obstacles they can see to the goal.
Quality focus
Specific tools and techniques, such as ongoing integration, automated unit testing, paired programming, test-based development, design patterns, behavioral development, domain-based design, code refactoring, and other techniques are often used to improve quality and improve product development. agility. The idea is that quality is built into software and always has proven software for customers.
Philosophy
Compared with traditional software engineering, agile software development mainly target complex systems and product development with dynamic, non-deterministic and non-linear characteristics. Accurate estimates, stable plans, and predictions are often difficult to obtain in the early stages, and trust in them tends to be low. The agile practitioner will attempt to reduce the necessary confidence leaps before a proof of value can be obtained. Requirements and designs are held to appear. A large front specification might cause a lot of waste in such a case, that is, not economically sound. This fundamental argument and previous industry experience, learned from years of success and failure, has helped shape the agile development of adaptative, iterative and evolutionary developments.
Adaptive vs. predicted
The development method is on the continuum from adaptive to predictive . The agile software development method lies on the adaptive side of this circuit. One of the key adaptive development methods is the rolling wave approach for scheduling planning, which identifies milestones but leaves the flexibility in the path to reach them, and also allows for the milestone itself to change.
The Adaptive method focuses on quick adjustments to reality changes. When project needs change, the adaptive team also changes. The adaptive team has difficulty explaining what will happen in the future. The farther the date, the more difficult the adaptive method of what will happen to that date. The adaptive team can not report what tasks they will take next week, but only the features they plan for next month. When asked about a six-month release from now, the adaptive team may be able to report only a mission statement for release, or an expected value statement vs. cost.
The Predictive method, in contrast, focuses on detailed analysis and planning of the future and meets known risks. In the extreme, the predictive team can report exactly what features and tasks are planned for the entire length of the development process. The predictive method relies on an effective initial phase analysis and if this is very wrong, the project may have difficulty changing direction. Predictive teams often form change control boards to ensure they only consider the most valuable changes.
Risk analysis can be used to choose between adaptive ( agile or value-driven ) and predictive ( plan-driven ) methods. Barry Boehm and Richard Turner stated that each side of the continuum has its own home ground as follows:
Iterative vs. waterfall
One of the differences between agile software development methods and waterfalls is the approach to quality and testing. In the waterfall model, there is always a separate testing phase after the build phase ; However, in the agile software development testing is completed in the same iteration as programming.
Because testing is done in every iteration - which develops a small piece of software - users can often use new software and validate value. Once users know the real value of updated software, they can make better decisions about the future of the software. Have retrospective sessions and software re-planning in each iteration - Scrum typically has just a two-week iteration - helping the team to keep adjusting the plan so as to maximize the value it provides. This follows a pattern similar to the PDCA cycle, since this work is planned, done, checked, reviewed and retrospectively, and the approved changes are act .
This recurring approach supports products rather than the project's mindset . This provides greater flexibility during the development process; while on project requirements are defined and locked from the start, making it difficult to change them later. Repeating product development allows software to evolve in response to changing business environments or market needs.
Due to the short iteration style of agile software development, it also has a strong connection with the concept of slender startup.
Code vs. documentation
In a letter to IEEE Computer , Steven Rakitin expressed his cynicism about agile software development, calling it "another attempt to undermine software engineering disciplines" and translating "software that works through comprehensive documentation" as "our want to spend all our coding time.Remember, real programmers do not write documentation. "
This is disputed by supporters of agile software development, stating that developers should write documentation if it is the best way to achieve relevant goals, but there are often better ways to accomplish those goals than to write static documentation. Scott Ambler states that the documentation should be "barely good enough" (JBGE), that too much or comprehensive documentation will usually lead to waste, and developers rarely trust detailed documentation because it usually does not sync with code, while too little documentation can also cause problems for maintenance, communication, learning, and knowledge sharing. Alistair Cockburn writes about the Crystal Clear method:
Crystal considers the development of a series of cooperative games, and intends that enough documentation to help the next victory in the next game. Crystal work products include use cases, risk lists, iteration plans, core domain models, and design notes to inform choice... but no template for clear documents and descriptions, but the purpose is clear, just enough documentation for the next game. I always tend to characterize this to my team as: what you want to know if you join the team tomorrow.
Agile software development method
Agile software development methods support a variety of software development life cycles. Some focus on practice (eg, XP, pragmatic programming, agile modeling), while some focus on managing workflows (eg, Scrum, Kanban). Some support activities for specification and development requirements (eg, FDD), while some attempt to cover the full development life cycle (eg, DSDM, RUP).
Popular agile software development frameworks include (but are not limited to):
- Adaptive software development (ASD)
- Agile modeling
- Agile integrated process (AUP)
- Disciplined agile delivery
- Dynamic system development method (DSDM)
- Extreme programming (XP)
- Feature-based development (FDD)
- Software development is lean
- Kanban
- Rapid app development (RAD)
- Scrum
- Scrumban
Practice of agile software development
The development of agile software is supported by a number of concrete practices, covering areas such as requirements, design, modeling, coding, testing, planning, risk management, process, quality, etc. Some well-known software development practices include:
- Development based on acceptance test (ATDD)
- Agile modeling
- The agile test
- Backlog (Products and Sprint)
- Behavior-based development (BDD)
- Business analyst designer (BADM) method
- Continuous integration (CI)
- Cross-functional team
- Domain-based design (DDD)
- Information radiator (scrum board, task board, visual management board, burndown chart)
- Repetitive and gradual development (IID)
- Low code development platform
- Pair programming
- Plan poker
- Refactoring
- Retrospective
- Scrum events (sprint planning, daily scrum, sprint and retrospective reviews)
- Story-based modeling
- Test-driven development (TDD)
- Timeboxing
- The user story
- User story mapping
- Speed ​​tracking
The Agile Alliance has provided a comprehensive online guide for implementing this and other practices.
Sewing method
In the literature, different terms refer to the idea of ​​adaptation methods, including 'sewing methods', 'fragment adaptation methods' and 'situational method engineering'. The sewing method is defined as:
A process or capability in which a human agent defines a system development approach for a given project situation through responsive change in, and a dynamic intermediate between context, intent, and method fragments.
Compatibility situations should be considered as distinguishing characteristics between agile methods and more well-planned software development methods, with agile methods that allow the product development team to tailor the work practices according to the needs of each product. Potentially, most nimble methods can be suitable for sewing methods, such as DSDM designed in CMM context. and XP is customized with the Rules of Practice technique (RDP). Not all agile supporters agree, however, with Schwaber noting "that's how we got into trouble in the first place, thinking that the problem does not have a perfect methodology." [Efforts should] focus on change [required] in the company ". Bas Vodde reinforces this point of view, suggesting that unlike traditional and large methodologies that require you to select and select elements, Scrum provides the basics above which you add additional elements to localize and contextualize their use. large scale, offshore and distributed Regulated domain
The agile software development method was initially seen as best suited for the development of non-critical products, thus excluded from use in regulated domains such as medical devices, pharmaceuticals, finance, nuclear systems, automotive, and the avionics sector, etc. However, in recent years, there have been several initiatives for adaptation of agile methods for this domain.
There are many standards that can be applied within a regulated domain, including ISO 26262, ISO 9000, ISO 9001, and ISO/IEC 15504. A number of key issues are critical in the regulated domain:
- Quality assurance (QA): A systematic and inherent quality management that supports a professionally controlled process and the reliability and reliability of the product.
- Safety and security: Formal planning and risk management to reduce security risks to users and safeguard users safely from unintentional and harmful misuse.
- Traceability: The documentation provides evidence of regulatory compliance that can be audited and facilitates tracking and investigating issues.
- Verify and Validate (V & amp; V): Embedded throughout the software development process (eg user requirements specifications, functional specifications, design specifications, code review, unit testing, integration testing, system testing).
Experience and adoption
Although agile software development methods can be used with paradigms or programming languages ​​in practice, they are initially closely related to object-oriented environments such as Smalltalk and Lisp and then Java. The early adopters of the agile method are usually small to medium teams that work on an unprecedented system with requirements that are difficult to resolve and may change as the system is being developed. This section describes common problems facing organizations as they try to adopt agile software development methods as well as techniques to measure the quality and performance of agile teams.
Measuring agility
The best agile practitioners always emphasize sound engineering principles. As a result, there are a number of best practices and tools to measure the performance of agile software and team development.
Internal ratings
Agility measurement index , among others, assesses the development of the five dimensions of product development (duration, risk, novelty, effort, and interaction). Other techniques are based on measurable goals and one study shows that speed can be used as agility metrics. There is also an agile self-assessment to determine whether a team uses agile software development practices (Nokia test, Karlskrona test, 42 test points).
Public survey
One early study reported gains in quality, productivity, and business satisfaction using agile software development methods was a survey conducted by Shine Technologies from November 2002 to January 2003.
A similar survey, State of Agile , is conducted each year starting in 2006 with thousands of participants from around the software development community. It tracks trends about the benefits of agility, lessons learned, and good practice. Each survey has reported an increasing number saying that agile software development helps them deliver software faster; enhance their ability to manage customer priority changes; and increase their productivity. Surveys also consistently show better results with agile product development methods than with classical project management. In balance, there are reports that some people feel that agile development methods are still too young to allow broad academic research on their success.
The common agile software development trap
Organizations and teams that implement agile software development often face the difficulty of transitioning from more traditional methods such as waterfall development, such as teams that have agile processes imposed on them. This is often called anti-pattern stalk or more commonly agile odor . Below are some common examples:
Lack of overall product design
The purpose of agile software development is to focus more on producing software that works and less on documentation. This is in contrast to the waterfall model where the process is often highly controlled and small changes to the system require significant revision of supporting documentation. However, this does not justify completely without analysis or design at all. Failure to pay attention to the design may cause the team to proceed quickly at first but then have significant rework needed as they try to improve the system. One of the main features of agile software development is iterative. When done correctly the designs appear as systems are developed and the similarities and opportunities for reuse are found.
Add story to current iteration
In agile software development, storytelling (similar to case description) is typically used to define requirements and iterations is a short time in which teams are committed to a specific purpose. Adding stories to an ongoing iteration will harm a good workflow. This should be added to the product backlog and prioritized for the next iteration or in rare cases, iterations can be canceled.
This does not mean that a story can not be expanded. Teams must deal with new information, which can generate additional tasks for a story. If the new information prevents the story from being completed during the iteration, then it should be taken to the next iteration. However, it should be prioritized on all remaining stories, as new information may have changed the original priorities of the story.
Lack of sponsor support
Agile software development is often implemented as a grassroots effort within the organization by software development teams that are trying to optimize their development process and ensure consistency in the software development lifecycle. With no sponsored support, teams can face the difficulties and rejection of business partners, development teams and other management. In addition, they may suffer without proper funding and resources. This increases the likelihood of failure.
Insufficient training
A survey conducted by VersionOne found respondents mentioned inadequate training as the most significant cause for lethal implementation failed. The team has fallen into the trap of assuming the agile software development process reduction compared to other methodologies such as waterfalls means that there are no actual rules for agile. software development. Agile software development is a set of specified methodologies, and training/practice is a requirement.
The role of the product owner is not populated correctly
The product owner is responsible for representing the business in development activities and is often the most demanding role.
A common mistake is to have a product owner role populated by someone from the development team. This requires the team to make its own decisions about prioritizing without any real feedback from the business. They try to resolve business issues internally or put a job on hold when they reach outside the team to get directions. This often leads to interruptions and disruptions in collaboration.
Team is out of focus
Agile software development requires teams to meet product commitments, which means they have to focus solely on the work for that product. However, team members who seem to have spare capacity are often expected to take on other jobs, which make it difficult for them to help with the work their teams have done.
Excessive preparation/planning
Teams can fall into the trap of spending too much time preparing or planning. This is a common trap for teams that are less familiar with agile software development where teams feel obliged to have full understanding and full specification of all stories. Teams must be ready to move forward only with stories where they have confidence, then during iterations continue to find and prepare jobs for the next iteration (often referred to as a refinement of the backlog or care).
Troubleshooting in daily standup
The daily standup should be a focused and timely meeting where all team members disseminate information. If troubleshooting occurs, it can often only involve certain team members and potentially not the best use of the entire team time. If during the daily standup the team starts diving into troubleshooting, it should be set aside until the sub-teams can discuss, usually as soon as the standup finishes.
Setting a task
One of the desired benefits of agile software development is to empower teams to make choices, as they are closest to the problem. In addition, they should make the choice as close as possible to the implementation, to use more timely information in the decision. If team members are assigned tasks by others or are too early in the process, the benefits of local and timely decision-making can be lost.
The assigned work also limits the team members into specific roles (e.g., team A's members must always do database work), which limits opportunities for cross-training. Team members themselves can choose to take on tasks that stretch their abilities and provide cross training opportunities.
Master scrum as a contributor
Another common trap is for scrum masters acting as contributors. Although not prohibited by the Scrum methodology, the master scrum needs to ensure they have the capacity to act in the scrum master role first and not to do development work. The role of the master scrum is to facilitate the process rather than to make the product.
Having a master scrum also multitasking can result in too many contexts to be productive. Additionally, as the master scrum is responsible for ensuring the roadblock is removed so that the team can make progress, the benefits gained by individual tasks moving forward may not exceed the deferred roadblock due to lack of capacity.
Lack of test automation
Due to the iterative nature of agile development, multiple rounds of testing are often required. Automated testing helps reduce the impact of unit repeatability, integration, and regression testing and frees developers and testers to focus on higher-value jobs.
Test automation also supports continued refactoring required by repeatable software development. Allowing developers to run tests quickly to confirm refactoring has not changed the functionality of the app can reduce the workload and increase the belief that the cleanup attempt has not introduced a new flaw.
Allowing technical debt to build
Focusing on delivering new functions could lead to an increase in technical debt. Teams should allow themselves time to repair defects and refactoring. Technical debt hampers planning ability by increasing the number of unscheduled jobs because production defects divert the team's attention from further progress.
As the system evolves, it is important for refactors because the entropy of the system naturally increases. Over time, the lack of constant care leads to increased defects and development costs.
Trying to take too much in the iteration
A common misconception is that agile software development allows continuous change, but backlog iterations are agreements about what work can be completed during the iteration. Having too much work in the process (WIP) results in inefficiencies such as context switching and queuing. The team should avoid feeling depressed to take on additional work.
Time, resources, scope and quality remain
Agile software development improves the time (iteration duration), quality, and resources ideally first (although maintaining a fixed resource may be difficult if the developer is often away from the task of handling production incidents), while the scope remains variable. The customer or product owner often encourages a fixed scope for an iteration. However, teams should be reluctant to commit to locked time, resources and scope (commonly known as project management triangle). Attempts to add scope to a fixed time and agile software development resources can lead to quality degradation.
Developer burner
Due to the speed of focus and the sustainable nature of the nimble practice, there is a high risk of fatigue among members of the delivery team.
Agile Management
The term agile management is applied to iterative, incremental methods of managing design and building engineering, information technology, and other business activities aimed at providing highly flexible and interactive development of new products or services. way, based on the principles expressed in the Manifesto for Agile Software Development .
Agile X techniques can also be called extreme project management. This is a variant of the repetitive life cycle in which items are delivered gradually. The main difference between agile and iterative development is that the agile method completes a fraction of the deliverables in each delivery cycle (iteration), while the iterative method develops the entire deliverable circuit over time, completing it near the end of the project. The iterative and nimble method was developed in response to the various obstacles that developed in the form of more successive project organizations. For example, as technology projects grow in complexity, end users tend to have difficulty defining long-term requirements without being able to see progressive prototypes. Evolving projects within the iteration can continually collect feedback to help refine these requirements.
Agile management also offers a simple framework that promotes communication and reflection on past work among team members. Teams that use traditional waterfall planning and adopt agile development methods usually go through the transformation phase and often take help from agile trainers who help guide the team through a seamless transformation. There are usually two agile coaching styles: agile, push-based and tensile-based agile training. The agile management approach has also been used and adapted to the business and government sectors. For example, in the United States federal government, the United States Agency for International Development (USAID) uses a collaborative project management approach that focuses on combining collaborative, learning and adaptation (CLA) strategies to replicate and customize programming.
The agile methods are mentioned in the Guide for the Project Management Body of Knowledge ( PMBOK's Guide ) under the Project Life Cycle definition:
Adaptive project life cycle , the project life cycle, also known as a change-driven or nimble method, is intended to facilitate change and requires a sustainable level of stakeholder engagement. The adaptive life cycle is also repetitive and incremental, but differs in very fast iterations (usually 2-4 weeks duration) and remains in time and resources.
Apps outside of software development
According to Jean-Loup Richet (Research Fellow at ESSEC Institute for Strategic Innovation & Services) "this approach can be effectively utilized for non-software products and for general project management, especially in areas of innovation and uncertainty." The end result is the product or project that best suits the needs of the current customer and is delivered with minimal cost, waste, and time, allowing the company to achieve basic profits earlier than through a traditional approach.
Agile software development methods have been widely used for software product development and some of them use certain characteristics of software, such as object technology. However, this technique can be applied to the development of non-software products, such as computers, motor vehicles, medical equipment, food, clothing, and music; see Flexible product development. Agile software development methods have been used in infrastructure development and non-development IT migration. Some of the broader principles of agile software development have also found applications in general management (eg, strategy, governance, risk, finance) under the requirements of business agility or lively business management.
Under a vivacious business management model, software engineering techniques, practices, principles and values ​​are agile in five domains.
- Integrated customer engagement: to inculcate customers in every shipping process to share accountability for product/service delivery.
- Facilitation-based management: adopts agile management models, such as the role of Scrum Master, to facilitate day-to-day team operations.
- Agile work practices: adopt specific iterative and incremental work practices such as Scrum, Kanban, test-based development or feature-based development across all business functions (from sales, human resources, finance and marketing).
- Possible organizational structure: focusing on staff engagement, personal autonomy, and results-based governance.
- Agile application processes (along with DevOps and lean manufacturing), to data analytics, business intelligence, large data, and data science are called DataOps
Agile software development paradigm can be used in other areas of life such as raising children. Its success in child development may be based on some basic management principles; communication, adaptation, and awareness. In TED Talk, Bruce Feiler shared how he applied the basic agile paradigm to housekeeping management and raising children.
Criticism
Agile practices can be inefficient in large organizations and certain types of development. Many organizations believe that agile software development methodologies are too extreme and adopt a Hybrid approach that mixes agile software development elements and plan-driven approaches. Some methods, such as dynamic system development methods (DSDM) try this in a disciplined way, without sacrificing basic principles.
Increased application of agile practices has also been criticized as a management mode that only describes good practices that exist under new jargon, promotes a one-size-fits-all mindset toward all development strategies, and incorrectly emphasizes the above method results.
Alistair Cockburn hosted the 10th anniversary of the Manifesto for Agile Software Development in Snowbird, Utah on February 12, 2011, gathering about 30 people who have been involved in the original meeting and since then. A list of about 20 elephants indoors ('unattractive' agile topics/issues) was gathered, including aspects: alliances, failures and limitations of practice and the context of agile software development (possible causes: commercial interests, decontextualization, there is no clear way to make progress based on failure, limited objective evidence, cognitive bias and misconceptions, politics and culture.As Philippe Kruchten writes:
Source of the article : Wikipedia
0 Comments