敏捷开发方法综述

Posted 就是潘金莲的野野鬼

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了敏捷开发方法综述相关的知识,希望对你有一定的参考价值。

看了知乎上的帖子,查阅资料,下面是有关于敏捷开发的定义。
 
……………核心角色………………………
产品设计:负责产品设计,将产品需求转化为DEMO和设计文档,交付开发和测试。同时,验收产品功能。 

开发:将设计转化为实际产品,交付给测试。 

测试:测试产品,测试通过的交付给产品设计人员。不通过的踢回给开发。 

Leader:负责下达任务,另外重要职责就是,当团队成员中出现意见不合时,负责拍板!
………………………………………………………………

      敏捷开发的核心就是团结,敏捷开发追求效率,将一个大的产品功能划分成小的,然后一块块的迭代开发。在这个过程中,大家之间采用一种互相容易理解的方式表达产品需求,可能一些特别细节方面的不会在设计文档中体现(如果要达到非常细的程度是非常耗时的),在开发和测试过程中,互相的沟通讨论是非常多的,这时如果发现产品描述中缺少的或者错误的,大家会口头协调好处理方法,再由产品经理一点点得补进去,如果这个时候团队之间不够团结,互相斤斤计较“你写的文档有问题!”“你理解能力太差!”等等,将会很难推行。开发和测试之间也是一样。
……………核心角色………………………
产品设计:负责产品设计,将产品需求转化为DEMO和设计文档,交付开发和测试。同时,验收产品功能。 

开发:将设计转化为实际产品,交付给测试。 

测试:测试产品,测试通过的交付给产品设计人员。不通过的踢回给开发。 

Leader:负责下达任务,另外重要职责就是,当团队成员中出现意见不合时,负责拍板!
………………………………………………………………

前面说了,敏捷开发的核心就是团结,敏捷开发追求效率,将一个大的产品功能划分成小的,然后一块块的迭代开发。在这个过程中,大家之间采用一种互相容易理解的方式表达产品需求,可能一些特别细节方面的不会在设计文档中体现(如果要达到非常细的程度是非常耗时的),在开发和测试过程中,互相的沟通讨论是非常多的,这时如果发现产品描述中缺少的或者错误的,大家会口头协调好处理方法,再由产品经理一点点得补进去,如果这个时候团队之间不够团结,互相斤斤计较“你写的文档有问题!”“你理解能力太差!”等等,将会很难推行。开发和测试之间也是一样。

敏捷开发包括了哪些内容

敏捷开发总的流程如下:
1.需求规划和分期
2. 需求评审
3. 需求讲解
4. 方案评审
5. 每日晨会
6. 性能测试
7. CodeReview
8. Demo
9. 测试阶段
10.线上Bug修改流程

     跟我说哪些东西不应该包含在敏捷开发流程里,如果你不喜欢,跟你的观念有冲突,你可以把敏捷开发这四个字换成任意四个字。总之,如果要解决这些问题,这是我目前看到的最佳实践,每一个节点都非纸上谈兵,而是经过无数个尝试和失败总结出来的。
如果你是一个IT公司的管理者,如果你不知道该怎么去管理自己的团队,我强烈安列你按着我说的这种标准化方式去做,放心,出了问题我保证不会负一点责任。
确切的说,我说的敏捷开发流程,并不仅仅是开发团队的事情,它背后隐藏着更多的理念。

1.产品和开发必须是一个Team,大家只是分工不同,角色不同,并不是两个对立的团队。

如果你的公司是把产品和开发分成两个部门,那么恭喜你,产品和开发之间的纠纷一定无限多。

在所有我带的Team中,自始至终强调的理念就是:出了问题,别跟我说这是产品设计出来,这是开发团队实现不了的。我只知道这是你们一个开发小组所有人的责任,这个后果是所有的人都需要承担的。如果我们认真的区分这是什么问题,那么也只是为了避免下次出现同样的情况,用户只会知道是一个公司出了一款垃圾产品,没有人关心到底是产品还是开发的锅。

这是做敏捷开发的大前提。或者不仅仅是产品和开发,责任共担,One Team这个理念是贯穿始终的。这并不是说,大锅饭,而是说,面对不好的结果,所有Team的人都必须共同承担。出现问题的原因仅仅是为了追溯和重现当时的场景,以避免后续会出现同样的情况。

产品和开发必须是一个Team还体现在需求分期上。这一点在讲到需求分期的流程的时候,会提高的。实际上,需求分期如果没做好,敏捷开发只能流于形式。

需求分期怎么做,这是MVP的事情,另一个话题。简单来说,每一期都要有一个提前的预测,这一期里要做的所有的功能都只为了检测自己的预测是否正确。并根据结果去不断的调整开发规划。

2.职责明确,每个人要负责的事情必须清晰无误,谁该做哪些事情,必须要提前讲清楚。

开发团队的推荐角色应该是这样的。
PM 1个
UI 1个
CSS/js 1~2个
Java 2~4个
android 1~2个
ios 1~2个
QA 1个

这是一个相对平衡的模板,这样的一个8~10人的小Team,是可以复制的。敏捷开发支持多个Team并行开发。理论上来讲。这种方式,可以支持五到六个小Team同时启动。

在讲到最后多Team并发协作的时候,我也会提到的。
除了这些项目小组的角色,还有各个Team的Leader。我比较推荐小组分成如下几种:
1.产品Team 产品团队
2.用户体验 Team 传统的UI团队升级为UE,升级为整个系统甚至是公司的用户体验师。
3.后端Team 苦逼的后端
4.前端Team Android/IOS/JS 表问我为什么把这三个放到一起,我就是认为一个前端工程师应该三者通吃。可以在某一个客户端上了解的更深入,但是普通的项目上手还是应该没有问题的。
5.QATeam QA只需要做功能测试,回归测试,边界测试,并不需要做性能测试。
 
3.每个人必须学会主动去为自己的事情负责

当有了第二条,你很快就能发现团队中,谁是能够尽守职责,更主动的人。第3条很难做到,特别在很多公司,并不注重对于团队凝聚力的培养,也不会注重和他们之间的交流,不知道他们想要什么。

所以这也是我一再强调的,敏捷开发并不仅仅是一个开发流程,更是一种管理的方式,他牵涉到绩效考核,公司福利,上下班制度等等你看不到的东西。

如果说你的团队成员并不能做到为自己的事情负责,那么你需要的就是,要么就是去更换团队,要么就是想办法去激励团队。

以上是关于敏捷开发方法综述的主要内容,如果未能解决你的问题,请参考以下文章

敏捷开发方法综述

敏捷开发方法综述

敏捷开发方法综述

敏捷开发方法综述

敏捷开发 Scrum 综述

敏捷开发方法综述