Week 7 迭代总结

写在前面：

本次我为团队博客写了一篇总结，深刻总结了我们组发生的问题以及将来要做的事情。有兴趣请移步http://www.cnblogs.com/Buaa-software

Week 7 Alpha轮迭代总结以及我的一些启发

先说说我们的项目：

我们的项目没有大泥球。

大泥球这种东西对于一个项目来说是要了命的，出现这种情况纯属大家没有精力和意愿去维护以前的代码。这大大降低了项目的潜力，让代码成为用过即丢的一次性物品，浪费了大量的时间、精力。而这一切却仅仅因为作者们在更新时不去修改以前代码的兼容和BUG，导致泥球越滚越大。

我们的项目有黄上同学作为首席测试员，他为我们的代码找出了许多BUG，我们及时的更新了自己的类。保证了整个项目的稳定。而且项目的代码复用性也得到了提高。

一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为何物的所谓IT“专业人士”永无休止地复制着，粘贴着。

 

       这篇文章说的很有意思，也很有道理。所谓质量，只有某人对它负责时才有意义。好多项目有着臃肿的代码，却实现不了基本的功能。在开发过程中一个很常见的事情是：这个问题不会，于是在网上找到了一段代码来解决问题。然而这段代码没有头没有尾，就错误的用在了这里，虽然解决了问题，却给后面的开发引来了很多隐患。我们的项目是从头做起的，那些基本的功能也是我们一点一点实现的，所以也不存在这种问题。

我同意没有银弹的说法。我相信无论是在软件工程，还是在其他的课程当中，银弹这种东西都是不存在的。没有万能或万全的方法论，对于软件工程这一门学科来说，在软件开发过程当中，最重要的还是三个字：看需求。

1. 项目得多长时间完成？
2. 项目的启动资金有多少，有多少人做？
3. 项目的核心功能有多少，需要什么样的稳定性？
4. ……

这些东西在没有确定之前，我们不能得出一个结论。同样我想到目前为止，还没有万能药能解决所有的不同需求的项目。

软件工程的方法论毫无疑问是有用的。我们把大部分次要复杂度通过软件工程的方法论都优化掉了。剩下的主要复杂度是我们的学习成本，我们都是在学习中逐渐进步的。我们在软件工程的A轮迭代中得到了很多经验教训。现在把我们团队博客的一部分迁移过来，以便展示：

简单地总结一下，我们的团队有成员没有达到敏捷开发的要求，体现在：自主管理，自我组织。

       自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑任务；每次Sprint结束之后，还要总结不足，提出改进，并且要自己实施这些改进。“自主管理”不等于“没有管理”。

       自我组织：以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还有帮助他改进，项目缺少某类资源自己还要顶上去。

       这件事情发生在团队身上，就是“积极度不高”。大家没有积极地把这件事情做出激情，对于团队交代给的任务也没有积极完成。比如说，如果留学生同学能够主动的来要代码，把我们分享的知识学习完全，写博客的同学能主动找开发人员要今天的进度。负责辅助首席程序员写代码的同学能够主动的去要任务来减轻首席程序员的负担，这些都是“自主”掌控的地方，而在这些地方我们掌控的都不好。

另外，在阅读中的这一句话我简直不能同意更多：

通常情况下，最引人注目的创新解决方案来自于意识到你对问题的概念是错误的。

而我们组几次大型的更新，几次把代码推倒重来，恰恰因为发现我们原来的想法是错误的。因为一些交流上的不直白，我们多花了两天时间写代码。这说明，一个好的系统架构师是多么重要，他能从一开始就把问题考虑到。从而能让整个队轻松解决一些问题。我离这个目标还差很远，我还需要太多的经验。

还有，在设计的初期，

一定要画图！

一定要画图！

一定要画图！

重要的事情说很多遍。队友无法想象你在想什么，只交流不画图只能带来更高的沟通成本。

这次迭代对我而言还有更深层的体会，不过跟软件工程的方法没什么关系，而是我自己的问题：

1. 被别人带着，是痛苦的。我还是喜欢自己去实现什么东西，才能神清气爽，毫无羞愧。让自己的队友做大部分东西，对我而言是一件很不舒服的事情。我希望能在团队中有所贡献，而且还不能低，否则还不如不参加团队。在团队做出来东西时一点喜悦感都没有。
2. 有问题就要及时说，不要以为队友可以轻松意识到。有可能你有的信息他们并没有，不把想法说出去就会白白加大交流沟通的成本，而毫无所得。
3. 程序员更应当爱惜羽毛。要对自己写过的代码负责任，保证其可复用性和稳定性，不要写完一扔就不管了，最后还要麻烦别人把东西实现。到时候可能别人读不懂你的代码就自己写了，你辛辛苦苦写的劳动成果可能因为这样的小事情而毁于一旦。

暂时就这些吧。

老师大人和助教大人，我14-22号要跟着学校出去，可能会无法及时回复博客，请您谅解，我会时常关注您的评论的！