精益软件开发
采用丰田生产系统（TPS）的原则和实践
- TPS开发旨在解决影响生产过程的问题，例如
- 过度：对于雇员和过程是假不必要的额外压力
- 违规：不切实际的需求导致过程中的不均匀
- 浪费：非增值活动或过程
- 精益7原则
- 消除浪费：对客户没有带来价值的事务就是浪费
- 尽快交付：短期迭代或者小批量提供有价值的反馈，促进有效的决策制定
- 团队授权：精益专注于团队，因为决策定制和管理的来源让团队了解最佳选择和成本
- 延迟决定：管理不确定性的最佳方法是收集信息，最后的责任时刻给予承诺，打破部件
- 建立整体：确保质量是嵌入在整个系统的，系统需要构建自动化测试，安装和持续集成。
- 目光长远，脚踏实地，快速试错，快速学习
SCRUM
- Scrum团队包含产品负责人、开发团队和Scrum主管
- 产品负责人负责实现产品价值的最大化。
- 开发团队是一个跨职能自组织团队，其开发成员拥有所需的一切资源，可在不依赖团队外部其他资源的情况下交付工作产品。
- Scrum主管负责确保Scrum过程获得相应支持且Scrum团队遵从实践和规则，并指导团队消除障碍。
- Scrum事件
- 冲刺Sprint
- Sprint计划会议
- 每日站立会议
- Sprint评审会议
- Sprint回顾会议
- Scrum工件
- 产品待办列表
- 冲刺Sprint待办列表
- 增量
极限编程
- 一种基于频繁交付周期的软件开发方法
- 理念：将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践。
- 现场客户 ( On-site Customer )
- 代码规范 ( Code Standards )
- 每周40小时工作制 ( 40-hour Week )
- 计划博弈 ( Planning Game )
- 系统隐喻 ( System Metaphor )
- 简单设计 ( Simple Design )
- 测试驱动 ( Test-driven )
- 代码重构 ( Refactoring )
- 成对编程 ( Pair Programming )
- 集体代码所有制（Collective Ownership）
- 持续集成 ( Continuous Integration )
- 小型发布 ( Small Release )
https://blog.csdn.net/haydenwang8287/article/details/39134493
看板方法
- 任务列表可视化
- 限制在制品
水晶方法
功能驱动方法（FDD）
动态系统开发方法（DSDM）
敏捷统一过程（AUP）
OpenUP
毕业后第一份工作刚开始的团队就使用了scrum，但没过几个月，团队领导去了公司另一个城市的办事处工作，后来的领导就没有继续实施敏捷了。后来公司的其他的团队也纷纷模仿之前的团队进行每日站立会议（也许因为这是scrum里面最容易被人看见并模仿的活动），但好像都没有能一直坚持下去，有些人觉得这很浪费时间，有些团队因为每天一大早就忙得团团转很难凑齐人开会，有些团队的每日站立会议变得越来越长，有时甚至一站就站一个小时……现在回想起来，有些团队可能真的不适合进行每日站立会议，另一方，一些团队及成员只是表面模仿了每日站立会议这项敏捷实践，并不是围绕敏捷的原则去使用这一实践，并没有真正受益于敏捷。我看到的这些例子，正好印证了前几天所学的内容：项目团队是否敏捷并不取决于是否采用了敏捷实践，而是在于是否遵循敏捷价值观和原则，“一个团队可以采用敏捷实践，但如果不遵循敏捷价值观和原则，那么它将不能得到敏捷开发的潜在好处”。
