1. Agile Softwareentwicklung Lars Jankowfsky, swoodoo.com
Dienstag, 21. Juli 2009
2. Lars Jankowfsky CTO and (Co-)Founder swoodoo AG (Co-)Founder
OXID eSales AG XP, agile development fanatic developing since 15+
years php since php/ Software Architect > 10 years Lars
Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
3. lessons learned COST QUALITY TIME SCOPE Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
4. Get Ready FIRE! Aim... Aim... Aim... Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
5. Agile methods are based on: + Communication + Simplicity +
Feedback + Courage Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli
2009
6. http://agilemanifesto.org/ Individuals and interactions over
processes and tools Working software over comprehensive
documentation Customer collaboration over contract negotiation
Responding to change over following a plan Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
7. Agile ? THINK ! Lars Jankowfsky, swoodoo.com Dienstag, 21.
Juli 2009
8. popular Agile methods Adaptive Software Development Feature
Driven Development DSDM - Dynamic Systems Development Method Scrum
crystal clear XP .... Lars Jankowfsky, swoodoo.com Dienstag, 21.
Juli 2009
9. Scrum ! Pigs, Chicken, User and Stakeholder... Plan (
product backlog ) Very good process, used often. Sprint planning
session Sprint ( == Iteration ) Daily meetings Sprint review
Closure http://www.controlchaos.com/ Lars Jankowfsky, swoodoo.com
Dienstag, 21. Juli 2009
10. eXtreme Programming ! Besides crystal clear the only
process which focuses on integration, testing and for smaller teams
( 2 - 12 ) developing. needs test-driven-development focuses on
automatic testing a change in the way we program includes
continuous integration http://www.extremeprogramming.org/ Lars
Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
11. eXtreme Programming Software development is too hard to
spend time on things that don't matter. So, what really matters?
Listening, Testing, Coding, and Designing. (Kent Beck, father of
Extreme Programming) Lars Jankowfsky, swoodoo.com Dienstag, 21.
Juli 2009
12. eXtreme Programming ! embrace changes! + people vs.
hardware + automated tests + continous integration Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
13. eXtreme Programming + Planning + Designing + Coding +
Testing Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
14. Planning XP + The Customer Lars Jankowfsky, swoodoo.com
Dienstag, 21. Juli 2009
15. Planning XP - the Customer Is always available Writes User
Stories and specifies Functional Tests Sets priorities, explains
stories May or may not be an end-user Has authority to decide
questions about the stories Create/Defines acceptance tests Lars
Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
16. Balancing Power Lars Jankowfsky, swoodoo.com Dienstag, 21.
Juli 2009
17. Customer bill of rights As the customer, you have the right
to: An overall plan, to know what can be accomplished, when, and at
what cost; Get the most possible value out of every programming
week; See progress in a running system, proven to work by passing
repeatable tests that you specify; Change your mind, to substitute
functionality, and to change priorities without paying exorbitant
costs; Be informed of schedule changes, in time to choose how to
reduce scope to restore the original date, even cancel at any time
and be left with a useful working system reflecting investment to
date. Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
18. Programmer bill of rights As the Developer, you have the
right to: Know what is needed, with clear declarations of priority;
Produce quality work at all times; Ask for and receive help from
peers, superiors, and customers; Make and update your own
estimates; Accept your responsibilities instead of having them
assigned to you. Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli
2009
19. Planning XP The Customer + Stories Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
20. Planning XP - the Stories A short story about the
functionality from the point of view of the Customer No technical
jargon One for each major feature in the system Must be written by
the customer Are used to create time estimates for release planning
Replace a large Requirements Document The stories are the base for
acceptance tests Only enough detail to make a low risk estimate of
how long the story will take to implement. Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
21. Planning XP - the Stories Use simple technics ( postit )
Find a place where all developer can see the stories User Story
Example: User should be able to register himself to get access to
the system. 3 SP Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli
2009
22. Planning XP The Customer Stories + Estimation Lars
Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
23. Planning XP - Estimation Yesterdays Weather use your
experience ask other teams which may have done similar things
Estimate using Story Points == ideal Person Days Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
24. Planning XP The Customer Stories Estimation + Release Plan
Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
25. Planning XP - Release Plan Customer defines the business
value of desired stories ( priority ) Stories which are too large
need to be split into smaller chunks Higher risks stories should
come first Define release dates - these are fixed, scope not Lars
Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
26. The Release plan Lars Jankowfsky, swoodoo.com Dienstag, 21.
Juli 2009
27. Never slip a date! falling behind ? Change the plan! Lars
Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
28. Planning XP - Iterations From release backlog the stories
with highest priorities are taken and assigned to the next
iteration. An iteration can be 1-3 weeks usually Stories for
Iteration are broken down into Tasks by Developers Tasks are
estimated by all Developers as a group Developers sign up for
Tasks, and estimate the time to complete Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
29. Planning XP - Iterations... If a task has more than 2-3
Story points, then break it into smaller parts. If there are any
questions ask the customer, he should attend Iteration planning
meeting Can only sign up for as many points as were completed in
the last Iteration Once development begins, Project Velocity
measures progress Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli
2009
30. Planning XP - Iterations... Lars Jankowfsky, swoodoo.com
Dienstag, 21. Juli 2009
31. During Iteration: Stand Up Meeting Track status in daily
Stand-Up Meeting Ask for Story Points left - not for SP done Every
morning for 5 minutes STAND UP! What did you do yesterday ? What do
you plan todo today ? Any Showstoppers or important issues ? ( e.g.
taking half day off... ) Tell Team what you did, not some Task
number Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
32. During Iteration: Tracking speed Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
33. Designing XP + Simplicity + Choose a System Metaphor + CRC
Cards + Spike Solutions + Never Add Functionality Early + Refactor
Mercilessly Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli
2009
34. Designing XP: Refactor Mercilessly Refactoring is the
process of changing a software system in such a way that it does
not alter the external behavior of the code yet improves its
internal structure. (Martin Fowler) Lars Jankowfsky, swoodoo.com
Dienstag, 21. Juli 2009
35. Coding XP + Use coding standards. Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
36. Coding XP: Use coding standards Agree on standards in team
Coding standards keep the code consistent and easy for the entire
team to read and refactor. Write them down somewhere ( wiki / trac
) phpCodeSniffer (preCommit Hook) Lars Jankowfsky, swoodoo.com
Dienstag, 21. Juli 2009
37. Coding XP Use coding standards. + Integrate often. Check in
daily. Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
38. Coding XP: Check in daily Forces developer to write small
functions Makes it impossible to create huge frameworks/ functions
This is the fundament for having good tests later Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
39. Coding XP Use coding standards. Integrate often. Check in
daily. + Code the unit test first. Lars Jankowfsky, swoodoo.com
Dienstag, 21. Juli 2009
40. Coding XP: Code the unit test first. Upon creation of a
function write unit tests Write many tests for each function
Success case Error case Stupid input case Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
41. Coding XP: Unit tests PHPUnit - http://www.phpunit.de/
SimpleTest - http://simpletest.sourceforge.net/ Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
42. Coding XP Use coding standards. Integrate often. Check in
daily. Code the unit test first. + Use collective code ownership.
Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
43. Coding XP: collective code ownership Collective Code
Ownership encourages everyone to contribute new ideas to all
segments of the project. (Don Wells) Have a look what your
collegaues are doing Any developer can change any line of code to
add functionality, fix bugs, or refactor. Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
44. Coding XP Use coding standards. Integrate often. Check in
daily. Code the unit test first. Use collective code ownership. +
Leave optimization till last. Lars Jankowfsky, swoodoo.com
Dienstag, 21. Juli 2009
45. Coding XP: Optimize last Make it work, make it right, then
make it fast. Never guess what performance will be - measure it!
Create clear rules for performance and test it. ( ab or siege can
be used in unit tests ) Lars Jankowfsky, swoodoo.com Dienstag, 21.
Juli 2009
46. Coding XP Use coding standards. Integrate often. Check in
daily. Code the unit test first. Use collective code ownership.
Leave optimization till last. + No overtime. Lars Jankowfsky,
swoodoo.com Dienstag, 21. Juli 2009
47. Coding XP: No overtime Projects that require overtime to be
finished on time will be late no matter what you do. Overtime sucks
the spirit and motivation out of a team. Better play a game instead
and build castles instead of creating bugs in the software Lars
Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
48. Testing XP + Create acceptance tests. + Use continuous
integration! + Run tests automatically + Publish the results Lars
Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
49. Hope vs. knowledge Lars Jankowfsky, swoodoo.com Dienstag,
21. Juli 2009
50. Testing XP: Acceptance Tests use Selenium Java solution
which enables automatic click tests.
http://www.openqa.org/selenium/ Lars Jankowfsky, swoodoo.com
Dienstag, 21. Juli 2009
51. Testing XP: continuous integration Continuous Integration
is a software development practice where members of a team
integrate their work frequently, usually each person integrates at
least daily - leading to multiple integrations per day. Each
integration is verified by an automated build (including test) to
detect integration errors as quickly as possible. ( Martin Fowler )
http://www.martinfowler.com/articles/ continuousIntegration.html
Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
52. Testing XP: continuous integration Various tools: phing
XINC ( http://sourceforge.net/projects/xinc ) We use cruisecontrol
check out http://buildix.thoughtworks.com/ phpUnderControl Lars
Jankowfsky, swoodoo.com Dienstag, 21. Juli 2009
53. Testing XP: cruisecontrol GUI Lars Jankowfsky, swoodoo.com
Dienstag, 21. Juli 2009
54. Questions ? Lars Jankowfsky, swoodoo.com Dienstag, 21. Juli
2009
55. Resources used: Extreme Programming: A gentle introduction.
http://www.extremeprogramming.org/ Extreme Programming -
Introduction Mayford Technologies Inc. Wikipedia Extreme
Programming Explained: Embrace Change. Kent Beck Refactoring
Improving the Design of Existing Code. Lars Jankowfsky, swoodoo.com
Dienstag, 21. Juli 2009
