Fall 2011 Chapter 5 New and Emerging Process Methodologies

Objectives

• Understand – Limitations of traditional process methodologies – Applicability of agile processes – Basic tenets of agile processes • Gain familiarity with some agile processes

What are agile processes

• Family of software development methodologies • Short releases and iterations – Divide into small pieces – Release to customer as often as possible • Incremental design – Don’t try to complete design up front – Delay design decisions as long as possible • User involvement – Get user feedback as often as possible • Minimal documentation – Only necessary amount of documentation • Informal communications – People communicate better informally • Change – Things will change, plan for that

The Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. That is, while there is value in the items on the right, we value the items on the left more. 1. Individuals and interactions - 2

.

Working software - 3

.

Customer collaboration 4

.

Responding to change - - -

over processes and tools over comprehensive documentation over contract negotiation over following a plan http://agilemanifesto.org

Problems with traditional processes

• Lengthy development time • Inability to cope with changes in requirements • Assumes requirements are understood at beginning of project • Relies on heroic development effort • Complex methodology • Waste/duplication of effort

Some Agile Methodologies

• No process will work for all projects • Choose process best matched to project • Four of many agile methodologies – Extreme Programming (XP) – Crystal Clear/Orange – Rational Unified Process (RUP) • Framework – Microsoft Solutions Framework

XP: Core Values

• • • •

Communication

(between team and with customers)

Simplicity Feedback

decision)

(in design and code) (at many levels)

Courage (to make and implement difficult

XP: Fundamental Principles

• Rapid feedback – Use pair programming, unit testing, integration, and short interations and releases • Simplicity – Try the simplest approach possible • Incremental change – Try small changes that add up – Use code refactoring – small modifications to improve code • Embrace change – Preserve options for the future – Delay decisions that commit one to a path for as long as possible • Quality work – Create the best product possible

XP: Other Principles

• Ongoing learning • Small initial investment • Playing to win • Concrete experiments • Open, honest communications • Working with people’s instincts • Accepting responsibility • Local adaptation • Traveling light • Honest measurement

1.

– – 2.

3.

– 4.

– – 5.

– – 6.

– – – – XP: 12 practices Planning Determine features to be included in next release Business priorities and technical estimates Short releases Get a working system quickly Release new versions in short cycles (2 to 4 weeks) Base new detail plans on customer feedback Metaphor Use a metaphor instead of an architecture Simple design Eliminate unnecessary complexity as soon as possible Design can be changed in later versions Test-driven development Continuous and automated Write tests before writing code Design improvement (Refactoring) Remove duplication, improve communication, and simplify or add needed flexibility

XP: 12 practices 7. Pair programming – Two programmers working at same machine 8. Collective ownership – Anyone can change any code at any time 9. Continuous integration – Integrate and test every time a task is completed (many times a day) 10. Sustainable pace – – 40 hours a week reasonable Never overtime two consecutive weeks 11. On-site customer – Include real customer on the team 12. Coding standards – Everyone needs to use the same rules

XP: Planning

• Plan only the immediate next iteration in detail • Four variables to adjust in a project – Scope • What needs to be done for system to be useful – Cost – Quality – Time • Scope is easier to change (drop features) • Uses stories (represents a task, similar to use cases)

XP: Planning (2)

 Who makes the decisions?

• Client decides – Scope: needed for useful system – Priorities: identify and prioritize characteristics – Release scope: what is included in each release – Release dates • Technical side decides – Estimates: how long will each feature take – Consequences: best technology and programming language – Process: how are work activities performed; team organization

XP: Planning game

• Goal: Maximize value of software produced • Strategy: Invest as little as possible to get most functionality as quickly as possible • Three phases: – Exploration – delimit possible scope – Commitment – choose release scope, date • Business sorts stories (features) into three categories: essential, important, and nice to have • Development sorts stories by risk: can precisely estimate, can estimate reasonably well, those that cannot be estimated • Business chooses the scope, those story cards that can meet the schedule, or the schedule is readjusted to meet scope – Steering – adjust plan • Add, remove, or adjust stories

XP Planning Game - Exploration

• Goal: Find out/decide what the system can do • Moves – Write a story (client) – Estimate a story (developer) – Split a story

XP Planning game - commitment

• Business chooses scope and date of next release • Development commits to it • Moves – Sort stories (essential, important, nice) – Sort by risk (precise estimate, guess, no clue) – Development sets velocity (ideal vs calendar time) – Business chooses scope (which stories/tasks)

XP Planning game - Steering

• Update and adjust plan • Moves – Client can choose stories for iteration – Recovery • Developer asks client to reprioritize – Add/Replace story – Re-estimate

Crystal

• One methodology cannot fit all projects • What/how to adapt to project • Classify projects by – Size (number of developers) – Criticality: Loss that a malfunction would cause • Life • Essential money • Discretionary money • Customer comfort – Priority (time pressure)

Three defined methodologies

• Darker color, heavier the methodology – Crystal clear • Non critical projects • Teams of six to eight – Crystal orange • Critical but not life critical • Teams up to 40 people – Crystal orange web • Need more that these three – Life-critical – Large-scale projects – Etc.

Adjusting methodologies

• Larger methodologies for larger teams • Heavier methodologies for more critical projects • Give preference to interactive communication over formal documentation • Understand that people vary. High discipline processes are harder to adopt • Assume people want to be ‘good citizens’

Crystal - Properties

• Frequent delivery – At least every few months – Types of delivery: all users, limited users, only demo • Reflective improvement – Always thinking what can be improved • Close communication – Team members in close proximity • Personal safety – No reprisals for speaking up • Focus – Minimize disruptions • Easy access to expert users – Get expert advise when needed • Good technical environment – Automated tests, configuration management, and frequent integration

Teams Roles/ Separate people

Clear

One team, same room

Orange

Different teams for system planning, project monitoring, architecture, technology, functions, infrastructure and external testing At least 4 people, playing the roles of Sponsor, Senior designer, programmer, user.

Other roles may be filled by the same people, including Project manager, Business expert, Requirements gatherer 14 different roles, played by different people, including (besides those of Crystal Clear), Project Manager, Sponsor, Business Expert, Architect, Design Mentor, Tester and UI designer.

Work products Maximum Release length 9 items, including schedule, use cases, design sketches, test cases and user manuals.

13 items, including those in Crystal Clear plus requirements documents, status reports, UI design documents and Inter-team specs.

Work products are developed until they are understandable, precise and stable enough for peer review. 2 months 2-4 months, two user viewings per release

Figure 5.2: Comparison of Crystal Clear and Crystal Orange

Crystal – Common features

• Progress tracked by deliveries, not by documents • Automated regression testing • Direct user involvement • Two user viewings per release • Methodology tuning workshops • Mandatory policy standards • Coding style etc left to local standards • Techniques for individual roles are left to individual These are similar to XP

Unified Process as Agile

• UP usually considered heavy – All requirements at inception – Architecture, design upfront – Rational Unified Process (RUP) mandates many documents/artifacts • But – iterative and incremental – UP doesn’t really require all products, RUP does • Restrict products, eliminate roles, add iterations

Microsoft Solutions Framework

• Framework, not methodology (one level up) • Can be done as agile • Components – Foundational principles – Models – Disciplines – Key concepts – Proven practices – Recommendations

MSF: Foundational Principles

• Foster open communications • Work toward a shared vision • Empower team members • Establish clear accountability and shared responsibility • Focus on business value • Stay agile, expect change • Invest in quality • Learn from all experiences

Role

Program management Development Test Release Management User Experience Product Management

MSF Team model

Key quality goal

Delivery within project constraints Delivery to product specifications Ensuring each release addresses all issues Smooth deployment and ongoing management Enhanced user performance Satisfied customers

Phase

Envisioning Planning Developing Stabilizing Deploying

MSF Process Model

Milestone (deliverable)

Approved vision/scope

Mindset

Exploratory Approved project plans Investigatory Scope complete (all features implemented) Creative (design) Approved Release Readiness (debugged functionality complete) Deployment complete (for this release) Single-Minded (find and correct bugs) Disciplined

MSF – Management disciplines

• Project Management • Risk Management • Readiness Management

Open Source Development

• Make source open, allow users to modify • Many developers give code back, improve program • Success stories: Linux, Apache, MySQL • Not really agile

Open Source vs. Agile

• Similarities – Small releases – Informal communications – Customer availability – Continuous integration – Shared Vision • Differences – Larger teams – Distributed teams – Scaling

Agile vs Traditional

Requirements Design User involvement Documentation Communication Complexity Overhead Agile • Assumes change • Informal requirements • Constant user interaction • Informal • Iterative • Crucial • Frequent • Minimal, only as needed • Source code.

• Informally • Throughout the project.

• Low • Low Traditional / Heavy • Assumes no change • Complete, detailed, formal requirements document • Formal • Upfront • Beginning (Requirements) • End (Acceptance testing) • heavy, formal documents • Documents • Formal memos and meetings • High.

• High

Process vs. Project

Scope/size Criticality People Company Culture Stability

Agile (XP)

•Small. •One team, 3-10 people.

•Relatively low. •Not for life-critical systems • Team players • 'good citizens‘ • Good developers • Small co-located companies • Relaxed cultures. • Not needed • Copes with changes in requirements or environment.

Traditional (RUP)

• Large projects. • Can be scaled down • Higher • Almost anybody • Different roles • Larger companies • Geographically remote sites • Formal cultures.

• Assumes stable environment and requirements •Less suited to cope with changes.

Agile vs. Traditional

• Advantages – Simpler – Low cost, overhead – Deals with changes – Fast results – Usable systems • Risks, Disadvantages – Not scalable – Relies on teamwork – Relies on access to customer – Cultural clash