Agile Software Development

1. Agile Software Development FazalWahab

2. What is Agile? • An iterative and incremental (evolutionary) approach performed in a highly collaborative manner with just the right amount of ceremony to produce high quality software in a cost effective and timely manner which meets thechanging needs of its stakeholders. • Core principles • “Fits just right” process • Continuous testing and validation • Consistent team collaboration • Rapid response to change • Ongoing customer involvement • Frequent delivery of working software

3. How Agile is Different • Focus on collaboration: • Less paperwork and more conversation • Stakeholders actively involved • Focus on working software: • Greater feedback makes agile projects easier to manage • Less documentation is required • Less bureaucracy • Agilists are generalizing specialists: • Less hand offs between people • Less people required • Specialists find it difficult at first to fit into the team • Agile is based on practice, not theory: • This is a significant change from traditional • You need to see how agile works in practice to truly understand it

4. Myth busters Myth No Documentation Undisciplined No Planning Not Predictable Does Not Scale Is a Fad Silver Bullet RUP isn’t agile Not Fixed Price Reality Agile Documentation Requires great discipline Just-in-time (JIT) planning Far more predictable Eclipse is agile It’s quickly becoming the norm It requires skilled people RUP is as agile as you make it Agile provides stakeholders control over the budget, schedule, and scope

5. Why Agile Workswww.ambysoft.com/essays/whyAgileWorksFeedback.htm

6. Agile Development Practices • Regular Delivery of Working Software • Only valid measure of progress • Provides visible results to stakeholders • True earned value, not documentation-based “earned value” • Daily Stakeholder Interaction • On-Site Customer • Active Stakeholder Participation • Product Owner • Continuous Integration • Automatically compile, test, and style check your code • Continuous code integration is nice • Continuous system integration is nicer

7. Test First Design (TFD)www.agiledata.org/essays/tdd.html • With TFD you write a single test and then just enough production code to fulfill that test • Test-Driven Development (TDD) = Refactoring + TFD • TDD is a just-in-time (JIT) specification activity • TDD is a continuous confirmatory validation activity • TDD via Customer/Acceptance Tests • Specification of requirements • TDD via Developer Tests • Specification of design • TDD is also called Behavior Driven Development (BDD)

8. Other Agile Quality Practices • Non-solo development • Pair programming • Modeling with others • Effectively continuous inspections • Following guidance • Coding practices • Database standards • User interface (UI) standards • Modeling style guidelines (www.agilemodeling.com/style) • Refactoring • Small change to your code which improves the quality of the design without changing the semantics • Code refactoring • UI refactoring • Database refactoring

9. Working in Priority Order: Agile Change Managementwww.agilemodeling.com/essays/agileRequirements.htm

10. Agile Model Driven Development (AMDD)www.agilemodeling.com/essays/amdd.htm • Do just enough initial envisioning to understand the scope and technical direction • Model storm on a just-in-time basis to gather the details when you need them

11. Agile User Experience (UEX) • Observations: • User interface (UI) and usability issues are critical to the success of most systems • The UI is the system to the end user • Few developers have solid UEX skills, although many think they do • Advice: • Everyone should have some UEX training • Have someone with UEX expertise within your organization, and ensure that they pair regularly • Part of initial envisioning should address UEX issues • UEX issues will need to be addressed throughout development • Recognize that few of us are building the iPod, but when we tread into new territory we may need to do more up-front work than usual

12. Agile Documentation Practiceswww.agilemodeling.com/essays/agileDocumentation.htm • Maximize stakeholder ROI • Are treated as a requirement • Have a specific customer and facilitate the work efforts of that customer • Are concise • Fulfill a purpose • Describe information that is less likely to change • Describe “good things to know” • Are sufficiently accurate, consistent, and detailed – But aren’t perfect

13. Compliance requirement Critical, Audited Low risk Geographical distribution Entrenched process, people, and policy Co-located Global Minimal Significant Organization distribution (outsourcing, partnerships) Application complexity Simple, single platform Complex, multi-platform Third party In-house Team size Degree of Governance Under 10 developers 100’s of developers Informal Formal Challenges with Agile in the Mainstream Agile Development

14. Scaling TDD: Agile Model Driven Development (AMDD) www.agilemodeling.com/essays/amdd.htm

15. The Generic Agile Lifecycle

16. References and Recommended Reading • www.agilealliance.com • www.agilemodeling.com • www.agiledata.org • www.enterpriseunifiedprocess.com • www.ibm.com/rational/agile/ • Ambler, S.W. (2002). Agile Modeling: Effective Practices for XP and the UP. New York: John Wiley & Sons. • Ambler, S.W. (2003). Agile Database Techniques. New York: John Wiley & Sons. • Ambler, S.W. (2004). The Object Primer 3rd Edition: AMDD with UML 2. New York: Cambridge University Press. • Ambler, S.W. and Sadalage, P.J. (2006). Refactoring Databases: Evolutionary Database Design. Reading, MA: Addison Wesley Longman, Inc. • Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide. Reading, MA: Addison Wesley • McGovern, J., Ambler, S.W., Stevens, M., Linn, J., Sharan, V., & Jo, E. (2003). The Practical Guide to Enterprise Architecture. Prentice Hall PTR.