sign in sign up
<<
Home , Continuous integration

Agile Development Evolution of Paradigms

• Hacking • Structured Analysis / Structured Design • Waterfall • Spiral • Iterative and Incremental • Agile

Agile Principles

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

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

• Adaptive software development • Lean software development (ASD) • • Agile modeling • Rapid application development • Agile (AUP) (RAD) • Disciplined agile delivery • Scrum • Dynamic systems development • method (DSDM) • (Several others) • (XP) • Feature-driven development (FDD) 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 • Documentation • All code is written to satisfy all requirements that remain in • Overview Document scope • What does the system do and why? How does it fit into our existing • Code is written according to documented coding standards product set? • Code is appropriately commented • Technical Documentation • Code is reviewed by at least one peer • Architectural overview • Code is reviewed by an architect (if required) • Development Environment Setup Instructions • Deployment Instructions • Code is checked in • Technical Description • Testing • API Documentation • Automated (90%+ automated unit coverage unless • Deployment a lower level is appropriate based on requirements) • The story is deployable on production hardware • Main and important scenarios are automated (Selenium for UI scenarios, integration tests for non-UI scenarios) • The deployment is automated to the extent possible, and can be done by an ops team by following the documented • All tests (automated and manual) are passing deployment instructions • There are no known defects with a severity higher than “low” • Monitoring • Acceptance and Performance Criteria • Monitoring infrastructure is in place, satisfies the stated • The story satisfies all acceptance and performance monitoring requirements, and is runnable at deployment criteria Need to create coding standards documents for the languages we use. 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