2023年开年，给自己定了学习目标，首先要计划学习一下项目管理方面的内容，于是从京东上买到了《敏捷项目管理·第3版》进行阅读。计划在2023的Q1将其看完，会将其中重要的内容整理到简书中。
敏捷宣言-价值观（2001）：个体和互动高于流程和工具；可工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。
第一章 项目管理现代化
瀑布式项目管理：只有在前一个阶段完成之后，才能进入到下一个阶段。它大体包括以下阶段：需求-->设计-->开发-->集成-->测试-->部署。
传统项目是指为实现商业论证中计划的特定收益而进行的临时性的团队工作。项目通常在可交付物投入生产后结束，由其他团队对后续运营工作提供支持并评估项目对业务的影响。
而如今，产品被认为是长期性的、创造价值的资产，需要永久性团队以迭代的方式对其进行细化、设计、开发、测试、集成、归档、支持，直到实现商业成果。
稳固的永久性团队能够实现信息透明、自我检查和自我调整（经验过程控制）。理想情况下，永久性团队成员表现得更像一个家庭。
敏捷产品开发是通过构建可使用的、功能完善的产品增量，并在产品开发过程中不断收集和实现客户反馈来不断迭代，以减少不确定性因素。通过敏捷产品开发持续交付客户价值，增加了获得额外资金的可能性。
在敏捷产品开发中，产品功能的优先级是由对要解决的问题最熟悉的人决定的。敏捷团队不再遵循大量文档化的规范，而是力求获得客户的真实反馈。
敏捷产品开发失败率下降的原因是敏捷团队在频繁地检查进展和客户满意度的基础上对产品进行即时的调整。（传统项目失败率29%，敏捷项目失败率只有9%）
第二章 运用敏捷宣言和原则
个体和互动的优点：①沟通是清楚和有效果的；②沟通是快速和有效率的；③因为人们在一起工作，所以团队工作变得强大；④开发团队能够自组织；⑤开发团队有更多机会去创新；⑥开发团队可以根据需要迅速调整流程；⑦开发团队成员能为产品担负主人翁角色；⑧开发团队成员能有更高的工作满意度。
在敏捷产品开发中，衡量是否真正实现产品需求的唯一标准是生产出与该需求相对应的可工作的功能。
敏捷方法论总是将客户看作产品开发的一部分。合作而非对抗能够产出更好、更精益、更有用的产品。
变化是构建伟大产品的有价值的工具。通常如果能快速响应客户、产品用户和市场，团队就能开发出符合人们需要的、有用的产品。
变更对于产品开发团队而言是意料之中的，而非颠覆性的。
敏捷12条指导性原则：
（1）我们最优先考虑的是：通过尽早和持续不断地交付有高价值的软件来使客户满意。
（2）即使在开发后期也欢迎需求变更。敏捷流程利用变更为客户创造竞争优势。
（3）采用较短的项目周期（从几周到几个月），不断地交付可工作的软件。
（4）业务人员和开发人员必须在整个项目期间每天一起工作（相互合作）。
（5）围绕富有进取心的个体而创建项目。为他们提供所需的环境和支持，信任他们所开展的工作。
（6）不论团队内外，传递信息效果最好且效率最高的方式是面对面的交谈。
（7）可工作的软件是衡量进度的首要标准。
（8）敏捷流程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。
（9）坚持不懈地追求技术卓越和良好设计，从而增强敏捷能力。
（10）以简洁为本，最大限度地减少工作量。
（11）最好的架构、需求和设计出自自组织团队。
（12）团队定期地反思如何能提高成效，并相应地调整自身的行为。
以上的12条核心原则可以有4种组合方式：客户满意（1，2，3，4）、质量（1，3，4，6，7，8，9，12）、团队工作（4，5，6，8，11，12）、产品开发（1，2，3，7，8，9，10）。
让客户满意的敏捷策略：①在每次迭代中，首先产出最高优先级特性；②理想情况下，把产品负责人和其他团队成员集中在一起办公，以消除沟通障碍；③把需求分解成可以在短期迭代中交付的小价值模块；④书面需求越简单越好，推进更加积极有效的面对面沟通；⑤当每项功能完成时，让产品负责人进行验收；⑥定期重新回顾/检查特性列表，以确保最有价值的需求始终具有最高优先级。
质量管理策略：①在产品开发之初定义“完成”意味着什么，然后使用该定义作为高质量产品的标杆； ②通过自动化方式每天进行积极的测试； ③根据需要，仅构建哪些必需的功能；④评审软件代码并进行精简重构；⑤向干系人和客户只展示被产品负责人验证过的功能；⑥在每天、每个迭代以及整个产品生命周期中设置多个反馈点。
促进团队有效工作的策略：①开发团队集中办公，为有效的、实时的沟通扫清物理障碍。②构建一个有利于协助的物理环境。③构建一个鼓励团队成员说出他们想法的环境。④尽可能面对面沟通，如果通过交流能处理问题，就不要发电子邮件。⑤如果有需要，当天就澄清所有的疑问。⑥鼓励开发团队自己解决问题，而不是让经理为开发团队解决问题。⑦抵制对团队成员进行洗牌的诱惑，努力使团队成长为一个稳定、永久、高绩效、能力不断提升的团队。
成功的产品开发的敏捷方法：①为开发团队提供实时的问题解答，使其免受竞争的优先事项的影响，赋能团队制定解决方案并决定每次迭代中要完成的工作量；②制作“刚好够”的文档；（“刚好够”是褒义词，意味着项目中的任务、文档、会议或者几乎所有需要创建的东西达到实现目标的程度即可。）③精简状态报告，使开发团队能够短时间把信息推送出去，而不是让项目经理花费大量时间来提取有用的信息；④最小化非开发任务；⑤树立信心，认为变更是正常且有益的，而不是让人惧怕和躲闪的东西；⑥采用准时制的需求细化方式，以最大限度地减少变更干扰或工作浪费；⑦与开发团队合作，建立现实的进度计划与目标；⑧保护团队远离组织安排的、与产品目标无关的工作，这些工作可能影响产品目标的完成；⑨理解工作与生活的适当平衡是高效开发的组成部分；⑩将产品视为长期投资，需要永久性团队追求价值高于遵循规范。
在第三版教材中，作者增加了3条“白金原则”：抵制形式化；将团队视为整体的思考与行动；可视化而非书写。
敏捷石蕊测试
（1）我们此刻的所作所为对有价值的软件的尽早和持续的交付是否提供了支持？
（2）我们的流程是否欢迎变更并能够从变更中获得好处？
（3）我们的流程是否能够引导并支持可工作软件的交付？
（4）开发人员和产品负责任是否每日在一起工作？客户和业务干系人是否与团队紧密合作？
（5）我们的环境是否给予团队完成工作所需的支持？
（6）我们面对面的沟通是否比电话或者邮件沟通更多？
（7）我们是否通过所开发的可工作的功能的数量来测量进展？
（8）我们是否能长期维持目前的开发步伐？
（9）我们是否支持那些考虑未来变更的卓越技术和良好设计？
（10）我们是否最大化了不必要工作量？换言之，为实现客户的产品目标，我们是否尽可能少的只做必要的工作？
（11）开发团队是否是自组织与自管理的？他们是否具有迈向成功的自由？
（12）我们是否进行定期的反思并相应地调整我们的行为？
如果你对所有这些问题的回答都是肯定的，那你可能变得更敏捷。如果你对任何一个问题的回答是“否”，那么你能做些什么样的努力才能将这项问题的回答改为“是”？
