This lesson covers Agile Methodology from TutorialsPoint
Agile is a software development methodology to build a software incrementally using short iterations of 1 to 4 weeks so that the development process is aligned with the changing business needs.
Instead of a single-pass development of 6 to 18 months where all the requirements and risks are predicted upfront, Agile adopts a process of frequent feedback where a workable product is delivered after 1 to 4 week iteration.
Roles in Agile
- A Scrum Master is a team leader and facilitator who helps the team members to follow agile practices so that they can meet their commitments. The responsibilities of a scrum master are as follows −
- To enable close co-operation between all roles and functions.
- To remove any blocks.
- To shield the team from any disturbances.
- To work with the organization to track the progress and processes of the company.
- To ensure that Agile Inspect & Adapt processes are leveraged properly which includes
- Daily stand-ups,
- Planned meetings,
- Retrospective Meetings, and
- To facilitate team meetings and decision-making process.
- A Product Owner is the one who drives the product from business perspective. The responsibilities or a Product Owner are as follows −
- To define the requirements and prioritize their values.
- To determine the release date and contents.
- To take an active role in iteration planning and release planning meetings.
- To ensure that team is working on the most valued requirement.
- To represent the voice of the customer.
- To accept the user stories that meet the definition of done and defined acceptance criteria.
- Every agile team should be a self-sufficient team with 5 to 9 team members and an average experience ranging from of 6 to 10 years.
- Typically, an agile team comprises of
- 3 to 4 developers,
- 1 tester,
- 1 technical lead,
- 1 product owner and
- 1 scrum master
- Product Owner and Scrum master are considered to be a part of Team Interface, whereas other members are part of Technical Interface.
How an Agile Team Plans its Work?
- An Agile team works in iterations to deliver user stories where each iteration is of 10 to 15 days.
- Each user story is planned based on its backlog prioritization and size.
- The team uses its capacity − how many hours are available with team to work on tasks − to decide how much scope they have to plan.
- A Point defines how much a team can commit. A point usually refers to 8 hours.
- Each story is estimated in points.
- Capacity defines how much an individual can commit.
- Capacity is estimated in hours.
What is a User Story?
- A user story is a requirement which defines what is required by the user as functionality.
- A user story can be in two forms −
- As a
I want so that
- In order to
as a I want
- As a
- During release planning, a rough estimate is given to a user story using relative scale as points.
- During iteration planning, the story is broken down into tasks.
Relationship of User Stories and Tasks
- User story talks about what is to be done. It defines what a user needs.
- Task talks about how it is to be done. It defines how a functionality is to be implemented.
- Stories are implemented by tasks. Each story is a collection of tasks.
- User story is divided into tasks when it is planned in current iteration.
- Tasks are estimated in hours, typically from 2 to 12 hours.
- Stories are validated using acceptance tests.
When a Story is Done
The team decides what done means. The criteria may be −
All tasks (development, testing) are completed.
All acceptance tests are running and are passed.
No defect is open.
Product owner has accepted the story.
Deliverable to the end-user.
What is Acceptance Criteria?
- Criteria defines the functionality, behavior, and performance required by a feature so that it can be accepted by the product owner.
- It defines what is to be done so that the developer knows when a user story is complete.
How the Requirements are Defined?
- Requirements are defined as
- A User Story,
- With Acceptance Criteria, and
- Tasks to implement the story.
In February 2001, at the Snowbird resort in Utah, 17 software developers met to discuss lightweight development methods. The outcome of their meeting was the following Agile Manifesto for software development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value −
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Twelve Principles of Agile Manifesto
- Customer Satisfaction − Highest priority is given to satisfy the requirements of customers through early and continuous delivery of valuable software.
- Welcome Change − Changes are inevitable during software development. Ever-changing requirements should be welcome, even late in the development phase. Agile processes should work to increase customers’ competitive advantage.
- Deliver a Working Software − Deliver a working software frequently, ranging from a few weeks to a few months, considering shorter time-scale.
- Collaboration − Business people and developers must work together during the entire life of a project.
- Motivation − Projects should be built around motivated individuals. Provide an environment to support individual team members and trust them so as to make them feel responsible to get the job done.
- Face-to-face Conversation − Face-to-face conversation is the most efficient and effective method of conveying information to and within a development team.
- Measure the Progress as per the Working Software − Working software is the key and it should be the primary measure of progress.
- Maintain Constant Pace − Agile processes aim towards sustainable development. The business, the developers, and the users should be able to maintain a constant pace with the project.
- Monitoring − Pay regular attention to technical excellence and good design to enhance agility.
- Simplicity − Keep things simple and use simple terms to measure the work that is not completed.
- Self-organized Teams − An agile team should be self-organized and should not depend heavily on other teams because the best architectures, requirements, and designs emerge from self-organized teams.
- Review the Work Regularly − Review the work done at regular intervals so that the team can reflect on how to become more effective and adjust its behavior accordingly.
Agile - Characteristics
Iterative/incremental and Ready to Evolve
- Most of the agile development methods break a problem into smaller tasks.
- There is no direct long-term planning for any requirement.
- Normally, iterations are planned which are of vary short period of time, for example, 1 to 4 weeks.
- A cross-functional team is created for each iteration that works in all functions of software development like planning, requirements analysis, design, coding, unit testing, and acceptance testing.
- The result at the end of the iteration is a working product and it is demonstrated to the stakeholders at the end of an iteration.
- After demo, review comments are taken and are planned to be incorporated in the working software as required.
- Each agile team should have a customer representative such as a product owner in scrum methodology.
- This representative is authorized to act on behalf of the stakeholders and he can answer the queries of the developers in between iterations.
- An information radiator (physical display) is normally located prominently in an office, where passers-by can see the progress of the agile team.
- This information radiator shows an up-to-date summary of the status of a project.
- Daily stand-up is a common culture of any agile development; it is also known as daily scrum.
- It is a kind of a brief session where each team member reports to each other regarding the status of what they have done, what to do next, and any issues they are facing.