文章详情

「敏捷开发」适合什么样的团队

小二郎 1个月以前

如今互联网行业,每天有无数的公司倒下,同样也有无数的公司站起来。


越来越多的人将「敏捷开发」搬上台面大谈特谈,或是为了抢占市场先机、或是为了不断修正需求方向、或是表现出相当的创业精神进而“骗取”资本热钱。


有太多太多的原因让人们追捧「敏捷开发」,这些追捧既有目的性极强的也有无脑跟风的。我在好多论坛或者交流群也见过有人问关于自己的团队适不适合「敏捷开发」的问题。


所以今天,我来说说究竟什么样的团队才适合「敏捷开发」。


1.小团队


这点应该毋庸置疑。

从生活经验上来看,小动物一般用敏捷来形容,比如兔子、猫(当然,大动物也有,如:这头猪真胖,但它竟然还这么敏捷)。


小团队不会出现大团队那种尾大不掉的情况,「敏捷开发」进度可能每天都会变化,小团队有着更低的管理成本,产品经理可以很好的把控整个团队节奏。

当然,小团队也是要五脏俱全的。


2.需求聚焦


如前文所说,大家采用「敏捷开发」肯定是有目的的。不管什么目的,肯定是为了快速响应、快速上线。这时,产品需求一定要聚焦、再聚焦。


有太多团队都是开发到后期突然要改一些不影响大局的东西,比如界面不好看、Icon不精致、交互不酷炫、需求Cover面窄。这些东西放在普通开发节奏的团队中是没有大问题的,但是在「敏捷开发」团队中,只会拖慢整个团队进度,本末倒置。


3.工作内容无边界


及时补位的思想是要深入到每个团队成员心里的。


「敏捷开发」的团队或是初创团队一般都是一个人当好几个人用,每个人都是多面手(这也是好多朋友觉得小公司好的一点,即负责的内容多、成长快),原因就是他们的工作没有边界。


比如底层开发生病了,中间层大哥一定要顶上;比如QA人手不够了,产品经理写测试用例并参与测试也是常见的事。


4.团队无明显短板


越小的团队越容易暴露问题,木桶理论在小团队中更容易体现。

「敏捷开发」过程很容易被团队中的短板所影响,这事虽然其他成员也有及时补位的精神,但每个人精力毕竟有限,我们还是希望能够每个人各尽其职。补的应该是未知的突发情况,而不是可预见的短板,这两个本身就不是一回事。


5.互相信任


团队目标必须高度一致,并且相互信任,尽量少的辜负其他人。


产品绝对信任开发评估结果,开发绝对信任产品发起的需求等等。少质疑多沟通,才能快速实现目标。


好多大团队都会有各种需求评审、用例评审,每天文山会海,而「敏捷开发」会尽可能简化这个流程。但是我们要说的评审只是手段,目的还是要锤炼产品需求。因此纠结于是否该简化评审流程的朋友们,请尝试理解“不要把手段当目的”这句话。弱化评审的前提一定是产品经理自己已经将需求想明白,即满足团队预期、满足产品预期,再进行交付。


6.拥抱变化


之所以采用「敏捷开发」,真正的目的是快速响应、解决问题。当外界环境发生变化的时候,一定要及时接受并拥抱变化。


所谓的变化来自两方面。一方面是外部变化,比如产品方向和预期不符、市场反馈不好等;一方面是内部变化,比如效果图或者交互真的需要改动才能上线等。


面对这种未知的问题,团队里的相关人员需要及时调整心态,一起拥抱变化。


个人经历


我所在的两个团队可以勉强算作是「敏捷开发」团队。

第一个产品20个月发布26个正式版,50多个Beta版,且保证每个Beta版有可以让用户明显感知的新特性;第二个产品7个月发布10个正式版,20多个Beta版。


第一个团队满足上述所有条件,「敏捷开发」地非常顺畅;第二个团队由于有短板存在,导致「敏捷开发」非常吃力,加上后期团队成员心态变化,所以基本走上了各种评审的道路。


然而,我想说的是所谓的「敏捷开发」与非「敏捷开发」并没有谁好谁差的本质区别,只是哪个更适合团队。就像前面所说,不要把手段当作目的,主要还是看解决什么问题。


总结


  • 「敏捷开发」需谨慎,一定要扪心自问团队是否满足上面说的几点。

  • 「敏捷开发」不是万能的,解决问题才是王道,切勿盲目崇拜。


PS. 「敏捷开发」过后,产品经理一定要整理文档,否则快是快了,什么都没留住。切记,切记!!!

作者:一条产品狗
來源:简书

阅读 1200
1
17
收藏成功