01
因为固定合同项目需要稳定的需求和可预测的过程,硬性将固定价格项目和敏捷融合通常会导致冲突和痛苦的结局。敏捷需要与客户建立不同于传统模式的关系,在适应性敏捷过程中,客户对软件开发过程有更细颗粒度的控制,可以在迭代中调整开发方向。虽然这种程度的参与并不适用于所有合同客户,但对于成功运用敏捷至关重要。02
从资源,进度,需求范围看瀑布和敏捷的差异:
瀑布:需求范围是固定的,管理的是资源和进度。
敏捷:资源和进度是固定的,管理的是需求范围。
03
我对敏捷最大的担忧:屠龙者终成恶龙!
04
用户故事应该描述用户要解决的问题,而不是描述解决方案。
05
如果老板再抱怨迭代velocity太低, 你就偷偷把1个点的故事改成2个点的故事好了,效率马上提升一倍。还想把velocity作为业务目标吗?
06
敏捷不一定要整个组织都敏捷,关键团队需要敏捷, 但所有人都需要准备好支持这些团队的“敏捷”。07
一个能够运行的复杂系统通常是从一个能够运行的简单系统演化而来的。一个从零开始设计,一步完成的复杂系统不会正常运行,也无法通过修修补补使其运行,你必须从构建一个可以运行的简单系统起步。
08
好的敏捷过程是一个能够让你更好应对不可预测性的过程,这也是适应性的意义所在。业界很早意识到迭代是应对不可预测性的有效手段。如果迭代未能提供有效反馈,敏捷就失去了意义。迭代的时长应由反馈价值决定。09
时间盒(timebox)不是用来控制时间的,时间盒的作用是支持团队尽早做出困难的决策,给自己更多解决难题的选择和机会。10
“软”件是最具可塑性的产品,充分利用其“可变性”,IT公司可以提升自身的市场竞争力。而传统瀑布开发模式往往会削弱这一优势。用好敏捷,增强研发晚期更改需求的能力,这是一个赢得市场的重要利器。
推荐阅读
1. 醍醐灌顶的QA十个认知
2. CMMI十大怪象,自己品,不解释
3. 一针不见血的CMMI十个真相
三尺讲桌就在这小小二维码,长按二维码“识别”关注