Agile Development Evolution of Software Development Paradigms Hacking

Agile Development

Evolution of Software Development Paradigms • Hacking • Structured Analysis / Structured Design • Waterfall • Spiral • Iterative and Incremental • Agile

Agile Principles 1. 2. 3. 4. 5. 6. 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. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Common Agile Practices • Test-Driven Development • Pair Programming • Refactoring • Continuous Integration • User Stories • Timeboxing • Retrospectives • Velocity Tracking • Planning Poker • Burndown Charts • (Several others)

Agile Methods • Adaptive software development (ASD) • Agile modeling • Agile unified process (AUP) • Disciplined agile delivery • Dynamic systems development method (DSDM) • Extreme programming (XP) • Feature-driven development (FDD) • Lean software development • Kanban • Rapid application development (RAD) • Scrumban • (Several others)

Scrum Overview

Sample Definition of Ready • Story Definition / Overview Complete • Paragraph (2 -3 sentences is OK), stating what the story is. • Acceptance (success) criteria defined • Criteria are clearly stated and testable • UI Mockups created (if applicable) • May be hand drawn • Performance criteria defined (if applicable) • Criteria are clearly stated and testable • Initial functional requirements written • May be bullet points at this stage

Sample Definition of Done • Code Complete • All code is written to satisfy all requirements that remain in scope • Code is written according to documented coding standards • Code is appropriately commented • Code is reviewed by at least one peer • Code is reviewed by an architect (if required) • Code is checked in • Testing • Automated unit testing (90%+ automated unit coverage unless a lower level is appropriate based on requirements) • Main and important scenarios are automated (Selenium for UI scenarios, integration tests for non-UI scenarios) • All tests (automated and manual) are passing • There are no known defects with a severity higher than “low” • Acceptance and Performance Criteria • The story satisfies all acceptance and performance criteria Need to create coding standards documents for the languages we use. • Documentation • Overview Document • What does the system do and why? How does it fit into our existing product set? • Technical Documentation • • • Architectural overview Development Environment Setup Instructions Deployment Instructions Technical Description API Documentation • Deployment • The story is deployable on production hardware • The deployment is automated to the extent possible, and can be done by an ops team by following the documented deployment instructions • Monitoring infrastructure is in place, satisfies the stated monitoring requirements, and is runnable at deployment

Story Point Estimation • Scales • Ideal Hours (or Ideal Days) • Modified Fibonacci Series • 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞ • Methods • Ordering Method • Team members take turns placing a story card in a scale category or moving a story card • There are usually limits to how many times a card can be moved and/or how far it can be moved • Planning Poker • Each team member has cards with each number from the Fibonacci series • After discussing a story, all play a card at the same time and then discuss and resolve differences • Usually the player of the highest and lowest cards are asked to explain • Others

Sprint Burndown Chart Example 1

Sprint Burndown Chart Example 2

Sprint Burndown Chart Example 3

Refactoring in Agile Development: Test-Driven Development 14