敏捷实践总结（六）——依赖性太强的独立项目

敏捷风已经在提高班刮了一大阵子了。现在项目验收已经通过了，没有什么大问题。接下来的工作就是进行一两次大规模的测试，改改bug，然后就是愉快的等待，等待着投入使用。

尽管现在做完系统了，感觉爽歪歪~~。当初做开发的时候，还是相当“痛苦”的。下面结合我们的项目与敏捷开发，谈谈此次的感受。

搞需求阶段

我们组逻辑上与jc组依赖性非常强，只是业务上不尽相同。所以我们的组的开发强烈依赖jc组。

         

                                                   （jc组同志不做饭，我们就没饭吃啊）

又由于各组同时开始开发，所以我们组在一个多月的时间，一直在搞需求。在此过程中，又由于我们与项目主管的沟通不充分，彼此都没有进行充分了解，致使项目一拖再拖。直接导致我们后期重新设计了一次。

交互的问题，大家都是第一次遇到，系统之间交互是通过什么形式的问题，开始的时候定下来传json，而后面开发的时候，都说直接传对象就可以，省事儿。然后后面就传对象了。

开始两个月了。我们就集中解决了两个问题：一、根据最新定下来的需求，重新设计；二、技术攻坚，解决已知的技术问题，并做成Demo（一些由于封装有难度，就没有进行，导致后面很多问题，详细内容后文介绍）。所以，尽管开发了很长时间，几乎没有什么东西可以拿出来展示。项目主管都急的不行了，总是问我们“是不是有什么解决不了的问题”解决不了，有没有什么困难啥的，有啥需要帮忙的……其实，活儿我们真的没少干……

这里有一个问题需要我们思考：如何才能快速拿出一个展示的东西，或者是一个能够简单运行的产品界面，这对我们来说是非常重要的。因为对于用户来说，界面才是整个软件。而后台的架构啊，最新的技术实现啊，都不是最用户关心的。

然后，也就进入后面真正的开发阶段。

开发阶段

做项目期间，曾感觉我们的项目不适合使用敏捷开发。因为我们组的开发对其他组的依赖性他强，包括他们的webservice接口的稳定性、实现的功能性、以及查询上来的数据。另外，由于多组依赖jc组，所以jc的jboss服务器、数据库变更情况比较频繁，比如变更一个接口，那么就需要重新本地maven库，更新并重新启动本地jboss开发服务器……太多的依赖性，就加大了项目的依赖性，也就增加了我们组的开发难度。

所以，在评估Sprint以及Story的时候，出现诸多失误。由于困难重重，大家投入更多的精力到技术细节的实现，而忽略了忠实记录开发情况。对于敏捷的记录情况不是很真实这一现象，这也是我最遗憾的地方，浪费了一个深入学习敏捷的机会，浪费了一个在项目中学习敏捷管理软件的的机会。

（图片传不上来……hold on）

仔细想想，在我们这次开发中，什么是最重要的呢？是沟通！而在敏捷开发中，却是更加强调开发人员的沟通能力。如此看来，我们组系统的开发，比其他组更加适合使用敏捷开发模式。

大家都坐在一个屋开发，需要什么直接喊一嗓子就OK，然后一天下来，问题、情况各种各样。通过晨会，开发组内部简短的几句话就都能够彼此了解各自的进展情况。同时，也极大程度上避免了走“重复发明创造的轮子”。类似的问题，解决起来很快。

另外，再总结以下几点

组长是核心

组长同志一定要把自己左边的脸皮贴右脸上。不得不说，组长同志任务艰巨。包括项目主管旨意的传到，以及与其他组之间的重叠部分。都需要你拉下脸来，时急时缓的一遍一遍的催，以及自己组员各自的开发情况：考虑他们的能力与任务分配的合理性，如果一个任务三天还未完成，无论什么原因，你都应该细致的了解他的详细开发现状。

组长信任组员是必须的，没有信任的团队没有任何存在意义。然而再充分的信任也需要看实际数据，不能完全凭借组员嘴上说的，这就好比再自由生长的小树，也离不开大地的关怀。有约束的信任才是有利的信任。

开口前想一想

很多时候，像webservice调不通了，或者说服务器是不是又有问题了。如果你自己实在解决不了，你也需要考虑大家解决问题的能力。找到最了解这类问题的人，向他寻求帮助。有时候尽管不能马上解决问题，这也会是你了解该问题、解决该问题最快的方式。

敏捷经验总结

晨会期间，大家容易陷入一个技术细节问题的讨论中，然后时间经常会拖很长。

大家使用英语交流项目上的事情，有一些费劲。

敏捷团队中每一个人的力量都是不可或缺的，不抛弃任何人，不放弃任何人。

积极使用敏捷管理软件管理项目进度。如Jenkins、禅道。

想想这次开发的经历还是挺痛苦的，具体的说应该是憋屈。依赖性太强，限制因素较多。做不出展示的东西来，很打击大家的开发积极性。然后会出现以下现象：其他组数据库中有了我们需要的数据，接口比较稳定后，大家会惊讶的发现，我们的系统随着这些工作的完成而完成了。