是什么让你的敏捷方法做得不伦不类

2021-09-29 13:09:43  26 浏览  0 评论   赞

公司的一个项目也曾尝试使用敏捷方法,但实践中留下了诸多问题。大家都在抱怨根本没有敏捷可言,主要还是由于公司原有的组织架构和业务类型造成的

是什么让你的敏捷方法做得不伦不类

图16733-1:

互联网产品的开发周期短,需求不断变化,所以敏捷方法是很适合互联网产品开发项目的。但综观国内,能灵活且高效地使用敏捷方法去进行项目管理的成功案例并不多。大的方面在这里就不啰嗦了,如需了解,可以看这里。

公司的一个项目也曾尝试使用敏捷方法,但实践中留下了诸多问题。大家都在抱怨根本没有敏捷可言,最后做得不伦不类。究其原因,主要还是由于公司原有的组织架构和业务类型造成的。

组织架构:公司现有的组织架构是矩阵型,QA和developer分别隶属于不同的Manager。这样就造成QA在项目中不能全力投入,QA manager有可能会安排别的任务给QA。敏捷项目则最好是QA和developer隶属于同一个manager,这样就便于协调QA的任务分配,保证QA可以全力跟进项目;另外,敏捷项目中的人数为4-7人为宜,其中1-2人为QA。这么小的团队,没必要再加入一个QA manager的角色,这样只会增加了沟通的渠道数,反而影响了进度。

项目类型:公司业务范围属有线电视领域,客户为有线电视运营商。这类客户是对产品的稳定性和可靠性要求特别高。他们往往会在lab里面试用产品半年至数年之久,这样用户的反馈就非常慢,周期也拉得很长了。用户的需求很难及时地反馈并反应到产品上面来,所以敏捷开发对这类的产品根本不适合。

采用敏捷方法的项目对项目组成员要求较高,起码整体是在同一个水平线上,没有明显示短板。另外则要求团队的合作意识较强,最好是已经进行了一段时间的磨合,团队成员之间相互了解,相互信任。敏捷方法非常强调信任:产品的owner要信任团队成员;团队成员之间要相互信任;qa和developer之间要相互信任。出现了问题,不需要直接找qa,直接由developer来认领; 任务单也是一样,由成员自己来主动认领。

产品的owner则负责整体工作的协调,并负责确定项目的范围。在用户反馈方面,负责汇总和筛选,制定出下一个版本的feature List。

这里要强调的是QA需求在需求分析阶段就介要入,只有这样,在测试的过程中才不会有遗漏项没用测试用例覆盖到。

另外,团队成员的座位安排也非常重要,他们要集中在某一区域,这样非常方便口头沟通和交流。即节省时间又可以避免距离较远而影响沟通效率的情况。

好的,就这些吧。

文章来源:互联网老猎人的牧场

 

转载请注明:网创网 www.netcyw.cn/b16733.html

赞 ()
发表评论
  • 昵称
  • 网址
(0) 个小伙伴发表了自己的观点
    暂无评论

Copyright © 2018-2019 小王子工作室 版权所有 滇ICP备14007766号-3 邮箱:yangzy187@126.com