程序员谈敏捷团队

⑴ 身为程序员怎么能不懂什么是敏捷开发

什么是敏捷开发？s
敏捷开发(AgileDevelopment)是一种以人为核心、迭代、循序渐进的开发方法。
怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
为什么说是以人为核心？
我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
什么是迭代？
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
关于Scrum和XP
前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的，这里我主要讲Scrum。
什么是Scrum？
Scrum的英文意思是橄榄球运动的一个专业术语，内推网www.neitui.me，专注于做互联网招聘行业内部推荐、打造最专业的互联网招聘内部推荐直招平台。表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
【Scrum开发流程中的三大角色】
产品负责人（ProctOwner）
指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
流程管理员（ScrumMaster）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（ScrumTeam）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

⑵ 敏捷团队の定义

敏捷的团队是自我反省、持续调整的团队

一、敏捷项目管理：

（1）Iteration

软件开发模型经历了从瀑布到螺旋再到敏捷的过程，迭代不是敏捷独有的创造，无论在RUP还是在MSF中迭代都是其核心特性之一。而在Tencent特别强调的是并行迭代，即多个版本并行，最大程度发挥资源的效率。

Release（发布）可理解成当实现的产品Feature累积到一定用户价值时的正式发布，它是比Iteration更大的概念；Iteration（迭代）是在固定时间内开发Feature的过程，Release一般包括多次Iteration。

（2）TimeBox

TimeBox（时间箱）反映了敏捷开发的节奏，即在固定时间内实现不固定特性的周期，抛开需求定义阶段，从设计-实现-测试到部署，在Tencent一般一至两周时间居多。

（3）Planning Game

对敏捷的一种常见误解是不要计划，其实在敏捷的体系中不仅强调计划，甚至区分Release计划、Iteration计划和Task计划等多种不同粒度、不同时长的计划。Planning Game突出的是让用户代表参与，由用户代表评估UserStory/Feature的优先级，开发人员评估任务的开发时间，由用户代表+项目经理+核心成员三方共同排序、组合，确定本次迭代计划需要实现的Feature List。在Tencent用户代表就是产品经理。

（4）IterationPlanningMeeting

IterationPlanningMeeting就是Planning Game实现的管理形式，通过会议沟通达成。

（5）Stand-up Meeting

团队成员围成一圈，逐个说明3个问题：昨天做了什么，今天计划做什么，有没有困难并计划如何解决。对Team而言这是检查进度、快速调整非常有效的形式，在Tencent这已经成为大家每天早上的固定习惯。

（6）ShowCase

提交测试前由开发人员演示实现的功能，产品经理到场Review是否符合当初的设想，避免接近发布时才反馈。

（7）Retrospect

每个迭代结束后，项目经理组织或轮流组织所有Team成员共同回顾本次迭代的得与失，整理Well/LessWell，因为敏捷的团队是自我反省、持续调整的团队。

二、敏捷软件开发：

（1）Story Card/Story Wall/Feature List

StoryCard是XP中推荐的需求定义方法，要求符合Invest和Moscow原则；StoryWall则用于跟踪StoryCard的变化状态，而FeatureList是Tencent一直沿用的需求表达形式，在Tencent的TAPD工具中已经实现了类似ThoughtWorks 的Mingle的StoryCard管理功能，对于需求跟踪而言这是不错的方法，一目了然。

（2）Refactoring

相信我们都听过这句话：好的代码不是设计出来的，而是重构出来的。

（3）TDD

“测试驱动开发”在Tencent执行地并不太好，Tencent的产品以Web形式居多、业务逻辑相对简单，C++下的单元测试有些力不从心。相反自动化测试在Tencent比较盛行，因为有测试部门专门的自动化测试Team在推动，而且链接的是正式生产环境，可以即时反映产品当前的状态。

（4）Pair Programming

理论上结对编程可以提高代码的质量，而且并不会降低开发效率，但Tencent的业务繁忙，资源上不允许两人结对。

（5）CI

持续集成可以降低发布前集成阶段的难度与成本，Tencent的自动化构建系统推行的比较早，覆盖了大多数产品，而且正在朝自动化构建-自动化测试-自动化发布三者协同的目标迈进。

（6）灰度发布

灰度发布是Tencent的又一创新，它将产品试用扩大到海量用户一端，在小范围及时吸取用户反馈，分析用户行为和喜好，持续修正自己产品的功能体验。

当然开发方法和流程确定了还远远不够，更难的是如何将它推动落地。首先Tencent组织开发了承载敏捷思想的TAPD项目管理工具，它类似 ThoughtWorks的Mingle；然后推出了敏捷能力模型，类似CMM成熟度模型一样对Team评级加以引导；同时还推出了敏捷指数排行榜形成竞争，营造你追我赶的声势氛围。

文章写到这里行将结束，最后我们分析Tencent为什么选择Google和ThoughtWorks，其实是由互联网行业本身的特点决定的，互联网的生存法则就是大鱼吃小鱼、快鱼吃慢鱼，谁转身的快、谁拥抱变化、谁更关注用户，谁才可以笑到最后。阿里巴巴董事局主席马云说过：今天很残酷，明天更残酷，后天很美好，但绝大多数人都死在明天晚上，却见不到后天的太阳。

⑶ 敏捷开发的敏捷开发团队原则

最大的分歧
最大的分歧在于开发人员和测试人员之间。作为敏捷团队的成员，测试人员被期望能编写一点代码，同时开发人员可以做一些测试。各自的强项还是很重要：新的角色要求每个成员成为大家所谓的“通才”。测试人员大多数时间作测试，开发人员大都编写代码，但所有人都分享他们的工作，而且有能力承担他们面前的任务。
发现中立点
团队决定作为一个团队需要做什么，如何最好地分配工作。第一步是让团队成员说说他们自己的技能集、优点和缺点。但却不希望他们根据以前角色（如，软件测试员或开发员）来定义自己。所以找到一个中立点，她列出了小型离线会议，和每周工作之外的小时集体活动所需的事项。这样，该团队去当地的农场采摘蓝莓。他们一起上瑜珈课。他们集体在厨房里烤燕麦棒，做果沙。
正确执行应用程序
团队找到了让自此感到舒服的新水平。整个项目的工作流程顺利进行，只做一个待办的事情，而不是四个。

⑷ 如何在敏捷开发中做需求分析

【敏捷项目没有需求分析吗?】 在很多人的印象中，敏捷软件开发是种类似黑客行为的过程，是程序员最爱的勾当。不写文档，不作需求分析，没有项目经理，做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要，因此在经过考虑后，放弃了敏捷方法。 项目经理圈子真的是这样吗?敏捷过程到底是如何做需求分析?用户故事和用例有什么区别?敏捷过程如何去管理需求的?这些是一些想要实践敏捷的人一直在困惑的事情。 我们常常看到书中讲，程序员拿到一个用户故事后，怎么计划，怎么分解，怎么写单元测试，怎么小步前进，怎么持续集成。这是典型的程序员视角。事实上，敏捷方法分为三部分，敏捷项目管理，敏捷需求分析，敏捷软件开发。上述书中提到的完全是敏捷开发中的实践，很多人了解到的敏捷，只是敏捷的三分之一。 【敏捷项目中谁来做需求分析?】 在敏捷的团队中，作一个敏捷程序员确实是非常舒服的事情。从程序员的角度来看，只需要选择一张他感兴趣的故事卡片，了解清楚该卡片的需求，开始从功能测试写代码，等通过了所有测试就完工。基本上不需要考虑太多的事情，非常轻松愉快。但程序员向谁去问清楚需求?故事卡片是怎样写出来的呢?让我们来关注开发前发生的事情。 了解敏捷过程的人都知道，Kent Beck在XP过程中提到了现场客户，如果一个敏捷团队能够有现场客户，这当然是最棒的事情。但多数情况下，客户都是很忙碌的，很难全力投入到软件开发过程中。这时候，我们就需要商务分析师这个角色，来充当客户的角色。 我在公司的团队中曾担任的就是商务分析师这个角色。商务分析师最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事并将需求转述给程序员。同时，商务分析师也要代替客户负责功能验收测试。 【敏捷项目中如何进行需求分析?】 敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流，搞清楚客户到底需要什么，到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向，就可以不迷失方向。和客户进行交流，最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验，客户说，我要这个功能，我想要怎么怎么样。这时候要特别注意，他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么，挖掘出他真正的目标。 在这个目标下，商务分析师开始进行需求的分析：我们到底是否真的需要这个需求?有没有更好的解决方案?有没有简单并且低廉的方式?换一种形式是不是也能达到这样的需求?这个需求有多少地方涉及到以前的软件变更? 搞清楚这些事情后，就可以写出用户故事。用户故事的书写遵循一定的原则，一般包括三部分："作为(系统的一个涉众)，我想要(做一件事)，从而(达到一个商业价值)"。在书写的时候格式比较随意，可以在故事卡背面写上注释或疑问，甚至画上界面原形图。 举一个最常见的用户故事例子，“作为一个普通用户，我希望能够用用户名和密码登录，以便我能享受到个性化的服务”。其中，用户是系统涉众，登录是他想要做的事情，而他的目标是获得个性化的服务。 从这个例子我们可以想象到，这个页面可能存在两个文本框，用于输入用户名和密码，有一个按钮来登录，并且不登录就不能看到个人资料，另外，如果用户输入错误需要提示“登录失败请重试”。这就是可见性，也可以称为可测试性。我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。 用户故事的作用有两个，一个是作为进度跟踪的依据，一个是作为与人交谈的备忘录。用户故事卡片并不是很精确的需求，因此不需要把事情描述的非常清楚。将需求的详细分析推迟到实现前夕来完成，这是敏捷需求分析的精华所在。任何提前做好的东西都会导致浪费，敏捷过程提倡足够就好，避免浪费。 不少人对用户故事和用例的区别感到疑惑。用户故事的作用是备忘功能，而不是文档。而用例需要详细的描述其操作步骤，以及每个异常路径，因而起到了文档的作用。用户故事是可见的商业价值，而不是功能描述。每个用户故事的粒度和工作量都相差不多，这和用例有很大的区别。用户故事是小粒度的，可测试的，可见的，并且是有价值的。 【敏捷项目需求分析案例】 公司有个项目组作的是一个网游物品交易平台。该平台是典型的互联网项目，在开工的时候客户对功能需求还不明确，但需要快速推出抢占市场，正是最适合敏捷过程的项目。 在项目伊始，商务分析师和客户做了深入的谈话，了解他的商业构想，他的盈利模式，搞清楚宏观的结构，然后思考并整理获得的结果，花1-2天时间将客户需求大略整理为几十个用户故事。这些用户故事并不完善，不足以做好整个系统。但对于我们开始项目的前一阵，已经足够了。我们可以从这里开始项目。敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前，由一组有经验的开发人员大致评估一下用户故事，标记出不同的难度和风险，并提出问题供商务分析师来获得更详细的信息，商务分析师会和相关涉众去讨论。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选，客户可以选择这些用户故事，或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。 项目经理圈子客户看到每个迭代交付的可运行的软件后或者得到用户反馈后，常常会有新的想法冒出来。有些想法是好的，有些想法就属于看到别家网站有这个功能，不假思索的提出的功能。这些不同的需求都需要经过认真的分析，找出哪些是值得我们立即考虑的，哪些是不用急迫的去实现的。 有一次和客户谈话时，他说到希望增加拍卖功能。那么，我们为什么需要拍卖呢?客户说希望让用户拍卖物品以获得最高价格。经过考虑，我们发现网游物品的实时性和唯一性决定了系统不适合使用拍卖机制。拍卖的时效性无法满足实时交易的要求，因此，用户最终放弃了这个特性。 另一次，客服人员提出增加一个查询用户交易的功能，而此时我们有其他更加重要的功能需要先去考虑，查询用户交易功能可以由技术人员临时通过数据库直接代为查询，因为项目运营初期交易不是很多，暂时还不需要专门的后台功能来支持客服的工作。所以把这个需求卡片一直贴在墙壁上，始终没有排到最高的优先级。 客户一开始也不是很能够接受敏捷需求中强调商业价值和优先级的做法。但经过几个月的磨合，客户也逐渐适应了许多敏捷思想，甚至我在和客户讨论时，偶然提起了后期的某种可能的情况，他们还能够帮我纠正应当考虑目前的情况，为近期的情况作计划。 用户故事的跟踪和管理是由项目经理来进行。每个迭代跟踪卡片的进展，是否已经开始实现?是否已经完成代码开发?是否已经开始功能测试?不同的卡片在迭代前都会评估为不同的大小。我们一般分为大中小三级。等实践过几个迭代后，团队的开发速度基本保持恒定，我们就可以很容易的知道每个迭代能做多少个用户故事，这样就可以安排下一迭代的开发。 每个迭代内分析好恰好足够下一个迭代开发的需求，就是商务分析师每个迭代的主要工作内容。商务分析师的需求分析工作在上一个迭代完成，包括需求的了解，分析，评估和排列优先级。 在每个迭代开始的时候，由商务分析师主持召开迭代计划会议，在会议上向所有的程序员解释这个迭代要完成的用户故事，然后由程序员自由提问，知道他们能够获得足够开始实现该功能的信息。 在程序员完成一个用户故事后，商务分析师还要来代表客户做功能验收测试，查看是否完成了预计的功能，是否有程序员还没有想到的异常情况。如果存在问题需要退回给程序员继续完成。这在一定程度上保证了系统完成的需求不偏离客户的要求。当然，更多的测试还需要QA来完成。 我们的实践充分表明了，敏捷过程并不是没有需求分析，而是把需求分析过程分散到整个开发的过程中，让开发和需求分析并行进行。这就是公司敏捷方法实施成功的秘诀之一。而商务分析师在这个过程中，起到了纽带和桥梁的作用，是一个团队不可缺少的角色 。

⑸ 以亲身经历解读敏捷软件开发（一）什么是敏捷软件开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

自主权

专注于工作，交付正确的软件，而不是被他人的愤怒情绪所影响。

分享经验

构建完美软件开发流程，并没有统一的模式。但是在这个领域，敏捷技术，加上持续的应用和改进，都能够达到敏捷的成功。

⑹ 如何打造优秀的敏捷团队

(一)首先要明确团队目标。
建立团队的目的是什么，这个团队要完成怎样的目标。目标很重要，因为目标就是方向。每个团队的组建都是为完成一定的目标或使命。没有目标的团队没有存在的意义，或者说没有目标的团队也称不上为一个团队。
(二)、确立团队成员标准，选对人上船。
团队的目标确定了，就要选择正确的团队成员，该如何选择团队成员呢?我个人认为应该选择那些认同团队价值观、优势能够互补的人来团队工作。价值观的认同很关键，不认同团队的价值观大家就不能实现很好的沟通，也就不可能有效率可言。另外并不是所有最强的人组合在一起就能组成一个最强的团队，团队成功的关键在于充分发挥整体优势，这就需要团队中的成员做到优势互补，实现整体大于局部之和。
(三)、建立好团队内部规则。
没有规矩不成方圆，一个团队如果能形成战斗力必须建立健全的游戏规则，如岗位职责、权利的界定，团队成员沟通、交流方式的确立等。这些规则应能保证一个团队的正常运行，让团队每个成员的主动性、积极性和创造性发挥出来，使整个团队充满活力。
(四)选择一个好的团队领导。
我们不能强调个人的作用，但我们也不能忽略个人的作用。一个好的团队领导对于建设高效率的团队有着不可替代的作用。一个好的团队领导能充分发挥团队中每个成员的优势，使团队的资源实现最大程度的优化，从而创造出非凡的业绩。
(五)学会宽容。
宽容是一种很高的品质。在一个团队内部，由于每个团队成员的性格特征可能不同，考虑问题的出发点不同，难免会产生摩擦，但每个人都应该抱着一种“对事不对人”的态度去宽容别人对自己的批评，甚至是不理解，而不能一味地去争执，许多东西需要时间去证明，争论没有任何意义。
团队的精髓是沟通、分工、合作、共同进步，以形成一个目标明确、有战斗力的团队。能够做到以上五点，相信你一定可以打造出一个优质的队伍。