Scrum -Abhijit Mahajan -Neelam Agrawal an agile - PowerPoint PPT Presentation

ì ¡ Scrum ¡ -­‑Abhijit ¡Mahajan ¡ ¡ -­‑Neelam ¡Agrawal ¡ an ¡agile ¡development ¡process ¡methodology ¡ ¡

Introduction ¡ ì Scrum ¡is ¡an ¡agile ¡so<ware ¡development ¡methodology ¡ ì It ¡is ¡an ¡itera>ve ¡and ¡incremental ¡methodology ¡ ¡ for ¡so<ware ¡projects ¡and ¡product-­‑ ¡or ¡applica>on-­‑ ì development ¡ ì Projects ¡progress ¡via ¡a ¡series ¡of ¡itera>ons ¡ ¡ called ¡sprints ¡ ¡ ì ì which ¡are ¡usually ¡2-­‑4 ¡weeks ¡long ¡ ì A ¡typical ¡scrum ¡team ¡has ¡between ¡five ¡and ¡nine ¡people ¡ ¡ but ¡Scrum ¡projects ¡can ¡easily ¡scale ¡into ¡the ¡hundreds ¡ ì

History ¡

History ¡ 1993-­‑Jeff ¡Sutherland, ¡John ¡Scumniotales ¡and ¡Jeff ¡McKenna, ¡ ì came ¡up ¡with ¡an ¡approach ¡at ¡Easel ¡Corpora>on ¡ first ¡to ¡refer ¡it ¡using ¡the ¡single ¡word ¡ Scrum . ¡ ì In ¡1996, ¡Sutherland ¡and ¡Schwaber ¡jointly ¡presented ¡a ¡paper ¡ ì describing ¡the ¡ Scrum ¡method ¡at ¡the ¡Business ¡Object ¡Design ¡ and ¡Implementa>on ¡Workshop ¡ ¡ held ¡as ¡part ¡of ¡OOPSLA ¡’95 ¡in ¡Aus>n, ¡Texas. ¡ ì 1998-­‑ ¡Ken, ¡Jeff, ¡et ¡al ¡came ¡up ¡with ¡“Scrum ¡a ¡pa[ern ¡language ¡ ì for ¡hyperproduc>ve ¡so<ware ¡development” ¡ In ¡2001, ¡Schwaber ¡worked ¡with ¡Mike ¡Beedle ¡to ¡describe ¡the ¡ ì method ¡in ¡the ¡book ¡ Agile ¡with ¡Scrum ¡

SCRUM ¡Methodology ¡

Scrum ¡& ¡Rugby ¡ ì The ¡SCRUM ¡methodology ¡shares ¡many ¡characteris>cs ¡ with ¡the ¡sport ¡of ¡Rugby ¡: ¡ The ¡context ¡is ¡set ¡by ¡ ¡ ì ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡playing ¡field ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡(environment) ¡and ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡rugby ¡rules ¡(controls). ¡ The ¡primary ¡cycle ¡is ¡moving ¡the ¡ball ¡forward. ¡ ì Rugby ¡evolved ¡from ¡breaking ¡soccer ¡rules ¡-­‑ ¡adap>ng ¡to ¡ ì the ¡environment. ¡ The ¡game ¡does ¡not ¡end ¡un>l ¡environment ¡dictates ¡ ì (business ¡need, ¡compe>>on, ¡func>onality, ¡>metable). ¡

Scrum ¡phase ¡list ¡ ì Pregame ¡ Planning ¡ ì System ¡Architecture/High ¡Level ¡Design ¡ ì ì Game ¡ Sprints ¡(Concurrent ¡Engineering) ¡ ì Develop ¡(Analysis,Design,Develop) ¡ ì Wrap ¡ ì Review ¡ ì Adjust ¡ ì ì Postgame ¡ Closure ¡ ì

SCRUM ¡Phases ¡(1) ¡ ì Pregame ¡ Planning ¡: ¡ ¡ ì ì Defini>on ¡of ¡a ¡new ¡release ¡based ¡on ¡currently ¡known ¡ backlog, ¡along ¡with ¡an ¡es>mate ¡of ¡its ¡schedule ¡and ¡cost. ¡ ¡ ì If ¡a ¡new ¡system ¡is ¡being ¡developed, ¡this ¡phase ¡consists ¡of ¡ both ¡conceptualiza>on ¡and ¡analysis. ¡ ¡ ì If ¡an ¡exis>ng ¡system ¡is ¡being ¡enhanced, ¡this ¡phase ¡ consists ¡of ¡limited ¡analysis. ¡ Architecture ¡: ¡ ¡ ì ì Design ¡how ¡the ¡backlog ¡items ¡will ¡be ¡implemented. ¡ ¡ ì This ¡phase ¡includes ¡system ¡architecture ¡modifica>on ¡and ¡ high ¡level ¡design. ¡

SCRUM ¡Phases ¡(2) ¡ ì Game ¡ Development ¡Sprints ¡: ¡ ¡ ì ì Development ¡of ¡new ¡release ¡func>onality, ¡with ¡constant ¡ respect ¡to ¡the ¡variables ¡of ¡>me, ¡requirements, ¡quality, ¡ cost, ¡and ¡compe>>on. ¡ ì Interac>on ¡with ¡these ¡variables ¡defines ¡the ¡end ¡of ¡this ¡ phase. ¡ ¡ ì There ¡are ¡mul>ple, ¡itera>ve ¡development ¡sprints, ¡or ¡ cycles, ¡that ¡are ¡used ¡to ¡evolve ¡the ¡system. ¡ ì Postgame ¡ Closure ¡: ¡ ¡ ì ì Prepara>on ¡for ¡release, ¡including ¡final ¡documenta>on, ¡ pre-­‑release ¡staged ¡tes>ng, ¡and ¡release. ¡

Planning ¡(1) ¡ ì Development ¡of ¡a ¡comprehensive ¡backlog ¡list. ¡ ì Defini>on ¡of ¡the ¡delivery ¡date ¡and ¡func>onality ¡of ¡one ¡ or ¡more ¡releases. ¡ ì Selec>on ¡of ¡the ¡release ¡most ¡appropriate ¡for ¡immediate ¡ development. ¡ ì Mapping ¡of ¡product ¡packets ¡(objects) ¡for ¡backlog ¡items ¡ in ¡the ¡selected ¡release. ¡ ì Defini>on ¡of ¡project ¡team(s) ¡for ¡the ¡building ¡of ¡the ¡new ¡ release. ¡

Planning ¡(2) ¡ ì Assessment ¡of ¡risk ¡and ¡appropriate ¡risk ¡controls. ¡ ì Review ¡and ¡possible ¡adjustment ¡of ¡backlog ¡items ¡ and ¡packets. ¡ ì Valida>on ¡or ¡reselec>on ¡of ¡development ¡tools ¡and ¡ infrastructure. ¡ ì Es>ma>on ¡of ¡release ¡cost, ¡including ¡development, ¡ collateral ¡material, ¡marke>ng, ¡training, ¡and ¡rollout. ¡ ì Verifica>on ¡of ¡management ¡approval ¡and ¡funding. ¡

Architecture/High ¡Level ¡Design ¡(1) ¡ ì Review ¡assigned ¡backlog ¡items. ¡ ì Iden>fy ¡changes ¡necessary ¡to ¡implement ¡backlog ¡ items. ¡ ì Perform ¡domain ¡analysis ¡to ¡the ¡extent ¡required ¡to ¡ build, ¡enhance, ¡or ¡update ¡the ¡domain ¡models ¡to ¡ reflect ¡the ¡new ¡system ¡context ¡and ¡requirements. ¡ ì Refine ¡the ¡system ¡architecture ¡to ¡support ¡the ¡new ¡ context ¡and ¡requirements. ¡

Architecture/High ¡Level ¡Design ¡(2) ¡ ì Iden>fy ¡any ¡problems ¡or ¡issues ¡in ¡developing ¡or ¡ implemen>ng ¡the ¡changes ¡ ì Design ¡review ¡mee>ng, ¡each ¡team ¡presen>ng ¡ approach ¡and ¡changes ¡to ¡implement ¡each ¡backlog ¡ item. ¡ ¡ ì Reassign ¡changes ¡as ¡required. ¡

Sprint ¡(1) ¡ ì A ¡sprint ¡is ¡the ¡basic ¡unit ¡in ¡Scrum ¡ lasts ¡between ¡one ¡week ¡and ¡one ¡month ¡ ì ì Each ¡sprint ¡is ¡preceded ¡by ¡a ¡mee>ng ¡ where ¡the ¡tasks ¡for ¡the ¡sprint ¡are ¡ini>ated ¡for ¡the ¡sprint ¡ ì goal ¡ ì The ¡work ¡items ¡come ¡from ¡the ¡product ¡ backlog ¡ which ¡is ¡a ¡priori>zed ¡list ¡of ¡requirements ¡ ì ì During ¡the ¡sprint ¡planning ¡mee>ng, ¡the ¡Product ¡Owner ¡ informs ¡the ¡group ¡of ¡the ¡items ¡in ¡the ¡product ¡backlog ¡ that ¡needs ¡to ¡be ¡completed ¡ ¡ the ¡ones ¡with ¡the ¡highest ¡priority ¡ ¡ ì

Sprint ¡(2) ¡ ì The ¡group ¡then ¡determines ¡how ¡much ¡of ¡this ¡they ¡ can ¡commit ¡to ¡complete ¡during ¡the ¡next ¡sprint ¡ ì ¡and ¡records ¡this ¡in ¡the ¡sprint ¡backlog ¡ ì During ¡a ¡sprint, ¡no ¡one ¡is ¡allowed ¡to ¡change ¡the ¡ sprint ¡backlog ¡ ì ¡which ¡means ¡that ¡the ¡requirements ¡are ¡frozen ¡for ¡ that ¡sprint ¡ ì ¡if ¡requirements ¡are ¡not ¡completed ¡for ¡any ¡reason ¡ they ¡are ¡le< ¡out ¡and ¡returned ¡to ¡the ¡product ¡ backlog ¡

More ¡Game ¡phase(1) ¡ ì Develop: ¡ ¡ ì Defining ¡changes ¡needed ¡for ¡ ¡ ì the ¡implementa>on ¡of ¡backlog ¡requirements ¡into ¡packets, ¡ opening ¡the ¡packets, ¡performing ¡domain ¡analysis ¡ ì designing, ¡developing, ¡implemen>ng, ¡tes>ng, ¡and ¡ documen>ng ¡the ¡changes. ¡ ¡ ì Development ¡consists ¡of ¡the ¡micro ¡process ¡of ¡discovery, ¡ inven>on, ¡and ¡implementa>on. ¡ ì Wrap: ¡ ¡ ì Closing ¡the ¡packets, ¡crea>ng ¡an ¡executable ¡version ¡of ¡ changes ¡and ¡how ¡they ¡implement ¡backlog ¡ requirements. ¡