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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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
markers
Lack of risk analysis
Copyright © 2016 Curt Hill

17. 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

18. 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