3.敏捷项目管理模型<br>
构想
代替较传统的“开始”，指出构想的重要性。确定产品构想、<br>项目目标和控制要素、项目目标和控制要素、项目社团以及团队如何共同工作<br>
构想阶段为客户和项目团队创建构想，该构想包括什么、谁提供提供和如何提供。首先，我们需要构想提供什么，即产品及项目范围构想;其次，我们需要构想参与者都有谁；客户、产平经理、项目团队成员和利益相关方组成的社团；最后，项目团队成员必须构想他们打算如何共同工作
*可交付的产品：产品构想框；项目数据表——项目目标声明、企业目标、性能、性能价值<br>*可靠的、适应性强的产品：项目数据表——质量目标<br>*在可接受的约束内：项目数据表——均衡矩阵（范围、进度和成本）
产品体系结构的目标是描述项目内部沟通渠道，是一种促进探索和知道正在进行的产品开发的设计。一个早期的“骨架”产品体系结构不仅能知道技术工作，也能指导执行技术工作人员的组织工作。它旨在把较大的项目背景传达给开发团队，而不是局限于一个设计。
项目数据表是用一页概括主要商业和质量目标、产品功能和项目管理信息。这是一个简单却又重要影响力的文档
当项目启动的时候，项目计划保持在价值、质量和约束三者之间的健康平衡非常重要。当这个平衡被打破的时候，权衡矩阵就开始发挥作用
团队在某个具体项目选择和裁减做法
哪些做法是必需的？<br>还需要哪些辅助性做法？<br>需要对选择的做法哪些修改？<br>做法的编档、批准和更改需要什么手续和形式？
在构想阶段后，构想并没有停止。在每次迭代的开头，团队在一起思考下一次迭代时，团队成员需要重新审视该构想。重新审视的目的是为了修改这个构想，或者在紧张的日常工作之余，提醒团队他们努力的目的地在哪里
推演
收集初始的、广泛的产品要求
将工作量定义为一个产品功能清单<br>
制订一个迭代的、基于功能的交付计划<br>
产品经理控制哪些功能应该包含在产品中，而开发工程师控制功能的设计和实施方式。<br>产品经理没有全力说，“我们落后了，让我们缩短测试时间吧<br>
如果我们想要适应性、灵活性、创新以及对客户了解到的新信息做出相应，就需要奖励团队对这些变化的响应，<br>而不能因为团队成员未能“实现计划”而警告他们<br>
敏捷开发是关于焦点和平衡的：集中于项目的主要构想和目标，强迫做出困难的权衡决策，以保持产品各方面的平衡
当进度出现问题的时候，瀑布式方法所见任务，通常是减少测试，而敏捷方法减少功能，前者降低质量，后者缩小范围
把风险降低策略纳入计划
估计项目成本，并生成其他必要的行政管理和财务信息
探索
在短期内计划和提供它精测试的功能，不断致力于减少项目不确定性
通过管理工作量和使用适当的技术方法和风险降低策略，按计划交付产品功能
设定迭代长度时应该遵循3个标准：交付用具价值功能块（故事）、构建和测试故事（可工作的软件）和产品团队对的验收
工作量管理旨在让团队成员自己管理必要的日常任务，以便在每次迭代结束时交付故事。<br>团队成员应该尽可能地管理自己的工作量。每个人你和整个团队都对交付他们在迭代计划中承诺的结果负有责任<br>
项目领导者主要是通过制定业绩目标（故事、质量目标、所需的做法）并监督其实施（不用微观管理）<br>，而不是通过制定任务进行监督管理。<br>
当产品开发团队对卓越技术做空口承诺时，当项目和产品经理促使团队仓促而不是迅速地工作时，就会招致技术债务
重构不应该成为草率设计的借口，我们的目标不是重构，而是保证可行的、适应能力强的设计，这就要求每个步骤都有优秀的设计做法。
建立协作的、自我组织的项目社团，这是每个人的责任但需要由项目经理和迭代领导者推动<br>
如果从根本上来讲，你不信任别人，那么在任何情况、任何时间、人们都不吭能突然值得信赖。<br>对于极少数真正不信赖的个人，优秀的领导者有一个解决方法，就是将他们从团队清理出去，而不是用难以负担的控制折磨整个组织
适应能力强的团队的一个信条是创新源自于不同背景的个人相互交流，每个人都有各自的想法，每个人都将信息和观点贡献给开发流程
交往规则：建立关系、确定做法和做决策。建立关系的规则是：鼓励开放、坦诚的沟通；确定做法的规则是：<br>迭代长度将为2个星期；做决策的标准规则是：没有偷工减料（以质量为导向的规则）<br>
每日站会不应该是用来解决问题，而只需要确认问题，一旦确认问题，有关团队成员会在会议结束之后聚在一起对这些问题加以解决
管理团队与客户、产品经理和其他利益相关方的项目交流
适应
没有最好的做法，只有更适合具体情况的做法
客户或产品团队通过客户中心组的参与和延时实际的产品，从而进行产品的验收测试，仍然是最重要和最有益的敏捷做法之一
4.敏捷项目扩展
敏捷项目扩展
大型项目存在的问题包括日益增加的官僚主义、过多的文案工作、无法管理的通信网络和缺乏灵活性
敏捷是一种理念，一种思维方式，而不是一套做法或流程
沟通设计之所以困难是因为它取决于一系列关系的基础——信任、尊重和接收文化差异和共享信息。
决策小结：<br> 团队：体系结构<br> 任务：开发应用数据模型<br> *受影响团队，所有功能团队和几个专业团队<br> *提供信息团队，基础团队，挑选几个功能团队<br> *参与讨论：基础团队有两名体系结构团队的兼职成员，来自第N个功能团队的一名高级设计师<br> *决策者：体系结构团队<br> *决策结果传播：给所有团队负责人Email.<br> *决策审核：无
文档支持沟通和协作、促进知识传播、保留历史信息、帮助改进产品和满足法律法规的需要。他们并非不重要，仅仅是不如可行的产品版本重要
敏捷方法和以文档为中心（或以模型为中心）的方法之间的问题并不是文档过多或者没有文档的问题，而是正确组合文档和交互方式以促进理解和沟通的问题。敏捷主义者倾向于交互方式，而传统方式主义者倾向于文档
敏捷文档的指导原则<br> *根本问题是知识转移——理解而不是文档<br> *知识转移需要人与人的交互，特别在知识复杂性增加时<br> *文档应该刚刚足够，但不能不够，使用概括文档而不是详细文档<br> *文档应该进可能地非正式——白板、挂图、数码照片，维基等<br> *交互的、动态的文档对于敏捷项目非常重要<br> *可行的软件是开发目标之一，促使该软件的改进是目标侄儿，考虑用刚刚足够的文档来支持两个目标的实现<br> *文档需求因行业、公司和项目的不同而各异<br> *用户文档应该和故事一样被确定下来，并由客户排优先级<br>
交往规则<br><br> *对于影响自身工作的体系结构决策，功能团队可提出自己的意见，并且可以参与决策过程（可能要限制参与表决的团队数量）<br><br> *有权对任何体系结果变化所带来的影响进行评估，并相应地调整自己的估计方法和进度计划<br><br> *当团队对某项体系结构决策的否决权置之不理时，有权请求产品和项目经理就该决策进行审核<br><br> 体系结构团队<br><br> *有权及时得到拟定的体系结构计划的各种信息和反馈<br><br> *在功能团队实现体系结构决策时遇到问题时，有权及时收到相关的通知
<b>不要把项目中存在的一般问题都归因为敏捷问题，不管使用什么方法，都会产生这样的问题</b>
治理敏捷项目
有关项目治理，主管对两件事情干兴趣——投资和风险
治理是在不确定环境中制定投资决策。主管必须制定投资决策，确定投资回报率（ROI）并且评估获取该投资回报率的概率。投资回报率有3个组成部分；产生的价值（资金流入）、消耗的成本（资金流出）和时间（流入和流出的时机）、主管必须回答两个基本问题：预测的项目价值和投资回报率是什么？获取这个回报率的概率多大？
概念阶段要实现两个首要目标，创建并确定产品构想以及识别和降低风险。构想包括产品构想、营销构想、财务构想和团队构想。风险包括市场风险(我们能卖出去吗)、技术风险（我们会构建吗？）、财务风险（我们能赚到钱吗？）。概念阶段也是为了验证概念，而不是研究项目的可行性或识别风险。
大多数公司花费太多的时间定义阶段、确定过程。如果把这些时间花费在思考决策关卡和通过这些关卡需要具备哪些信息时，将更有意义。
评估敏捷绩效
约束越严格，团队拥有的灵活性越少，团队交付最高优先级结果的可能性就越少
项目管理归根结底与两件事情有关：管理人和管理决策
评估团队的相对业绩而不是按照计划衡量团队的产出，一个明显优势是这种评估方式对于改进没有设置上限（目标）。因为一切都是相对的，所以优秀的团队会努力做得越来越好，而不是试图满足目标。
我们的绩效系统必须建立在正确的意愿之上——去指引，而不是惩罚；去学习，而不是重复；去适应，而不是拒绝改变。如果我们想要建立适应型组织，那么必须撅起固定的绩效合同，而去追寻一种符合这些新的意图的评估系统
一次自己的项目体验
由于新人的加入，版本缺陷暴增，交付时间产出不足
来自外部的压力、统计相关度量指标，引入问责机制
我的处理方式：
强调敬畏代码，自我负责
加强沟通，老带新
弱化问责机制带来的负面影响
可靠的创新笔记<br>
重要的是要记住，任何产品、任何组织都不可能在各个领域做到无限的敏捷
思维组织如同一个活的有机体，其中应变是生命力和生存的关键。过渡僵化和详细的计划必须屈从于结合了较少计划和较多应变的策略
.试验之所以重要是因为通过了解到什么是有效的、什么是无效的，人们开发出来优秀的新产品、服务和使整个商业得到发展，尽管人们对’测试‘和’从失败中学习‘满是赞誉之间，但如今的组织、流程和创新管理常常阻碍试验
如果不能给客户交付价值，任何项目团队都不可能长期存在。但从长远看，如何交付产品、如何在工作中交互、如何相互尊重则更加重要。
以客户为中心——向客户交付价值，也以技术为中心——支持卓越技术以便能够在未来继续交付价值。领导帮助团队专注于交付产品，同时最大限度地较少合规工作的干扰
朋友，在那个年代人们有得是信仰；而我们现代人有的是观点，仅有观点是不足以建造哥特式教堂的。仅有观点也不足以创造产品和适应能力强的组织。如果我们希望创造优秀的产品和更好的工作场所，就需要有深刻的信仰和坚决的承诺，需要有建立在核心价值观和原则基础上的流程和实践
优秀的产品来自于优秀的团队：有原则，有特征、有信仰、有毅力和有勇气的团队
扩展：如何在结构内创新
