Notes for this course:
*******************************************************************************************
MODULE 4
*******************************************************************************************
// you don't have to define iterations to deliver software effectively
Plan a release.
- identifying a flexibility matrix
- identifying releases based on priority items in flexibility matrix and release criteria
- resource planning (Scrum team is responsible for allocating team members)
- identifying techniques to optimize a team that is geographically distributed
- selecting a project methodology
- risk management
// Study guide is a little like waterfall
What is a flexibility matrix
- Based on the iron triagle - scope, resources, schedule
- Scope is most flexible
- resources are least flexible
- schedule is moderatly flexible
“identifying releases based on priority items in flexibility matrix and release criteria”
- No.
- Think agile. Think lean.
- Think delivering business value in small increments, quickly, with high quality.
- Think backlogs, velocity, and forecasting sprints
- Then, if all else fails, think of traditional work breakdowns in Project, with predecessors,
external dependencies and critical paths.
// "plan the work, work the plan" does not fit to agile or the exam
// if you face things like critical path, use MS Project. Not typical
Sprint Capacity Planning
// consider who you have and their capacity per day
// Web Access is an important tool, not necessarily for the test
// web access gives us capacity forecasting
Geographically distributed teams
-Use electronic tools to share documents and data
- SharePoint, TFS, etc
-Pay close attention to cultural issues
-Use video when possible
-Do not post key documents or data only on the wall of the ‘home office’
// important that key documents are distributed to whole team
// colocating is the first choice - fosters professional relationships
// by colocating we mean the same work area (not different floors)
// video is a good tool for remote locations.
// colocated team has shared accountability and ownership
Define a project-tracking process.
- identifying a project tracking tool and an associated process (triage process, bug
management)
- defining how to manage effort
- determining team forecast management
- defining a prioritization scheme
- determining how to validate project health
// start and end date focus is dysfunctional, it looks at utilization rather than results
// what is the complexity of what we are working on?
// what is our past velocity? Past is not always perfect predictor
// product owner prioritizes the backlog
// important to know backlog items business value and necessary effort. gives us
// ratio of business value to effort, can but used for prioritization
// risk is critical consideration. Crucial backlog items should move up the backlog
// some small wins are good, but effort alone should not be prioritization metric
// same with business value.
Identifying an appropriate tool for project management
- Primary MS tools for tracking software development projects are TFS and Project
// important to understand Project
- TFS is very strong at handling most software development efforts, however it is weak
at predecessor/successor relationships, handling efforts outside the development team,
and identifying key measures such as the critical path.
// MS Project is better for predecessor/successor and critical path
// non-development concerns are better handled in Project
// earned value is easy in Project
- MS Project is strong at many of the things TFS is weak at, however it is weak in
gathering data through the normal day to day activities of the team, as well as most
other software development project tracking needs.
Forecasting deilvery
// we can adjust how much "effort" we can get done in a sprint. Can estimate available
// sprint effort to better forcase delivery and plan sprints.
Reports – Use them
- Bug Status
- Bug Trends
- Build Quality Indicators
- Build Success Over Time
- Build Summary
- Burndown and Burn Rate
- Reactivations
- Remaining Work
- Requirements Overview
- Requirements Progress
- Status on All Iterations
- Test Case Readiness
- Test Plan Progress
- Unplanned Work
// can also use cumulative flow diagram
// walk around and talk to people
// - if everyone is smiling, you should be on track
// - if heads are hanging, probably going to be late
// Use TFS for good, not evil.
// Use metric with care. A poorly framed metric can hurt a team -
// - lines of code by a dev
// - bugs discovered by testers
// http://search.dilbert.com/comic/10%20Dollars%20Bug%20Fix
Scope a project.
- scoping the effort for a release
- defining an architecture design process
// Why do we design architecture? XP says YAGNI (ya ain't gonna need it...)
- defining scope boundaries (is/is not list)
- determining the definition of “done”
- defining a process when effort estimates are significantly inaccurate
(i.e. every software development project ever)
Determining effort and release plan
Architectural design - Layer diagrams
// you can define layers and assign classes and namespaces to different layers
// define dependencies, show how they work with each other
// validate against our .NET 2.0 code
// easy to get carried away with validation
Architectural design - DGML
// these tools help us rapidly understand existing code bases.
// we can understand the root cause of problems
// only available in Ultimate
Architectural design - UML Diagrams
// UML has been back and forth in MS products
// powerful tool to express ideas graphically
Architectural Diagrams
- Good for sharing knowledge of the design
- Good for collaboration
- Layer diagrams can enforce architectural standards by limiting what is allowed/disallowed
inside of a layer (done primarily by namespace)
- Architecture requirements in a layer diagram can be validated during a build.
- DGML diagrams can be extended to include more than just architectural elements.
// with plugin you can visualize work items
Definition of Done
- In Scrum, the team agrees on what it means for a task, user story, bug or other item to
be ‘done’
- The Definition of Done is generally beyond the acceptance criteria specified in a user
story or product backlog item.
EXAM BEST BETS
- Don’t overthink this section.
- Many of the ideas here are covered directly by the Scrum and process overviews done
earlier today.
*******************************************************************************************
MODULE 5
*******************************************************************************************
Elicit requirements.
- defining project requirements
- reviewing and clarifying requirements
- defining acceptance criteria
- defining UI platform requirements (Web, mobile)
- assigning a business value
// TFS2012 webaccess -> work -> backlog
// scrum user stories should be light
// As a <some user> I want <some goal> so that <some reason>
// As a service rep I want to view tickets on a Windows Phone so I can get new updates
// quickly while I'm on the road.
// Define effort, product owner specifies business value. Scott likes using Fibonnacci nums
// acceptance criteria - must be viewable portrait and landscape, must receive updates OTA
// updates must include address, must include geolocation and mapping.
// requirements should be simple enough that you can create acceptance criteria
// can create an "epoch" with child nodes for requirement - used for big requirements
// that require multiple sprints
Estimate requirements.
- managing and assigning effort estimates (assigning story points)
- resizing user requirements into smaller, manageable pieces
- executing task breakdown
- estimating the requirements baseline
// Scrum is resistance to scope creep, as are most Agile ALM methods
Story Points
- Story points are an arbitrary measure of the effort required to implement a story.
- It is the team’s estimate of how hard the story is.
- Team specific. Doesn’t translate between teams well.
- Generally not related to days, or tied to other time based intervals.
- Often uses a rounded Fibonacci sequence (1,2,3,5,8,13,20,40)
- In Scrum, story points are often used to by the Team to measure the effort required for
a product backlog item
- Sprint velocity is based on story points
- Estimated in a number of ways, including planning poker
// not officially part of Scrum
// can relate effort to common tasks that everyone can identify (like changing a tire on a
// car)
// Scrum master should NOT be picking effort, neither should product owner
Resizing requirements
- In order to deliver value continuously and receive rapid feedback, requirements must be
sufficiently small.
- Think: Smallest possible item that provides business value
- Business value could be customer value, reduced risk, validated learning, revenue or
other key metric.
- Thoughts:
- Generally not everything in a 200 page requirements document is required.
- Small requirements that can be shipped independently allow completely new ways of
working
Document requirements.
- defining acceptance criteria
- listing requirements
- adding requirement details
- designing UI storyboards
Prioritize requirements.
- identifying requirements that are critical path
- identifying must-have requirements
- enabling the entire team (including customers) to participate in requirements
prioritization
- identifying dependencies
Identifying must-have requirements
- Ensure anything designated as must-have truly must be had in order to meet a “minimally
viable product”
- My experience: about 75% of most “must have” requirements generally aren’t actually
required to deliver customer value or achieve validated learning
- Several tools exist for classifying requirements:
- MoSCoW (Must have, Should have, Could have, Would like)
- Regardless of tool, hardest part is ruthlessly reducing the batch size of delivered code
to the truly “must have” requirements
// "desirements" should be filtered from real requirements
Critical Path
- The critical path is the longest necessary path through a network of activities when
respecting their interdependencies
- Work breakdown structure (list of all activities)
- Time estimate for each activity
- Dependencies between activities
- TFS does not calculate a critical path. MS Project does.
- MS Project can sync with TFS
- fidelity depends on the field mapping file in the process template
- <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Scheduling.StartDate"
ProjectField="pjTaskStart" PublishOnly="true"/>
// you cannot deliver product any faster than the critical path unless you shrink items
// on the critical path
// Work Breakdown Structure is hard to finagle in TFS.
// Project interacts differently with CMMI, Scrum, and Agile templates
// Scrum template won't tie with Project unless you modify it (Scrum is too simple)
EXAM BEST BETS
- Although the prep guide seems to stress formal requirements management, keep a lean and
agile mindset for test success.
- Scrum intro earlier in the day still applies strongly to this section
- Many ways to prioritize requirements
- In Scrum, prioritization is done by the Product Owner
- Understand, however, the strengths MS Project brings if a critical path must be
identified, or predecessor/successor relationships need to be defined.
// don't try to change an organizations culture all at once, need a transition (say from
// waterfall to agile)
No comments:
Post a Comment