可是在接触敏捷开发这个体系以前，本身有机会作一个项目，那个时候我开始将本身认为更有利于项目的管理工做作了一些应用，那个阶段个人主要作法是：程序员
一、项目中开始划分更短的制品交互周期，而不是之前那样等待产品开发完毕后发布各类测试版本。
二、更充分与市场人员交流，在市场人员进行需求交底时，让更多的甚至全体成员参与会议，了解产品的原始业务及需求。而且在过程当中有问题也及时的解答及沟通。
三、增强沟通力度，开发测试都在一块儿天天都会开个小会，通报每日的工做成果，将本身的问题说出来。
四、不一样以往的发布频率，测试从项目开始便要切入到产品生产过程，而不是等到最后全部功能都完成后。从而大大减小变更对计划的影响。markdown
在作这些工做的时候我并不知道敏捷开发这个东西，直到在2010年进入一个公司很是提倡敏捷开发，已经有了迭代周期、backlog、站立会议、周例会等等，在这个团队中对开发过程有各类规章要求，彻底是制度化的，这在我加入的初期很是的不适应。事实上回头想一想，那种方式已经变的不敏捷了，彻底是一种教条式的应用。架构
后来本身有机会回到了老东家，开始本身带团队，很巧老东家被收购后开始推广敏捷开发，只不过由于不是总部，因此此次没有范本，彻底由我本身来组织及控制。很高兴这个小团队几个月下来，我的以为比较成功，固然后面也获得了公司的承认。框架
下面就敏捷开发分享一些应该着重注意的点，解决这些问题我想对任何开发团队都会有很大的帮助。工具
需求在开发中的重要性
大量的开发过程告诉我，需求在软件开发过程当中是极其重要的。传统的开发强调初期的需求调研及须要分析，这个过程对于一些正规的团队会产生大量的文档，然后交由开发展开产品生产。post
然而，事实却不是想象这么简单，无数的例子说明了一点，仅仅在需求调研过程当中了解到的需求是没法保证的。数不清的例子告诉咱们，需求是会变的，变的缘由不少。在极端的状况下，有些客户签字的需求在开发完后，有须要变动也很正常。测试
因此需求是影响软件开发的第一重要因素，需求来源于业务，咱们开发的产品不就是由于这些业务才去作的吗？如何需求都没法把握好，还谈什么开发出好用的产品？blog
然而如何作好需求呢？我想首先要确立需求的地位，而后只有经过不断的沟通、尝试、反馈向真实需求迈进。资源
强调人与人的交流
无论怎么样开发过程当中主要仍是靠人的，并且软件开发是个复杂的团体工程，一个小些的产品也会涉及到各种人：客户、业务分析、管理人员、程序员、测试员等等。这么多人在一块儿作事情，有一方没有处理好结果确定就会有问题。
有这样一个例子：客户提出了一个会员管理功能需求，需求人员了解后组织了解决方案，因而交付了开发实现。而通过二个月无尽的黑夜以后交付，需求一看有个模块作的有误差，可是已经来不及修改了。交给客户看后，发现这不是他们要的会员管理功能相差较大，另外在功能开发的这一段时间，客户又有了新想法，要对原先需求作调整。
这种例子可能你们常常经历吧？
这种问题在敏捷开发方法中提出了解决方法，就是经过不断的交付可用的制品。看起来很抽象，其实很简单。一样是上面的例子：
Ø 客户提出会员管理功能需求
Ø 需求人员在了解需求后与开发负责人商量，肯定一个快迭代的开发计划，每二周向客户演示一次，并将这个计划与客户确认
Ø 确认后需求人员向全体成员讲解需求背景故事
Ø 开发负责人组织并肯定迭代计划内容，明确每一个迭代提交的产品目标、开发任务安排、测试跟踪计划
Ø 每一个迭代过程当中都由需求及测试进行确认每一个任务的实现结果是否跑偏
Ø 后面就是每二周向客户演示一次产品，并得到客户的反馈
Ø 根据客户的反馈调整下个迭代计划，并继续下一个迭代
Ø 直到产品交付
经过上面的步骤，就不至于在开发完成后才知道用户的真实想法，由于不少用户对软件开发是没有概念的，他只知道本身有某种需求，但最开始是没有一个完整的概念的。因此就要经过不断的让用户看到产品的模型，这个过程用户才会逐步的对产品产生概念。一样的在过程当中客户的提出需求变动也是在必定的可控制范围以内，这样一来能够大大的减小软件返工的状况，天然就不会拖延计划了。
而这个过程当中，需求已经完成了一个真正的过渡，再也不是一头重的状况了。他让需求从客户那快速的反馈到开发团队中。一样的，在开发不断的交付制品时，需求也更加及时的了解到产品的进度，把握开发人员开发的功能是否符合需求。
固然这并非一个标准作法，不一样的团队能够有不一样的处理方式。这里只是想强调需求须要更多的投入到开发过程当中去，及时的与客户沟通交流，了解到客户的真实想法。
强调文档的做用
我以为不少对敏捷开发的一个误解就是不须要文档，敏捷开发并未抛弃文档。只是更强调更有效的方式使用文档。在不少传统开发方法中，特别是不少很正规的开发团队对文档的要求很是苛刻。然而事实是文档不易管理，最痛苦的是很差维护，文档须要随着变化而变化，好比需求调整、技术架构升级、产品维护等等。若是要保证文档的一致性，太难了。特别是对于一些没法进行有效管理的开发团队就更加明显，常常是软件已经几个版本了，文档倒是两年前的。
但敏捷真的不须要文档吗？我想不是的，如何把文档作到好维护我想才是最重要的。文档到底指的指的什么？什么样的算文档？
提出上面两个问题，咱们先想一想常常说的文档的做用是什么？不就是一个传播工具吗？能够用做记录、给他人看、用于之后查看。有不少方法可就解决了这个问题，好比wiki系统。维护一个wiki系统，能够随时写，随时维护，能够方便的查找。嗯，多方便。
另一个问题就是什么样的工做须要造成文档呢？
记得在前一家公司，维护一个10多年的老系统修改一个公式计算的BUG，可是怎么也不知道这个复杂的公式是什么意思，问过了公司大部分的人也无人可解。这时想，若是当初有那么一份文档，谢天谢地。
像这种关键的内容有份文档仍是很重要的，不然随着时间推移，谁也不能保证能记得住当时为何会这么干。
记得多年前一次记笔记的经历，我看了一篇文章了解了DELPHI实现单实例模式的方法，这种方法很酷。因而整理成了笔记写在了wiki上，次日就获得了回复，帮助到了别外产品开发组的同事。
嗯，文档就是这样他具备传播性，你不可能跑去跟全部人说出你的想法，可是文档却更容易达成。他也有传承性，有些文档也许10多年后又起了重要做用。
团队协做
一、减小对开发人员的干扰
曾经接手一个产品的开发，最初遇到一个很头痛的问题，原先写好的迭代计划，并且工做量也较大，你们都在忙着。即使在这样的状态下，客服人员却常常跑来找某个程序员A维护各类系统问题，程序员A在一次维护中居然致使了系统数据出现大面积错误。程序员A心理上承受着巨大的压力，而天天的这些问题又不得不解决，加之新版本又有很重的开发任务没法完成，最终致使整个开发计划变动。
我没法再忍受，找到了需求及客服的负责人，沟通后发现这些问题不少都是重复性的，主要是由于原先系统的不足。因而回去组织人员作了几个后台临时功能，并交付给了客服人员，以后就没有再来找过这位程序员A。后续我又找到了客服负责人，要求不能直接找开发人员解决这类问题，并与负责人约定了处理过程。
这是个例子，在实际状况中还有不少这种事情，甚至有不少开发人员要直接面对客户。我想对于职能型团队来讲，开发团队最好是减小这些方面的干忧。固然对于一我的包干的状况就不讨论了。
大部分的人都不是超人，在一个时间段内处理超出本身负荷的工做是很难作好保质保量的。因此对于开发管理人员必定要考虑到这点，尽可能让开发人员有比较好的工做进度环境，经过外界的方式来解决一些开发团队的干扰。
我接触过的不少程序员都很反感这种干扰，虽然有些人在这种全面的工做强度下成长很快，可是并不是全部人都适应，长期下来会有怨恨和不快，工做效率会降低。心情舒畅仍是很重要的，记得有一次迭代总结时，有个程序员总结说：发现心情舒畅本身的工做效率很高。呵呵。我想你也有同感吧。
二、不要忽略测试人员在开发阶段的做用
曾经多少次在项目发布前加班到深夜2点的情景还历历在目，那种感受即快乐又痛苦。因为和客户签订的合同的交付日期就要到了，产品却迟迟未集成完成，测试只能干等着上网聊QQ。就在下班前的一刻发布了，测试开始了紧张的测试，在屏幕闪动中，一个个的BUG提交，直到流程都没法都走不下去，测试无奈了。次日就要发布，实施人员就等着制品次日出差。只有不断的改，再发布，无尽的循环。直到你们都憔悴的看着老大，终于老大说：还剩下的这几个问题可有可无，你们回去吧。
几个月的开发过去后在总结会上，只能抱怨测试资源不足，时间过短，需求更改太多，需求更改后测试不知道。无数的问题一次一次的出如今一样的总结会议上。
上面的这个例子不少人应该经历过，真的测试只有最后一刻才能体现价值吗？我想不是的。
在后面的项目中我总结了这个问题的，针对每一个开发任务要求进行测试验证。而测试如何验证呢？他须要知道这个开发任务的需求是如何，提早作好测试计划及测试用例，在接到开发制品后测试并提交BUG，这个工做是能够开发过程当中就能不断的进行的。保证每个任务的质量，能够大大减小后期集成的错误量。
另外根据敏捷开发的思想，测试团队在开发过程当中也须要增强与开发团队的交流，甚至有必要组成虚拟团队，位置调整到一块儿，这样能够及时快速的交流，参加开发团队的站立会议一样能够及时了解到开发的实际状况及进度，反过来把握测试计划及测试内容。
特别是测试从另外一个角度来审视需求，这样也能够必定程度上发现或者改善需求上的不足。
三、发挥团队人员的潜力
敏捷开发比较提倡开发任务由开发本身评估并认领工做任务，这样能够激发开发的潜在动力。
以前在作一个新产品时，须要使用java，而咱们团队是使用C#的，面临转型问题。而有一位同事很感兴趣，因而我就让他负责前期的框架探索与搭建。结果就是这位小伙工做效率很高，我最初给他的目标所有都完成了。最有意思的是后面产品开始研发时，这位小伙已经成为了团队的大牛，你们有问题都找他解决。也正是由于这个过程，这位小伙被全面激活，也在你们面前展现了能力。甚至在小伙离职时也被领导给予大幅涨薪来挽留。只不过谁又能想象到这位小伙进入我团队以前是由于被定为裁人的目标而调剂过来的呢!
因此充分发挥好每一个人员的特色，让人可以在本身感兴趣的工做中，效果会不少。减小指派方式的任务的分配，充分发挥我的的主动性，这个团队精神面貌也会好不少。
四、管理者不要离团队太远
做为团队的Leader要参与到团队的工做中去，好比一个开发主管必定要写写代码，参与架构等对项目有关的事情，而不是在那里分分任务。这样团队成员才会以为这个Leader很亲近感。
特别是有些开发主管在带队后离团队愈来愈远，有时对于开发进度不如意时就说：“这么个简单功能怎么会搞了这么久？”，其实天天都在加班的同事内心想着：“有本事你来？”，即便这个小组长有这个能力，但对于团队来讲也不是一件好事，由于你们都抱有怨恨之心，还谈什么好好工做呢？这个小组长就是失职的。因此这种状况下应该主动去了解进度滞后的缘由，而且本身要加入到解决问题的工做中去，而不是在边上抱怨别人。
五、小组织不要搞太多的官
中国几千年的文化，官本位一直影响着咱们，你们都想坐在那指挥，本身啥事也不用干，想一想都惬意。在咱们这个行业是否是发现也很相似？你们都想着干几年当个小组长，而后升个部门经理，当上CTO迎娶白富美。
团队的管理基本是事与人的管理，很是的伤脑和心。若是一个组织内，特别是小组织内“官”太多，协调就会很是的难，你们就会常常性的扯皮。
结束
与敏捷开发结缘也有几年，从开始的抵触到后面的承认经历了许多，这个过程并非一蹴而就的，须要花时间花精力，特别是要去实践、总结。
还有我以为是不能太教条，不少事情都要有怀疑的心，而后去实践总结，找到合适本身团队的方式方法。