用户必须积极参与
- 解读:用户参与能最大程度在业务需求梳理和确认上给予及时准确的反馈,同时用户作为参与者能够及时获取项目推进过程的相关信息。
必须授权团队做决定 (对应敏捷宣言--个体与交互胜过过程与工具)
- 解读:团队是冲在一线的开始实施者,他们对当前情况是最了解的,在做某些决定的时候没有必要遵循条条框框,层层上报,最后才层层传达决定。要相信团队的专业能力,判断能力。
需求变化,时间表不变(拥抱变化,额外付出精力通过放弃其他非关键的需求)
- 解读:唯一不变的是变化,但是把项目做成功的目标是没有变化。变化往往是不得不变,我们需要拥抱变化,不是为了做项目而做项目,变化的背后必定是价值在支撑。变化处理原则,抓住重点,主要矛盾,集中精力解决,必要时放弃或忽略次要矛盾问题。
轻量化,可视化在较高层次捕获需求 (卡片,截图序列,草图......)
- 解读:可视化极大帮助理解项目整体需求
进行小的,迭代增量式开发
- 解读:项目进展可见,用户每次仅须了解几个新加功能,用户更容易提供反馈,项目风险小
专注于软件产品的频繁发布
- 解读:MVP交付,持续交付,反馈,改进,产出
完成每个功能后再做下一个功能 (TDD 测试用例驱动)
- 解读:成品交付,做好收尾,尽量不要返工
2/8原则
- 解读:重点关注主流程,集中精力完成核心功能
测试集成在整个项目周期,尽早并经常地测试
- 解读:持续构建,发布
所有利益相关者的合作方法至关重要
- 解读:整合资源,促成各方面有利项目推进的有利条件达成
注:内容整理自,David C.Kung 美 《面向对象工程》