1）传统预测性软件开发流程的使用是导致如此之多项目失败的罪魁祸首。预测性流程也叫瀑布式流程，其可行性依赖于项目计划的准确性和执行的严格性。
2）YDC为什么软件开发能成功？
1.需求的控制
2.开发工具及框架控制
3.开发人选及流程控制
需求。无变更风险时确定性最高。随着不明确因素、涌现式描述和可预见性变更的增多，确定性降低。 技术。所用技术为人熟知时确定性最高。随着开发及运营技术复杂度的提升，不同的技术在不同的软件开发和发布阶段通过接口交互，确定性随之降低。 人。确定性随着人员数量的增多而降低。当人员数量超过4个或者5个，甚至达到上百个并经常改变时，确定性不断降低，因为不同的人有不同的意见、态度和情绪。以团队或分组方式工作时，成员间的互动和工作的不可预见性是巨大的。
3）
斯黛西图（Stacey Graph）是用来评估工作中的确定性和可预测性的有效工具。 [1] 斯黛西图用于度量不同维度的工作的确定性和不可预见性，并标示出工作范围。我们用它来为软件开发中的三个维度建模，这三个维度分别是需求、技术和人
4）
由于PTC现在能够在30天内开发出完整的功能，因此开发人员能够在任意适合的迭代中和客户直接交流。他们能够更直接地了解需求，以及如何更好地实现它们。客户也发现了这样的改变，开始在每个迭代中和开发团队一起工作。他们积极参与定义功能，得到了真正想要的功能。
开发和客户沟通的结果要不要有文档记录下来？沟通时是不是有测试参加？没有的话，后期测试的标准是什么？
5）
总的来说，我们发现小团队最适合进行这种迭代增量式的软件开发工作。这里所说的小团队，一般来说应该由3~9人组成。团队总体应该拥有将需求转化为功能增量所必备的技能，从而实现你的愿景。根据开发的软件类型，团队中的成员应该具备编程、测试、设计、分析、编写文档、设计架构等技能。我们希望通过调整团队结构、提高工程实践能力和建立规范来塑造团队特质，提高团队的生产率、质量、创造力和持续改进的能力。 我们对高效软件开发团队的见解，大量地参考了竹内弘高和野中郁次郎的研究结果 [1] 。他们曾经在哈佛大学进行关于团队流程的研究。他们调查了拥有较高目标的自主团队，其团队成员积极地相互学习，以短期迭代为主要工作方式。这些团队之间紧密的协作能够缩短知识更新周期，从而有助于创新和更快地响应市场，获得高质量的结果。这些团队让他们想起了英式橄榄球，于是他们把这种项目管理方式叫做Scrum——英式橄榄球中球出界后重新开始比赛的仪式。
最合适的人员比例分配？需求分析1，架构编码3，UI设计1，测试2，PO1，8名团队成员！
6）
以下问题都有可能在迭代中发生，需要进行讨论。
开发的功能太少了。
作为一个开发团队，他们总是努力在每次迭代中都完成至少一个业务功能，无论这个功能有多么小。然而，有些时候团队有可能在迭代中只开发出了很少或者是不可用的功能。这有可能是团队需要在迭代中掌握大量新技术、进行架构设计或自动化测试，占用了开发功能的时间。也可能是因为开发人员本身不够出色，无法按时按量完成任务，需要重新接受培训或者被替换掉。
交付的功能与实际需求差距太大。
副总裁可能会发现团队并不能理解他想要的东西。他需要和团队更加紧密地工作，才能更好地向团队传达愿景和澄清需求，从而保证对方完全明白他的想法。如果团队对这款软件和基金管理了解甚少，他可能需要花更多的时间和他们交流，或者寻找新的团队成员。
团队成员在迭代中感到不知所措。
试点团队的成员可能感觉迭代工作像是在学习一种新的舞蹈。他们需要找到不同的工作方式，既让大家都感觉良好，又能产生更好的结果。
团队成员之间完全无法一起工作。
团队成员之间的工作方式需要检视。这个时候也许需要从外部引入一位引导者，帮助他们更好地沟通或者做出更好的决定。有时可能需要重组团队。当然，在这种情况下，之前所获得的经验也就丢失了。 根据讨论的结果，试点经理要求团队成员提出一些建议，即在接下来的迭代中应该如何改变才能提高工作效率。
7）
下，之前所获得的经验也就丢失了。 根据讨论的结果，试点经理要求团队成员提出一些建议，即在接下来的迭代中应该如何改变才能提高工作效率。
8）
相信你的员工能做更多 团队中真正干活的人是找出解决方案的最佳人选。这种想法与很多管理层教导式的思想相背离。过去，需要一位经理来设定目标和实现方法，然后团队按照他的计划工作。但是，这样所有人的能力都会受到经理自身的经验、见识和智慧的限制。
相信你的员工能做更多 团队中真正干活的人是找出解决方案的最佳人选。这种想法与很多管理层教导式的思想相背离。过去，需要一位经理来设定目标和实现方法，然后团队按照他的计划工作。但是，这样所有人的能力都会受到经理自身的经验、见识和智慧的限制。 如果团队成员可以自由决定应该做什么，他们就能够根据实际情况进行调整。他们可以分享各自的想法和技能，共同找出最好的解决方案。他们可以先尝试一种方案，如果不可行，再尝试别的方案。这就是我们所说的“自组织”。这种在团队中集思广益而不仅仅依赖于经理个人想法的管理方式，能让团队的所有成员尽其所能。 在自组织的方式里，经理的任务是设定目标、帮助团队和扫除障碍，团队成员被授予了充分的自主性。
这种东西在中国能不能行得通？效果怎么样？有待在实际项目中检验！
经验型软件开发流程在组织里能有多成功，很大程度上取决于组织的管理层，及其在面对以上这些变革时的领导力和影响力。
9）
我们把这种情形叫做Scrum PRN [1] 。正如p.r.n.的药物控制由护士/护工或者病人本人决定，当你面对重要的机会或巨大的挑战，需要短时间内开发出软件时，可以快速地实施Scrum PRN。为了解决危机或把握稍纵即逝的机会，应该特事特办，使用不同的工作方式。Scrum PRN并不需要得到专门的批准。组织对软件的急切需求就是最好的授权。 [1]. 对PRN或者pro re nata的解释之一是“当环境需要的时候”。医学处方上的prn的意思是“当必要时服用”或者“当需要时服用”。
10）
据斯坦迪什组织估计，50%的软件功能很少甚至从未被使用 [1] 。例如，80%的客户只使用大型网站hp.com中14%的功能 [2] 。因此，为了优化价值，产品负责人必须决定何时停止后续Sprint，以保证交付的功能都是高价值的。按照这样的策略，完成项目所需的时间只需要原来的40%。只要持续关注开发的价值，就能获得这样的生产率。
11）
我们知道可以利用Scrum应对挑战，把握机会。在第一个Sprint开始之前，通常我们都想知道项目大概需要多长时间以及成本是多少。我们可以先进行几个Sprint，然后通过这几个Sprint得出的数据使用外推法对整个项目的成本有个初步的估计。
12）
Sprint的长度永远不要超过一个月。
13）
在一个项目内保持Sprint的长度一致 尽可能在一个项目中，从第一个到最后一个Sprint，让所有Sprint的长度保持一致。软件开发团队在保持一定速率的时候表现最好，因为他们形成了自己的节奏。
14）
项目级Scrum再进一步就是成立Scrum工作室——一个长期运营的，可以让Scrum软件项目快速启动的机构。这个软件工作室在是组织内的一个全新、独立的机构。有些组织用Scrum工作室来运营所有项目。当然，也可以只运营具有一定复杂程度、规模或者风险的项目。就像PRN的Scrum一样，在工作室中使用Scrum解决了在企业里全面推广Scrum时可能遇到的潜在困难和问题。 软件工作室又叫做软件工厂 [1] 。然而，通常来说工厂意味着重复和标准化的简单工作，软件开发却恰恰相反。
15）scrum工作室协议
16）
在向Scrum转型的过程中，整个企业会发生剧变，所有人都在一种可控的混乱中工作，而这种状态会持续几年。但最终，软件的每个版本会变得越来越好，员工都很乐意来上班，客户也开始乐于和企业合作。然而，企业转型成功与否取决于发起转型的高管。我们已经见过太多例子，在企业内的其他人还没有真正懂得如何用新的方法思考和工作，转型还没有在企业内扎根时，发起人就由于晋升或离职离开了原来的岗位。当发起人高管离开之后，之前取得的进步将灰飞烟灭，而刚被掩埋却没有根除的旧文化又会卷土重来。之前取得的优势和持续改进的习惯也会随着时间的推移渐渐减弱。尽管企业仍然比实施Scrum之前优秀得多，但是它本可以更优秀。人们也变得小心谨慎。在发起人离开的几年之内，企业不会比开始转型前更差，却称不上是真正敏捷的Scrum企业。这样一来就错过了彻底转型的机会。 回顾笔记时我们发现，在我们所知道或者亲身参与过的企业转型中，一旦发起的高管离职，几乎都不可避免地发生了上述这些问题。
17）
在企业转型过程中必须谨记的两个忠告。 1.不要试图改变Scrum Scrum不是可以被随意修改以迎合现有企业文化的流程。相反，企业的文化应该进行调整来适应Scrum。在Scrum中，阻碍本书所描述的软件开发方式的文化障碍将无所遁形。对于一个企业来说，Scrum就像是“煤矿里的金丝雀” [1] 。如果没有用Scrum建立敏捷、透明的开发环境，那么隐藏的问题将会一直留在企业内损害企业的利益。这个时候就失去了使用Scrum最主要的好处。 2.不要犹豫 不要认为企业转型是件容易的事。开始策划一件有价值的事情的时候，目标明确、身体力行以及建立氛围都是非常重要的。一旦开始使用Scrum，就能更容易地找到最主要的障碍。过度计划和过度思考是很多企业中常见的问题。但是，这并不是Scrum的初衷。Scrum所需要的是实际行动、测试、评估、学习、移除障碍，然后用更多行动来为大家创造有价值的
18）
用Scrum的方式实施Scrum就是利用Scrum的流程来实现组织的转型。要成功实施Scrum，组织必须进行两项主要改变。首先，软件开发人员必须组成小团队，并学会如何使用Scrum进行软件开发。其次，移除所有有碍于优化创新和软件交付的障碍。这些障碍会随着Scrum的使用逐渐显现。第一项改变能够提升软件交付的能力，第二项改变则可以为提高生产效率和投资回报率清除障碍。这两项改变都具有挑战性，也需要努力才能达成。它们是转型工程的核心，因此无论管理层有多强烈的愿望或者决心推进Scrum，都不能在这两方面节省时间。
19）
Scrum的经验型流程模型
