查看: 154|回复: 0

谈谈敏捷开发

[复制链接]

该用户从未签到

发表于 2019-11-3 14:50:14 | 显示全部楼层 |阅读模式
我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的公司,被迫式的接触了许多“敏捷开发”,随着项目经历越来越多,慢慢的就开始有了更新的熟悉和想法。
但是在接触敏捷开发这个体系之前,自己有时机做一个项目,那个时候我开始将自己认为更有利于项目的管理工作做了一些应用,那个阶段我的重要做法是:
1、项目中开始划分更短的制品交互周期,而不是以前那样等候产物开发完毕后发布各种测试版本。
2、更充分与市场人员交换,在市场人员进行需求交底时,让更多的甚至全体成员到场会议,相识产物的原始业务及需求。并且在过程中有问题也实时的解答及沟通。
3、加强沟通力度,开发测试都在一起天天都会开个小会,通报每日的工作结果,将自己的问题说出来。
4、不同以往的发布频率,测试从项目开始便要切入到产物生产过程,而不是等到最后所有功能都完成后。从而大大减少变动对筹划的影响。
在做这些工作的时候我并不知道敏捷开发这个东西,直到在2010年进入一个公司非常提倡敏捷开发,已经有了迭代周期、backlog、站立会议、周例会等等,在这个团队中对开发过程有各种规章要求,完全是制度化的,这在我加入的初期非常的不适应。事实上转头想想,那种方式已经变的不敏捷了,完全是一种教条式的应用。
后来自己有时机回到了老东家,开始自己带团队,很巧老东家被收购后开始推广敏捷开发,只不过因为不是总部,所以这次没有范本,完全由我自己来组织及控制。很高兴这个小团队几个月下来,个人觉得比力成功,固然背面也得到了公司的承认。
下面就敏捷开发分享一些应该着重注意的点,办理这些问题我想对任何开发团队都会有很大的帮助。
需求在开发中的重要性

大量的开发过程告诉我,需求在软件开发过程中是极其重要的。传统的开发夸大初期的需求调研及需要分析,这个过程对于一些正规的团队会产生大量的文档,而后交由开发睁开产物生产。
然而,事实却不是想象这么简朴,无数的例子阐明了一点,仅仅在需求调研过程中相识到的需求是无法保证的。数不清的例子告诉我们,需求是会变的,变的缘故原由很多。在极端的情况下,有些客户签字的需求在开发完后,有需要变更也很正常。
所以需求是影响软件开发的第一重要因素,需求来源于业务,我们开发的产物不就是因为这些业务才去做的吗?怎样需求都无法把握好,还谈什么开发出好用的产物?
然而怎样做好需求呢?我想首先要确立需求的地位,然后只有通过不断的沟通、尝试、反馈向真实需求迈进。
夸大人与人的交换

不管怎么样开发过程中重要照旧靠人的,而且软件开发是个复杂的团体工程,一个小些的产物也会涉及到各类人:客户、业务分析、管理人员、程序员、测试员等等。这么多人在一起办事情,有一方没有处理好结果肯定就会有问题。
有如许一个例子:客户提出了一个会员管理功能需求,需求人员相识后组织了办理方案,于是交付了开发实现。而颠末二个月无尽的黑夜之后交付,需求一看有个模块做的有偏差,但是已经来不及修改了。交给客户看后,发现这不是他们要的会员管理功能相差较大,另外在功能开发的这一段时间,客户又有了新想法,要对原先需求做调整。
这种例子大概大家经常经历吧?
这种问题在敏捷开发方法中提出了办理方法,就是通过不断的交付可用的制品。看起来很抽象,实在很简朴。同样是上面的例子:
客户提出会员管理功能需求
需求人员在相识需求后与开发负责人探讨,确定一个快迭代的开发筹划,每二周向客户演示一次,并将这个筹划与客户确认
确认后需求人员向全体成员讲解需求配景故事
开发负责人组织并确定迭代筹划内容,明白每个迭代提交的产物目标、开发任务安排、测试跟踪筹划
每个迭代过程中都由需求及测试进行确认每个任务的实现结果是否跑偏
背面就是每二周向客户演示一次产物,并得到客户的反馈
根据客户的反馈调整下个迭代筹划,并继承下一个迭代
直到产物交付
通过上面的步调,就不至于在开发完成后才知道用户的真实想法,因为很多用户对软件开发是没有概念的,他只知道自己有某种需求,但最开始是没有一个完备的概念的。所以就要通过不断的让用户看到产物的模型,这个过程用户才会逐步的对产物产生概念。同样的在过程中客户的提出需求变更也是在一定的可控制范围之内,如许一来可以大大的减少软件返工的情况,自然就不会拖延筹划了。
而这个过程中,需求已经完成了一个真正的过渡,不再是一头重的情况了。他让需求从客户那快速的反馈到开发团队中。同样的,在开发不断的交付制品时,需求也更加实时的相识到产物的进度,把握开发人员开发的功能是否符合需求。
固然这并不是一个标准做法,不同的团队可以有不同的处理方式。这里只是想夸大需求需要更多的投入到开发过程中去,实时的与客户沟通交换,相识到客户的真实想法。
夸大文档的作用

我觉得很多对敏捷开发的一个误解就是不需要文档,敏捷开发并未抛弃文档。只是更夸大更有效的方式使用文档。在很多传统开发方法中,特殊是很多很正规的开发团队对文档的要求非常苛刻。然而事实是文档不易管理,最痛苦的是欠好维护,文档需要随着变化而变化,比如需求调整、技术架构升级、产物维护等等。如果要保证文档的一致性,太难了。特殊是对于一些无法进行有效管理的开发团队就更加明显,经常是软件已经几个版本了,文档却是两年前的。
但敏捷真的不需要文档吗?我想不是的,怎样把文档做到好维护我想才是最重要的。文档到底指的指的什么?什么样的算文档?
提出上面两个问题,我们先想想经常说的文档的作用是什么?不就是一个流传工具吗?可以用作记录、给他人看、用于以后检察。有很多方法可就办理了这个问题,比如wiki系统。维护一个wiki系统,可以随时写,随时维护,可以方便的查找。嗯,多方便。
另外一个问题就是什么样的工作需要形成文档呢?
记得在前一家公司,维护一个10多年的老系统修改一个公式计算的BUG,但是怎么也不知道这个复杂的公式是什么意思,问过了公司大部门的人也无人可解。这时想,如果当初有那么一份文档,谢天谢地。
像这种关键的内容有份文档照旧很重要的,否则随着时间推移,谁也不能保证能记得住其时为什么会这么干。
记得多年前一次记笔记的经历,我看了一篇文章相识了DELPHI实现单实例模式的方法,这种方法很酷。于是整理成了笔记写在了wiki上,第二天就得到了回复,帮助到了别外产物开发组的同事。
嗯,文档就是如许他具有流传性,你不大概跑去跟所有人说出你的想法,但是文档却更容易达成。他也有传承性,有些文档大概10多年后又起了重要作用。
团队协作

1、减少对开发人员的干扰

曾经接办一个产物的开发,最初遇到一个很头痛的问题,原先写好的迭代筹划,而且工作量也较大,大家都在忙着。即便在如许的状态下,客服人员却经常跑来找某个程序员A维护各种系统问题,程序员A在一次维护中竟然导致了系统数据出现大面积错误。程序员A心理上承受着巨大的压力,而天天的这些问题又不得不办理,加之新版本又有很重的开发任务无法完成,终极导致整个开发筹划变更。
我无法再忍受,找到了需求及客服的负责人,沟通后发现这些问题很多都是重复性的,重要是因为原先系统的不足。于是回去组织人员做了几个后台暂时功能,并交付给了客服人员,之后就没有再来找过这位程序员A。后续我又找到了客服负责人,要求不能直接找开发人员办理这类问题,并与负责人约定了处理过程。
这是个例子,在现实情况中还有很多这种事情,甚至有很多开发人员要直接面对客户。我想对于职能型团队来说,开发团队最好是减少这些方面的干忧。固然对于一个人包干的情况就不讨论了。
大部门的人都不是超人,在一个时间段内处理超出自己负荷的工作是很难做好保质保量的。所以对于开发管理人员一定要考虑到这点,尽量让开发人员有比力好的工作进度环境,通过外界的方式来办理一些开发团队的干扰。
我接触过的很多程序员都很反感这种干扰,固然有些人在这种全面的工作强度下发展很快,但是并非所有人都适应,长期下来会有怨恨和不快,工作效率会降落。心情愉快照旧很重要的,记得有一次迭代总结时,有个程序员总结说:发现心情愉快自己的工作效率很高。呵呵。我想你也有同感吧。
2、不要忽略测试人员在开发阶段的作用

曾经多少次在项目发布前加班到深夜2点的情景还历历在目,那种感觉即快乐又痛苦。由于和客户签定的合同的交付日期就要到了,产物却迟迟未集成完成,测试只能干等着上网聊QQ。就在下班前的一刻发布了,测试开始了紧张的测试,在屏幕闪动中,一个个的BUG提交,直到流程都无法都走不下去,测试无奈了。第二天就要发布,实施人员就等着制品第二天出差。只有不断的改,再发布,无尽的循环。直到大家都憔悴的看着老大,终于老大说:还剩下的这几个问题无关紧要,大家回去吧。
几个月的开发已往后在总结会上,只能诉苦测试资源不足,时间太短,需求更改太多,需求更改后测试不知道。无数的问题一次一次的出现在同样的总结会议上。
上面的这个例子很多人应该经历过,真的测试只有最后一刻才能体现价值吗?我想不是的。
在背面的项目中我总结了这个问题的,针对每个开发任务要求进行测试验证。而测试怎样验证呢?他需要知道这个开发任务的需求是怎样,提前做好测试筹划及测试用例,在接到开发制品后测试并提交BUG,这个工作是可以开发过程中就能不断的进行的。保证每一个任务的质量,可以大大减少后期集成的错误量。
另外根据敏捷开发的思想,测试团队在开发过程中也需要加强与开发团队的交换,甚至有须要构成虚拟团队,位置调整到一起,如许可以实时快速的交换,参加开发团队的站立会议同样可以实时相识到开发的现实情况及进度,反过来把握测试筹划及测试内容。
特殊是测试从另一个角度来审阅需求,如许也可以一定程度上发现大概改善需求上的不足。
3、发挥团队人员的潜力

敏捷开发比力提倡开发任务由开发自己评估并认领工作任务,如许可以激发开发的潜在动力。
之前在做一个新产物时,需要使用java,而我们团队是使用C#的,面临转型问题。而有一位同事很感兴趣,于是我就让他负责前期的框架探索与搭建。结果就是这位小伙工作效率很高,我最初给他的目标全部都完成了。最有意思的是背面产物开始研发时,这位小伙已经成为了团队的大牛,大家有问题都找他办理。也正是因为这个过程,这位小伙被全面激活,也在大家面前展示了能力。甚至在小伙去职时也被领导给予大幅涨薪来挽留。只不过谁又能想象到这位小伙进入我团队之前是因为被定为裁人的目标而调度过来的呢!
所以充分发挥好每个人员的特点,让人能够在自己感兴趣的工作中,效果会很多。减少指派方式的任务的分配,充分发挥个人的自动性,这个团队精神面貌也会好很多。
4、管理者不要离团队太远

作为团队的Leader要到场到团队的工作中去,比如一个开发主管一定要写写代码,到场架构等对项目有关的事情,而不是在那里分分任务。如许团队成员才会觉得这个Leader很密切感。
特殊是有些开发主管在带队后离团队越来越远,有时对于开发进度不如意时就说:“这么个简朴功能怎么会搞了这么久?”,实在天天都在加班的同事心里想着:“有本事你来?”,纵然这个小组长有这个能力,但对于团队来说也不是一件功德,因为大家都抱有怨恨之心,还谈什么好好工作呢?这个小组长就是失职的。所以这种情况下应该自动去相识进度滞后的缘故原由,并且自己要加入到办理问题的工作中去,而不是在边上诉苦别人。
5、小组织不要搞太多的官

中国几千年的文化,官本位一直影响着我们,大家都想坐在那指挥,自己啥事也不用干,想想都惬意。在我们这个行业是不是发现也很雷同?大家都想着干几年当个小组长,然后升个部门经理,当上CTO迎娶白富美。
团队的管理基本是事与人的管理,非常的伤脑和心。如果一个组织内,特殊是小组织内“官”太多,协调就会非常的难,大家就会经常性的扯皮。
竣事

与敏捷开发结缘也有几年,从开始的抵触到背面的承认经历了许多,这个过程并不是一蹴而就的,需要花时间花精力,特殊是要去实践、总结。
还有我觉得是不能太教条,很多事情都要有猜疑的心,然后去实践总结,找到合适自己团队的方式方法。
写点软件开发技术、理财、生活小文章,java\delphi

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?用户注册

x

天涯海角也要找到Ni:谈谈敏捷开发

中发现Ni: 谈谈敏捷开发
中发现Ni: 谈谈敏捷开发
中发现Ni: 谈谈敏捷开发
中发现Ni: 谈谈敏捷开发
中发现Ni: 谈谈敏捷开发
中发现Ni: 谈谈敏捷开发
相关技术服务需求,请联系管理员和客服QQ:2753533861或QQ:619920289
您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

帖子推荐:
客服咨询

QQ:2753533861

服务时间 9:00-22:00

快速回复 返回顶部 返回列表