EXtreme Programming rediscovered Krešimir Fertalj University of Zagreb Faculty of EE & Computing...

eXtreme Programming rediscovered Kreimir Fertalj University of Zagreb Faculty of EE & Computing Department of Applied Computing Aug 2014DAAD \ Fertalj1

Intro Aug 2014DAAD \ Fertalj2

XP is Programming under extreme conditions Lightweight software development process ? methodology Focused on continuous change throughout SW product L-C Non-linear, adaptive, incrementally oriented Based on longstanding practices, including evolutionary prototyping, short release cycles, and active end-user involvement in requirements definition Aug 2014DAAD \ Fertalj3

Suitability [sorted] Business software Changing requirements Fast-pace In-house development On-site customer Vague requirements Aug 2014DAAD \ Fertalj4

Usability +use small to medium-size projects using co-located teams of a dozen or fewer programmers total duration of 1-6 months !use large projects, long projects, or projects with high reliability requirements projects that face risks in areas other than requirements, schedule, or staff inexperience Aug 2014DAAD \ Fertalj5

Values Communication Oral + electronic, frequent / continuous, everyone Simplicity Design the simplest + KISS & grow the system as & when required Feedback From both teammates & customers early and often Courage Actions & decisions, even unpopular, YAGNI Respect Mutual respect among all stakeholders Aug 2014DAAD \ Fertalj6

XP LifeCycle (LC) Aug 2014DAAD \ Fertalj7 Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. Agile Software Development Methods: Review and Analysis. VTT Publications, 2002, p.19

XP LC briefly Exploration = Requirements Analysis Writing user stories Planning = Forecasting and Estimating Planning Game Development = Sequence of iterative cycles Concludes with a product release - a couple of cycles before production Iteration Planning Game (IPG ) tasks for each cycle assigned, estimated Test-First Programming, Pair Programming, Regression Testing Implementation Continuous integration very short intervals on separate server, regression & integration tests Aug 2014DAAD \ Fertalj8

Primary practices Aug 2014DAAD \ Fertalj9

Requirement Analysis & Planning [User] Stories Short descriptions of customer-visible functionalities Weekly Cycle SW development performed a week at the time A meeting where the stories are chosen by the customer A cycle may start in the middle of the week ! Quarterly Cycle rolling wave planning Slack Lower-priority tasks that can be dropped if project gets behind the schedule Aug 2014DAAD \ Fertalj10

Team & Human Factors Sit Together Co-located team, open space Whole Team All the skills needed, sense of belonging Informative Workspace [B|W]board, visible wall graphs, , CMS/GSS/PMS [mostly] Energized Work Limited overtime Pair Programming 2 programmers { driver, observer/navigator } at 1 machine Aug 2014DAAD \ Fertalj11 If the customer wont move to the team, move the team to the customer Working overtime occasionally does not violate the goal of working at a sustainable pace (Hunt, 2010)

Design Incremental Design No Big Design/Modelling/Requirements Up-Front (BDUF, BMUF, BRUF) Design + refactor incrementally during coding [dislike] Test-First Programming Test-Driven Development Automated unit tests incrementally written All stories have at least one acceptance test preferably automated Aug 2014DAAD \ Fertalj12 Repeat write a failing automated test write just enough code to pass the test refactor A few times an hour

Software Coding & Releasing Ten-Minute Build System should be built & all of the tests should be finished in 10 minutes Continuous Integration Daily Build & Smoke Test Continuous = at least daily By regularly integrating with current build And getting every elses code Code may only be checked in if all tests pass CI server Release builds in the morning Messaging fix the build Penalty for breaking the build [or leaving w/o checking in] Aug 2014DAAD \ Fertalj13

Corollary practices real customer, incremental deployment, negotiated scope contract, pay-per-use team continuity, daily stand-up meetings # unofficial practice shrinking team, root cause analysis, code and tests, shared code, single code base daily deployment, Aug 2014DAAD \ Fertalj14

XP team Self-organizing, cross-functional, sufficiently competent Team size : optimal 7 2, like 5 Team roles Manager management of team & problems # manager, team lead Coach tutoring, monitoring, issue control # programmer, tech lead Programmer estimating, coding incl. tests, refactoring Tester test development Customer story selection and prioritizing, acceptance test writing More roles Tracker, Trainer, Doomsayer, Product Manager, Domain Expert, Interaction Designer, Business Analyst Aug 2014DAAD \ Fertalj15

[some] Practical issues Aug 2014DAAD \ Fertalj16

Controversies [& how to deal with] XP is a hackers paradise or at the very least encourages hacking Active PM, n stories 90% done = 0 stories XP Programmers get to work in pairs! Not all, but sophisticated functions Programmers should switch roles and change partners XP doesnt force team members to specialize Specialization is not always a good thing Paraprofesionalism, Fach-idiotism, Versatility is good, for small teams! Aug 2014DAAD \ Fertalj17

[continued] XP promotes gradual development of the infrastructure & frameworks ! necessarily CSLA.NET, EntLib, Spring, GWT, Struts, Oracle ADF, XP doesnt conduct a complete up-front analysis & design What about iterative SAD | parallel development ? XP does not encourage the implementation documentation The code is not sufficiently self-documenting # the weakest point ! Comments, round-trip engineering, frameworks & patterns, , help += manual XP is not a complete methodology Common sense & best practices over methodologies (Fertalj) Aug 2014DAAD \ Fertalj18

[Iteration] Planning [Game] Elaboration: { write + estimate + split } a story Commitment: Sort by value of { must, should, nice to } have { 0, 1, 2, 3, 5, 9 } Sort by risk { confident, reasonably sure, cannot estimate } Choose scope = set of USs Set velocity map Ideal Engineering Days (IED) to reality Steering: Iteration planning, project recovery, identifying new story, project re-estimation Aug 2014DAAD \ Fertalj19

Ideally short iteration(s) The idea pre-determined iteration length - timeboxing the scope is reduced to fit the iteration length No consensus Scrum 2-4 weeks, XP & FDD 1-2 weeks 2 weeks seems fine Criteria team's maturity (novice-longer, experienced-shorter) effort = TeamSize * Iterationlength Variable iteration lengths shorter at the beginning (1wk), longer later in the project (>=2wks) longer 1st iteration due to the prep of infrastructure Aug 2014DAAD \ Fertalj20

User story US is not a detailed requirement A promise to have a conversation (Cockburn) detailed enough to allow an effort/time estimate should be short e.g. 3 sentences US != UC details are obtained during iterations [not] written by the customer(s) Partitioned interview Aug 2014DAAD \ Fertalj21

no design modeling before programming The idea of avoiding analysis paralysis over-engineering and over-modelling Often distorts to model & fix approach code-first programming database refactoring PowerPoint architecture Instead, try Agile modelling in workshops Throwaway prototypes in a different language use of application/enterprise framework(s) Aug 2014DAAD \ Fertalj22

Testing Unit tests cant test overall system behaviour Selective, e.g. unit tests for the business logic Incremental - evolving Repeated - regression Automated where possible Other tests Integration: { UI, UC, interaction, interface } testing System: { reqs, usability, security, performance, doc } testing Acceptance: { alpha, beta } testing, audit test Aug 2014DAAD \ Fertalj23

Refactoring Aug 2014DAAD \ Fertalj24 When to refactor if it aint broke, dont fix it - refactor with a purpose When examining existing code to understand how it works After implementing a new feature When not to refactor When there is no clear plan of the improvement Within bug fixing How to refactor Tool support, IDE integrated Dont over-refactor Limit to 7 2 common out of 72++ refactorings

Release release early As soon as it can add a business value to the customer small release , Relative: on a 2-year project small can be after 2-3 months 60-100 stories (Khramtchenko, 2004) release often Frequency of iterations Not all iterations may result in a release ! Aug 2014DAAD \ Fertalj25

[mostly] Energized Work Extended overtime is a productivity-reducing technique (DeMarco) If you come in on Monday and say To meet our goals, well have to work late again, then you already have a problem that cant be solved by working more hours. (Beck & Andres 2004, 60) Overtime can be good every now and then team members need to kick it up a gear such as when nearing a finish line or perhaps attacking a critical, user-reported defect Aug 2014DAAD \ Fertalj26

Relation to other practices Aug 2014DAAD \ Fertalj27

Positioning Aug 2014DAAD \ Fertalj28 Optimizing Agile for Your Organization Jenny Stuart, Vice President of Consulting, Construx Software Version 1, September 2008

XP Evolutionary prototyping 10-12 co-located, OOPs XP Coach, informal 13+11 highly- specified, disciplined dev. practices 1-2 week iterations Stand-up meetings Visible wall graphs Minimal archival doc. Aug 2014DAAD \ Fertalj29 Scrum Evolutionary delivery Small teams, 6 roles Scrum Master, certified 7 practices 30-day sprints Daily Scrum meetings Burndown chart PM wrapper around dev. FDD Incremental, iterative Scalable to larger teams Chief programmer(s) 8 highly-specified dev. practices 2-week features 6 milestones / feature Burn Up chart UML modelling

Scrum vs XP High level Focused on PM Sprint 2-4 weeks The team is free to choose features; sequence irrelevant Customer cannot change requirements within sprint Scrum Master, certified Engineering practice Programming and testing Iteration 1-2 weeks Features developed in a strict order Requirements can change before work on feature started new or equivalent can be swapped XP Coach, informal role Aug 2014DAAD \ Fertalj30

Aug 2014DAAD \ Fertalj31 Scrum with XP (Mar & Schwaber, 2002) IPG Sprint Backlog eXtreme sPrint (Fertalj) Variant: Sprint Review + Refactoring (Zuiderveld, 2004)

FDD vs XP Aug 2014DAAD \ Fertalj32 Feature = a client-valued function that can be implemented in 2 weeks Features are treated as tasks to be performed FDD controls the process without saying how to implement

FDD with XP (Hunt, 2006) Aug 2014DAAD \ Fertalj33 revise features plan iteration repeat start feature break into tasks repeat AM & XP until feature completed until all features implemented

RUP and XP Universal development framework Adaptable templates (roadmaps) Best [supporting] practices Detailed documentation Programming and testing practice Basic principles Development practices Aug 2014DAAD \ Fertalj34 dX : A minimal RUP Process (Booch et.al, 1998) RUP Plug-In for XP (Rational, 2002) RUP and XP A Modern Perspective (Fertalj et.al, 2006)

Aug 2014DAAD \ Fertalj35 Based on UP XP mini-waterfall Minimal set of UML MOOSAD (Dennis et.al, 2005) Minimalistic Object-Oriented Systems Analysis & Design

IXP vs XP Industrial XP XP evolved within diverse industries Organic evolution of XP Minimalistic, customer-centric, test-driven spirit New practices Readiness assessment Project community Project chartering Test-driven management Retrospectives Continuous learning Redefined practices SDD, DDD, Pairing, Iterative usability, Aug 2014DAAD \ Fertalj36

References & Resources Hunt: Agile Software Construction, Springer, 2006 Larman & Vodde: Practices for Scaling Lean & Agile Development, Addison-Wesley, 2010 Williams: A Survey of Agile Development Methodologies, 2007 http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf http://collaboration.csc.ncsu.edu/laurie/publicationsAll.html http://extremeprogramming.org/ http://xprogramming.com/ http://www.industrialxp.org/ Aug 2014DAAD \ Fertalj37

Aug 2014DAAD \ Fertalj38

EXtreme Programming rediscovered Krešimir Fertalj University of Zagreb Faculty of EE & Computing...

Documents

Transcript of EXtreme Programming rediscovered Krešimir Fertalj University of Zagreb Faculty of EE & Computing...