Agile
Transcript: Agile Software Development The Traditional Waterfall Method Requirements Architecture Development Test Repeat Where it goes wrong? Customer is only represented in the requirements All requirements must be pre-determined and disconnects may occur if not clear How Agile Works Works Agile is "adaptive" in nature to allow adapting quickly to changes in scope Terms include: sprint, scrum, and backlog Sprint: Time restricted to one week Team will commit to which features will be delivered during the sprint from the backlog Any features not completed will return to the backlog Burndown will be used to establish rate of features added vs. those completed Roles: The Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. The Team is responsible for delivering the product. A Team is typically made up of people with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.). It is recommended that the Team be self-organizing and self-led, but often work with some form of project or team management. Scrum is facilitated by a ScrumMaster who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the team leader but acts as a buffer between the team and any distracting influences. Daily Scrum: Each day during the sprint, a project status meeting occurs. This is called a daily scrum, or the daily standup. This meeting has specific guidelines: The meeting starts precisely on time. All are welcome, but normally only the core roles speak The meeting is timeboxed to 15 minutes The meeting should happen at the same location and same time every day During the meeting, each team member answers three questions:[12] What have you done since yesterday? What are you planning to do today? Do you have any problems that would prevent you from accomplishing your goal? Backlog and Burn Down Product backlog The product backlog is a high-level list that is maintained throughout the entire project. It aggregates backlog items: broad descriptions of all potential features, prioritized as an absolute ordering by business value. It is therefore the “What” that will be built, sorted by importance. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timeline and, to a limited extent prioritize. For example, if the “add spellcheck” and “add table support” features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI (Return on Investment) is higher. The Product Backlog, and business value of each listed item is the property of the product owner. The associated development effort is however set by the Team. Sprint backlog The sprint backlog is the list of work the team must address during the next sprint. Features are broken down into tasks, which, as a best practice, should normally be between four and sixteen hours of work. With this level of detail the whole team understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. This promotes self-organization of the team, and developer buy-in. The sprint backlog is the property of the team, and all included estimates are provided by the Team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”. Sprint Burndown The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. Planning and Review Sprint Planning Meeting At the beginning of the sprint cycle, a “Sprint Planning Meeting” is held. Select what work is to be done Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team Identify and communicate how much of the work is likely to be done during the current sprint Eight hour time limit (1st four hours) Product Owner + Team: dialog for prioritizing the Product Backlog (2nd four hours) Team only: hashing out a plan for the Sprint, resulting in the Sprint Backlog At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective” Sprint Review Meeting Review the work that was completed and not completed Present the completed work to the stakeholders (a.k.a. “the demo”) Incomplete work cannot be demonstrated Four hour time limit
Prezi Present
Prezi Video
Prezi Design
