MSF for Agile Software Development
MSF for Agile Software Development
Granville Miller (aka Randy Miller)
MSF is an agile software process that reflects some of the practices used within Microsoft.
Agenda
- Agile Software Development
- Team Model
- Team model is the most critical piece of the agile software development process. If you know it, you can answer 90% of the questions.
- Personas/Scenarios
- The “Agile” Pattern
- Shadow Applications
- Incremental Threat Modeling
- Context-Driven Testing
- Risk
Randy usually gives people about a day’s worth of presentation on this stuff, and we’re trying to cover it in an hour, so this will be much abbreviated. There’s much more info available on Microsoft’s Web site (see link, below).
Project Success is Rare
- 2004: 15% failed, 51% challenged, 34% succeeded
- 2000: 23% failed, 49% challenged, 28% succeeded
- 1995: 40% failed, 33% challenged, 27% succeeded
- 1994: 31% failed, 53% challenged, 16% succeeded
- The good news: State is Improving
- Small Releases
- Increased Customer Involvement
- You’d think success would depend on some new server technology or something, but customer involvement seems more important
- Agile Manifesto
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- An agile method is
- Iterative
- Incremental
- Self-organizing and
- Emergent.
- It must include the attributes; otherwise it is a “lightened defined process”.
Activities in MSF
- There are more roles than just customer and developer. There are architects, testers, etc., who add value.
- More roles -> communication complexity increases.
- Composed of 14 basic work streams
- Basic activity building blocks of MSF
- A work stream is an activity that is composed of other activities
- Activities are described using the ETVX format (whatever that is)
- Contains 70 activities (not including work streams)
- Most work streams are performed by a single role
- Roles <-> Constituencies
- Team of Peers
- Business analyst: Product management
- is responsible for two constituency groups: one is the sponsor, the other is the users.
- is responsible for tracking time.
- Release manager: in charge of understanding deployment, handing it off. Product manager: responsible for tracking budget and such. They can be combined.
- Roles
- Developer
- Project Manager
- Business Analyst (handles interaction with customer)
- Architect
- Tester
- Release Manager
- Work Streams / Goals
- Capture Product Vision (business analyst)
- Create a Scenario
- Create a Quality of Service Requirement
- Plan an Iteration (project manager)
- Create Solution Architecture (architect)
- Implement a Development Task (developer)
- Build a Product
- Test a Scenario
- Test a Quality of Service Requirement
- Fix a Bug
- Close a Bug (tester)
- Release a Product
- Guide Project (project manager)
- Guide Iteration (project manager)
- Choose the MSF for Agile Software Development process for projects with results-oriented teams who can work without lots of intermediate documentation
- “Stretch to Fit” instead of “Shrink to Fit”
- Minimalist approach
- Agile methodologies promote adaptation
Scaling to All Project Sizes
- There’s a matrix for whether it’s a good fit to combine particular roles
- (P)ossible, (U)nlikely, (N)ot recommended
- “If you have the skills to play a role, you may play that role”
- Smallest project size is 3 people (with one or two people, you probably don’t need much process)
Mindsets:
- More than a set of activities – a collection of values
- Quality is Defined by Customer
- Pride of Workmanship
- Team of Peers
- Frequent Delivery
- Willingness to Learn
- Get Specific Early
- Qualities of Service
- Citizenship
- Different roles. Some care only about time. Some don’t care so much about time, and fight for quality. Who breaks deadlocks?
Adaptation
- There are many events that may befall a project that are not covered by our process
- Use best judgment and adapt based on mindsets and principles
Personas
- Descriptions of a group of typical users
- Persona represents a “proxy” for the user group, and provides a means to talk and reason about the group through the characteristics of one fictional individual
- On-site customer is the best you could hope for.
- Actors in use cases: the other extreme. A developer is a developer.
- Persona: fictional representations of people.
- Be respectful.
- Best Buy did a set of personae for their customers. One was the “Devil Customer”. This was fine until it landed in the Wall Street Journal.
- Can represent the novice and the advanced developer.
- Scenarios associated with each persona.
- Knowledge, skill, usage pattern
- Be respectful.
- Can still meet actual customers (and refine our personae).
- Different people come up with different personae, write them on sticky notes, put them on the board. When you take yours up, you decide whether it should be combined with one of the others, or should be separate.
- Q: Where do you get pictures to use for your personae? A: Got any artists in your group? Can you buy a CD of stock photography?
- Baseball cards of personae (including organizations)
- When you’re trying to make a decision, at least you have a clue.
Jack
- Role: Online shopper
- Motivation: Get it quick
- Usage pattern: Hates shopping but wants to get it quick. …
Incremental approach – Why scenarios over use cases?
- Risk reduction
- Changes
- Delivery
- Progress
- Activities need to be able to handle small increments up to a single change
- A scenario is basically a single path through a use case. Easy to break into smaller increments if needed.
The Agile Pattern
- Scenario list (aka backlog) -> iteration plan
- Peel off pieces, add them to a particular iteration
- The things in the list aren’t actually scenarios – they’re reminders. The business analyst writes them up for the iteration.
Date or Feature Driven
- Which?
- Parkinson’s Law: If you give developers more time, they will find ways to fill that time. So you have to be aggressive on the date, right?
- But not everything is really date-driven
- “We’re going to deliver in March, even if it’s March 51st”
Minimum Acceptance Level
- If you ask customers what they want, they’ll list off the Exciters & Delighters. (What do you want in your TV? Remote control, stereo, closed captioning, etc.)
- But they usually won’t tell you about the Dissatisfiers (must-have requirements) (ability to turn the TV on without the remote, good picture quality, etc.)
- First few iterations: you work mostly on the dissatisfiers, and a little on the exciters. But you can’t deliver until you make enough progress on the dissatisfiers.
- So even if time ran out on iteration 3, you still couldn’t ship.
- Of course, this is all pragmatic. Depends on market. If you really want to be first-to-market, you might ship anyway.
- Even if you’re date-driven, you might not really be date-driven, because you might not be able to ship without X features.
Feature graphs:
- Active (until the developer finishes it – doesn’t distinguish ones that haven’t yet been given to the developers to work on)
- Resolved (goes to test: implemented fully)
- Closed (tester can run it totally through)
- Do a stacked area graph over time. Active=red, resolved=yellow, closed=green.
- If you’ve still got too much red as of the ship date, the project manager and the business analyst have a problem, and need to start talking to each other.
- If the yellow keeps growing over time, it could mean you don’t have enough testers, or that scheduling is poor (finishing too many items at once), or the test cases are failing (coders are submitting bad code and marking it as resolved, and the testers have to kick it back), or management is putting too much pressure on and the team stops caring about actual quality and becomes totally dysfunctional.
- Value of any practice depends on its context
- If you absolutely *must* ship by a certain date or the company runs out of money, you might be incented to ship something that’s not ready. Is that the right thing to do? It depends on how the market reacts.
- There are good practices in context, but there are no best practices
- People, working together, are the most important part of any project’s context.
Context Driven Approach
- Testing that is acceptable on opne project may be criminal on another
- Define shipping criteria based on what’s important to us
- Release criteria
- No Severity 1s and 2s in the shipping product
- Testing thresholds
- Code Coverage for Unit Test
- Getting 60% code coverage is really normal
- To get 80%, you start using things like mock objects, and it gets harder
- To get 95%-100%, you start building scaffolding and bizarre stuff
- What’s right? Answer: it depends entirely on the project.
- Focusing on statement and branch coverage is not sufficient.
- Missing code
- Incorrect handling of boundary conditions
- Timing problems
- Memory leaks
Bug debt
- If the developer has more than 30 bugs, it’s time to schedule a bugfix iteration, where you fix bugs (and fix bugs only)
- Worth doing even though you take a hit on velocity, because you’ll take a hit on velocity anyway (because you either fix them as you go, or they slow down your coding or testing)
Conduct Exploratory Testing (One Heuristic)
- Assume a persona
- Time-box
- Traverse the system looking for new goals, roadblocks, or improvements, keeping the needs of the persona in mind
- Add any new bugs, scenarios, or quality of service requirements discovered using this process
Risk and Agile Processes
- Agile processes drive out risk through short release cycles and customer feedback.
- Requirements risk
- Implementation risk
- Quality risk
Governance
- Objectives Reviewed
- Progress Assessed
- Test Thresholds Evaluated
- Risks Identified and Mitigated
- Deployment Ready
Methods of Adoption
- Organization / Team
- Grassroots – individuals find the practices useful and the process spreads by providing value
- MSF provides friction-free usage that doesn’t get in the way
More info
- http://www.microsoft.com/msf – download “MSF for Agile Software Development (Process Guidance Only)”; has much more info than this presentation
- Will be released in book form – MS wants to ship it with Team Foundation 1Q next year