300 likes | 610 Views
Software Quality and Agile SW Development. Johan Lindvall TY 22.4.2005. Content. Backround and problems IID Scrum XP Quality. Backround and Problems. waterfall: response to ad-hoc code-and-fix 1960’s, Winston Royce (proponent of iterative dev.) e.g. DoD standard 2167
E N D
Software Quality and Agile SW Development Johan Lindvall TY 22.4.2005
Content • Backround and problems • IID • Scrum • XP • Quality
Backround and Problems • waterfall: response to ad-hoc code-and-fix 1960’s, Winston Royce (proponent of iterative dev.) • e.g. DoD standard 2167 • system should be clearly specified before its design and implemention • the clients are not sure what they want • details will only be revealed during development • as the product develop, clients change their minds • external forces (competitor’s product) -> high change rate, not predictable manufactoring
IID • Interative and incremental development • Agile methods are a subset of iterative and evolutionary methods • The key practices: iterative development risk-driven and client-driven timeboxing evolutionary development evolutionary requirements adaptive planning
Iterative Development • ID is an approach to build sw of several iterations • each iteration a mini-project • requirements analysis, design, programming, test • iteration release: a stable, integrated and tested internal (external) partially complete system
iteration by iteration system grows incrementally with new features iterative and incremental development IID • at least 3 iterations • recommended lenght is 1-6 weeks per itr. • early risk mitigation and discovery • riskiest problems first • a study [Johnson2002]: • 45% of features were not used • 19% rarely • 16% sometimes • 13% often • 7% always
final product better matches true client desires quality • iterative development is lower risk and better success, productivity, and defect rates than WF • early and regular process improvement • a per-iteration assessment • confidence and satisfaction from early, repeated success team self-confidence customer confidence in the team
Risk-Driven and Client-Driven Iterative Planning • What to do in the first/next iteration? • Risk-driven: the riskiest, most difficult elements for the early iterations • Client-driven: the choice of features comes from client, the currently highest business value
Timeboxing • the practice of fixing the iteration end-date and not allow it to change • if short of time, reduce the scope and leave features to the next iteration • no adding of new tasks to iteration
Evolutionary and Apadtive Development • requirements, plan, estimates, solution evolve and are refined • requires feedback from users, tests, developers • consept: evolutionary ~ adaptive = iterative-timebox
Evolutionary Requirements Analysis • requirements are not always changing (Boehm 1988 25%) • most requirements discovery and refinement usually occours during early iterations • e.g. 1-2 day req. workshop/itr. • early top-ten high-level req. (e.g. load, usability) • a study (1995, 107 projects) • 18% of the projects completed the reqs. in 1 iteration • 32% in 2 iterations • 50% in 3 or more iterations
Evolutionary and Adaptive planning • an initial phase of high uncertainty which drops • cone of uncertainty (effort, cost, shedule /time) • apadtive planning: no detailed schedule are created
Delivery • partial software produced, not merely documents • incremental delivery: system into production, deliveries between 3-12 months • evolutionary delivery: attempt to capture feedback, promoted in agile development
Agile sw development • requiring feedback to guide direction, early testing, early demos • agility – rapid and flexible response to change • motto: embrace change • practices and principles: simplicity, lightness, communication, self-directed teams, programming over documents • eg. Scrum and XP • whiteboard (wall sketches), snapshots • timeboxed iterative and evolutionary development, adaptive planning, promote evolutionary delivery • http://www.digitoday.fi/showPage.php?page_id=9&news_id=28365
The Agile Manifesto Individuals and interactions over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following the plan
The Agile principles • early and continuous delivery of valuable sw • welcome changing requirements, even late • delivery working sw frequently • business people and developers daily together • motivated individuals • face-to-face conversation for information • working sw is the primary measure of progress • agile processes promote sustainable development • developpers, users maintain constant pace • attention to technical excellence and good design enhances agility • simplicity essentail – the art of maximizing the amount of work not done • the best architectures, requirements and desings emerges from self-organizing teams • the team regulary reflects on how to become more effective
Scrum • by Takeuchi and Nonaka 1986 paper of summarizing common best practises in 10 innovatoive Japanese companies • timebox exactly 30 days • working in a common room • daily meeting, at the same time and place • self-directed teams (one team <=7, many teams) • external demo at the end of each iter.
Cockburn scale C, D, E, L and 1-100-… • client-driven adaptive planning • Lifecycle: plannig, staging,development, release • Planning: • establish the vision, set expectations, funding • write vision, budget, initial Product Backlog • Staging: • identify more requirements, priorotize enough for first iteration
Development: • implenent a system ready for release in series of 30 days (sprints) • Sprint planning: choose goals for the next iteration, how to achieve the requests. Sprint Backlog: tasks (in next 4-16h) to meet the goals • during iteration do not add work, uninterrupted focus • quality assurance occurs specially in Sprint, with less new development Release: • operational deployment • or each release begins with staging
Product Backlog a list of all product requirements, functionality, features, techlogy never finished evolves • Sprint Backlog daily estimate of work remaining for each task Scrum is based on the insight that SW development is creative and unpredictible new product development, and therefore empairical rather than defined methods are needed.
Scrum values • Commitment • the team commits to a defined goal and decide themselves how best to meet it • Focus • team not distracted, chickens and pics-rule, srcum master • Openness • product backlog makes visible the work and priorities • Respect – self-organizing • Courage – trust the team
XP • eXtreme Programming, Kent Beck 1980’s • truly adobted by developpers! • Cockburn scale C, D, E and 1-20 • small team projects, <10 developpers • emphasizes collaboration, quick and early sw creation • the cost of change may not rise over time
4 values • communication: pairs, daily meetings, customer on-site • simplicity: ’Do simpliest thing that could possbly work’. Eg. avoid creating generalized components. • feedback: drives to quality and adaption • courage: simple design & tests rapid and radical changes
1-4 weeks iterations • story cards to summarize requirements, not required detailed workproducts • programming in pairs (deep skill transfer) • common project room • full-time participation by requirements donor (the client, end user) for ongoing verbal explinations • test-driven development, code reviews, frequent integration of all code short iterations, early feedback quality • tests written ahead! • timeboxed, no working overtime
12 core practices • The planning game • scope, priority, composition of releases, dates of releases • estmates, consequences, process, detailed scheduling • Small releases • the most valuable business requirements • Metaphor • the basic elements and their relationships, naive statement • Simple Design • runs all the tests, no duplicated logic, every intention important, fewest possible classes and methods
Testing • unit tests, functional tests • Refactoring • even more simpler? • Pair programming • implemention vs. strategy • Collective ownership • need to change now, not later • Continous Integration • integrated and tested after few hours - a day • 40 hour week • On-site customer • Coding standards
Others: Evo • 1960’s, published 1976 • 1-2 weeks iteration • evolutionary delivery on each iteration • plans iterations by highest value-to-cost ratio
Others: UP • Unified Process, 1990’s • iterative, not agile • risk-driven development in early iterations focusing on creation of the core architecture and driving down the high risks • 2-6 weeks iterations
Quality • research show that shorter steps have lower complexity and risk, better feedback, and higher productivity and success rate • early defect removal, less useless work, concentration on essential features • each iteration tested for acceptance real business value for customer.
References • Larman, Craig: Agile and Iterative Development, Addison-Wesley, 2004 • Beck, Kent: Extreme programming explained: embrace change, Addison-Wesley, 2000 • Scwaber Ken, Beedle Mike:Agile Software Development with Scrum, Prentice-Hall, 2002 • http://www.digitoday.fi/showPage.php?page_id=9&news_id=28365