欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

为什么我的敏捷项目有如此多的问题? 博客分类: 管理 敏捷开发项目管理企业应用软件测试QQ 

程序员文章站 2024-02-21 11:37:10
...

OK,敏捷哈。不争论什么是敏捷。我们来看一些现象,然后你来告诉我,你有没有遇到过这些问题。

没人提真正的Feedback

每个迭代结束之后,我都会做Showcase。但是从Showcase上收集到最多的,就是UI的问题,字体太小之类的。每个Release发布之后,项目都会部署一个试用版本。但就是不见真正的用户来“试用”,就更别提Feedback了。敏捷不是强调Feedback吗?客户(Customer)时间不够,同时他们也不是最终用户,提不出足够有深度的Feedback。而最终用户呢,压根就没兴趣。

架构咋弄啊

每个迭代都要被催着出东西,哪里有时间弄架构哦。一开始就一个劲的加功能。前几个迭代大家都很Happy,功能出来的特别快。后来就越来越慢了,团队情绪也很差。

客户说没有不是Must Have的

事情实在太多了,做不完呀。那让客户来排优先级吧,把哪些是Must Have的找出来。但是客户说了,这些都很重要,没有这个Feature,或者那个Feature系统就压根没有用处。

路漫漫其修远兮,我到底在往哪走

团队的成员越来越多地在抱怨,天天做Story。但是这些Story都是干什么用的呢?这做一点,那做一点,根本就整合不到一个Vision里去。客户说,我给了你Vision啊,你看这个Feature那个Feature,这些要做的东西就是我们的Vision啊(心里还在犯嘀咕呢,你们干活的吵什么吵)。

 

这些问题都有一个相同的最终根源。我们先来看最明显的Feedback问题。为什么客户和最终用户都不提Feedback?因为不关他们的事!做Showcase不过就是在眼前晃两下,有深度的Feedback不是那么容易及时地想到的。而Release又有多少是真正部署到产品环境的?最终用户一方面还用这旧的系统,天天忙着四脚朝天的,哪里有时间来试用我们的新系统呢?无论你是设置了一个测试机在他的桌子旁边,还是一天三次的发Email提醒。只要你的系统不是完成他工作必须的一部分,他就不会理你。

为什么Release出来的系统不能部署到Production环境呢?这不是很奇怪吗。是的,确实很奇怪。但是,假如你是客户,你被你的组织委任了一个替换现有系统的差事。现有的系统有100个功能,完全开发完这些功能可能需要两年。但是,每三个月都有一次绩效考核。你会不会希望每三个月,就让领导看到你都弄出了点了啥?于是你找到了一个号称可以做敏捷开发的外包公司,要求他们每三个月给你出一个版本。但是这个版本能真正上Production么?不能!现有系统有100个功能,那么多用户在用呢。你三个月弄出来的系统怎么替换这么大一个系统啊?一个“成熟的企业”,对于一个这样系统的GO OR NOT GO MEETING都要开三个月呢。

也许你要说,我们是真正的Green Field开发,彻底重头写的。那么有你开发的系统之前,这家企业是怎么运作的?至少有一个Paper Process吧。没有电子系统,人们就用纸笔,各种单据来工作呗。IT系统不过是Paper Process的自动化而已。再说了,这年头还真没几个请得起我们,而且现在还没有一个IT系统的,需要从Paper Process开始的?

除非你做的是非常有创新性的企业开发。通过创新性的IT系统,开发新的业务。比如通过新的交易应用来辅助新的Margin Loan产品的市场投放。大部分时间来说,我们都是被引入进来“替换”现有的Paper Process,或者现有的遗留应用的。

 

假设我们要替换的就是一个有100个功能的遗留应用,我们是怎么来“玩”敏捷的呢?基本上来说,我们假设了一个温室的环境。在这个环境里,你可以假设你做的是Green Field的开发。把100个功能,分成多个Release,每个Release又分成多个Iteration。在每个Release之后都会发布一个Pilot版本给测试用户试用。这样就可以迭代式地添加Feature,直到最后能够替换原有的系统。从我的经验看来,正是这种做法,部分导致了以上问题(甚至有些情况下是根源)。前面已经提到了,这样会导致缺少来自最终用户的,真正的Feedback。其次,由于少了一个Feature都无法替换旧的系统,客户很难做出优先级的正确选择。以替换旧的系统为目的,所有的Feature都是Must Have。同时这样会导致每个Release缺乏明确的,唯一的Goal。经常是这个Feature做一些,那个Feature做一些,Team会觉得没有明确的目标。

 

如果我们不以替换旧的系统为目标?那么应该以什么为目标?这个时候你可以去看看Eric Evan的Strategic Design。他说,你应该想想What drives you to spend million dollars on this project in the first place(你为什么在最开始要在这个项目上决定花上一百万美元)。这个背后一定是原因的。基于对这个原因的理解,我们可以选定一定的Feature来实现。然后就开始实现,然后把实现部署了让所有的用户去用。用这种策略,而不是前面那种策略,这样就逼着我们去做很多事情。而我相信这些事情,很有可能就有助于解决前面四个问题。特别是,其中的架构问题。为什么呢?架构是什么?架构就是对问题的一种分解方式。怎么样才能迫使我们去思考架构问题呢?在现有的系统上打个洞,然后挖掉一块,围一道墙,里面再把新的Feature做出来。没有对系统整体的了解,没有对模块的分解,没有对模块之间耦合依赖关系的分析,是不可能做到这些的。这样就迫使我们做出一个低耦合高内聚的架构!

 

把这种策略做到极致就是之前我说过的持续部署才是王道。不但每个Release都和旧的系统集成起来,然后真正的部署。甚至,我们可以做到每个迭代都部署。在Fred George描述的团队里,甚至都没有迭代。一个Feature开发出来就立马被部署了。