从今天开始的21天里，每天学习一点敏捷项目管理的内容并把笔记写在这里。主要的参考教材为《敏捷实践指南》（Project Management Institue）和《敏捷项目管理》（Jim Highsmith著），教材上有的内容尽量少重复，主要是写自己的理解。

---

敏捷是什么？

敏捷不是某种方法论
敏捷不是某种软件开发的方式
敏捷不是某种框架或流程
敏捷是一种理念，不断地用一些价值观和原则来指导决策，并付诸实践。

敏捷的价值观

• 个体和互动 高于 流程和工具

• 可工作的产品 高于 详尽的文档

• 客户合作 高于 合同谈判

• 响应变化 高于 遵循计划

敏捷的原则

1. 我们最优先要做时通过尽早地、持续地交付有价值的软件来使客户满意。

尽早的交付可运行的软件有助于更早开始获得客户的反馈、更好地理解客户的需求，同时也帮助客户更好地了解自己的需求。

2. 即使到了开发的后期、也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

敏捷的实践者不惧怕变化，变化是好事。无卡时代，市场需求一直在变化中，因此项目的变化意味着更了解市场需求了。

3. 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

交付的时间间隔越短，意味着与客户的互动和协作越紧密。

4. 在整个项目开发期间，业务人员和开发人员必须天天在一起工作。

客户、需求人员、开发人员之间需要进行频繁的交互，这样有助于在早期发现和解决问题。

5. 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。

敏捷团队的领导者更倾向于作为一个仆人，为团队成员清楚障碍、建立自信，而不是给他们安排任务。

6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交流。

7. 可工作的软件是首要的进度度量标准。

8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

9. 不断地关注优秀的技能和好的设计会增强敏捷能力。

敏捷团队无论何时都应该尽可能地做到技术卓越。应该使用自动化工具来集成和测试代码，应该通过代码评审来保证代码的正确性与可读性。不可读以及有隐患的代码会变成技术债务，而且是高利贷，会让日后项目的变更变得越来越昂贵，最终拖垮团队。

10. 简洁为本——极力减少不必要的工作量的艺术。

未来不可预测，不必提前做大量冗余的设计。

11. 最好的架构、需求和设计出自于自组织的团队。

强调敏捷项目的领导应该是服务式的领导，引导团队成员围绕核心价值观做决策，而不是管理团队成员，给团队成员安排任务。

12. 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

如何做到敏捷？

项目团队是否敏捷，关键不在于是否使用了敏捷的实践方法，而是在于团队在实践以及决策的时候是否遵循敏捷的价值观和原则。

诸如每日站立会议、看板、极限编程等等的这些敏捷实践都可能很有用，但是使用这些实践方法并不会使团队变得敏捷，甚至会让团队厌恶这些实践方法。例如，有些团队看到觉得每日站立会议好像不错，也跟着进行每日站立会议，但是本该简短的站立会议总是变得越来越长，最后变成了坐下会议；有些团队看到看板好像很清晰，也引进了这种方法，但是看板上的进行中的任务变得越来越多，有些任务卡一直贴在中间没有进展，越来越多成员在忙着看板上没有的任务……这些都是因为团队没有真正理解敏捷，不知道为什么要使用这些实践方法，也有可能，这些方法根本就不适合他们的团队。

真正敏捷的团队，用敏捷的价值观和原则来指导他们的实践，他们根据情况选择适合自己的敏捷实践方式，并在适当的时候进行调整。