eXtremely Distributed Software Development XDSD for short Copyright © 2016 Curt Hill

Introduction A new agile system intended to manage free-lance developers Uses a technique called Puzzle Driven Development This breaks the project into very small units of work Typical work unit is less than an hour in length Limited communication among developers Author is Yegor Bugayenko Copyright © 2016 Curt Hill

Setup The project leaders work for or are contracted by the enterprise They partition the project into bite size pieces These tasks are obtained Farm out the pieces concurrently to free-lance developers They control the quality and pay the developers Copyright © 2016 Curt Hill

Use of GIT GIT is usually used for the repository Developer gets a private copy of the repository When complete with the task issues a pull request Repository owner reviews work If it meets expectations The work is merged to trunk Task is closed Payment is submitted Copyright © 2016 Curt Hill

XDSD Principles Only Closed Tasks are Paid For Tasks are Small Unfinished Components may be Delivered No Informal Communications between Developers Bugs are Paid For Pull Requests Only No Compromises About Code Quality Copyright © 2016 Curt Hill

Tasks and Payments A task may have a time budget of 15 minutes to an hour This may be subject to negotiation An hourly rate is negotiated The developer has ten days to finish the task The payment is fixed by the task duration and the hourly rate Does not matter if it took five minutes or five days Copyright © 2016 Curt Hill

No Obligation Principle Each developer is under no obligation to finish on time or even start They are free-lancers they may accept it or reject it They may take less than the amount of time or more Must be complete in ten days or task is given to someone else Only if task is completed in that ten days will payment be rendered Copyright © 2016 Curt Hill

Definition of Done Task is done when the deliverables are returned to the author They determine that the task is done acceptably Only when done is payment made Copyright © 2016 Curt Hill

Developer Suggestions Don't even start a task unless you're sure you can finish it Ask any and all questions of the task author before any work Don't assume anything Stay after the author to close tasks Don't expect any help from anyone — you're on your own; Ask about payment if you don’t receive it automatically after an author closes your task(s) Copyright © 2016 Curt Hill

Unfinished Components may be Delivered A 30 minute time frame is usually not enough for a complete module What is expected is the start of the module with stubs for the pieces where the specification may not have been clear These are the puzzles of PDD Copyright © 2016 Curt Hill

PDD Puzzle Driven Development Similar in concept to stepwise refinement The unknown pieces are called puzzles Puzzles are items that we are not sure about and that require more refinement Refinement can come from the author They may also be new tasks Copyright © 2016 Curt Hill

Java Puzzles Developers in Java use several annotations to indicate a puzzle @todo indicates a puzzle @ignore indicates a stub that is not as yet implemented This is a task waiting for implementation Copyright © 2016 Curt Hill

No Informal Communications The only means of communication is the ticket tracking system The only encouraged communication is between the author and the developer The author creates the ticket Copyright © 2016 Curt Hill

Bugs are Paid For At the hourly rate for 15 minutes Mostly testers find bugs, but developers or anyone else may as well Each bug found then generates a task to fix A bug is: Reproducible Refers to functionality already implemented Can be fixed in a reasonable amount of time Doesn't duplicate a bug already reported Copyright © 2016 Curt Hill

Team Roles Project Manager — assigns tasks and pays on completion System Analyst — documents the product owner's ideas Architect — defines how system components interact Designer — implements most complex components Programmer — implements all components Tester — finds and reports bugs Copyright © 2016 Curt Hill

Types of Problems Most of the personnel inserts or removes the following types of problems Unclear or ambiguous requirements Features not yet implemented Functional and non-functional bugs Lack of test coverage Unresolved @todo markers Lack of risk analysis Copyright © 2016 Curt Hill

No Compromises About Code Quality Before a trunk merge occurs all unit tests are done Static analyzers are also run These are automated No payment unless it passes everything Copyright © 2016 Curt Hill

Finally XDSD is an agile approach that deals with: Software development paradigm Free-lance developer management tool One of the newest systems Assignment: Where are the XDSD tasks to be found? Copyright © 2016 Curt Hill