The Agile Manifesto (and a brief history lesson)
•Transferir como KEY, PDF•
2 gostaram•2,484 visualizações
The Agile Manifesto values individuals and interactions, working software, customer collaboration, and responding to change over processes/tools, documentation, contract negotiation, and strict plans. It lists 12 principles including satisfying customers through early delivery, welcoming changing requirements, frequent delivery, business/developers working daily together, and face-to-face communication. The manifesto helped uncover better software development practices through values emphasizing people over process.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a The Agile Manifesto (and a brief history lesson)
Semelhante a The Agile Manifesto (and a brief history lesson) (20)
Mais de Adrian Howard
Mais de Adrian Howard (20)
Último
Último (20)
The Agile Manifesto (and a brief history lesson)
- 1. The Agile Manifesto (and a bit of a history lesson)
- 4. Manifesto Values We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
- 5. Manifesto Principles Our highest priority is to satisfy the customer Working software is the primary measure of through early and continuous delivery of valuable progress. software. Agile processes promote sustainable development. Welcome changing requirements, even late in The sponsors, developers, and users should be able development. Agile processes harness change for the to maintain a constant pace indefinitely. customer's competitive advantage. Continuous attention to technical excellence and Deliver working software frequently, from a couple good design enhances agility. of weeks to a couple of months, with a preference to the shorter timescale. Simplicity — the art of maximizing the amount of work not done--is essential. Business people and developers must work together daily throughout the project. The best architectures, requirements, and designs emerge from self-organizing teams. Build projects around motivated individuals. Give them the environment and support they need, and At regular intervals, the team reflects on how to trust them to get the job done. become more effective, then tunes and adjusts its behavior accordingly. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- 6. Manifesto Values We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
- 7. Individuals and interactions over processes and tools
- 8. Working software over comprehensive documentation
- 9. Customer collaboration over contract negotiation
- 10. Responding to change over following a plan
- 11. Values Principles Crystal XP ASD DSDM FDD Scrum Your Process
- 12. Scrum = Agile
- 13. Scrum ≠ Agile
- 15. You should ask questions now :-) adrianh@quietstars.com twitter.com/adrianh quietstars.com
Notas do Editor
- First the history lesson...
- * You can find examples of some “agile” practices in the 50s/60s. * Scrum has its origins in mid-80s, formalised in the mid-nineties. * Extreme Programming started mid-nineties. * All before the term “Agile” was ever used.
- * What XP, Scrum, etc. did was bring together practices in a new way * Synergy between practices. Sum is greater than its parts. * Previous common term was “lightweight” - obvious double meaning. * “Agile” as a term to describe these terms dates from Feb 2001. * Group of 17 practitioners got together and produced...
- Break the rules - and read out the slide.
- * There are also principles... but we only have ten minutes. * But you should really go read them and think about them. * I’ll give a pointer at the end for those who are interested.
- * This bit is important. * Agile is not rejecting process, tools, documentation, contracts and plans. * Agile is about changing the priorities. * Everything subservient to the things that produce working software providing business value * Let’s talk about these in a bit more detail
- * Not about just sitting down without a plan and hacking. * Not about absence of tools (e.g. xUnit frameworks, index cards) * Not about absence of process (e.g. stand ups, planning game) * It’s stopping processes and tools getting in the way of people building the product. Personal networks and communication vital. * It’s focussing on the _people_ and making them more effective * E.g. Adopting TDD frees up testers for Exploratory Testing
- * We’re all familiar with the evil 3 inch requirements documents with the 27 8-by-10 colour glossy photographs with circles and arrows and a paragraph on the back of each one. * It’s always wrong. Hard to see where. * By focusing on iteratively delivering software - we avoid the problem * Document to communicate - not to define. * Draw maps, not plans.
- * Traditional processes are usually contractual. * “We want this” / “We can do this” * When this changes - trouble ensues. * “this” often changes * Agile process are collaborative and consensus driven * “We’re producing this”
- * The plan, as they say, never survives contact with the enemy * Q: When do management and customers want to know about problems? * A: Now * Traditional processes are fragile in the face of changing requirements * Build your processes around feedback and change. * “Embrace change” was one of the XP slogans * Maps. Not plans.
- * So we have a bunch of effective processes… * That share some common principles… * … and common values * Agile is empirical * Based on working methods, not academic business theory * Agile is not a silver bullet
- * Some treat Scrum and Agile as synonyms.
- * Not true. * Scrum is one of family of methods - including XP, FDD, etc. * They all share values and principles of the Agile Manifesto * If your process is failing - it pays to revisit the values & principles
- * Read all the values and principles here * It’s worth spending the time * Look at _other_ agile methods than the one you use * Look for practices from other fields, like UX, that share agile values
- * If you have any questions... just drop me a line :-)