敏捷开发与价值交付
透明
涌现的过程和工作必须对执行工作的人员和接受工作的人员都是可见的。重要的决策是基于其 3 个正式工件的感知状态。透明度较低的工件可能导致做出降低价值并增加风险的决策。
透明使检视成为可能。没有透明的检视会产生误导和浪费。
下属做的“大量工作”在领导眼中不重要，也没有纳入评估中，视为不透明。领导部署工作不清晰，存在模糊边界，视为不透明。
模糊的需求传递与信息遮蔽必然会导致似是而非的结果和有缺陷或缺失的交付物。
所以在讨论决策时，必须双向澄清，确保双方对事实和数据的理解是一致的。
清晰的工作部署
团队领导或主管必须清晰、可衡量地部署工作。模糊的边界（例如“让页面更好看”）是透明度的最大杀手。它导致下属难以评估工作量，而领导难以评估结果。
清晰的验收标准（例如“将页面加载时间从 2s 优化到 1s”）是透明的基石。
透明的工作状态
团队成员必须主动呈现工作的价值。不透明的工作量是无效的。开发者不能只埋头写代码，还需要向团队和领导解释所做工作的业务价值和技术影响。例如，与其说“我重构了用户列表组件”，不如说“我重构了用户列表组件，将其性能提升了 30%，减少了用户等待时间”。
如何在前端团队中落地“透明”？
- 定期同步会议： 每日站会（Daily Stand-up）是最好的实践。每个成员简要分享昨天做了什么、今天要做什么以及遇到了什么障碍。这能确保所有人都对项目进展有清晰的感知。
- 代码审查（Code Review）： 代码审查不仅仅是发现 Bug，更是一种知识共享和透明化的过程。通过审查，团队成员可以学习彼此的实现思路，发现潜在的问题，并确保代码质量符合规范。
- 技术分享与文档： 定期进行技术分享，鼓励编写高质量的技术文档。这能将个人的知识转化为团队的财富，让整个团队的技术能力和认知都变得透明。
检视
Scrum 工件和实现商定目标的进展必须经常地和勤勉地检视，以便发现潜在的不良的差异或问题。为了帮助检视， Scrum 以 5 个事件的形式提供了稳定的节奏。
检视使适应成为可能。没有适应的检视是毫无意义的。 Scrum 事件旨在激发改变。
周期性的，监视监控项目，组件，工件，代码，需求，设计，团队协作和产品质量，进度是否与既定目标一致，是否需要调整。
这个过程不是为了指责，而是为了识别出与我们既定目标不一致的“不良差异”。
它帮助我们识别出哪些方面需要改进，哪些方面做得很好，哪些方面需要调整。
规划与落地之间的偏差复盘，总结为经验教训，持续改进。
适应
如果过程的任何方面超出可接受的范围或所得的产品不可接受， 就必须对当下的过程或过程处理 的内容加以调整。 调整工作必须尽快执行以最小化进一步的偏差。
当所涉人员没有得到授权或不能自管理（self-managing） 时， 则适应将变得更加困难。 在通过检 视学到任何新东西时， Scrum Team 会做出相应调整。
“适应”的本质是执行力和响应力。它不仅仅是承认错误，更是迅速采取行动来纠正错误。
快速接受现实，聚焦于解决问题，而不是纠结于错误本身。抛弃主观情绪，强调职业素养
授权与自管理
- 授权（Empowerment）： 如果一个团队没有权力自己决定如何解决问题，每次调整都需要层层审批，那么“适应”就会变得缓慢且低效。在敏捷团队中，开发者应该被赋予一定的技术决策权，能够自主选择工具和方案，以快速响应项目中出现的问题。
- 自管理（Self-managing）： 一个自管理的团队能够主动识别问题，并共同商议解决方案。他们不会被动等待领导的指令，而是会主动发起检视和适应的行动。这种文化是快速适应的催化剂。
敏捷思想理念
敏捷宣言
- 个体与互动重于流程和工具
- 工作的软件重于详尽的文档
- 客户协作重于合同谈判
- 响应变化重于遵循计划 也就是说,尽管右项有其价值,我们更重视左项的价值。
敏捷 12 原则
- 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意
- 欣然面对需求变化,即使在开发后期也一样,为了客户的竞争优势,敏捷过程掌控变化
- 经常地交付可工作的软件,相隔几个星期或一两个月,倾向于采取较短的周期
- 业务人员和开发人员必须相互合作,项目中的每一天都不例外
- 激发个体的斗志,以他们为核心搭建项目,提供所需的环境和支援,辅以信任,从而达成目标
- 不论团队内外,传递信息效果最好效率也是最高的方式是面对面的交谈
- 可以工作的软件进度的首要度量标准
- 敏捷过程提倡可持续开发,责任人、开发人员和用户要能够共同维持其步调稳定延续
- 坚持不懈的追求技术卓越和良好设计,敏捷能力由此增强
- 以简洁为本,它是极力减少不必要工作量的艺术
- 最好的架构、需求和设计出自自组织团队
- 团队定期地反思如何能够提高成效,并依此调整自身的举止表现
敏捷核心实践和原则
- 在迭代中尽早演示交付的价值
- 用户故事反映商业价值和优先级
- 客户持续改进
- 所有需求的验收测试
价值交付
价值交付是敏捷开发的核心目标。它强调通过持续交付有价值的软件来满足客户需求和期望。
从历史经验教训来看，不注重价值交付的项目最终都走向了失败，就如同不注重盈利的公司最终都会破产一样。
同等重要的是，价值交付不仅仅是技术问题，更是业务问题，管理问题，当需求的发布者都不知道应当交付用户什么才能产生价值时，开发者再努力也无济于事。
工艺再精湛的花圈，装裱的再华丽，送给不需要的人，也只是浪费，还得挨顿揍。
思想的传达
在团队内部需要建立起共识与开放的团队氛围，确保每个成员都理解并认同价值交付的理念。
包括理解，信任，尊重，协作，沟通，批评与自我批评，奖励与赞赏。在此文化基础上，再去推动具体的实践和理念。
避免一言堂，满朝诸公皆是一时之选，可谓群贤必至，少长咸集，但总万事全凭圣裁，这是司马懿要累死诸葛亮的节奏。
适当的裁剪
最优秀的团队组织与管理方法始于团队本身，而不是盲目地照搬某个框架或方法论。
每个团队都有其独特的背景，文化，目标和挑战，因此需要根据实际情况进行裁剪和调整。
在很久之前每当我发现新的“玩具”，我总是迫不及待地想要与团队分享和应用，但往往事与愿违，团队成员天然地抗拒变革，尤其是当他们还没有看到明显的收益时。
因此，敏捷实践的推广需要循序渐进，逐步引入，并且要不断地评估和调整，以确保其真正适合团队的需求和目标。
by:lichonglou
