敏捷开发的初始理解

一,什么是敏捷开发

1,敏捷开发的概念

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。
把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

2,遵循的基本原则

个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值,但是我们认为左项具有更大的价值。

3,实际有效的建议

快速迭代
让测试人员和开发者参与需求讨论
编写可测试的需求文档
多沟通,尽量减少文档
做好产品原型
及早考虑测试


二,敏捷开发的具体实现形式

1,站会

每天工作开始前,小团队聚一起少时沟通。
确定每个人工作的大致情况,是否在预期的进度内;发现是否有异常情况,对异常情况进行管理,整理备用方案。一切都是为了按照预定进度进行,在适当的时间提供可用的版本。

2,看板

应用泳道图的样式,将任务的进度明显的展示出来。
应用及时的状态反馈,能够看到整体情况,也能够看到自己任务所处的状态,便于团队进度管控,以及适当的促进个人的工作效率。


三,敏捷开发的个人理解

1,敏捷开发的意义

敏捷开发通过各个形式,在不断的迭代,快速的提交可用软件的情况下,能够较好的适应用户需求,且整体进度的管控相对比较合理何时。
看板的应用也确实能够促进个人用户的工作激情,也能够便于管理人员掌控全体。

2,敏捷开发实现的误区规避

敏捷开发是一个理念,在具体执行时不能生搬硬套
(1)沟通因为参与人员多少,所消耗的成本区别,造成大团队不适用;
沟通进度及问题反馈,需要相关人员或者通才,或者更高层次的人才能理解与产生有效沟通,对于精于一个小方向或者一线执行人员,意义并不明确;
(2)在软件规模较小的时候,版本之间的修改影响面较广,而在软件较大的时候,版本升级次数过多,对于用户很不好,对于测试人员,为了保证产品质量的回归测试资源浪费明显;且版本修改内容过少时,版本更新的意义就失去;
(3)客户合作不合作不是最大的问题,最大的问题在于协同办公,甚至是异地协同办公,所以在没有有些数据收集与反馈渠道,客户合作再好也仍是解决不了新修改版本具体承载意义的反馈;在现在时时变化的社会潮流中,客户也很难把我自己真实的需求。若是你能够做好需求规划,满足客户,客户也是很满意的;若是客户自己定义需求,那就开始随着客户需求的变更整个团队无限轮转吧!若是用户能够很好的定义需求,那自己家的产品干嘛呢?!
不是不要求变化,而是在变化中,需要遵循自己的规则,有自己的重心。

看过一篇文章,描述传统的瀑布研发流程是火炮,敏捷开发是导弹。这个从某种意义上已经阐明了瀑布研发和敏捷研发的特点。在个人的认知中,应该结合两种方式,各取其长,构建属于每个公司自己的工作模式。
火炮的造价低,火力猛,在快速定位目标后,集火干掉目标;这里的关键在于目标的瞄准 和 弹道发射的速度。大目标的确定,这是最关键的问题,及时研发最初是导弹,直接瞄准目标,也比胡乱开一个目标,不断调整到目标来的更快,成本更低。若是发现目标发生重大偏离不管是什么模式,都是需要新投入,进行调整的。
市场的表现即是,若是新一项突破性的技术形成,整体的产品方向必须调整。

个人建议,在传统的瀑布模型上,增加产品的管控;在研发的过程中使用敏捷模式,快速的交付产品,验证产品的效益,及时调整。形成良性的循环,不断反思,不断试错,进行成长。


参考资料:

为什么我不推荐敏捷开发?

你大概走了假敏捷


要是在第一个产品版本中,只能有3个功能,你要选哪一个?书中给出的建议是,一定要有用户反馈和留言功能。因为,在一个产品的验证阶段和不成熟期时,用户的反馈永远是让产品朝正确方向迭代的重要决策依据。

猜你喜欢

转载自blog.csdn.net/u013205623/article/details/80437147