20. changingplan.com
Thanks:
Agile Software Development Manifesto
http://www.colourlovers.com/palette/725464/real_life
changingplan.com
Hinweis der Redaktion
“Manifesto for Agile Software Development”
better way of building software
17 middle aged white guys
1. Martin Fowler (Chief Scientist TW) * Kent Beck (JUnit, TDD, XP) * Alistair Cockburn * Ward Cunningham (invented Wiki) * Andrew Hunt * Dave Thomas (PragProg) * Robert C. Martin
2. Mike Beedle * Arie van Bennekum * James Grenning * Jim Highsmith * Ron Jeffries * Jon Kern * Brian Marick * Steve Mellor (UML, IEEE Software mag) * Ken Schwaber * Jeff Sutherland
* I’m talking about the principles
principles - big hitters
while there is value in the items on the bottom, we value the items on the top more
something funny!
story:
- dev and testing in two groups - process build and test
- blame as people used the process to identify ‘issues’
- things went bad and added more process
- two groups brought closer together and removed barriers - one team - emphathy
- horizontal groups
* you need both processes and tools. they help. but dont be a slave.
story:
- dev and testing in two groups - process build and test
- blame as people used the process to identify ‘issues’
- things went bad and added more process
- two groups brought closer together and removed barriers - one team - emphathy
- horizontal groups
* let good people do what you hired them to do. make a decision!
story:
- dev and testing in two groups - process build and test
- blame as people used the process to identify ‘issues’
- things went bad and added more process
- two groups brought closer together and removed barriers - one team - emphathy
- horizontal groups
good: lean & adaptive processes and tools - like svn, git, simple pm, simple forecasting - back off MBAs!
story: At a startup where they wrote a word doc for every page
- know what is in the system
- just use the system
* agile does _NOT_ say ‘no doc’, Lean says ‘just enough’ doc
story: At a startup where they wrote a word doc for every page
- know what is in the system
- just use the system
* agile does _NOT_ say ‘no doc’, Lean says ‘just enough’ doc
story: At a startup where they wrote a word doc for every page
- know what is in the system
- just use the system
you need some doc - it is a form of comms, but don’t do it at the expense of face-to-face.
Talk about last massive project
* kept squeezing each task into smaller and smaller timeframe
* scheduled to work at 12 midnight and 4am
* gung-ho attitude of push it through so you don’t look like a ‘failure’
* had to change the plan when we ran late.
Edward Yourdon - Death March
* budget, timeline, morale is blown and you keep on going
only helps contracting companies - not client, not employees, not contractors
Talk about last massive project
* kept squeezing each task into smaller and smaller timeframe
* scheduled to work at 12 midnight and 4am
* gung-ho attitude of push it through so you don’t look like a ‘failure’
* had to change the plan when we ran late.
Edward Yourdon - Death March
* budget, timeline, morale is blown and you keep on going
only helps contracting companies - not client, not employees, not contractors
Talk about last massive project
* kept squeezing each task into smaller and smaller timeframe
* scheduled to work at 12 midnight and 4am
* gung-ho attitude of push it through so you don’t look like a ‘failure’
* had to change the plan when we ran late.
Edward Yourdon - Death March
* budget, timeline, morale is blown and you keep on going
only helps contracting companies - not client, not employees, not contractors
Hardest point
* most contracts define deliverables and in an agile project these change
* get the lawyers in last
grant the vendor a financial incentive if the project objectives are achieved -- and a penalty if they aren't - these goals are business objectives rather than technical objectives
* just enough formality to make agreements safe for both sides
http://www.cutter.com/content-and-analysis/resource-centers/agile-project-management/sample-our-research/apmu0617.html
Hardest point
* most contracts define deliverables and in an agile project these change
* get the lawyers in last
grant the vendor a financial incentive if the project objectives are achieved -- and a penalty if they aren't - these goals are business objectives rather than technical objectives
* just enough formality to make agreements safe for both sides
http://www.cutter.com/content-and-analysis/resource-centers/agile-project-management/sample-our-research/apmu0617.html
Hardest point
* most contracts define deliverables and in an agile project these change
* get the lawyers in last
grant the vendor a financial incentive if the project objectives are achieved -- and a penalty if they aren't - these goals are business objectives rather than technical objectives
* just enough formality to make agreements safe for both sides
http://www.cutter.com/content-and-analysis/resource-centers/agile-project-management/sample-our-research/apmu0617.html
* Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
* Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
* Business people and developers must work together daily throughout the project.
**teaser! Find out more
- hopefully nothing to crazy in there.
- this is what agile is supposed to be about
- ignore the cowboys and learn for yourself!
Tool that captures these values
Alpha
Need interested people to help make something great