(1)-故事工作量估算导致的问题

背景

自从我们使用scrum进行项目开发后，出现了这样那样的问题，有些是因为我们对scrum的理解不到位，有些则是客观因素导致的，针对这些问题，在每次迭代的总结会上，我们进行了反思，并根据具体环境对scrum进行了一一调整，想通过几篇文章和大家分享一下我的经验。

我说的不一定正确，只是描述问题，然后说说我对问题的看法，采取的解决方案，希望使用敏捷开发的大牛提供宝贵意见。

故事工作量估算导致的问题

我们在对backlog中的story进行估算的时候，我们采用了一些前人总结出的敏捷开发的最佳实践，其中一条直接导致了我们这次迭代提前结束：

1、共同估算：在估算前不应该指定谁将开发这个故事，而是以接收故事的小组为单 位集体估算，每个人提出自己的看法，大家综合。这样才能以集体智慧完成任务。

共同估算没有错，用集体智慧和知识对“做什么，怎么做，需要多少工作量”达成共识，共同估算也是为了提高团队成员主人翁的意识，大家会关心自己曾参与讨论的事情；共同估算意味着共同讨论，能提高团队成员对需求的理解程度，有助于开发出满足需求的功能，而且如果开发期间领了任务的人有事脱离岗位，另一个曾经参与讨论的人更容易接手些。

但，注意红色的部分，”在估算前不应该指定谁将开发这个故事“，这个最佳实践确使我们吃了亏。

我们项目组一个5个人，迭代周期为2周，一共6个story，在开发进行了1周后，三个人闲置了，因为他们已经完成了各自的story，而他们又没办法插手别人的story，因为别人进行了一半，而这个story的任务是有连续性的，闲置下来的人根本无法领这些未完成story下的任务，也就是出现了”任务对人的依赖性“。

不知道我描述清楚了没，我们的第一次迭代就这么提前结束了，因为我不可能让三个人闲着没事干，等着另外两个人。

经过总结会，我们决定在对story的工作量进行估算的时候，我们把谁做这个story规定好，这样每个人在本次迭代的任务量都是饱和的，除非划分不合理，不然不会出现上述情况，这时候问题又来了，在对每个人的story进行工作量估算的时候，各自都想争取到更多的时间，也就是都认为自己的story工作量巨大，如果不满足他的要求，很可能会引发抵触情绪。

在估算前，到底应不应该指定谁将开发这个故事？ 我们不能一棒子打死，简单答案绝不止是"应该"或”不应该“。要根据story的性质来决定，一般情况下：

1、对于功能性的Story，如开发一个用户管理模块，这种story，不应该指定由谁开发。分解后的任务粒度，应该尽可能地小，最好是1人日能完成，尽可能做到任务之间不要有依赖关系（尽可能，虽然很难）。

2、对于非功能性的Story，如解决某个架构上的难题，应该指定由谁开发，应该指定高水平的开发人员解决，对于大型项目，如果能有单独的一小部分人专门解决架构上的问题，环境上的问题，或者其他疑难问题，采用传统命令式的方式进行管理，我倒觉得更合适些。

最后针对迭代计划，进行一个宏观地评估，主要是为了避免出现任务粒度过大，依赖性强导致的"任务对人的依赖性"。

这篇就谈的这里，下篇谈谈敏捷开发实践中，关于文档的话题。

(2)-要不要文档？

背景

自从我们使用scrum进行项目开发后，出现了这样那样的问题，有些是因为我们对scrum的理解不到位，有些则是客观因素导致的，针对这些问题，在每次迭代的总结会上，我们进行了反思，并根据具体环境对scrum进行了一一调整，想通过几篇文章和大家分享一下我的经验。

我说的不一定正确，只是描述问题，然后说说我对问题的看法，采取的解决方案，希望使用敏捷开发的大牛提供宝贵意见。

到底要不要文档？

以前我们做项目多采用传统的瀑布模型，前期有详尽地需求文档，设计文档，如果发生变更，还要遵循复杂地变更流程，很多时候文档得不到及时地更新，项目做完了，但是项目跟文档根本对不上，而且偏差很大，给维护人员造成了很大的麻烦，所以弱弱地说一句，瀑布模型不太适应变化。文档成了让我们头痛的问题。

从去年开始，我们开始采用scrum开发，让我们眼前一亮的是，“scrum不提倡写文档”（真的吗？）。所以我们在得到基本地需求后，就开始上马开发了，但开发了一段时间后，被一个领导L叫停了，他让我们准备整个项目的wbs，甘特图，搞清楚我们到底要完成哪些任务，这些任务的轻重缓急，有个整体地规划。而另一个领导X，也就是我们scrum的领路人并不提倡我们写这些文档。我们夹在两个领导之间，着实郁闷了几天，最后我们遵循了领导L的意见。

但项目进行中，我们并没有写需求文档，只是根据简单地需求描述，就开始实施设计，开发。开发过程中，发现设计不合理，改设计，发现需求理解不到位，接着该设计，在开发人员频繁地修改中，总算是满足了基本的需求。不可否认，遇到问题，能够及时解决问题，scrum的确能快速地响应变化，但这样真的没问题吗？我们遇到了两次这样的冲突，“你当初就是这么设计的，是你让我这么开发的”，“我绝对没有这样设计，我当时的意思是……”，“你做的根本不能满足需求”，“需求就是这么说的”。好吧，需求，设计，开发之间地扯皮，推卸责任开始了。

面对这种情况，scrum master该如何处理？我继续翻阅相关资料，发现我们犯了一个致命地错误，scrum并不是不提倡写文档，而是不提倡冗杂过度地写文档。回想起领导L说的那句话，“我感觉，你们有用敏捷开发当挡箭牌，拒绝写文档的味道”（大概是这么个意思吧，懒得再查阅email了），现在看来，当时刚接触scrum，如获至宝，感觉终于可以摆脱文档了，一激动，就理解片面了。发现问题后，我们决定采用wiki工具（后面会单独写篇博客，谈谈敏捷开发的工具）对文档等进行管理，对需求（用户故事）等核心文档进行逐步完善，使变化可追溯，不至于出现需求，设计，开发互相互相扯皮的情况，少了很多争吵，说好听点，让项目组更和谐了。

查阅scrum资料的时候，发现了一些大牛博客中说得很有道理，列在下面，供大家参考：

大型项目尤其是系统工程级别的项目，比如军工、航空类项目，设计的工作量很大，原因是这种投入毕竟是可控的；而一旦由于设计工作不充分，导致严重的返工，则往往不是简单的费用问题，还往往造成项目被终止。因而在这类项目中推广敏捷，应该适当增加文档的数量，以便长期项目能够按计划完成。在互联网、消费电子行业则正好相反，返工主要是由于业务变化而不是错误或不足的设计引起的；相反过度设计往往在未被付诸实现之前就已经过时，反而形成浪费。因此在这类项目中推广敏捷，应当适当降低文档的数量，以便在业务变化时轻装上阵，而不需要同步修改大量设计文档。

应当理解敏捷开发的出发点不是不写文档只写代码，而是减少浪费，以便能按照自己项目的特点，灵活选择文档的数量及其形式，
在过度设计和返工之间找到平衡。 --------------摘自火星人，陈勇http://blog.csdn.net/cheny_com

忽视文档的另一大原因，是将敏捷思想中的“可工作的软件重于面面俱道的文档”理解为“软件开发可以不写文档”（敏捷宣言中用的是“面面俱道的文档”，而不是“言简意赅的文档”）。相信不少团队正是将这一敏捷思想当作不写文档的“挡箭牌”。

回头最初领导L要求的wbs，甘特图，其实他的初衷并不是让我们写繁杂地文档，只是让我们有个全局观，分清任务地轻重缓急，有个整体的计划，有计划总比没计划要好。直到后来，因为项目之初没有把系统接口放在网络图的关键路径上，导致后续开发延误，我才真正意识到领导L当时的苦衷，其实领导L要求的文档，在scrum上就是一个具有优先级的backlog，而当时我们并没有对此足够重视，我们的backlog不断更改，也给我们的工作造成了不少麻烦，感触很深，如果能找到一个既有非常熟悉需求、又有资格和权力设置Story优先级的产品负责人，真的不容易。在我们项目组是采用几个人一起扮演产品负责人的角色。

写不写文档？答案已经很明了了，文档要写，根据项目特点有所取舍。

我有一个没有实践的想法，如果在项目团队中增加一个专职的文案，这个文案必须懂技术，虽然增加了沟通成本，会不会进一步减少团队成员的文档负担，提高效率？不成熟的想法，有待以后实践。

（3）-我们为什么需要持续集成？

背景

自从我们使用scrum进行项目开发后，出现了这样那样的问题，有些是因为我们对scrum的理解不到位，有些则是客观因素导致的，针对这些问题，在每次迭代的总结会上，我们进行了反思，并根据具体环境对scrum进行了一一调整，想通过几篇文章和大家分享一下我的经验。

我说的不一定正确，只是描述问题，然后说说我对问题的看法，采取的解决方案，希望使用敏捷开发的大牛提供宝贵意见。

为什么我们需要持续集成？

又要从我们的故事说起，我越来越喜欢讲故事了……

在前几个sprint的评审会上，我们只是让各个组员单独演示了自己开发的功能，并且约定时间，大家都提交一个稳定的版本，做了一次集成。

过了一些天，领导L突然造访，想看看项目进展，让我们集成起来，这时候问题来了，各个模块开发进度不一，很难找到某个时间点，让大家顺利集成。上次是约定好时间，大家有所准备，这次又不能使用上次的集成版本，太陈旧了。所以出现了这样的情况，领导L坐在那里等着看，大家赶紧手忙脚乱的构建，然后集成，幸好没出大问题，结果可以看了，但中间浪费了不少时间。

领导L的造访，说明了他对进度和质量的担忧，我们该如何让他放心？

另一方面，scrum提倡，可用的软件优于面面俱到的文档。但如何保证可用软件的质量成了一个棘手的问题，尤其是在不断变化的需求中。

怎么办才能看出软件质量的优劣，进度的快慢？ 经常集成起来，看看效果，不就知道质量怎么样，进度怎么样了嘛？而且经常集成起来看，有助于发现问题，解决问题，如需求有没有偏差，是不是领导和客户想要的效果，又或者发现和解决这样那样的bug等等。

但经常集成，又会牵扯开发人员很多精力去更好地协同工作，这是在开发过程中不可回避的问题。

这次又得站在巨人的肩膀上了，看下面一段话：

持续集成正是针对上述一系列问题的一种软件开发实践，它倡导团队开发成员必须经常集成他们的工作，甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队能够更快的开发内聚的软件。

—— Martin Fowler

持续集成的核心价值在于：

1、降低风险，每天都可能发生多次集成，有利于及早发现软件质量问题。

2、自动完成，通过自动化工具可以避免开发人员投入过多精力

3、软件运行状态随时可看，可以增加领导和团队成员对项目的信心。

4、利于对未来进行把控，持续集成的信息有利于我们对未来进行更好地规划和把控。

概念不多说，我们团队非常需要持续集成，所以经过调研，我们采用jenkins作为持续集成的大管家，Jenkins 就是一个配置简单和使用方便的持续集成服务器。由它完成自动构建、自动部署、集成。用了一段时间，还不错，上面说的一系列问题也迎刃而解。
写到这里有一点小感触：很多东西的产生是那么地理所当然，顺理成章。

（4）-有时候我们需要结对编程

背景

自从我们使用scrum进行项目开发后，出现了这样那样的问题，有些是因为我们对scrum的理解不到位，有些则是客观因素导致的，针对这些问题，在每次迭代的总结会上，我们进行了反思，并根据具体环境对scrum进行了一一调整，想通过几篇文章和大家分享一下我的经验。

我说的不一定正确，只是描述问题，然后说说我对问题的看法，采取的解决方案，希望使用敏捷开发的大牛提供宝贵意见。

有时候我们需要结对编程

我不是个擅长讲故事的人，但写这种经验性的小文章，又不得不从故事说起，大家就继续听我唠吧。

我们的项目有一个专门维护开发环境和攻克疑难问题的小组，这个小组的主要责任是扫清其他产品开发组遇到的各种各样棘手的问题，并且维护一个稳定，易用，统一的开发，持续构建集成，测试环境。

我在负责项目的同时，也跟着这个小组处理一些问题。在处理这些问题的过程中，有几次我们采用了结对编程，感觉效果还可以。

例如，一次解决jenkins远程部署的问题，一个让人感觉很简单的问题，我把这个问题拆成了两步，先完成本地部署，然后再完成远程。但我做了整整两天，依然无果。最开始，我使用deploy it插件，部署到tomcat下成功了，但换成jboss就失败了。

后来经过思考，我觉得，即使部署jboss成功了，这种简单插件根本不能满足我们的需求，我们自动部署是部署很多个jar，和war，而且很可能不是部署的远端同一台服务器上。

所以我开始尝试使用自定义脚本，写自定义脚本不是我擅长的，所以我找来项目组的小崔，因为他当初写过很多操作jboss的脚本，我们结对来完成这块，我提需求，然后由他指导我写脚本，大概2个小时的样子，我们就搞定了，后面就是优化的事情了。

到此为止，我们完成了使用jenkins自动本地部署，接下来就是远程部署了，我们使用的服务器是Win Server 2008，我在服务器上建立一个共享文件夹，通过在本地建立磁盘映射来关联远程的共享文件夹，然后通过脚本把需要部署的项目放入映射盘中。我手动复制到文件夹一点问题也没有，但使用脚本就死活找不到路径，Why？解决了一个下午，无果。

我想我的思维走入了死角，我需要一个人跟我结对，我找来项目组的小新，我们结对解决这个问题，我给他提供了我找到的一些解决方案，然后我们尝试了一些方法，最后在一个外国的论坛上找到了答案。这个论坛上提供的方法，我之前试过，但没有成功，后来发现，我是漏掉了一个步骤，在小新的帮助下，我们没用多长时间就解决了。

再例如，一次解决单点登录跨域，css和js丢失，小海做了几天，快做吐了，也是死了活，活了死，最后我，小新，小海，我们三个结对解决这个问题，我们想利用框架自身的特性去解决这个问题，但我们联系了前端框架的创作者，他表示暂时不支持该功能。晴天霹雳啊，难道我们要为此换掉整个前端框架吗？如果换掉，可想产品组的人们会是什么反应？会吃了我们。让他们重新做前端这块，估计是不行了。我们不得不继续寻找替代方案，大家在一起，思维的确活跃，我们尝试了很多次后，终于敲定了一个折中方案，代价就是损失了一些部署上的灵活性。

还有一些故事，不再说了，在几次结对中，我们总结出了一些东东，跟大家分享下：

1、结对编程，拓宽思路，避免一个人钻入死胡同。所谓，当局者迷，旁观者清。

2、增加了解决问题的耐心，如果一个人遇到棘手的问题，迟迟不能解决，脾气容易暴躁，容易放弃。如果有人作伴，可以更有耐心，可以在互相调侃中解决问题。

3、结对编程，在解决未知领域问题时，有奇效。最好是两个人有一定技术积累，至少一个人已经有所研究。切忌两个新手一起从零开始。

4、结对编程可以使知识互补，让人学到新东西，在解决问题中体会快乐。

以上是我的直观感受，可以看出，我更提倡在解决复杂问题时结对，日常的开发工作，我觉得可以采用火星人陈勇提到的松结对方式，具体我还没有尝试过，试过后再来和大家分享。

（5）-有些工具不得不用

做敏捷开发，贵在敏捷，如何敏捷？我们需要一系列成熟的工具去帮助我们敏捷。

这篇文档不写技术，就是纯粹地说工具，介绍我们实施scrum过程中，起到关键作用的工具。

1、Jira或物理看板

Jira配合JIRA Agile插件，即可实施敏捷开发，核心就是提供了一个电子看板，再配合上可自定义的工作流

如果不喜欢对着冷冰冰的电脑，我们完全可以采用最原始的方式，准备一块白板，相信互动和交流都变得“生动”和“开放”起来。

不想再去取材了，直接引用网友的图片：http://pmohome.blog.163.com/blog/static/1946610792012630102610284/

2、confluence

进行敏捷开发怎么能少了Confluence，它一个专业的wiki程序。它是一个知识管理的工具，通过它可以实现团队成员之间的协作和知识共享。

想想维基百科，你就知道confluence的便利之处。

3、jenkins

持续集成倡导团队开发成员必须经常集成他们的工作，甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队能够更快的开发内聚的软件。

没错，jenkins就是帮助我们完成持续构建和集成的。

4、maven和nexus

Maven是一个采用纯Java编写的开 源项目管理工具。Maven采用了一种被称之为project object model (POM)概念来管理项目，所有的项目配置信息都被定义在一个叫做POM.xml的文件中，通过该文件，Maven可以管理项目的整个声明周期，包括编 译，构建，测试，发布，报告等等。目前Apache下绝大多数项目都已经采用Maven进行管理。而Maven本身还支持多种插件，可以方便更灵活的控制 项目。

所以，怎么能少了maven呢！既然maven用上了，nexus还会远吗？

上网copy一段介绍吧。

Nexus 是Maven仓库管理器，如果你使用Maven，你可以从Maven中央仓库 下载所需要的构件（artifact），但这通常不是一个好的做法，你应该在本地架设一个Maven仓库服务器，在代理远程仓库的同时维护本地仓库，以节省带宽和时间，Nexus就可以满足这样的需要。此外，他还提供了强大的仓库管理功能，构件搜索功能，它基于REST，友好的UI是一个extjs的REST客户端，它占用较少的内存，基于简单文件系统而非数据库。这些优点使其日趋成为最流行的Maven仓库管理器。

5、checkstyle

不要总是在你的员工面前一遍又一遍地喊：要遵循代码规范！直接使用checkstyle检查一下，然后利用eclipse自动format就搞定了。

如果连手动检查都懒得做，那就交给jenkins吧。

6、findbug

静态分析工具承诺无需开发人员费劲就能找出代码中已有的缺陷。当然，如果有多年的编写经验，就会知道这些承诺并不是一定能兑现。它会发现一些伪问题，但这并不能掩盖它的贡献。FindBugs 检查类或者 JAR 文件，将字节码与一组缺陷模式进行对比以发现可能的问题。有了静态分析工具，就可以在不实际运行程序的情况对软件进行分析。

不需要手动做，交给jenkins吧

7、javamelody

JavaMelody能够在QA和实际运行生产环境监测Java或Java EE应用程序服务器。并以图表的形式显示：Java内存和Java CPU使用情况，用户Session数量，JDBC连接数，和http请求、sql请求、jsp页面与业务接口方法（EJB3、Spring、Guice）的执行数量，平均执行时间，错误百分比等。图表可以按天，周，月，年或自定义时间段查看。

看了上面简介，你就知道我为什么推荐你使用它了吧。

好东西，还有很多，慢慢来，站在巨人的肩膀上，这句话可不是白说的。