答案来了 – 用例子解释十个敏捷/精益的概念
这10个问题是我教“敏捷项目管理”课程时给的一个小测验（Quiz），参加上周CMMI2.0培训的熊会同学给了我一个惊喜，当天晚上就把她的答案发给了我。这里和大家分享下熊会（中文）和我MSE（Master of Software Engineering）学生（英文）给的例子，供大家参考！
Use an example to illustrate the difference between a story and a task?
Story: “As a user I would like the ability to view the current balance onmy bank account”
Task: Create test data to validate that the displayed bank account balance is correct.
Give an example to illustrate the difference between requirement creep and requirement evolution.
需求进化： 作为店家，新推出墨西哥披萨产品，新品配送的时候会随机赠送辣酱／甜酱，并收集客户反馈意见；发现成都客户反馈中选择辣酱并满意度高的占了90%，在后期墨西哥披萨正式上市，成都地区 配送选择精准赠送辣酱。
The important difference between a requirement creep and a requirement evolution is a degree of stakeholders’ inclusion indecision making. Evolution is a rational improvement of a requirement supported by consolidated and evaluated feedback of all project participants. Creep is an indiscriminate augmentation of a requirement driven by a disjoin effort of particular project stakeholders.
Imagine a situation where initial and greed project scope was to design a programmatic control of a specific power supply mainframe to automate power switching during testing. During the design it was discovered that the power supply uses a common interface architecture. The production floor has 5 variations of power supplies that appears to use this common architecture with only minor operational distinctions. The customer and design team decided to evaluate the viability of expansion of power supply programmatic control to a more abstract interface in order to make programmatic control operational of the entire family of devices. The customer realized the need of unavoidable future automation of production instrumentation while the developer verified the viability of the feature expansion. This is an example of a requirement evolution. Now imagine a situation where an instrumentation metrology and calibration board heard about automation efforts of power supply mainframes and decided to drive the agenda of feature augmentation to add instrument calibration reporting and notification elements. This feature has nothing to do with the initial project scope or vision and solely serves the agenda of asingle entity. This is an example of a requirement creep.
Name two differences between Agile (Scrum) and Lean (Kanban).
· Timeboxing is a prescribed part of the process. It used as a way to achieve short planning and commitment cycles
· Prescription of Roles (In Scrum PO, SM, The Team)
· Prescribes a prioritized Product Backloglog
· Work Product estimation is prescribed
· Cross-functional teams are prescribed
· Timeboxing is optional. More emphasis on work pulling
· Does not prescribe any roles
· Prioritization of work elements is optional
· WP estimation is optional
· Team commits to a certain amount of work to be completed within a timeboxed iteration. The items cannot be added during the ongoing iteration (practice strongly advises against altering commitments)
· Items are committed to iteration based on estimated complexity and priority and work-in-progress limited indirectly per sprint
· Work commitment is optional. New work items can be added to the process when sufficient work capacity is available
· Work is limited by limiting the size of work queues without commitment to any particular size as long as work pile up is avoided. Work-in-progress limited directly per workflow state
Give an example to illustrate the difference between estimating and constraining.
Estimating: Given the scope of this project, I estimatemy team can complete it in two months.
Constraining: We have government auditors arriving nextmonth. You have four weeks to complete this, and the scope is non-negotiable. Let’s find some temporary resources to help out.
Give an example to illustrate the difference between a compliance activity and a value-delivering activity.
For example, if my organization process dictates that in order to deliver a product to the customer I must first get through a series of pre-production signoffs, then during the development deliver structured development reports to receive more signoffs, then schedule and initiate pre-release activity with SQA and Change Control Board which mandates physical meetings that occur 2 times a month only, then navigate through the SQA sign-offs during the validation run, then complete a series of forms to perform version control tagging and archiving, then… you get the point. None of these activities deliver a value to my customer. These activities are compliance routines and roadblocks that the organization imposed to mitigate liabilities of their own mistakes, performance issues, over-budgeting, and legal audits. A value-delivering activity in this example would be organizing periodic customer meetings to demonstrate product viability and receive feedback, focus on priority-based development versus yield-based one, and fostering team environment that stimulates innovation and commitment to the customer.
Give an example to illustrate the difference between the Old Axiom and the New Axiom:
旧公理：第一次把事情做好。Old axiom: Get it right the first time.新公理：无论第一次做得多好，后续都需要变化，重要的是控制好变更成本。New axiom: No matter how good it is the first time, it is going to change, so keep the cost of change low.
Do not invest your technical and process excellence into a state-of-the-art product design because the state of this art is fluid and volatile. Instead of building a castle on a sand, approach the problem with underlying assumption that what is considered the best today, tomorrow will be just good, and next week it will become simply average. I feel that “getting it right the first time” approach is coming from Waterfall process where the focus is to invest as must time as possible to define as clear as possible requirements that will be fundamental to the best possible design. Except it just does not work. The only requirements that that are fully defines from the get-go are the ones that not even worth your time. Value is an emergent attribute of iterative refinement. What you will get the first time, even thought it may be right, the long-term value of it will likely be marginal because by focusing on immediate perfection you did not account for future adaptability. Customer value rarely comes in alump-sum at the delivery time; rather, customer value is being able to maintainthe product relevancy over its extended life-cycle.
Imagine that your deliverable is a corporate accounting platform. You start your development in early January and aim to deliver the best product on the market. You collect, analyze, and distill all the requirements, architect and construct an exemplary technical solution for B&B Whatever Co. and deliver it around October time. The customer is thrilled – the software is fast, accurate, easy to use, and increased the organization’s process yield. The like it so much, they want to expand it and add new features…and they want it around February next year. Unfortunately, you realize that your software is just too perfect in doing one and only one thing.You are unable to make the change by the deadline because of fundamental rework of architecture that is required. Luckily, your customer is still riding the wave of initial success and allows for partial feature delivery. You proceed with massive architectural changes, you are building another jewel, and try to predict customer future needs now so you don’t find yourself in the same situation – you “gold-plate” many features. However, in February you realize that new year’s tax code changes prompted company’s financial restructuring and all your past work is just way to “perfectly” rigid to accommodate these changes…and also they want their platform online.
This should come to no surprise that the company shortly found another software contractor. The moral is simple – Adapt or Perish.
Use example(s) to explain the concept of “Rhythm” in Lean method.
Rhythm means a steady cycle or repetition. It is defined most explicitly by the timeboxed sprints of Scrum. Each iteration has a consistent duration withrepeated activities that forms the core cycle of the project. A waterfall project is kind of like the dramatic line of a movie. It starts outcalmly with exposition (scope, requirements gathering), establishes conflict (scope and work breakdown vs. schedule and resource constraints), and the conflict and tension continuously increase through the development phase as complications arise and deadlines loom, resulting in a frenetic climax of crunch time and finally the relief of a post-release denouement. Agile projects are more like the dramatic line of a TV show over the course of a season. The components occur on a smaller, fixed timescale that repeats throughout the project/season. This lets audiences and team members experience the highs and lows more frequently in less overwhelming quantities.
Use example(s) to explain the difference between “defects” and “technical debt.”
If you imagine that during the validation activity you happen to find an execution route that has a potential to resolve itself inrun-time error and take down the system. This is an obvious defect. It is observable, and it factual, and it is fixable. Now, if you fix this defect,then this is pretty much the end of this. However, if you for some reason lose track of this defect – lost in documentation, lost in translation, lost in memory – then this defect has a pretty good chance of becoming a Technical Debt. In the future try explain why customer’s grid control mechanism went down for hours due to encountering a run-time run away issue and also try to explain why would this “bug” – that was known a few years back and was easy to fix- now will cost so much and so long to fix. You accumulated layers of Technical Debt on to of previously known Defect and effectively consolidated such Defect in a product architecture itself; the Defect is now the Architecture.
Give an example to illustrate the difference between a “Customer-Facing story” and a “Non-Customer-Facing story”.
Customer Facing story Ex: As a bank customer, I want to login, so that I can view my account.
Non Customer-Facing story Ex: Security of a bank system. Add STS (security token service) authentication feature to protect the systems, its data and avoid cyber crime.(Quality Attribute: Security).
10. 举例说明HighSmith（敏捷领军人物）给的“时间盒”用途。 Mr. Highsmith points out “In my early years of iterative development, I thought timeboxes were actually about time. What I came to realize is that timeboxes are actually about forcing tough decisions.”
XYZ Software, Inc. develops embedded software for mobile phones. A release date forthe phone has already been announced and the software team is working hard to develop some cutting-edge applications for the phone. They know that these applications will give them a competitive advantage. The competition is also going to release a similar phone with similar features at around the same time. XYZ Software realizes at their last iteration that they plan to release 5 more features than the team can handle (based on the team’s velocity) before the deadline. They have a total of 16 features, but the team can only finish 11. The product team, development team and executive sponsor must figure out which 11 features are most important and will give them the greatest competitive advantage. This is an example of a timebox, not only based on the team’sapplication of agile principles, but a timebox also imposed on them by themarket. It illustrates tough decisions that must be made to release a product.The decisions are tough because their sales may suffer if they make the wrong decisions.
《答案来了 – 用例子解释十个敏捷/精益的概念》来自互联网，仅为收藏学习，如侵权请联系删除。本文URL：http://www.bookhoes.com/794.html