12
By : Ashish Jain AGILE METHODOLOGY

Presentation on agile methodology

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Presentation on agile methodology

By : Ashish Jain

AGILE METHODOLOGY

Page 2: Presentation on agile methodology

WHAT IS AGILE.

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

Page 3: Presentation on agile methodology

ADVANTAGES OF AGILE• Agile helps to speed up the SDLC phases and bypasses process steps that add little value to the

project.

• Usually Agile methodologies promote less formal culture and encourage collaborative team approach.

• Agile facilitates smooth flow of knowledge sharing.

• Engages the stakeholders continuously so that the new requirements are gathered faster and there is no scope for guess work by the teams.

• It incorporates frequent and rapid changes into the SDLC for product functionality and features.

• Saves cost, time and efforts by following iterative incremental work delivery and thereby identifying deviations early.

• Redistributes leadership at various levels within the teams.

• Increases cohesion between the teams to deliver on time.

• Follows crisp and flexible documentation policies which save time.

• Provides the end result of higher quality of the software delivered and a highly satisfied customer.

Page 4: Presentation on agile methodology

DAILY SCRUM

On each day of a sprint, the team holds daily meetings ("the daily scrum”). Meetings are typically held in the same location and at the same time each day. Ideally, the daily scrum meeting is held in the morning, as it helps set the context for the coming day's work. These Scrum daily standup meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant.

The Scrum meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant sub-group immediately after the meeting. During the daily Scrum, each team member answers the following three questions:

• What did you do yesterday?• What will you do today?• Are there any impediments in your way?

Page 5: Presentation on agile methodology

PRODUCT BACKLOG

The agile product backlog is a prioritized features list, containing short descriptions of all functionality desired in the product. When using Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers.

A typical Scrum backlog comprises the following different types of items:

• Features

• Bugs

• Technical work

• Knowledge acquisition

Page 6: Presentation on agile methodology

SPRINT BACKLOGThe sprint backlog is a simple list of the tasks that must be executed by the team in order to deliver an increment of functional software at the end of that sprint.

Sprint backlog creation happens in the second part of the sprint planning meeting with the participation of every team member. Giving some real attention to this process is fundamental to a better understanding by the team about what should be done and to better planning during the sprint. Despite this, many teams still struggle with this activity.

Page 7: Presentation on agile methodology

SPRINT PLANNING• Involve every team member in the process. It can’t be said enough: the involvement of every team member in the process of sprint backlog discovery is essential. On a multi-

disciplinary team, everyone can contribute to task creation, enabling the team to draw from several different perspectives about the story. This generates a much richer Sprint Backlog than if only coders or a technical guru were involved.

• Discuss how every item should be implemented. Before any tasks are written on post-its it's necessary for the team to spend some time discussing every story that will be brought into the sprint. In fact, the majority of the meeting should be dedicated to understanding how the team is going to tackle the stories. This discussion will involve creating basic designs, checking existing code, discussing architectural possibilities, and so on. Having a shared understanding about the story and the possible solutions will enable the team to create a task list that truly expresses the work to be done.

• Have a definition of done. Having a common definition of done in place, available and visible to everyone is extremely important. This definition will serve as a guide to what should be done and will remind the team what the general acceptance criteria are for every item in the backlog.

• Identify all kinds of tasks. Too many teams focus on coding tasks. The truth is, though, that coding is not enough to deliver real working software. The sprint backlog should include every kind of task: object modeling, coding, learning a new technology, database activities, tests, and so on. Having a posted definition of done will help to remind teams of the tasks they are forgetting. By listing every aspect of delivering working software and going through those tasks, the team will gain a new understanding of the real effort the next sprint will require.

• Don't estimate tasks at all. This is a sensitive one. Estimating tasks in hours is popular and may be necessary when a team if first starting out. In the end, though, we can drop this without losing much. The team commitment to the sprint should be done with the backlog items in mind, not the tasks. After all, if we estimate that a task will take 4 hours but it actually takes 12 hours, as long as the team achieves the sprint goal, what difference does it make? Identifying as many tasks as possible and creating a sense of constant progress during the sprint should be enough.

• Don't assign tasks up front. Resist the temptation to direct work; the team should decide who is going to do what according to the circumstances. If you start to assign tasks to the “most suitable” team member, it will prevent the rest of the team from learning new things, block communication, and decrease collaboration. Empower and trust the team to manage themselves.

• Review the sprint commitment. After task identification, when the team has a much better understanding about the real effort that is needed, the sprint commitment should be reanalyzed. Does the selected sprint backlog really fit in the sprint? If not, there are some alternatives. Drop the item with the lowest priority or split stories into smaller pieces. What matters in the end is that the team can commit to something they have a good understanding about.

• Don't use too much time. Respect the time box. Define a meeting duration and stick to it. Timeboxing forces the team to concentrate and intensively discuss the items, making it much more likely that the tasks will be uncovered. The team cannot always identify everything that should be done during the sprint, but that's not a problem. It is much more important for them to gain a thorough understanding of the stories they are bringing into the sprint.

• Evolve the Sprint Backlog during the sprint. The team will understand more about the stories as they work on them. New ideas may arise and old ideas may be dropped. The Sprint Backlog should reflect these changes. The Daily Scrum is an excellent time to create new tasks and lose unnecessary ones.

• If the team invests the time and effort to build a good sprint backlog it will be rewarded with a much better overall understanding of the work to be done, a sense of progress on a daily basis, and a clear commitment to what will be delivered. It may not be easy, but it will be worth all the hard work.

Page 8: Presentation on agile methodology

FUNCTIONAL REVIEWSThe System Functional Review (SFR) is a technical review to ensure that the system's functional baseline is established and can satisfying the requirements of the Initial Capabilities Document (ICD) or draft Capability Development Document (CDD) within the currently allocated budget and schedule. It also determines whether the system's lower-level performance requirements are fully defined and consistent with the system concept and whether lower-level systems requirements trace to top-level system performance requirements. The SFR is conducted during the Development Phase of a program.

A critical component of an SFR review is the development of representative operational use cases for the system. System performance and the anticipated functional requirements for operations maintenance, and sustainment are assigned to sub-systems, hardware, software, or support after detailed analysis of the architecture and the environment in which it will be employed. The SFR determines whether the system's functional definition is fully decomposed to its lower level.

The system's lower-level performance requirements are evaluated to determine whether they are fully defined and consistent with the system concept, and whether traceability of lower-level systems requirements to top-level system performance and the CDD is maintained. This activity results in two major systems engineering products: the final version of the system performance specification and draft version of the performance specifications, which describe the items below system level (item performance specifications).

Completion of the SFR should provide the following:An established system functional baseline with traceability to lower-level performance requirements,

• An updated risk assessment for the Development Phase

• An updated program development schedule including system and software critical path drivers, and

• A preliminary system level maintenance plan with updates applicable to this phase.

Page 9: Presentation on agile methodology

CONTINUOUS INTEGRATION• According to Martin Fowler, continuous integration is a software development practice

that requires team members to integrate their work frequently. Every person integrates at least daily, which leads to multiple integrations each day. Integrations are verified by an automated build that runs regression tests to detect integration errors as quickly as possible. Teams find that this approach leads to significantly fewer integration problems and enables development of cohesive software more rapidly.

Page 10: Presentation on agile methodology

POTENTIALLY SHIPPABLE PRODUCTA potentially shippable product is one that has been designed, developed and tested and is therefore ready for distribution to anyone in the company for review or even to any external stakeholder. Adhering to a list of “done” criteria ensures that the sprint product is truly shippable.

The agile community differs in their opinion of what is shippable and what is potentially shippable. Many agile practitioners believe that potentially shippable is just one sprint away from the release. Others believe that potentially shippable means just that, ready to go to the customer immediately following the sprint.

For the sake of building a reference, done in this presentation means that the features developed in each sprint should be 100 percent complete, whatever that means for your particular circumstances.

Page 11: Presentation on agile methodology

SHOW & TELL AND REFLECTIONThe sprint review is held at the end of every sprint. This where the team demonstrate the next increment of the product to be delivered. The meeting is intentionally kept short and informal as the formalized part of the review will have already taken place. The way in which the meeting works best is to run the sprint review as a product demo where the new features that have been added during this iteration are presented to the audience.The real purpose of the sprint review …

• It offers the attendees the chance to understand and see for themselves the progress that has been made on the product. It might be necessary for the Product Owner to discuss where this fits into the overall scope of the product delivery in the introduction at the start of the meeting.

• The sprint review offers the team a chance to bring closure to their work for the duration of the sprint. The items or features that are demonstrated are considered to be closed and thus any outstanding requirements or other associated documentation is considered to also be closed. This gives the team an opportunity to celebrate their success on meeting their goals and it is an opportunity for any senior management present to recognize and affirm the efforts of the team. This is why I said earlier that it is important for all team members to be present; everyone needs to feel that sense of closure and completeness for the work carried out in the previous iteration. Equally so, everyone deserves to share in the recognition of the work done to date.

What a sprint review is not …

• It is not a meeting designed to criticies or for the team to take further actions for improvement to the product. It should be noted that this meeting is an informational meeting that raises awareness of the goals achieved thus far These are channeled through the product owner in the subsequent requirements gathering phase. Therefore it is not a Go – No-Go meeting. If the product is not considered fit for purpose before the review then my advise is to cancel the sprint review; the product owner can inform the necessary stakeholders as to why the product was considered to not meet the teams definition of done.

• It is not a document review meeting. Documents are often a necessary output from the product development process. If a document has been created it should be quality assured before the meeting and the smallest of introductions to identify where the document is stored and that it has been formally signed off according to the previously agreed definition of done.

Page 12: Presentation on agile methodology

Thank You