1.3 开发流程
← 1.2 团队协作 | 首页 | 下一节: 1.4 问题解决能力 →
敏捷软件开发 12 原则
- 最高优先级是通过尽早持续交付有价值的软件满足客户。
- 欢迎需求变化，即使是在开发后期——敏捷过程利用变化为客户创造竞争优势。
- 频繁交付可工作的软件（几周到几月，越短越好）。
- 业务人员和开发者每天一起工作。
- 围绕有动力的个体构建项目，给予信任和支持。
- 面对面沟通是最高效的信息传递方式。
- 可工作的软件是衡量进度的首要标准。
- 敏捷过程促进可持续开发——赞助者、开发者和用户应能保持恒定节奏。
- 持续关注技术卓越和良好设计增强敏捷性。
- 简洁——最大化"不做的事"——是核心。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期反思如何更有效，然后调整行为。
此外还需做到： - 适应迭代式、增量式开发。 - 具备自组织能力：无需事事等待指令。 - 始终聚焦优先级和业务价值，而非技术炫技。
为什么问开发者要时间估算是糟糕的主意
核心问题：开发者几乎完全无法准确预测项目需要多长时间。
- Standish Group CHAOS Report 显示：只有 29% 的软件项目按时、按预算、结果满意完成。敏捷方法成功率 39% vs 瀑布 11%。
- 根本原因：写完整规格本质上就是提前编程；软件项目具有唯一性和不可预测性；开发者常常被迫"撒谎"给估算。
- 业界甚至形成了潜规则：将开发者估算乘以 2-5 倍作为"真实"时间。
- 固定范围、固定价格、固定工期的合同是一切祸乱的根源。
替代方案（Scrum + Story Points）
- 创建产品待办列表（Product Backlog），用用户故事描述功能。
- 用工作量点数（Story Points）取代时间估算（Fibonacci 序列：1、2、3、5、8、13、21），找最简单的给 1 分，最难的给 13 或 21 分，以此为基准估算其他。
- 关键原则：永远不要让工作量点数与时间挂钩——否则一切回到原点。
- 经过几个 Cycle 后，团队速率（Velocity，每周期完成的点数）趋于稳定。
- 基于速率和 Backlog 中的点数排名，可以自动计算出某个故事大概何时完成。
- 避免使用"冲刺（Sprint）"一词——这个术语暗示冲刺后需要休息，与可持续开发的理念相悖；改用"周期（Cycle）"。
来源
- Agile Manifesto — Principles behind the Agile Manifesto: https://agilemanifesto.org/principles.html
- Romén Rodríguez-Gil — Why Asking for Time Estimates Is a Terrible Idea: https://www.romenrg.com/blog/2015/09/28/why-asking-developers-for-time-estimates-in-software-projects-is-a-terrible-idea-and-how-to-bypass-it-with-scrum/
- Standish Group — CHAOS Reports (referenced within)
← 1.2 团队协作 | 首页 | 下一节: 1.4 问题解决能力 →