Presentation on agile methodology

Click here to load reader

download Presentation on agile methodology

of 12

  • date post

    04-Dec-2014
  • Category

    Documents

  • view

    249
  • download

    4

Embed Size (px)

description

 

Transcript of Presentation on agile methodology

  • 1. AGILE METHODOLOGY By : Ashish Jain
  • 2. WHAT IS AGILE.Agile software development is a group of softwaredevelopment methods based on iterative andincremental development, where requirements andsolutions evolve through collaboration between self-organizing, cross-functional teams. It promotesadaptive planning, evolutionary development anddelivery, a time-boxed iterative approach, andencourages rapid and flexible response to change. It isa conceptual framework that promotes foreseeninteractions throughout the development cycle.
  • 3. 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.
  • 4. DAILY SCRUMOn each day of a sprint, the team holds daily meetings ("the daily scrum). Meetings are typicallyheld in the same location and at the same time each day. Ideally, the daily scrum meeting is heldin the morning, as it helps set the context for the coming days work. These Scrum daily standupmeetings 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 areraised are taken offline and usually dealt with by the relevant sub-group immediately after themeeting. 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?
  • 5. PRODUCT BACKLOGThe agile product backlog is a prioritized features list, containing short descriptions of allfunctionality desired in the product. When using Scrum, it is not necessary to start a projectwith a lengthy, upfront effort to document all requirements. Typically, a Scrum team and itsproduct owner begin by writing down everything they can think of for agile backlogprioritization. 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 aboutthe product and its customers.A typical Scrum backlog comprises the following different types of items: Features Bugs Technical work Knowledge acquisition
  • 6. SPRINT BACKLOGThe sprint backlog is a simple list of the tasks that must be executed by the team in order todeliver 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 theparticipation of every team member. Giving some real attention to this process is fundamentalto a better understanding by the team about what should be done and to better planningduring the sprint. Despite this, many teams still struggle with this activity.
  • 7. SPRINT PLANNING Involve every team member in the process. It cant 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 s everal different perspectives about the story. This generates a much richer Sprint Backlog than if only coders or a technical guru were involv ed. Discuss how every item should be implemented. Before any tasks are written on post-its its 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 unde rstanding how the team is going to tackle the stories. This discussion will involve creating basic designs, checking existing code, discussing architec tural 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 t he 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 del ivering working software and going through those tasks, the team will gain a new understanding of the real effort the next sprint will require. Dont 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 item s 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 t he 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. Dont 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 alt ernatives. 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 somethi ng they have a good understanding about. Dont 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 e verything that should be done during the sprint, but thats 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 tas ks 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.
  • 8. FUNCTIONAL REVIEWSThe System Functional Review (SFR) is a technical review to ensure that the systems functional baseline is established and c ansatisfying the requirements of the Initial Capabilities Document (ICD) or draft Capability Development Document (CDD) within thecurrently allocated budget and schedule. It also determines whether the systems lower -level performance requirements are fullydefined and consistent with the system concept and whether lower-level systems requirements trace to top-level systemperformance 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. Systemperformance 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