敏捷开发的原则
- 传递消息最有效率效果最后的方式是面对面的交谈，而不是通过流程和工具
- 一个能用的软件好过一个详尽的文档
- 和客户的持续合作和沟通好过合同谈判
- 用灵活的计划面对快速的需求变化
如何实行
第一重要的原则就是事实求是，结合开发团队的现状去实践敏捷开发的原则，符合就用，不符合就无需按照原则去强行改造，我们应该通过实践去改造理论，而不能照着理论去改变实践，而大多数的 SCRUM 培训做的正好就是强化理论，而不管实践。
第二重要的原则，软件开发的目的是开发出符合需求的能运行的软件，所以产出是衡量一个团队效率的最终标准，而不是 SCRUM 和 Sprint 中产出的各种文档和数据。
Agile is not scrum or sprint
Scrum 和 sprint 都不是 Agile， 只是一种管理的方法论，所以在实践 Agile 的过程中应该去其糟粕，取其精华。
在实践 Agile 的过程中也应当努力避免
敏捷开发的问题
- 相对于传统的瀑布开发模型，敏捷编程产生的原因是基于更注重编程人员，而轻流程的原则而诞生的，但是经过这么多年的发展，敏捷编程逐渐的偏离的其原本产生的原因，现在的 Scrum 更多的是重流程而轻人力，所有成员每天都要参与繁琐流程。
- Scrum 中有很多没有必要的流程，比如每日早晨的站会，对于一些团队来说，取消站会可以增加开发人员的效率，因为他们可以随时开始一天的工作，并且不担心会被打断。
- Sprint Review 在很多团队中都是不需要的，Story holder 可以每天从团队得到反馈，而不需要在 Sprint 结束时专门空出时间来展示。对于有完整的自动化 CI 的团队，Story holder 完全可以通过自己查看最新的未发布版本来知道开发进度。
- Sprint 将本来就是持续集成的开发流程切割成了一段段的时间段，这一点并不是特别的符合现在最新的开发模式，毕竟 Scrum 概念兴起的时候，持续集成的概念和工具还未提出。
- Agile 之所以变成重流程而轻人力的原因是因为开发团队的不断壮大，有了更多的层级结构之后，上层的管理人员需要通过这个流程去获取管理团队的数据，比如 Jira 可以通过简单的配置生成复杂的报表，所以整个流程变的更多是面向上层管理的工具，而轻视了真正的开发人员。
那该如何改进？
- 尽量的减少 Scrum 中团队不适合当前团队的流程
- 如果上层管理者需要数据，更多的通过自动化的方式去获取，比如分析项目的 Commits ，自动化测试的报告等
参考连接
指向原始笔记的链接