锁定老帖子 主题:互联网开发也能敏捷吗
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2010-03-19
有谁在YAHOO SINA或者GOOGLE TENCENT的办公室看到满墙的小纸条,燃尽图,一撮一撮的结对的? 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2010-03-19
我觉得应该是互联网开发更适合使用敏捷开发吧。
企业应用有明确的客户阵营,明确的需求,明确的项目边界,成本压力和发布压力等。 因此开发过程中的变化会很少,前期进行好的调研和设计,基本上就可以避免开发过程中的很多改动,把握好时间,朝着一个固定的目标努力就是了。这时候,是不是敏捷,对项目关系就不大了。 而互联网应用则完全不同,需求可能会根据用户的反馈,不断调整。因此需要不断的发布小的迭代产品,不断的添加,修改功能或者调整功能优先级,这时候,使用敏捷来拥抱不断变化的需求就更好了。 |
|
返回顶楼 | |
发表时间:2010-03-19
Joo 写道 有谁在YAHOO SINA或者GOOGLE TENCENT的办公室看到满墙的小纸条,燃尽图,一撮一撮的结对的?
不能说这样做了就敏捷,也不能说不这样做就不敏捷,敏捷不应该被形式化. 互联网的应用,我个人觉得区别在于是模仿,还是开创. 如果只是模仿,那肯定已经有一些既成的东西,其实和楼主所说的企业应用的特点差别也不大. 而对于开创性的,就是一个化无为有的过程.施行敏捷对于人员的要求,肯定要高得多.光有经验的积累和沉淀是不够的,还要具有前瞻性. |
|
返回顶楼 | |
发表时间:2010-03-19
xixix2004 写道 Joo 写道 有谁在YAHOO SINA或者GOOGLE TENCENT的办公室看到满墙的小纸条,燃尽图,一撮一撮的结对的?
不能说这样做了就敏捷,也不能说不这样做就不敏捷,敏捷不应该被形式化. 互联网的应用,我个人觉得区别在于是模仿,还是开创. 如果只是模仿,那肯定已经有一些既成的东西,其实和楼主所说的企业应用的特点差别也不大. 而对于开创性的,就是一个化无为有的过程.施行敏捷对于人员的要求,肯定要高得多.光有经验的积累和沉淀是不够的,还要具有前瞻性. 倒不是一定抓住形式不放,此处只是一个形象的说法 为什么我的感受跟你说的恰恰相反呢,互联网应用才是在开创啊,至少在创造性上比common Enterprise app dev要高出一大截。且不说各类花样繁多的互联网盈利模式,且不谈由互联网应用催生出的各种集群、缓存、分布式技术,光是互联网本身的活跃性就决定了要在其上做真正的敏捷将面临多少新问题。互联网开发领域从来就不缺乏新问题,如此看来,敏捷本身是否还足够敏捷呢 |
|
返回顶楼 | |
发表时间:2010-03-19
最后修改:2010-03-19
test case 必需
结对 一般公司作不到 小黄条 可以看的见. 燃尽图.没见过. 项目周期本身都 很短(一周,二周) 不知道这算不算敏捷呢 |
|
返回顶楼 | |
发表时间:2010-03-19
抛出异常的爱 写道 test case 必需
结对 一般公司作不到 小黄条 可以看的见. 燃尽图.没见过. 项目周期本身都 很短(一周,二周) 不知道这算不算敏捷呢 如楼上说,不能把这些作为判断是否敏捷的标准,也就不能说这么做是否敏捷。不过一到两周的项目规模本身需要敏捷吗,就好像带领一队人马轻装上阵冲刺200米,若以敏捷的名义让他们背上几口干粮和若干医药,貌似反倒是负担了 其实我并不是想要说明互联网应用不敏捷,或者其不可敏捷性,而是想知道他们具体怎么来做敏捷的? |
|
返回顶楼 | |
发表时间:2010-03-19
最后修改:2010-03-19
Joo 写道 抛出异常的爱 写道 test case 必需
结对 一般公司作不到 小黄条 可以看的见. 燃尽图.没见过. 项目周期本身都 很短(一周,二周) 不知道这算不算敏捷呢 如楼上说,不能把这些作为判断是否敏捷的标准,也就不能说这么做是否敏捷。不过一到两周的项目规模本身需要敏捷吗,就好像带领一队人马轻装上阵冲刺200米,若以敏捷的名义让他们背上几口干粮和若干医药,貌似反倒是负担了 其实我并不是想要说明互联网应用不敏捷,或者其不可敏捷性,而是想知道他们具体怎么来做敏捷的? 这是个实例.... 不知道你要怎么定义上面的流程. |
|
返回顶楼 | |
发表时间:2010-03-19
抛出异常的爱 写道 这是个实例.... 不知道你要怎么定义上面的流程. 不知道如何定义,呵呵,应该叫做“自发性的隐形敏捷”吧,带有一两个敏捷的feature,并从这些features中获益,其实who care到底是不是或叫不叫敏捷。若从这个观点来看,回归敏捷的本源,keep simple and fast response,就已经是敏捷了 |
|
返回顶楼 | |
发表时间:2010-03-19
我们就是做所谓的互联网,天天squad meeting,burn down chart,在我们这边看来,敏捷最有用的就是在保证质量(test)的基础上拥抱变化。要是做平台的,需求确定了,才用不着敏捷,直接瀑布了
|
|
返回顶楼 | |
发表时间:2010-03-19
互联网的变化可能会更多,比如一周就会有新功能Release,所以可能更适合迭代吧。
个人感觉! |
|
返回顶楼 | |