[Homework#1]回味·神笔马良

 

 

神笔马良的故事不陌生吧。在很久很久以前有个叫马良的。他有支笔很神，稍在墙上涂涂，就成真了。但是你懂的，童话里的故事都是骗人的。。。

五位北大研究生组成的Thinking小组，历时两个月，打造的新神笔马良是一款在线休闲画笔程序。新神笔马良想法来源于Algoloo，国外的儿童物理教学产品。我们这篇博文的想法来源于Thinking，神笔马良的作者。感谢他们给我们带来的思考。

Thinking小组的分工很专业，一位项目管理（PM），两位程序员（DEV），两位测试员（TEST）。传说这就是微软标准。。。终于明白为什么称微 软为“测试公司”。在我们以前的项目中，我们从来没有在测试上投入那么多时间。Thinking小组的分工起初让我们觉得不可思议。周老师花一次课时间来 讲软件测试起初也让我们觉得不可思议。但回首往事，Bug一直是我们的心痛。假如当时能多花一点时间用来测试的话，也许，我们就没必要花甚至比编码更多的 时间来调试。这一次软件工程，我们也按微软标准来分工。 Thinking小组的博客也很专业。 Thinking小组的博客目录。很有美感。（您老不知道美在哪？回复可见。。。）从这些细节就能看出Thinking小组对博客的认真。Thinking小组的博客内容也很认真。这是很值得学习的。代码是无趣于读者的。一项软件工程，如果想获得更多的影响和更多的支持以及更多的用户的话，首先要让别人了解这个工程。博客是一个很好的展示平台。 写文档也是团队合作不可或缺的工作。因为，于码农，别人的代码，甚至自己以前的代码也是无趣的。没有文档的代码是无用的。没有学过软件工程，不太可能会重视文档。所以，正如周老师说的，没学过软件工程的人以前写的程序一点用也没。 团队博客不能像个人博客那样随意。因为团队博客展示的是一个团队形象，很容易代表。Thinking小组在这方面处理得很好。

 

 

每篇博客的标题署名都很规范，风格统一。“团队名称+身份+名称”，很是大方。这很能展现团队的凝聚力。作为软件的官方博客，更应该规范博客格式，严谨博客。这样能给软件用户更多力。

团队博客的每一篇都影响着团队的形象。Thinking小组的很多博客的结尾都有规范的署名。这像是说，“Hey，我们对这篇博客负责，相信我们吧。”团队博客的语气也是很值得考量的。“我”和“我们”是不一样的。
不仅仅写博客有一群一群的规范。写代码，写文档，发邮件都有一群一群的规范。《代码大全》的厚度就能说明代码规范的一些些。软件工程的大量文档的大量规范刚被我们发现。。。项目开始前需要进行前期调研。“神笔马良”是一个微项目，但Thinking小组也进行了深入的调研。在“神笔马良”之前，又有一群一群的idea被pass掉。
在调研之后需要写需求分析。需求分析非常重要。因为对一个产品或者软件来说，最希望看到的就是其能得到广泛的使用，而搞清楚了用户的需求就是搞清楚了软件的方向！同时，需求分析还有一个重要的重用，在Thinking小组的博客中我们可以发现，当他们遇到紧要关头的时候，比如时间的紧迫以及外界的压力下决定“推迟”和“必须实现”的功能时，可以根据需求的优先级决定！
我们常常会畏惧，因为不知道的东西往往容易让人害怕！在实现一个软件的时候，必然会有很多我们没有熟悉掌握或者以前从没有接触过的技术！而且必然会有很多我们预想不到的情况！我们到底能不能完成这个项目？在我看到Thinking小组的软件成果时，我们的第一反应是他们很强，以前一定有经验！一定搞过这个东西！可是当我看到他们的blog时，我震惊了，他们一开始时是和我们一样的！他们说，不要畏惧，learn by doing ！这话说得真好！在做中学习！我们一定要秉承这样的态度才能把一个项目做好！即使失败了也无所谓，因为我们学到了东西！而且学习是在实践中获取的，连手都不敢动，如何能学？
在一个项目开发的时候一定会遇到各种分歧和冲突，Thinking 小组处理的很好，这是值得我们借鉴的地方。他们经常开短会议，如果遇到巨大的分歧时他们往往会通过投票的方式解决，或者在指导老师的带领下讨论解决。经常开会是很好的习惯，这有助于交流，增进友谊及协作的默契！还有值得我们学习的地方是他们将交付件定义清楚，功能细节还有接口定义都很到位，这样会使得每个人都有清楚的定位，及规范认识！正所谓，无规矩不成方圆嘛。清晰的架构也是我们需要的学习的，他们在blog中提到，一个好的清晰架构使得他们在项目的进程中少走了不少弯路！
Thinking小组的工作很完美。每个人都不可或缺。如果我们在Thinking小组的话，我们会花更多的时间在软件工程上，而不是技术学习上。我们觉得，技术是日新月异的，而软件工程的思想和方法基本不变，而且很受用。这包括怎么写文档，怎么构架系统，怎么进行测试。Thinking小组的测试方法很值得商榷。
我们认为Thinking小组在时间分配上似乎不太合理。后期时间分配太少了。MicroTeam队员Hui曾经参加过一项为期三个月的机器人比赛。因为对后期时间投入的乐观估计，所以在中期投入较多时间进行调整。最终因为后期测试不足导致比赛时出现Bug。。。

呃~这就是我们小组的收获和不同观点。最后感谢神笔马良，感谢Thinking！