我对灵敏开发是源于10多年前看了一本关于迭代开发的书，从而对迭代开发有了一些兴趣。从那时开端有了迭代开发的概念。跟着项目经验的增加迭代的重要性也越发觉得显着。随后进入了发起灵敏开发的公司，被迫式的触摸了许多“灵敏开发”，跟着项目阅历越来越多，慢慢的就开端有了更新的认识和主意。

但是在触摸灵敏开发这个体系之前，自己有机会做一个项目，那个时分我开端将自己认为更有利于项目的办理作业做了一些运用，那个阶段我的首要做法是：

1、项目中开端划分更短的制品交互周期，而不是以前那样等候产品开发完毕后发布各种测验版本。
2、更充沛与商场人员沟通，在商场人员进行需求交底时，让更多的甚至全体成员参加会议，了解产品的原始事务及需求。并且在进程中有问题也及时的解答及沟通。
3、加强沟通力度，开发测验都在一同每天都会开个小会，通报每日的作业成果，将自己的问题说出来。
4、不同以往的发布频率，测验从项目开端便要切入到产品出产进程，而不是比及最后所有功用都完结后。从而大大削减变动对方案的影响。

在做这些作业的时分我并不知道灵敏开发这个东西，直到在2010年进入一个公司十分发起灵敏开发，现已有了迭代周期、backlog、站立会议、周例会等等，在这个团队中对开发进程有各种规章要求，完全是制度化的，这在我加入的初期十分的不适应。现实上回头想想，那种办法现已变的不灵敏了，完全是一种教条式的运用。

后来自己有机会回到了老东家，开端自己带团队，很巧老东家被收购后开端推行灵敏开发，只不过由于不是总部，所以这次没有范本，完全由我自己来安排及操控。很快乐这个小团队几个月下来，个人觉得比较成功，当然后边也得到了公司的认可。

下面就灵敏开发分享一些应该着重留意的点，处理这些问题我想对任何开发团队都会有很大的帮助。

需求在开发中的重要性

许多的开发进程告知我，需求在软件开发进程中是极其重要的。传统的开发着重初期的需求调研及需求分析，这个进程关于一些正规的团队会发生许多的文档，然后交由开发打开产品出产。

但是，现实却不是幻想这么简略，许多的比如说明晰一点，仅仅在需求调研进程中了解到的需求是无法确保的。数不清的比如告知咱们，需求是会变的，变的原因许多。在极点的状况下，有些客户签字的需求在开发完后，有需求改变也很正常。

所以需求是影响软件开发的第一重要因素，需求来源于事务，咱们开发的产品不便是由于这些事务才去做的吗？怎么需求都无法掌握好，还谈什么开宣布好用的产品？

但是怎么做好需求呢？我想首先要建立需求的地位，然后只要经过不断的沟通、测验、反应向实在需求跨进。

着重人与人的沟通

不论怎么样开发进程中首要仍是靠人的，并且软件开发是个杂乱的团体工程，一个小些的产品也会涉及到各类人：客户、事务分析、办理人员、程序员、测验员等等。这么多人在一同做工作，有一方没有处理好成果肯定就会有问题。

有这样一个比如：客户提出了一个会员办理功用需求，需求人员了解后安排了处理方案，所以交给了开发完结。而经过二个月无尽的黑夜之后交给，需求一看有个模块做的有偏差，但是现已来不及修改了。交给客户看后，发现这不是他们要的会员办理功用相差较大，别的在功用开发的这一段时刻，客户又有了新主意，要对原先需求做调整。

这种比如或许咱们常常阅历吧？

这种问题在灵敏开发办法中提出了处理办法，便是经过不断的交给可用的制品。看起来很抽象，其实很简略。相同是上面的比如：
客户提出会员办理功用需求
需求人员在了解需求后与开发担任人商议，承认一个快迭代的开发方案，每二周向客户演示一次，并将这个方案与客户承认
承认后需求人员向全体成员解说需求背景故事
开发担任人安排并承认迭代方案内容，明确每个迭代提交的产品方针、开发使命安排、测验跟踪方案
每个迭代进程中都由需求及测验进行承认每个使命的完结成果是否跑偏
后边便是每二周向客户演示一次产品，并取得客户的反应
根据客户的反应调整下个迭代方案，并继续下一个迭代
直到产品交给

经过上面的步骤，就不至于在开发完结后才知道用户的实在主意，由于许多用户对软件开发是没有概念的，他只知道自己有某种需求，但最开端是没有一个完整的概念的。所以就要经过不断的让用户看到产品的模型，这个进程用户才会逐步的对产品发生概念。相同的在进程中客户的提出需求改变也是在必定的可操控范围之内，这样一来可以大大的削减软件返工的状况，自然就不会拖延方案了。

而这个进程中，需求现已完结了一个真实的过渡，不再是一头重的状况了。他让需求从客户那快速的反应到开发团队中。相同的，在开发不断的交给制品时，需求也愈加及时的了解到产品的进展，掌握开发人员开发的功用是否契合需求。
当然这并不是一个规范做法，不同的团队可以有不同的处理办法。这儿仅仅想着重需求需求更多的投入到开发进程中去，及时的与客户沟通沟通，了解到客户的实在主意。

着重文档的作用

我觉得许多对灵敏开发的一个误解便是不需求文档，灵敏开发并未抛弃文档。仅仅更着重更有用的办法运用文档。在许多传统开发办法中，特别是许多很正规的开发团队对文档的要求十分苛刻。但是现实是文档不易办理，最痛苦的是欠好保护，文档需求跟着改变而改变，比如需求调整、技术架构升级、产品保护等等。假如要确保文档的一致性，太难了。特别是关于一些无法进行有用办理的开发团队就愈加显着，常常是软件现已几个版本了，文档却是两年前的。

但灵敏真的不需求文档吗？我想不是的，怎么把文档做到好保护我想才是最重要的。文档到底指的指的什么？什么样的算文档？

提出上面两个问题，咱们先想想常常说的文档的作用是什么？不便是一个传播东西吗？可以用作记录、给他人看、用于今后查看。有许多办法可就处理了这个问题，比如wiki体系。保护一个wiki体系，可以随时写，随时保护，可以便利的查找。嗯，多便利。

别的一个问题便是什么样的作业需求构成文档呢？

记住在前一家公司，保护一个10多年的老体系修改一个公式计算的BUG，但是怎么也不知道这个杂乱的公式是什么意思，问过了公司大部分的人也无人可解。这时想，假如最初有那么一份文档，谢天谢地。

像这种关键的内容有份文档仍是很重要的，不然跟着时刻推移，谁也不能确保能记住住其时为什么会这么干。

记住多年前一次记笔记的阅历，我看了一篇文章了解了DELPHI完结单实例模式的办法，这种办法很帅。所以收拾成了笔记写在了wiki上，第二天就得到了回复，帮助到了别外产品开发组的搭档。

嗯，文档便是这样他具有传播性，你不或许跑去跟所有人说出你的主意，但是文档却更容易达到。他也有传承性，有些文档或许10多年后又起了重要作用。

团队协作

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

从前接手一个产品的开发，最初遇到一个很头痛的问题，原先写好的迭代方案，并且作业量也较大，咱们都在忙着。即便在这样的状态下，客服人员却常常跑来找某个程序员A保护各种体系问题，程序员A在一次保护中居然导致了体系数据出现大面积错误。程序员A心理上承受着巨大的压力，而每天的这些问题又不得不处理，加之新版本又有很重的开发使命无法完结，终究导致整个开发方案改变。

我无法再忍耐，找到了需求及客服的担任人，沟通后发现这些问题许多都是重复性的，首要是由于原先体系的不足。所以回去安排人员做了几个后台暂时功用，并交给给了客服人员，之后就没有再来找过这位程序员A。后续我又找到了客服担任人，要求不能直接找开发人员处理这类问题，并与担任人约好了处理进程。

这是个比如，在实际状况中还有许多这种工作，甚至有许多开发人员要直接面临客户。我想关于功能型团队来说，开发团队最好是削减这些方面的干忧。当然关于一个人包干的状况就不评论了。

大部分的人都不是超人，在一个时刻段内处理超出自己负荷的作业是很难做好保质保量的。所以关于开发办理人员必定要考虑到这点，尽量让开发人员有比较好的作业进展环境，经过外界的办法来处理一些开发团队的干扰。

成功的前端工程师很会善用东西，这些年低代码概念开端流行，像国外的Mendix，国内的JNPF，这种新型的开发办法，图形化的迁延拽配置界面，并兼容了自定义的组件、代码扩展，确实在B端后台办理类网站建设中很大程度上的提升了效率。

开源地址：www.yinmaisoft.com/?from=jueji…

任何信息化项目都可以根据 JNPF 开宣布 ERP、OA、CRM、EHR 等各类办理体系。

这边强烈建议试试它，你会发现不一样的惊喜！心情舒畅仍是很重要的，记住有一次迭代总结时，有个程序员总结说：发现心情舒畅自己的作业效率很高。呵呵。我想你也有同感吧。

2、不要忽略测验人员在开发阶段的作用

从前多少次在项目发布前加班到深夜2点的情形还历历在目，那种感觉即快乐又痛苦。由于和客户签定的合同的交给日期就要到了，产品却迟迟未集成完结，测验只能干等着上网聊QQ。就在下班前的一刻发布了，测验开端了严重的测验，在屏幕闪烁中，一个个的BUG提交，直到流程都无法都走不下去，测验无奈了。第二天就要发布，施行人员就等着制品第二天出差。只要不断的改，再发布，无尽的循环。直到咱们都瘦弱的看着老迈，总算老迈说：还剩下的这几个问题无关紧要，咱们回去吧。

几个月的开发过去后在总结会上，只能诉苦测验资源不足，时刻太短，需求更改太多，需求更改后测验不知道。许多的问题一次一次的出现在相同的总结会议上。

上面的这个比如许多人应该阅历过，真的测验只要最后一刻才干表现价值吗？我想不是的。

在后边的项目中我总结了这个问题的，针对每个开发使命要求进行测验验证。而测验怎么验证呢？他需求知道这个开发使命的需求是怎么，提前做好测验方案及测验用例，在接到开发制品后测验并提交BUG，这个作业是可以开发进程中就能不断的进行的。确保每一个使命的质量，可以大大削减后期集成的错误量。

别的根据灵敏开发的思维，测验团队在开发进程中也需求加强与开发团队的沟通，甚至有必要组成虚拟团队，方位调整到一同，这样可以及时快速的沟通，参加开发团队的站立会议相同可以及时了解到开发的实际状况及进展，反过来掌握测验方案及测验内容。

特别是测验从另一个视点来审视需求，这样也可以必定程度上发现或许改进需求上的不足。

3、发挥团队人员的潜力

灵敏开发比较发起开发使命由开发自己评估并招领作业使命，这样可以激发开发的潜在动力。

之前在做一个新产品时，需求运用java，而咱们团队是运用C#的，面临转型问题。而有一位搭档很感兴趣，所以我就让他担任前期的结构探索与搭建。成果便是这位小伙作业效率很高，我最初给他的方针全部都完结了。最有意思的是后边产品开端研制时，这位小伙现已成为了团队的大牛，咱们有问题都找他处理。也正是由于这个进程，这位小伙被全面激活，也在咱们面前展现了才能。甚至在小伙离职时也被领导给予大幅涨薪来挽留。只不过谁又能幻想到这位小伙进入我团队之前是由于被定为裁人的方针而调剂过来的呢!

所以充沛发挥好每个人员的特点，让人可以在自己感兴趣的作业中，作用会许多。削减指派办法的使命的分配，充沛发挥个人的自动性，这个团队精神面貌也会好许多。

4、办理者不要离团队太远

作为团队的Leader要参加到团队的作业中去，比如一个开发主管必定要写写代码，参加架构等对项目有关的工作，而不是在那里分分使命。这样团队成员才会觉得这个Leader很亲近感。

特别是有些开发主管在带队后离团队越来越远，有时关于开发进展不如意时就说：“这么个简略功用怎么会搞了这么久？”，其实每天都在加班的搭档心里想着：“有本事你来？”，即便这个小组长有这个才能，但关于团队来说也不是一件功德，由于咱们都抱有怨恨之心，还谈什么好好作业呢？这个小组长便是渎职的。所以这种状况下应该自动去了解进展滞后的原因，并且自己要加入到处理问题的作业中去，而不是在边上诉苦他人。

5、小安排不要搞太多的官

中国几千年的文明，官本位一直影响着咱们，咱们都想坐在那指挥，自己啥事也不必干，想想都惬意。在咱们这个行业是不是发现也很类似？咱们都想着干几年当个小组长，然后升个部门经理，当上CTO迎娶白富美。

团队的办理基本是事与人的办理，十分的伤脑和心。假如一个安排内，特别是小安排内“官”太多，协调就会十分的难，咱们就会常常性的扯皮。

结束

与灵敏开发结缘也有几年，从开端的抵触到后边的认可阅历了许多，这个进程并不是一蹴即至的，需求花时刻花精力，特别是要去实践、总结。

还有我觉得是不能太教条，许多工作都要有怀疑的心，然后去实践总结，找到适宜自己团队的办法办法。

注：此文章为原创，欢迎转载，请在文章页面显着方位给出此文链接！ 若您觉得这篇文章还不错请点击下右下角的引荐，十分感谢！