1/27/15 ¡ Today’s ¡goals ¡ eXtreme ¡Programming ¡ • What ¡is ¡XP? ¡ • When ¡should ¡I ¡(not) ¡use ¡XP? ¡ • HW 2 Three phases: integra,on ¡ code ¡reviews ¡ tes,ng ¡ design ¡ simplicity ¡ – submission ( Jan 23rd ), – grade others ( Jan 29th ), – peer reviews (review the reviewer Feb 1st ) http://xkcd.com/844/ Waterfall ¡development ¡process ¡ CS361 3-3 XP way Start ¡project ¡ Break ¡into ¡ Refactor ¡ pieces ¡ Yes Yes Good Any Implement ¡ code? More? one ¡piece ¡ no CS361 3-5 1 ¡
1/27/15 ¡ SoHware ¡development ¡processes ¡ • Many ¡ways ¡to ¡develop ¡soHware ¡ • hQp://agilemanifesto.org/ ¡ – Plan-‑driven ¡/ ¡agile ¡ – Centralized ¡/ ¡distributed ¡ – High ¡math ¡/ ¡low ¡math ¡ – Close ¡interacPon ¡with ¡customers ¡/ ¡liQle ¡ interacPon ¡ – Much ¡tesPng ¡/ ¡liQle ¡tesPng ¡ – Organize ¡by ¡architecture ¡/ ¡organize ¡by ¡features ¡ eXtreme ¡Programming ¡ Roles ¡in ¡XP ¡ • Main ¡roles ¡ – Customer ¡ Kent ¡Beck ¡ – Programmer ¡ • Secondary ¡roles ¡ – Coach ¡ – Boss ¡ – Quality ¡assurance ¡ 2 ¡
1/27/15 ¡ Big ¡ideas ¡in ¡XP ¡ IteraPon ¡ • Two ¡week ¡cycle ¡ • Don’t ¡write ¡much ¡documentaPon. ¡ ¡ ¡ • Plan ¡each ¡iteraPon ¡in ¡an ¡iteraPon ¡meePng ¡ • Implement ¡features ¡one ¡by ¡one, ¡ ¡ that ¡is ¡held ¡at ¡the ¡start. ¡ • Releasing ¡working ¡code ¡frequently, ¡ ¡ • IteraPon ¡is ¡going ¡to ¡implement ¡set ¡of ¡ user ¡ • working ¡closely ¡with ¡customer. ¡ ¡ ¡ stories. ¡ • Team ¡talks ¡a ¡lot ¡with ¡each ¡other, ¡the ¡main ¡ • Divide ¡work ¡into ¡tasks ¡small ¡enough ¡to ¡finish ¡ wriQen ¡product ¡is ¡working ¡code. ¡ in ¡a ¡day. ¡ • Each ¡day, ¡programmers ¡work ¡in ¡pairs ¡to ¡finish ¡ tasks. ¡ Working ¡soHware ¡ • All ¡soHware ¡has ¡automated ¡tests ¡(unit ¡tests) ¡ • All ¡tests ¡work, ¡all ¡the ¡Pme. ¡ ¡(Never ¡check ¡in ¡ broken ¡code). ¡ • How ¡to ¡work ¡on ¡a ¡task ¡ – Get ¡latest ¡version ¡of ¡the ¡code. ¡ ¡All ¡tests ¡work. ¡ – Write ¡test. ¡ ¡It ¡fails. ¡ – Write ¡code ¡to ¡make ¡test ¡work. ¡ ¡Now ¡all ¡tests ¡work. ¡ – Refactor ¡(clean ¡up) ¡ – Check ¡in ¡your ¡code ¡ Requirements ¡in ¡XP: ¡Planning ¡Game ¡ Planning ¡ • Customer ¡writes ¡ user ¡stories ¡ • Programmers ¡only ¡worry ¡about ¡one ¡iteraPon ¡ at ¡a ¡Pme ¡ • Customer ¡interprets ¡ ¡ • Customer ¡can ¡plan ¡as ¡many ¡iteraPons ¡as ¡ • Programmers ¡esPmate ¡Pme ¡to ¡do ¡each ¡story ¡ desired, ¡but ¡can ¡change ¡future ¡iteraPons ¡ ¡ • If ¡story ¡is ¡too ¡big, ¡customer ¡splits ¡it ¡ ¡ • Customer ¡chooses ¡stories ¡to ¡match ¡ project ¡ velocity ¡ • Project ¡velocity ¡is ¡amount ¡of ¡work ¡done ¡last ¡ iteraPon ¡ 3 ¡
1/27/15 ¡ Simplicity ¡ Unit ¡tests ¡and ¡refactoring ¡ • Add ¡one ¡feature ¡(user ¡story) ¡at ¡a ¡Pme. ¡ • Because ¡code ¡is ¡as ¡simple ¡as ¡it ¡can ¡be, ¡adding ¡ a ¡new ¡feature ¡tends ¡to ¡make ¡it ¡less ¡simple. ¡ • Don’t ¡worry ¡about ¡future ¡stories. ¡ • To ¡recover ¡simplicity, ¡you ¡must ¡refactor ¡the ¡ • Make ¡program ¡as ¡simple ¡as ¡possible ¡ code ¡ • The ¡simplest ¡thing ¡that ¡could ¡possibly ¡work ¡ • To ¡refactor ¡safely, ¡you ¡should ¡have ¡a ¡rigorous ¡ set ¡of ¡unit ¡tests. ¡ Miscelaneous ¡ XP ¡works ¡best ¡when ¡ • ConPnuous ¡integraPon ¡ • Smart ¡customer ¡ • Spike ¡ • Small ¡team ¡ • Acceptance ¡tests ¡vs. ¡unit ¡tests ¡ • People ¡who ¡like ¡to ¡talk ¡ • IteraPon ¡planning ¡meePng ¡vs. ¡daily ¡standup ¡ • All ¡in ¡one ¡room ¡(including ¡customer) ¡ meePng ¡ • Changing ¡requirements ¡ Best ¡pair-‑programming ¡partner ¡ XP ¡criPcism ¡ • Similar ¡ • “Pair-‑programming ¡is ¡a ¡waste ¡of ¡resources” ¡ – CompaPble ¡schedules, ¡working ¡style ¡ – Lots ¡of ¡research ¡published ¡by ¡Laurie ¡Williams ¡from ¡ – Feeling ¡of ¡partnership ¡and ¡equality ¡ [D. ¡Dig ¡– ¡PLoP’2004] ¡ NCSU ¡on ¡pair-‑programming ¡producPvity ¡and ¡quality ¡ ¡ – Efficient ¡communicaPon ¡ • Not ¡scalable ¡ • Not ¡too ¡similar ¡ • Risk ¡of ¡scope ¡creep ¡due ¡to ¡lack ¡of ¡requirements ¡ – Different ¡skills ¡useful ¡at ¡different ¡Pmes ¡ documentaPon ¡ – Promotes ¡creaPvity ¡ • Non-‑funcPonal ¡requirements ¡are ¡hard ¡to ¡fit ¡into ¡ user ¡stories ¡ 2-‑24 ¡ 4 ¡
1/27/15 ¡ Class ¡acPvity ¡ Next ¡Pme ¡ • Discuss ¡which ¡of ¡the ¡XP ¡pracPces ¡might ¡pose ¡challenges ¡ • UML ¡Class ¡and ¡Sequence ¡diagrams ¡ for ¡your ¡project ¡and ¡how ¡to ¡deal ¡with ¡them ¡ • Read ¡chapters ¡3-‑4 ¡from ¡UML ¡DisPlled ¡ ¡ -‑ ¡Pair ¡Programming, ¡TDD, ¡ConPnuous ¡IntegraPon, ¡On-‑site ¡ Customer, ¡Refactoring, ¡Planning ¡game, ¡Small ¡releases, ¡ CollecPve ¡code ¡ownership, ¡Simple ¡design, ¡System ¡ metaphor, ¡Sustainable ¡pace ¡ 5 ¡
Recommend
More recommend