The document discusses Agile software development processes. It describes the four key values and 12 principles of the Agile Manifesto. It then discusses what "agility" means and how it relates to responding effectively to change. It provides an overview of the Scrum framework, describing its distinguishing features like sprints, backlogs, daily stand-up meetings, and demos.
The document discusses Agile software development processes. It describes the four key values and 12 principles of the Agile Manifesto. It then discusses what "agility" means and how it relates to responding effectively to change. It provides an overview of the Scrum framework, describing its distinguishing features like sprints, backlogs, daily stand-up meetings, and demos.
Sanjida Nasreen Tumpa, Lecturer, Dept of CSE, MIST 4 key values 12 principles The Manifesto for Agile 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 4 key •Customer collaboration over contract values 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.” Kent Beck et al (2001) What is ―Agility‖? Effective (rapid and adaptive) response to change Effective communication among all stakeholders Drawing the customer onto the team Organizing a team so that it is in control of the work performed Yielding … Rapid, incremental delivery of software Agility and the Cost of Change Scrum Originally proposed by Schwaber and Beedle Scrum—distinguishing features Development work is partitioned into ―packets‖
Testing and documentation are on-going as the
product is constructed
Work occurs in ―sprints‖ and is derived from a
―backlog‖ of existing requirements
Meetings are very short and sometimes conducted
without chairs
―demos‖ are delivered to the customer with the time-
box allocated Scrum Originally proposed by Schwaber and Beedle Scrum—distinguishing features Development work is partitioned into ―packets‖
Testing and documentation are on-going as the
product is constructed
Work occurs in ―sprints‖ and is derived from a
―backlog‖ of existing requirements
Meetings are very short and sometimes conducted
without chairs
―demos‖ are delivered to the customer with the time-
box allocated Scrum Scrum Incorporates the following framework activities: requirements, analysis, design, evolution, and delivery. Scrum emphasizes the use of a set of software process patterns. Each of these process patterns defines a set of development actions: Backlog Sprint Scrum Master Scrum Meeting Demos Scrum: Backlog Prioritized list of project requirements or features
Items can be added to the backlog at any time
(this is how changes are introduced).
The product manager assesses the backlog
and updates priorities as required. Scrum: Sprint Consist of work units that are required to achieve a requirement defined in the backlog that must be fit into a predefined time-box (typically 30 days).
Changes (e.g., backlog work items) are not
introduced during the sprint. Hence, the sprint allows team members to work in a short-term, but stable environment. Scrum: Scrum Meeting Are short (typically 15 minutes) meetings held daily by the Scrum team.
Three key questions are asked and answered
by all team members: What did you do since the last team meeting? What obstacles are you encountering? What do you plan to accomplish by the next team meeting? Scrum: Scrum Master team leader, called Scrum master, leads the meeting and assesses the responses from each person.
The Scrum meeting helps the team to uncover
potential problems as early as possible. Also, these daily meetings lead to ―knowledge socialization‖ and thereby promote a self- organizing team structure. Scrum: Demos Deliver the software increment to the customer so that functionality that has been implemented can be demonstrated and evaluated by the customer.
The demo may not contain all planned
functionality, but rather those functions that can be delivered within the time-box that was established.