#头条创作挑战赛#
本期的主要笔记内容是敏捷项目管理的12条原则
客户满意的敏捷原则
第1条 我们最优先考虑的是通过尽早和持续不断地交付有价值的软件来使客户满意。
第2条 即使在开发后期也欢迎需求变更。敏捷流程利用变更为客户创造竞争优势。
第3条 采用较短的项目周期（从几周到几个月），不断地交付可工作的软件。
第4条 业务人员和开发人员必须在整个项目期间每天一起工作。
贯彻落实以上原则的方式：
- Scrum团队设置产品负责人(Product Owner)，由其负责把客户心中想要的翻译成产品需求。
- 产品负责人根据业务价值或风险对产品特性进行优先级排序，并与开发团队进行沟通。开发团队在较短的开发周期（称为“迭代”或“冲刺”）中交付列表中最有价值的特性。
- 产品负责人每天保持深度参与，以便澄清优先级和需求、做出决策、提供反馈以及快速解答产品开发过程中突然出现的许多问题。
- 频繁地交付可工作的产品特性，让产品负责人和客户对于产品开发状态有全面的了解。
- 随着开发团队每1~8周或更短时间持续交付完成的、可工作的和潜在可交付的功能，整个产品的价值随着它的可用功能的增加而逐步提升。
- 客户的投资价值是通过在产品开发过程中定期收到新的、可使用的产品功能而不断累积的，并非通过等到最后一刻才第一次甚至是仅有的一次交付可发布的产品特性来体现。
当客户不满意时，敏捷如何能加以帮助
质量的敏捷原则
第1条 我们最优先考虑的是通过尽早和持续不断地交付有价值的软件来使客户满意。
第3条 采用较短的项目周期（从几周到几个月），不断地交付可工作的软件。
第4条 业务人员和开发人员必须在整个项目期间每天一起工作。
第6条 不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈。
第7条 可工作的软件是测量进展的首要指标。
第8条 敏捷流程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。
第9条 坚持不懈地追求技术卓越和良好设计，从而增强敏捷能力。
第12条 团队定期反思如何能提高成效，并相应地调整自身的行为。
贯彻落实以上原则的方式：
- 在产品开发之初定义“完成”意味着什么（也就是可交付），然后使用该定义作为高质量产品的标杆；
- 通过自动化方式每天进行积极的测试；
- 根据需要，仅构建那些必需的功能；
- 评审软件代码并进行精简（重构）；
- 向干系人和客户只展示已经被产品负责人验收过的功能；
- 在每天、每个迭代以及整个产品生命周期中设置多个反馈时点。
团队的敏捷原则
第4条 业务人员和开发人员必须在整个项目期间每天一起工作。
第5条 围绕富有进取心的个体而创建项目。为他们提供所需的环境和支持，信任他们所开展的工作。
第6条 不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈。
第8条 敏捷流程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。
第11条 最好的架构、需求和设计出自自组织团队。
第12条 团队定期反思如何能提高成效，并相应地调整自身的行为。
贯彻落实以上原则的方式：
- 确保开发团队成员有合适的技能和上进心；——通过全天自发地进行交谈来学习知识、增强理解和提高效率，创建一个鼓励团队成员说出他们的想法的环境。
- 为任务的完成提供足够的培训；
- 支持自组织团队决定做什么和怎么做，不需要让管理者来告诉团队做什么；
- 让团队成员作为一个整体而非个体来承担责任；
- 面对面沟通，快速、有效地传递信息。
- 当每个迭代结束时，开回顾会议
- 创建一个有利于协作的物理环境：一个有白板、彩色笔和其他有助于开发和传递想法的触觉工具的团队房间，可以确保团队成员达成共识。
- 如果有需要，当天就澄清所有的疑问。
- 团队成员尽可能保持长期、稳定
产品开发的敏捷原则
第1条 我们最优先考虑的是通过尽早和持续不断地交付有价值的软件来使客户满意。
第2条 即使在开发后期也欢迎需求变更。敏捷流程利用变更为客户创造竞争优势。
第3条 采用较短的项目周期（从几周到几个月），不断地交付可工作的软件。
第7条 可工作的软件是测量进展的首要指标。
第8条 敏捷流程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。
第9条 坚持不懈地追求技术卓越和良好设计，从而增强敏捷能力。
第10条 以简洁为本，最大限度地减少工作量。
贯彻落实以上原则的方式：
- 将开发工作按照几周或持续时间更短的冲刺周期拆分。在整个开发过程中，每个冲刺的时间要保持一致，从而让团队长期处于一个可预测的开发节奏中。
- 规划、需求提炼、开发、测试和功能演示都在一个迭代中发生，这样可以降低长时间走错方向或开发出客户不想要的东西的风险。
- 敏捷实践鼓励富有成效的、健康的、稳定的开发节奏。例如，在流行的极限编程(XP)敏捷软件开发方法中，每周最多工作40小时，首选35小时。敏捷产品开发，尤其从长期来看，具有稳定性和可持续性，并更加富有成效。
- 敏捷方法使优先级、现有产品的开发经验以及最终每次冲刺中的开发速度清晰可见，这有助于团队很好地判断在给定时间内能够完成或应该完成多少工作量。
- 为开发团队提供实时的问题解答，使其免受竞争的优先事项的影响，赋能团队制定解决方案并决定每次迭代中要完成的工作量；
- 制作“刚好够”的文档；
- 精简状态报告，使开发团队能够短时间把信息推送出去，而不是让项目经理花费大量的时间来提取有用的信息；
- 最小化非开发任务；
- 树立信心，认为变更是正常且有益的，而不是让人惧怕和躲闪的东西；
- 采用准时制(JIT)的需求细化方式，以最大限度地减少变更干扰或工作浪费；
- 与开发团队合作，建立现实的进度计划与目标；
- 保护团队远离组织安排的、与产品目标无关的工作，这些工作可能影响产品目标的完成；
- 理解工作与生活的适当平衡是高效开发的组成部分；
- 将产品视为长期投资，需要永久性团队追求价值高于遵循规范。
传统项目管理和敏捷产品管理的对比
附加白金原则
>>抵制形式化：物理工作环境和讨论都是开放而畅通无阻的。文档只需保持最低的数量和复杂度
>>将团队视为整体的思考与行动：结对开发并经常交换伙伴，用统一的“产品开发者”的头衔替代各种不同的头衔，只在团队层级汇报工作，用团队绩效度量指标替代个人绩效度量指标
>>可视化而非书写：在工作环境中配备大量的白板、贴纸、笔以及纸张，使绘图工具随手可得；使用模型而非文字来沟通概念；通过图表、图形和仪表板来汇报状态
敏捷石蕊测试
要成为敏捷的一员，你需要去问：“这是敏捷吗？”
(1)我们此刻的所作所为对有价值的软件的【尽早和持续的交付】是否提供了支持？
(2)我们的流程是否欢迎变更并能够【从变更中获得好处】？
(3)我们的流程是否引导并支持【可工作的软件的交付】？
(4)开发人员和产品负责人是否【每日一起工作】？客户和业务干系人是否与团队紧密合作？
(5)我们的环境是否给予团队完成工作【所需的支持】？
(6)我们进行的【面对面沟通】是否比电话或者邮件沟通更多？
(7)我们是否通过所开发的可工作的功能的数量来【测量进展】？
(8)我们能否【长期维持】目前的开发节奏？
(9)我们是否支持那些【考虑未来变更的卓越技术和良好设计】？
(10) 我们是否最大化了不必要的工作量？换言之，为实现客户的产品目标，我们是否尽可能【只做必要的工作】？
(11)开发团队是否是【自组织与自管理】的？他们是否具有迈向成功的自由？
(12)我们是否进行【定期的反思】并相应地调整我们的行为？