CSC 2920 Software Development & Professional Practices

1. CSC 2920Software Development & Professional Practices Fall 2009 Dr. Chuck Lillie

2. Chapter 5 New and Emerging Process Methodologies

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

4. 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

5. 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 - - over processes and tools 2. Working software - - over comprehensive documentation 3. Customer collaboration-- over contract negotiation 4. Responding to change- - over following a plan http://agilemanifesto.org

6. 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

7. 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

8. Extreme Programming (XP): Core Values • Communication (between team and with customers) • Simplicity(in design and code) • Feedback (at many levels) • Courage (to make and implement difficult decision)

9. 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

10. 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

11. 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

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

13. 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)

14. 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

15. 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

16. XP Planning Game - Exploration • Goal: Find out/decide what the system can do • Moves • Write a story (client) • Estimate a story (developer) • Split or combine stories

17. 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)

18. 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

19. 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)

20. 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.

21. Adjusting methodologies • Larger methodologies for larger teams • Heavier methodologies for more critical projects • Preference to lighter methodologies since weight is costly • 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’

22. 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

23. Figure 5.2: Comparison of Crystal Clear and Crystal Orange

24. Crystal – Common features across all crystal methodologies • 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

25. Unified Process as Agile • UP is a framework • Does not specify particular techniques for all phases • UP usually considered heavy • All requirements at inception • Architecture, design upfront • RUP mandates many documents/artifacts • But • Iterative and incremental • UP doesn’t really require all products, RUP does • Restrict products, eliminate roles, add iterations

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

27. 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

28. MSF Team model

29. MSF Process Model

30. MSF – Management disciplines • Project Management • Risk Management • Readiness Management

31. 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

32. Open Source vs. Agile • Similarities • Small releases • Informal communications • Customer availability • Continuous integration • Shared Vision • Differences • Larger teams • Distributed teams • Scaling

33. Agile vs Traditional

34. Process vs. Project

35. 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