论文部分内容阅读
敏捷也有自己的“生命周期”，且随着市场需求的变化而不断进化。Rally重新定义的敏捷已经进化出了“两条腿”：一条由开发敏捷和业务敏捷组合而成的企业级敏捷， 另一条则由ALM（生命周期管理工具）支撑的敏捷思想构成。“两条腿”起着相辅相成的作用。
“敏捷”对企业来说绝不是新概念，在Rally Software亚洲区高级技术顾问钟顺发看来，如果把传统的开发敏捷定义为1.0版本，Rally倡议的企业级敏捷就是2.0版。
“技术开发上的敏捷实际上十年前就已经被业内提出了，软件的敏捷开发思维其实是从制造业的敏捷思维嫁接过来的，而怎么能够串联业务的敏捷、团队的敏捷，达到端到端、从头到底的敏捷，是2.0版的敏捷，最终实现的是从业务到软件开发团队的整体敏捷。”钟顺发对记者如是说。
从企业敏捷开发“病例”说起
敏捷开发的项目，成功的案例有很多，失败的案例也有很多。但在笔者看来，失败的敏捷开发案例通常会具有以下特征。
第一是败于为人诟病的“公司政治”，也即公司管理出于“不信任”的缘故，不允许真正主导项目敏捷开发的角色存在，或者安排一个没有实权的人来充当最终决策人或者“总设计师”，这种场景常见于大公司，最后的结果是让每个参与该项目的团队都认为“我们不是主人，我们只是帮忙的，所以我们不会对愿景是否能够实现负责”。当出现问题时，没人能找到对的人来咨询该怎么做。当项目继续推进时，即便出现了应该做出愿景调整的情形，也不会有人主动站出来调整。
第二是败于迭代周期被愚蠢地“标准化”了。一种很令人“惊奇”的情况是，敏捷项目经常会被一些企业很随意地规划成“3天一次迭代”或“一星期一次迭代”而不给出任何原因，这意味着企业只是在刻意地提高迭代开发的速度，而并非在真正地使用迭代这种方法。事实上，迭代应当尊重产品的进化过程，这个过程包括开发、进化、反馈（这个过程是循环发生的），而错误的迭代周期规划，会导致产品进化的畸形。
第三是对于愿景的实现过程分解得不够细。一个最朴素的道理是，越小的事情就越容易完成，但在企业内部却经常事与愿违。企业经常面对的是规模庞大的项目，项目的规划者常会出于对项目完成困难的畏惧而不愿花更多的时间将一个庞大的项目分解成足够细小的项目，于是当一部分容易完成的项目更早地被完成时，项目整体的完成时间会因为那些具有难度的项目还未被完成而延误。
第四是需求提交和被满足的过程出现了问题。笔者此前听说过一种场景，这一场景是发生在敏捷开发过程中的。当企业的一个开发团队要做迭代开发，来自客户的需求也不断地被提交过来时，就涉及需求权重的排列问题，简单说就是，先满足哪个需求。对此，产品经理、开发团队、销售或市场人员都会有不同的排序原则。如何解决权重安排时的冲突问题？这难住了很多的企业。
当然，上述文字并不能涵盖失败的敏捷开发案例所具有的一切特征，但至少能够摆出企业在敏捷开发中遇到的一些关键性问题，而对于解决上述问题，Rally独善其道。
业务与开发都要敏捷
无论什么样的企业，无论这家企业从事什么业务，要想更快、更好地发展，都可以考虑采用Rally提出的敏捷思维。
在Rally提出的敏捷思维中，包含五个层次的规划。最高层是愿景规划，是指企业从市场上获得灵感后，将这些灵感通过愿景的方式提交出来，愿景的提交频率一般情况下不会受到限制。往下一层是目标层，因为有了愿景就需要制定目标来完成。当企业有了目标，就能根据愿景把目标分解为一些特性，这就是第三层。实现了所有的特性，就等于实现了目标，于是企业又需要制定一个计划去安排在什么时间段去发布，并且有了发布计划之后，也需要让团队以迭代的方式继续实现交付，这是第四层。在最底层，需求被提交给团队后会被拆分成不同的任务，这些任务在Rally被称为故事（User Story）。这五层就像一颗洋葱一样层层相扣，从下到上是产生故事、发布计划、分解特性、完成目标，最终实现愿景。
在具体执行的过程中，企业该如何应用Rally提出的敏捷思维解决问题呢？
钟顺发以解决需求排序问题为例解释称，因为开发团队会做敏捷开发，业务团队也导入了敏捷的思维，在排序时开发团队会以技术优先，业务团队也会有自己的排序原则，二者之间会存在“冲突”。这时，中间就需要一层接口，即在业务上进行一个定期的规划，把开发敏捷和业务敏捷串联起来。具体的做法是，项目负责人每个星期或者每个季度把所有与项目存在利益关系的角色成员召集起来，先宣布这个星期或者季度的重点目标是什么，再给出这个季度或这个星期搜集上来的需求（用户故事），然后根据需求列出十大特性，让所有角色都参与做排序，最后一起对排序做公正的表决。表决后的结果在一定期间内不可以改动，即便是客户也不能。
“用户关注的是目标而不是特性，业务团队只关心发布周期，开发团队只关注要实现哪些特性，在排序时就不会出现冲突，排序的结果出来后也会很容易被一致认同。更重要的是，在这个过程中，需求的描述是从客户的角度给出的，而不是工程师的角度，所以开发出来的产品一定会满足用户和市场的需求。敏捷不光要应用到开发上，也要应用到业务，企业只有将业务的敏捷综合了开发的敏捷，才能释放潜能。”钟顺发如是说。
ALM可与敏捷共存
敏捷思维会帮助企业实现对市场变化的快速响应，而ALM（生命周期管理）工具会严格控制企业中不适应业务需求变化的那些流程，二者是否能够共存？
钟顺发认为在Rally可以实现二者的共存。
传统的ALM工具是管控型的，但Rally提供的ALM工具完全没有管控，并且不注重流程，而注重沟通和减少浪费。企业采用传统的ALM工具会浪费很多资源，比如时间，从企业决定实施一个项目开始，到项目实施完毕，中间的流程可能会耗时好几个月。
可为什么企业还需要ALM工具？
软件开发在30年前没有一个很合适的生命周期管理方法，所以只能借鉴传统行业中比如造车、盖房的方法。而因为房子造错了，拆了重建代价很大，因此不允许在规划中有错误出现。但在软件开发环境中，即使是出错了，也允许修改代码，纠错的成本和风险会低很多。
所以，传统的ALM工具是以一种不允许犯错误的思维或者是先预知问题，再预防问题的思维去做策划和编排。
可导入了敏捷思维之后，就可以鼓励企业“尽早”犯错，并希望企业在犯错中学习，在学习中“尽早”更正。
“Rally提供的ALM工具不会帮助企业做一个严谨的、闸门式的审批，而是允许企业做不断的规划和调整。以前的ALM工具都会规划一个固定的、很长的周期，然后所有的团队都要按照这个周期计划去做，即使半途出现差错也没有办法。
但Rally的ALM工具只会规划眼下短期内要做的事，然后短期内再规划一次，并以波浪的形式持续地发布和持续性地开发，这也是Rally的ALM工具与其他ALM工具的不同之处。”钟顺发如是说。
“敏捷”对企业来说绝不是新概念，在Rally Software亚洲区高级技术顾问钟顺发看来，如果把传统的开发敏捷定义为1.0版本，Rally倡议的企业级敏捷就是2.0版。
“技术开发上的敏捷实际上十年前就已经被业内提出了，软件的敏捷开发思维其实是从制造业的敏捷思维嫁接过来的，而怎么能够串联业务的敏捷、团队的敏捷，达到端到端、从头到底的敏捷，是2.0版的敏捷，最终实现的是从业务到软件开发团队的整体敏捷。”钟顺发对记者如是说。
从企业敏捷开发“病例”说起
敏捷开发的项目，成功的案例有很多，失败的案例也有很多。但在笔者看来，失败的敏捷开发案例通常会具有以下特征。
第一是败于为人诟病的“公司政治”，也即公司管理出于“不信任”的缘故，不允许真正主导项目敏捷开发的角色存在，或者安排一个没有实权的人来充当最终决策人或者“总设计师”，这种场景常见于大公司，最后的结果是让每个参与该项目的团队都认为“我们不是主人，我们只是帮忙的，所以我们不会对愿景是否能够实现负责”。当出现问题时，没人能找到对的人来咨询该怎么做。当项目继续推进时，即便出现了应该做出愿景调整的情形，也不会有人主动站出来调整。
第二是败于迭代周期被愚蠢地“标准化”了。一种很令人“惊奇”的情况是，敏捷项目经常会被一些企业很随意地规划成“3天一次迭代”或“一星期一次迭代”而不给出任何原因，这意味着企业只是在刻意地提高迭代开发的速度，而并非在真正地使用迭代这种方法。事实上，迭代应当尊重产品的进化过程，这个过程包括开发、进化、反馈（这个过程是循环发生的），而错误的迭代周期规划，会导致产品进化的畸形。
第三是对于愿景的实现过程分解得不够细。一个最朴素的道理是，越小的事情就越容易完成，但在企业内部却经常事与愿违。企业经常面对的是规模庞大的项目，项目的规划者常会出于对项目完成困难的畏惧而不愿花更多的时间将一个庞大的项目分解成足够细小的项目，于是当一部分容易完成的项目更早地被完成时，项目整体的完成时间会因为那些具有难度的项目还未被完成而延误。
第四是需求提交和被满足的过程出现了问题。笔者此前听说过一种场景，这一场景是发生在敏捷开发过程中的。当企业的一个开发团队要做迭代开发，来自客户的需求也不断地被提交过来时，就涉及需求权重的排列问题，简单说就是，先满足哪个需求。对此，产品经理、开发团队、销售或市场人员都会有不同的排序原则。如何解决权重安排时的冲突问题？这难住了很多的企业。
当然，上述文字并不能涵盖失败的敏捷开发案例所具有的一切特征，但至少能够摆出企业在敏捷开发中遇到的一些关键性问题，而对于解决上述问题，Rally独善其道。
业务与开发都要敏捷
无论什么样的企业，无论这家企业从事什么业务，要想更快、更好地发展，都可以考虑采用Rally提出的敏捷思维。
在Rally提出的敏捷思维中，包含五个层次的规划。最高层是愿景规划，是指企业从市场上获得灵感后，将这些灵感通过愿景的方式提交出来，愿景的提交频率一般情况下不会受到限制。往下一层是目标层，因为有了愿景就需要制定目标来完成。当企业有了目标，就能根据愿景把目标分解为一些特性，这就是第三层。实现了所有的特性，就等于实现了目标，于是企业又需要制定一个计划去安排在什么时间段去发布，并且有了发布计划之后，也需要让团队以迭代的方式继续实现交付，这是第四层。在最底层，需求被提交给团队后会被拆分成不同的任务，这些任务在Rally被称为故事（User Story）。这五层就像一颗洋葱一样层层相扣，从下到上是产生故事、发布计划、分解特性、完成目标，最终实现愿景。
在具体执行的过程中，企业该如何应用Rally提出的敏捷思维解决问题呢？
钟顺发以解决需求排序问题为例解释称，因为开发团队会做敏捷开发，业务团队也导入了敏捷的思维，在排序时开发团队会以技术优先，业务团队也会有自己的排序原则，二者之间会存在“冲突”。这时，中间就需要一层接口，即在业务上进行一个定期的规划，把开发敏捷和业务敏捷串联起来。具体的做法是，项目负责人每个星期或者每个季度把所有与项目存在利益关系的角色成员召集起来，先宣布这个星期或者季度的重点目标是什么，再给出这个季度或这个星期搜集上来的需求（用户故事），然后根据需求列出十大特性，让所有角色都参与做排序，最后一起对排序做公正的表决。表决后的结果在一定期间内不可以改动，即便是客户也不能。
“用户关注的是目标而不是特性，业务团队只关心发布周期，开发团队只关注要实现哪些特性，在排序时就不会出现冲突，排序的结果出来后也会很容易被一致认同。更重要的是，在这个过程中，需求的描述是从客户的角度给出的，而不是工程师的角度，所以开发出来的产品一定会满足用户和市场的需求。敏捷不光要应用到开发上，也要应用到业务，企业只有将业务的敏捷综合了开发的敏捷，才能释放潜能。”钟顺发如是说。
ALM可与敏捷共存
敏捷思维会帮助企业实现对市场变化的快速响应，而ALM（生命周期管理）工具会严格控制企业中不适应业务需求变化的那些流程，二者是否能够共存？
钟顺发认为在Rally可以实现二者的共存。
传统的ALM工具是管控型的，但Rally提供的ALM工具完全没有管控，并且不注重流程，而注重沟通和减少浪费。企业采用传统的ALM工具会浪费很多资源，比如时间，从企业决定实施一个项目开始，到项目实施完毕，中间的流程可能会耗时好几个月。
可为什么企业还需要ALM工具？
软件开发在30年前没有一个很合适的生命周期管理方法，所以只能借鉴传统行业中比如造车、盖房的方法。而因为房子造错了，拆了重建代价很大，因此不允许在规划中有错误出现。但在软件开发环境中，即使是出错了，也允许修改代码，纠错的成本和风险会低很多。
所以，传统的ALM工具是以一种不允许犯错误的思维或者是先预知问题，再预防问题的思维去做策划和编排。
可导入了敏捷思维之后，就可以鼓励企业“尽早”犯错，并希望企业在犯错中学习，在学习中“尽早”更正。
“Rally提供的ALM工具不会帮助企业做一个严谨的、闸门式的审批，而是允许企业做不断的规划和调整。以前的ALM工具都会规划一个固定的、很长的周期，然后所有的团队都要按照这个周期计划去做，即使半途出现差错也没有办法。
但Rally的ALM工具只会规划眼下短期内要做的事，然后短期内再规划一次，并以波浪的形式持续地发布和持续性地开发，这也是Rally的ALM工具与其他ALM工具的不同之处。”钟顺发如是说。