Extreme Programming Rediscovered: Agile Software Development Methodology

eXtreme Programming rediscovered Kre imir Fertalj University of Zagreb Faculty of EE & Computing Department of Applied Computing Aug 2014 DAAD \ Fertalj 1

Intro Aug 2014 DAAD \ Fertalj 2

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 2014 DAAD \ Fertalj 3

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

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 2014 DAAD \ Fertalj 5

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 2014 DAAD \ Fertalj 6

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

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 2014 DAAD \ Fertalj 8

Primary practices Aug 2014 DAAD \ Fertalj 9

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 2014 DAAD \ Fertalj 10

Team & Human Factors If the customer won t move to the team, move the team to the customer 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 2014 DAAD \ Fertalj Working overtime occasionally does not violate the goal of working at a sustainable pace (Hunt, 2010) 11

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 Repeat write a failing automated test write just enough code to pass the test refactor DAAD \ Fertalj A few times an hour Aug 2014 12

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 else s 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 2014 DAAD \ Fertalj 13

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

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 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 # programmer, tech lead Aug 2014 DAAD \ Fertalj 15

[some] Practical issues Aug 2014 DAAD \ Fertalj 16

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 doesn t force team members to specialize Specialization is not always a good thing Paraprofesionalism, Fach-idiotism, Versatility is good, for small teams! Aug 2014 DAAD \ Fertalj 17

[continued] XP promotes gradual development of the infrastructure & frameworks ! necessarily CSLA.NET, EntLib, Spring, GWT, Struts, Oracle ADF, XP doesn t 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 2014 DAAD \ Fertalj 18

[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 2014 DAAD \ Fertalj 19

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 2014 DAAD \ Fertalj 20

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 2014 DAAD \ Fertalj 21

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 2014 DAAD \ Fertalj 22

Testing Unit tests can t 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 2014 DAAD \ Fertalj 23

Refactoring When to refactor if it ain t broke, don t 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 Don t over-refactor Limit to 7 2 common out of 72++ refactorings Aug 2014 DAAD \ Fertalj 24

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 2014 DAAD \ Fertalj 25

[mostly] Energized Work Extended overtime is a productivity-reducing technique (DeMarco) If you come in on Monday and say To meet our goals, we ll have to work late again, then you already have a problem that can t 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 2014 DAAD \ Fertalj 26

Relation to other practices Aug 2014 DAAD \ Fertalj 27

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

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

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 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 Scrum Master, certified Aug 2014 DAAD \ Fertalj 30

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

FDD vs XP 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 Aug 2014 DAAD \ Fertalj 32

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

RUP and XP Universal development framework Adaptable templates (roadmaps) Best [supporting] practices Detailed documentation Programming and testing practice Basic principles Development practices 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 2014 DAAD \ Fertalj 34

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

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 2014 DAAD \ Fertalj 36

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 2014 DAAD \ Fertalj 37

Aug 2014 DAAD \ Fertalj 38