答案来了 – 用例子解释十个敏捷/精益的概念

这10个问题是我教“敏捷项目管理”课程时给的一个小测验（Quiz），参加上周CMMI2.0培训的熊会同学给了我一个惊喜，当天晚上就把她的答案发给了我。这里和大家分享下熊会（中文）和我MSE（Master of Software Engineering）学生（英文）给的例子，供大家参考！

1. 举例说明Story和Task的区别。

Use an example to illustrate the difference between a story and a task?

熊会同学的例子：

 用户故事：当用户打开小熊购物网站首页，希望在右下角看到根据以前购买和搜索信息推荐的物品清单。

task：从story分解成具体的开发任务，比如开发a要负责完成用户推荐算法ex11。

MSE学生的例子：

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.

2. 举例说明需求蔓延和需求进化的区别。

Give an example to illustrate the difference between requirement creep and requirement evolution.

熊会同学的例子：

需求蔓延：客户觉得昨天买的披萨很好吃，店家送的辣酱也不错，希望店家今天除了送辣酱，还能免费加送个烤牛排。

需求进化： 作为店家，新推出墨西哥披萨产品，新品配送的时候会随机赠送辣酱／甜酱，并收集客户反馈意见；发现成都客户反馈中选择辣酱并满意度高的占了90%，在后期墨西哥披萨正式上市，成都地区 配送选择精准赠送辣酱。

MSE学生的例子：

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.

3. 给出两个敏捷(Scrum)和精益（Kanban）的差异。

Name two differences between Agile (Scrum) and Lean (Kanban).

熊会同学的答案：

差异非常多，随便举2个例子：

1.角色定位不一样。

2.scrum按照迭代限制wip, kanban按照流程状态限制wip。

实际上现在很多公司在做scrum+kanban的融合探索。

MSE学生的答案：

Difference

Agile (Scrum)

· 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

Lean (Kanban)

· Timeboxing is optional. More emphasis on work  pulling

· Does not prescribe any roles

· Prioritization of work elements is optional

· WP estimation is optional

Difference

Agile (Scrum)

· 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

Lean (Kanban)

· 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

4. 举例说明估算和约束的区别。

Give an example to illustrate the difference between estimating and constraining.

熊会同学的例子

    估算和约束其实差异很大。举个例子，周末小朋友要给自己排时间表，我一般会让小家伙估计下每项作业时间，比如写完作文要多久，十分钟，还是十五分钟，基于他以往经验，小朋友会给自己估算下工作量和完成时间，这个叫估算。

    约束条件是指，我会告诉他，作文的字要写工整整齐，不符合要求要重写。然后小朋友会给基于这个约束条件给重新调整下作文完成的时间，比如加个2分钟。。因为写好字的时间增加了。

MSE学生的例子

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.

5. 举例说明合规活动和价值创造活动的差异。

Give an example to illustrate the difference between a compliance activity and a value-delivering activity.

 熊会同学的例子：

合规活动：很多年前，券商按照规定要求证券账户开户必须本人带上身份证去柜台才能办理。

价值创造活动：随着技术发展，部分券商开户支持线上app直接视频直接开户，给用户和券商都带来了更多价值和便利。

MSE学生的例子：

    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.

6. 举例说明旧公理和新公理的差异。

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.

熊会同学的例子

旧公理：只有把需求澄清清楚才能进入开发，实际上做出来的不一定是用户想要的，后期现场调整成本很大。

新公理：有时候用户并不知道自己真正想要什么，比如第一次做全自动化港口，因为没有人做过，所以先做个demo，同时做好架构设计以应对后期需求变化。通过快速上线后，不断通过实际运行做出最符合用户期望的产品。

MSE学生的例子

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.

7.  举例说明精益方法中“节奏”的概念。

Use example(s) to explain the concept of “Rhythm” in Lean method.

熊会同学的例子

    “Rhythm”最开始应该是源于生产流水线的节拍控制，精益里的叫法是“TaktTime”，（Takt是个德语词汇，表示像音乐节拍器那样准确的间隔时间），中文有翻译为“节拍”或者“节奏”，是20世纪30年代德国飞机制造工业中使用的一个生产管理工具。

    在精益生产中节拍时间是指为了满足客户的需求生产一个完整产品的节奏。从事生产应该像演奏音乐一样，按照节拍进行，不能忽快忽慢。如果你的节拍时间是每二分钟一个产品，这就意味着，每二分钟一件完整的产品离开装配线，而不应该有太多的流程等待时间。这个概念于20世纪50年代开始在丰田公司被广泛应用，并于60年代晚期推广到丰田公司所有的供应商。

    按节拍生产是精益生产的重要原则之一，一般做法是是通过在价值流中消除浪费来改进流程，创建连续流，让企业高质量低成本的在更短周期下交付产品和服务。（听起来是不是和软件敏捷开发交付目标比较类似？）

    在软件精益里也是借鉴了类似的概念，敏捷开发培训里常见的翻硬币的游戏和敏捷看板里控制在制品数量都是一些比较形象化的例子。主要目的是为了合理利用生产力，避免生产力限制和浪费，以提高需求吞吐率和提高需求从提出到上线的时间效率。

MSE学生的例子（注意这里讨论的是敏捷里的节奏）

    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.

8.      举例说明缺陷和技术债务的差异。

Use example(s) to explain the difference between “defects” and “technical debt.”

熊会同学的例子

缺陷：衣服破了个洞，赶快补补好继续穿

技术债务：衣服千疮百孔，而且还偏小了，先修补以满足现在需要，实际上，妈妈要赶紧存钱买件新的，要不明年就撑不过了。

MSE学生的例子

    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.

9.      举例说明“面向客户”的用户故事和“非面向客户”的用户故事。

Give an example to illustrate the difference between a “Customer-Facing story” and a “Non-Customer-Facing story”.

熊会同学的例子

     “ 面向客户”的用户故事：当客户打开小熊购物网站首页，客户希望在右下角看到根据以前购买和搜索信息推荐的物品清单。

“非面向客户”的用户故事：非客户视角的一些需求（比如面向生产后台人员的需求），举个例子，当网站页面发生故障，运维人员能快速从后台日志拿到对应错误提示信息以便快速找到故障原因并恢复正常运行。

MSE学生的例子

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

熊会同学的例子

举例：每轮迭代周期为两周。团队必须在两周周期内交付客户一个可用版本。在预算时间内对完不成的功能进行删减或者延迟，而不是拖延预算的时间。

MSE学生的例子

    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.