*******************************************************************************************
MODULE 2
*******************************************************************************************
Tips
- This section is all about attitude and mindset, not knowing specific details.
- Having the right mindset will get you through nearly all of the questions, without
having to focus on specific technical details.
- Understand the value of an end-to-end view of Application Lifecycle Management (ALM)
tools and practices.
- understanding that an observable problem may be indicative of a more general process
issue
- explaining the difference between optimizing a piece of the ALM process such as manual
testing and optimizing the entire ALM process
// Work Item Traceability and flow
// I development, we have a changeset (check-in) that are tied to builds. Changesets are
// tied to tasks, which are related to backlog items, which are tied to test suites, which
// are part of test plans. Test plans are linked to builds. Test cases are part of QA and
// are tied to automated tests on the development side. Backlog items are tied to
// storyboards, and project management nodes are all tied to stakeholder feedback
//
// users define requirements (product backlog)
// - impediment include misniterpreted requirements
// developers turn ideas into working software
// - impediment include churn in requirements, unmet user expectations, loss of focus
// operations realize value by operating software
// - impediments include disparate management tools, can't get actionable feedback
//
// Team barriers are often self inflicted (testers and devs on different floors)
// - increased costs, cycle times
// - dissatisfied users
// - lost value opportunities
//
// Teams without barriers deliver continuous value (continuous value delivery)
// users/stakeholders define requirements, create product backlog
// devs implement product backlog by creating working software
// operations puts into production, creating ops backlog, which is monitored
// ops gives feedback to stakeholders who refine requirements (restart cycle)
// the idea is to make this cycle faster and faster until it is continuous
// improve cycle times and quality
//
// Visual Studio ALM
// Teams without barriers. Continuous value delivery
// integration Faster time to market
// traceability => Balancing ability and quality
// collaboration Revenue Growth
// faster cycle times cost reduction
// ecstatic users/devs/testers/etc
// realized value opportunities
//
- Explain the benefits of fast feedback.
- explaining the importance of fast feedback related to communicating requirements
- explaining the benefits of end customer feedback to early software iterations
// we measure something and then adjust.
// putting in a delay between measurement and adjustment causes inefficiency
// delays slow feedback and cause queues.
// getting immediate feedback from tester makes devs more efficient - software is
// still in their mind, they are still on that sprint.
Problems with Slow Feedback
- Introduce more work into the system
- Long time between code and bug fix makes it harder for developer
- Long time between bug find and bug fix verification makes it harder for the tester
- Added complexity
- More context switching
- Lowers overall productivity
New Tools to speed feedback
- Requirements - PowerPoint Storyboarding
// use as a mock up
// moving away from big design documents to small user stories
- Customer Feedback - Feedback Client
// getting effective feedback rapidly is a common problem
// get very specific feedback, directed questions
Implement strategies to reduce end-to-end cycle time.
- identifying bottlenecks in the delivery process
- understanding the relationship between work in process (WIP) and cycle time
- identifying metrics that highlight bottlenecks
- creating potential solutions whose effectiveness can be validated
Cumulative flow diagram
- shows you when you have a bottleneck
- shows different code status as bands:
- deployed
- ready for approval
- in testing
- in progress
- ready to start
- if one band starts getting bigger, it is a bottleneck
- anytime you have a queue its a sign of a bottleneck
// Everything between assigned work and completed work is our work in process.
// Vertical line represents WIP for a give day. Horizontal line is the average lead time.
// as our WIP decreases, so does average lead time. It can be politically difficult
// to limit WIP, technically trivial.
// Using utilization as a proxy for productivity leads to a situation where more and more
// is being pushed into pipeline and ultimately is less efficient.
// Throughput is a better measure
// Analogy to freeways. Higher utilization is not more productive.
Little's Law
Delivery Time = WIP / Lead time
implies
Lead Time = WIP / Delivery Rate
thus
WIP is a LEADING metric for lead time.
Key metrics for identifying bottlenecks
- Leading indicators
- Queue sizes
- Batch Sizes
- Lagging indicators
- Velocity
- Other metrics:
- Rework costs
- Bug trends
Pay Attention to Queues
- CLOSE attention to queues...
- watch them like a hawk
Implement strategies to improve software quality.
- identifying process steps that introduce defects
- understanding the end-to-end quality process
- bringing quality efforts early in the development cycle
Conventional QA in the Modern App Lifecycle
- Late engagement of stakeholders functions
- Late detection of unmet requirements
- increased cycle times
- increased costs
Quality enablement practices
Continuous quality for continuous value delivery
- reduce mean time to repair (MTTR)
- acceptance test planning
- continuous acceptance testing
- testing in production
- team integration
- early detection of unmet requirements
- shortened cycle times
- reduced costs
Continuous acceptance testing -
- testing tools
- automated unit, integration, performance, load testing
- automated keyword, UI automation testing
- manual user, ad hoc testing
Implement strategies to reduce waste.
- identifying wasteful activities
- creating strategies to eliminate waste
- measuring the effectiveness of waste removal activities
What is waste?
- Inventory - Incomplete work. Work not in production
// code branch that is not in production
- Overproduction - Rarely used features
- Processing – Unneeded or excessive documentation / Looking for data
- Transport – Handovers, context switching
- Excessive Motion - Task Switching (Working on several projects in parallel, 20% loss)
- Waiting - Delays (caused by large batches, or too much work-in-process)
- Rework due to defects- Bugs
// in high performing teams, touch time is still only 20%. In ad hoc processes, touch
// time may be 1%
Dealing with Waste
- Finding Waste:
- Look for delays or bottlenecks in your software development.
- Work backward to identify the cause.
- The cause is likely wasteful.
- Eliminating Waste:
- Depends…
- Likely, focus on continuous improvement and cycle time reduction
- Key metrics:
- Cycle time reduction
- Rework costs
- Bug trends
Create a process improvement plan.
- creating strategies for implementing organizational change
- identifying key metrics to be tracked during the improvement effort
- creating consensus for the change
Key metrics
- Business value
- Rework costs
- Cycle time
- Bug trends
- Queue sizes
- Batch Sizes
EXAM BEST BETS
- Visit http://www.visualstudio.com/alm for an overview of the theory, and how theory
aligns with the Visual Studio tools
- Focus on reducing cycle time, speeding feedback, small batch sizes, breaking down
barriers, fast communication, minimally viable products and building quality in
- If you’re not convinced focusing on completing things faster with high quality is
the most important thing, fake it for the test.
- For tools, understand Storyboarding and the Feedback Client
*******************************************************************************************
MODULE 3
*******************************************************************************************
MSF for Agile Software Development
- Release version at TFS RTM was 6.0
- Best suited for teams that;
- Develop software in short iterative cycles
- Have open communication between team members
- Respond and adapt to change readily
- Do frequent deployment of their software
- Practice Scrum, XP, FDD or any other Agile methodology
Microsoft Visual Studio Scrum
- Release version at TFS RTM was 2.0
- Best suited for teams that;
- Have had Scrum training
- Use Scrum terminology
- Conduct Scrum ceremonies (Reviews, retrospectives)
- Use and maintain Product and Sprint Backlogs
MSF for CMMI Process Improvement
Capability Maturity Model Integration (CMMI)
- Release version at TFS RTM was 6.0
- Best suited for teams that;
- Develop in a more traditional waterfall manner
- Require a strong process driven workflow
- Are geared towards larger projects that are broken into phases and groups
- Are focused on gaining CMMI Level 3 appraisal
// Scrum teams can use CMMI process template
// process is distinct from template
// aligning template with process is a good idea
// for exam be famiiliar with all three templates
// possible to achieve CMMI Level 3,4,5 appraisal using Kanban
// if using waterfall, CMMI is template of choice
// template is written for agile teams trying to reach CMMI appraisal
// David Anderson developed Kanban, achieves some of the shortest cycle times
// take good ideas from Kanban, LEAN, Agile, Scrum...
// Agile and Scrum are most common in development
The Scrum Teams
- Scrum teams;
- Consists of a Product Owner, the Development Team and a Scrum Master
- Are self organizing and cross-functional
- Choose how best to accomplish their work, rather than being directed by others
outside the team
- The team model in Scrum in designed to optimize flexibility, creativity, and productivity.
- The ideal size of a Scrum team is between 3 and 9 members
// these rules are pretty immutable... changing them and you don't really have Agile/Scrum
// anymore...
// Three roles - Product Owner, Dev Team, Scrum Master
Roles – The Product Owner
- The PO is solely responsible for the Product Backlog. Accountable for;
- Clearly expressing Product Backlog items
- Ordering the items in the Product Backlog to best achieve goals and missions
- Ensuring the value of the work the Development Team performs
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and
shows what the Scrum Team will work on next
- Ensuring the Development Team understands items in the Product Backlog to the level
needed
// some stakeholders (like the CIO) might have significant sway on the backlog. Officially,
// the PO is still solely responsible.
Roles – The Development Team
- The Development Team consists of professionals who do the work of delivering a
potentially releasable Increment of “Done” product at the end of each Sprint.
- Development Teams have the following characteristics:
- They are self-organizing and cross-functional
- Scrum recognizes no titles for Development Team members other than Developer,
regardless of the work being performed by the person
- Individual Development Team members may have specialized skills and areas of focus,
but accountability belongs to the Development Team
- Development Teams do not contain sub-teams // fragmentation is bad
Roles – The Scrum Master
- The Scrum Master is responsible for ensuring Scrum is understood and enacted.
Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory,
practices, and rules.
- The Scrum Master is a servant-leader for the Scrum Team
- The Scrum Master can coach and guide the team but is NOT a Project Manager
- The Scrum Master removes impediments and facilitates Scrum events as requested or needed
// Scrum master is NOT a rebranded project manager
Scrum Events
- Sprint Planning Meeting
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Sprint Planning Meeting
- Plans the work to be performed in the next Sprint
- Is a collaboration between all members of the Scrum Team
- Time-boxed (2wk sprint = 4hrs, 4wk sprint = 8hrs)
- Meeting has two equal parts
- What will be delivered in the Increment resulting from the Sprint?
- How will the work needed to deliver the Increment be achieved?
Sprint Planning Meeting – Part 1 (50% timebox)
- What will be delivered in the Increment resulting from the Sprint?
- The Product Owner presents the ordered Product Backlog
- Inputs
- The Product Backlog
- The latest product Increment
- The past performance of the Development team
- Outputs
- A selection of items from the Product Backlog to go into the Sprint
- The Sprint Goal
** Only the Development Team can decide what goes into the sprint
** The Product Owner prioritizes items for the sprint, but the Dev Team
** decides what actually goes into it.
Sprint Planning Meeting – Part 2 (50% timebox)
- How will the work needed to deliver the Increment be achieved?
- The Development Team decides how it will build this functionality into a “Done”
increment
- The Sprint Backlog is the selection of items off the Product Backlog plus the plan
for delivering them
- Often the Product Owner attends this part of the meeting
// product owner can provide clarity, help in trade offs
- By the end of the Sprint Planning Meeting, the Development team should be able to
explain how it intends to work as a self-organizing team to accomplish the Sprint Goal
and create the anticipated Increment
Daily Scrum (stand-up meeting)
- A daily 15-minute time-boxed meeting for the Development Team
// usually held in the morning
- Used to synchronize activities and create a plan for the next 24 hours
- Each team member explains
- What has been accomplished since the last meeting?
- What will be done before the next meeting?
- What obstacles are in my way?
Sprint Review Meeting (2wk=2hr, 4wk=4hr)
- The Sprint Review Meeting is held at the end of the Sprint to inspect the Increment and
adapt the Product Backlog if needed
- The meeting should include the following elements;
- The Product Owner identified what has been “Done” (and not)
- The Development Team demonstrates the work that has been “Done” and answers questions
about the Increment
// no handwaving. work is either done or it isn't.
- The Product Owner discussed the Product Backlog as it stands
- The result of the meeting is a revised Product Backlog that defines the probable PBIs
for the next sprint
// timeboxing is very big in Scrum
Sprint Retrospective (4wk=3hr, 2wk=90mins)
- The purpose of this meeting is;
- Inspect how the last Sprint went with regards to people, relationships, process,
and tools
- Identify and order the major items that went well and potential improvements
- Create a plan for implementing improvements to the way the Scrum team does its work
- The Scrum Team may adapt the Definition of “Done” as appropriate to increase quality
// want to be an evolving team
// important to engage as a team
// we can evolve the definition of "done" if it makes sense to do so. Metric for code
// coverage... If we're not hitting our goals, might need to adjust "done". Important
// to balance goals appropriately, don't always have to increase.
Cancelling a sprint or iteration - Overview
- Only the Product Owner has the authority to cancel the Sprint, although he or she may
do so under influence from the stakeholders, the Development Team, or the Scrum Master
- A Sprint would be cancelled if the Sprint Goal becomes obsolete or if it no longer makes
sense given the circumstances
- Due to the short duration of Sprints, cancellation rarely makes sense
- Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon
// consult the Scrum Guide for reference
Cancelling a sprint or iteration - Process
- When a Sprint is cancelled, any completed and “Done” Product Backlog Items are reviewed.
- If part of the work is potentially releasable, the Product Owner typically accepts it.
- All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.
- The work done on them depreciates quickly and must be frequently re-estimated.
// team may be reluctant to cancel sprint because it's seen as failure.
// less cost in time and money if we just cut losses early
// building the wrong thing, budget changes, requirement changes can all render
// a sprint obsolete and appropriate to cancel. Some work items may need to go back onto
// the backlog with different priority.
Definition of “Done”
- When the Product Backlog item or an Increment is described as “Done”, everyone must
understand what “Done” means
- Although this varies significantly per Scrum Team, members must have a shared
understanding of what it means for work to be complete, to ensure transparency.
- This is the “Definition of Done” for the Scrum Team and is used to assess when work is
complete on the product Increment
- it is expected that their Definition of “Done” will expand to include more stringent
criteria for higher quality
// typically a team wants to excel and their requirements for "done" are excessive
// might start with fewer things, maybe add more things in the retrospectives as the
// process matures. Maybe team can put quality bars so that they can continue to meet
// business demands, while not limiting QA (refactoring, etc.)
Determining Sprint/Iteration Length
- Sprints are limited to one calendar month. When a Sprint’s horizon is too long the
definition of what is being built may change, complexity may rise, and risk may increase
- Sprints enable predictability by ensuring inspection and adaptation of progress toward a
goal at least every calendar month
- Sprints also limit risk to one calendar month of cost.
- Less certainty = shorter sprint duration
// if the situation is less dynamic, then a longer sprint may be more appropriate
// new teams might have a harder time meeting sprint goals, may take three or four sprints
// to really get into a cadence
// when the team is an expert Scrum team then sprint lengths can be anything
Backlog items not completed in a Sprint
- The Development Team should always try to select appropriate items from the Product
Backlog so they can be completed within a Sprint
- Incomplete work cannot be presented during the Sprint Review Meeting
// no credit for incomplete work
- Unstarted work can be returned to the Product Backlog for consideration accepting into
the next Sprint
- Frequently carrying incomplete work to the next Sprint can be detrimental to measuring
velocity
// important to "right size" sprint. Take items 1, 2, 3, & 5 because item 4 is too big
// very important that the items in a sprint are finished, pace should be sustainable.
// don't want people working the overtime deathmarch
Monitoring Sprint/Iteration progress
- At any point in time in a Sprint, the total work remaining in the Sprint Backlog items
can be summed. The Development Team tracks this total work remaining at least for every
Daily Scrum
// use burndown charts to make sure we're on track
// encourages team to work a bit harder to stay on track - self correction
- The Development Team tracks these sums daily and projects the likelihood of achieving
the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development
Team can manage its progress
- Scrum does not consider the time spent working on Sprint Backlog Items. The work
remaining and date are the only variables of interest
// some Agile methodologies capture original work estimates and actual time taken
// can be good for fast feedback.
//
// getting requirements gathering right in the beginning is important to reduce costs
//
// Scrum master role can be rotated - Devs can be Scrum Masters as well
// A product owner is a bit like a business analyst - turning vague requirements
// into good backlog items and user stories
// Presentation ended here.....
Establishing project drivers
- Scope-driven Projects
- you must wait to determine an end date until you have detailed estimates and a detailed
plan
- Planning overhead is increased
- Schedule buffering as a contingency against poor estimation will push the delivery date
out more, which increases costs.
Date-driven Projects
- Most software projects are date-driven because they can be delivered incrementally.
- Date-driven projects are common where an opportunity exists around a fixed date.
- Eg. Timing system for Olympic games swimming events
Assigning product requirements to iterations
- Representatives of the business stakeholders and the development team should work together to assign product requirements to iterations.
- Typically, you do this in a meeting, where you share or project the Office Excel view of the Product Requirements query.
- The assignment is completed by using the following pieces of information:
- The priority of the requirement.
- The estimated cost.
- Dependencies among the product requirements.
Work item unique to the CMMI template
- The MSF for CMMI Process Improvement process template is the only OOTB template that
has the following work item types
- Change Request
- Issue
- Risk
The Change Request work item type
Purpose
A team can use the change request work item to track a proposed change to some part of the product.
You can create a change request whenever a change is proposed to any work product that is under change control
The Issue work item type
Purpose
A team can use the issue work item to track an event or situation that might block work or is blocking work on the product
Issues differ from risks in that teams identify issues spontaneously, generally during daily team meetings
The Risk work item type
Purpose
Risk work items document a possible event or condition that can have a negative outcome on the project in the future.
A key aspect of project management is to identify and manage the risks of a project.
More information
For more information, review the topic Managing Change on the MSDN Library.
http://msdn.microsoft.com/en-us/library/ee461569.aspx
For more information, review the topic Managing Risks on the MSDN Library.
http://msdn.microsoft.com/en-us/library/ee461564.aspx
EXAM BEST BETS
Refer to the Process Guidance on the Microsoft website for each of the three OOTB templates
Create a matrix highlighting the key differences between each of the processes
Make sure you are familiar with all three processes, not just the one you may use at work
The Scrum Guide would be a good read for the Scrum process as well. http://www.scrum.org/Scrum-Guides
No comments:
Post a Comment