敏捷宣言与原则之间的关系
- 将敏捷明确表述为一种思维模式，它由《敏 捷宣言》的价值观所界定，受敏捷原则指导， 4通过各种实践实现
- 敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。
敏捷宣言(Manifesto)的4大价值观
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。
由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，但我们更重视左项价值。
其它译法或更新：
个体和互动 高于 过程和工具
工作的产品 高于 完备的文档
干系人合作 高于 协议谈判
响应变更 高于 遵循计划
敏捷价值观-1：个体和互动 > 流程和工具
- 知识经济时代的项目需求和技术快速变化，由此基于工业经济时代所总结出来的流程和工具已不适用，按照旧方法来管理项目时往往呈现 “做的越多、 错的越多”的现象 。知识经济时代，生产力主要依靠人们的大脑，高素质的 通才们（T型人才）组成的高效团队将更为关键
- 团队生产力 =个人生产力(50%)+互动产生的生产力增值(50%)
1、瀑布式管理是交接棒模式，互动很少，不具有生产力增值
2、敏捷式管理是互动协作模式，具有生产力增值 - 以人为本，做项目首先要打造一支高水平的队伍
敏捷价值观-2：工作的软件 > 详尽的文档
- 客户希望早用到或早看到产品(Seeing is Believing眼见为实)，且软件和高科技往往呈现先发优势。应该集中精力尽早实现(部分)工作的高价值产品功能(MVP)，并持续的增量式交付以实现积小胜为大胜
- 原始需求文档和计划类文档在后期已变更的面目全非，花大量时间和精力却制订了“无用”的文档，且每周繁琐的工作绩效报告却往往呈现出80-80现象(当认为完成80%时实际还剩80%)。应该避免去做详尽的文档，而是采用简单文档和可视化沟通，以便能够把更多的精力花在产出结果上
敏捷价值观-3：客户合作 > 合同谈判
- 客户对需求的认识也是一个渐进过程，与客户紧密合作才能获得符合市场的正确需求，走向双赢
- 早期的决策有很多是错误的，而严苛的合同很可能使后期浮现的真实需求不被实现，走向双输
敏捷价值观-4： 响应变化 > 遵循计划
- 变化/变革是诞生项目的最主要原因。变更是创建伟大产品的必要方式，项目执行要不断地检查并适应变化，进行滚动式规划
- 需求多变的情况下，详实的计划往往是“想象”和“虚假”的，严苛的变更控制流程往往令变更“知难而退”，扼杀了新出现的价值特性
敏捷12原则
| 1、我们最优先考虑的是通过尽早和持续不断地交付有价值的软件使客户满意 | 1.宣言4价值 |
| 2、即使在开发后期也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。 | 2. 欢迎变更 |
| 3、采用较短的项目周期（从几周到几个月）， 经常地交付可工作的软件。 | 3. 1~4周迭代 |
| 4、业务人员和开发人员必须在整个项目期间每天一起工作。 | 4. 全职/专注 |
| 5、围绕富有进取心的个体而创建项目。提供他们所需的环境和支持， 信任他们所开展的工作。 | 5. 以人为本 团队为核心 |
| 6、不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈。 | 6. 面对面可视化 |
| 7、可工作的软件是度量进度的首要指标。 | 7. 【 0-100】 |
| 8、敏捷过程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。 | 8. 可持续/不加班 |
| 9、坚持不懈地追求技术卓越和良好设计，从而增强敏捷能力。 | 9. 改进/重构 |
| 10、以简洁为本，它是极力减少未完成工作量的艺术。 | 10.简洁/二八 |
| 11、最好的架构、需求和设计出自于自组织团队。 | 11. 自组织团队 |
| 12、团队定期地反思如何能提高成效，并相应地协调和调整自身的行为。 | 12.回顾/检视 |
1、 我们最优先考虑的是尽早和持续不断地交付有价值的软件使客户满意
- 把客户满意放在首位，集中精力尽早交付高价值的部分产品功能 (MVP)，以便客户尽早用到、尽早反馈和调整。
- 增量交付能更快地、持续地应对客户的需求变化， 更好地满足客户
2、即使开发后期也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势
- 变化带来机会，而不应严格控制或花大量精力去约束变化
- 将问题转化为机会，利于问题解决的有价值变更应该被更好的应对
3、采用较短的项目周期 （从几周到几个月） ，经常地交付可工作的软件
- 小步快跑 ，及时让客户使用部分特性， 尽早产生收益（自筹资项目）。
- 短周期可以及时获得反馈，错误比较有限， 并使团队增加信心， 也给客户带来更高的确定性
4、 业务人员和开发人员必须在整个项目期间每天一起工作
- 业务人员/产品负责人(PO)和开发团队一起， 通过紧密合作，可以尽早实现需求。除了评审会，干系人也可以在其它时间参与到项目中来！
- 在一起，有效促进了开发团队与业务人员之间的相互理解（信息 + 情感）
5、围绕富有进取心的个体而创建项目。提供所需的环境和支持， 信任他们所开展的工作
- 脑力劳动依赖的是拥有智慧和激情的知识型人才， 自由发挥聪明才智是最重要的因素。 为团队赋能，创造积极氛围，不断激发创新和灵感
- 信任是给与的，认可成员是专业的、自我成长的； 相反， 不信任的成本很高！
6、不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈
- 面对面沟通的效果远大于基于文档的沟通
- 面对面且使用白板，是最有效的沟通方式。虚拟团队应多用视频沟通
7、 可工作的软件是度量进度的首要指标
- 后期才验收和使用，发现问题所造成的返工将导致项目呈现“成百者半九十” 的现象 （80-80法则/西瓜项目/进展75%但完成度为0 ）。团队着眼于产品交付物的可工作和尽早验收，将是衡量进度的最准确的方法
- 它能完成吗？可以使用吗（功能及质量）？ 产生预期结果了吗？ 干系人满意吗？
8、倡导可持续开发。发起人、开发人员和用户需要长期维持稳定的开发步伐
- 敏捷项目以稳定的步伐开发和交付， 客户借此获得更高的确定性
- 敏捷不主张加班文化。漫长的高强度脑力劳动后， 往往需要更长时间休息；否则只 能交付低质量及漏洞的工作，并需要更长时间、更大代价来修复，得不偿失。而持 续发展的效果更明显， 1.01的365次方=37.8
9、坚持不懈地追求技术卓越和良好设计，从而增强敏捷能力
- 追求卓越的重构会使系统更健壮，满足新需求，提高应变能力和韧性
- 及时清还技术债并消除隐患，追求良好设计，关注产品的长久可维护和可扩展
10、以简洁为本，它是极力减少待办工作量的艺术
- 80-20原则说明，应该专注于少数的重要产品特性上， 将其做到极致
- 过程亦是如此。例如使用简洁的用户故事， 而非繁杂且往往被忽略的需求文件；使 用可视化尤其是面对面的沟通，胜于复杂的文档化沟通
11、最好的架构、需求和设计出自于自组织团队
- 团队自我组织如何最好地完成工作， 积极参与目标管理和过程决策。 承诺、合作、 积极参与、团队决策都是自组织团队的特征。 反之，若项目失败， “猪” 的损失更大,团队成员应该具有主人翁精神
- 敏捷主管不要进行微观管理，应将工作的细节留给团队成员。 如今的多数员工是知识工作者，他们不需要监督，而需要激励和支持
12、团队定期反思如何能提高成效， 并相应地协调和调整自身的行为
- 变化的环境里，取得成功的良好做法是去不断地尝试、检查、并调整
- 知识工作是经验型过程，通过回顾实现及时总结、及时分享，及时应用
