21天敏捷项目管理——Day 5 敏捷方法（实践）

精益软件开发

采用丰田生产系统（TPS）的原则和实践

1. TPS开发旨在解决影响生产过程的问题，例如

• 过度：对于雇员和过程是假不必要的额外压力
• 违规：不切实际的需求导致过程中的不均匀
• 浪费：非增值活动或过程

2. 精益7原则

• 消除浪费：对客户没有带来价值的事务就是浪费
• 尽快交付：短期迭代或者小批量提供有价值的反馈，促进有效的决策制定
• 团队授权：精益专注于团队，因为决策定制和管理的来源让团队了解最佳选择和成本
• 延迟决定：管理不确定性的最佳方法是收集信息，最后的责任时刻给予承诺，打破部件
• 建立整体：确保质量是嵌入在整个系统的，系统需要构建自动化测试，安装和持续集成。
• 目光长远，脚踏实地，快速试错，快速学习

SCRUM

1. Scrum团队包含产品负责人、开发团队和Scrum主管

• 产品负责人负责实现产品价值的最大化。
• 开发团队是一个跨职能自组织团队，其开发成员拥有所需的一切资源，可在不依赖团队外部其他资源的情况下交付工作产品。
• Scrum主管负责确保Scrum过程获得相应支持且Scrum团队遵从实践和规则，并指导团队消除障碍。

2. Scrum事件

• 冲刺Sprint
• Sprint计划会议
• 每日站立会议
• Sprint评审会议
• Sprint回顾会议

3. Scrum工件

• 产品待办列表
• 冲刺Sprint待办列表
• 增量

极限编程

• 一种基于频繁交付周期的软件开发方法
• 理念：将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践。

1. 现场客户 ( On-site Customer )
2. 代码规范 ( Code Standards )
3. 每周40小时工作制 ( 40-hour Week )
4. 计划博弈 ( Planning Game )
5. 系统隐喻 ( System Metaphor )
6. 简单设计 ( Simple Design )
7. 测试驱动 ( Test-driven )
8. 代码重构 ( Refactoring )
9. 成对编程 ( Pair Programming )
10. 集体代码所有制（Collective Ownership）
11. 持续集成 ( Continuous Integration )
12. 小型发布 ( Small Release )

https://blog.csdn.net/haydenwang8287/article/details/39134493

看板方法

• 任务列表可视化
• 限制在制品

水晶方法

功能驱动方法（FDD）

动态系统开发方法（DSDM）

敏捷统一过程（AUP）

OpenUP

---

毕业后第一份工作刚开始的团队就使用了scrum，但没过几个月，团队领导去了公司另一个城市的办事处工作，后来的领导就没有继续实施敏捷了。后来公司的其他的团队也纷纷模仿之前的团队进行每日站立会议（也许因为这是scrum里面最容易被人看见并模仿的活动），但好像都没有能一直坚持下去，有些人觉得这很浪费时间，有些团队因为每天一大早就忙得团团转很难凑齐人开会，有些团队的每日站立会议变得越来越长，有时甚至一站就站一个小时……现在回想起来，有些团队可能真的不适合进行每日站立会议，另一方，一些团队及成员只是表面模仿了每日站立会议这项敏捷实践，并不是围绕敏捷的原则去使用这一实践，并没有真正受益于敏捷。我看到的这些例子，正好印证了前几天所学的内容：项目团队是否敏捷并不取决于是否采用了敏捷实践，而是在于是否遵循敏捷价值观和原则，“一个团队可以采用敏捷实践，但如果不遵循敏捷价值观和原则，那么它将不能得到敏捷开发的潜在好处”。