现代软件工程系列 学生的精彩文章 (6) 项目总结

http://lunarthu.spaces.live.com/c11_BlogPart_pagedir=Next&_c11_BlogPart_handle=cns!48EA3793D3DA17C8!211&_c11_BlogPart_BlogPart=blogview&_c=BlogPart January 10

学做一个PM By Cheng Lu

对于我们的SmartMe，我是真正倾注了感情的。看到今天SmartMe走出了坚实的第一步，心中首先是感谢，感谢LunaR团队四个好兄弟为咱们的软件付出的心血；然后是欣慰，我们几个月5个人的共同奋斗没有白费；最后更是展望，我们希望我们的SmartMe不因课程结束而销声匿迹，我们希望我们的SmartMe能真正成为一个成熟的软件产品。

在SmartMe中，我专注的只有一件事情：学做一个PM。

我是在软工课上第一次接触PM这一概念的。虽然一开始被指派有些鬼使神差，但是现在自己还是感觉很庆幸能得到这方面的锻炼。程序能力的提高固然是软件工程课程必不可少的要素之一，但是在工程的整个运行和管理方面能力的提高，以及一个商业视角的培养，我想才是软件工程这门课区别于其他程序设计课程最显著的地方。

虽然以前在别的组织中做过一些项目的负责人，在一个技术团队中做管理者自己还是头一回。开始我并不知道该怎么做。自己一直坚信代码是一个软件的灵魂，而PM是要负责除代码以外的任何事情，这让我更加迷茫，不知所措。好在我有4个最靠得住的兄弟和我并肩作战，他们对我犯的错误的容忍和他们的帮助，让我慢慢上路，谢谢你们。

我觉得PM最重要的事情是要团结整个团队，让每一个成员有一种归属感，他们能够在团队奋斗中感受到快乐。我努力让每一个人做的事情对于整个项目来说都是实实在在的贡献，并且尽量保证合理的分工，让每个人的工作量相差不多。一方面实实在在的贡献会产生成就感，这是快乐的重要源泉，另一方面平均的工作量又不会使任务重压力大的组员心生怨怒。福利政策自不可少，我们每周在翅香园或考研院开组会，作为PM，多花点钱也是义不容辞的。

PM另外一个重要的责任就是要保证项目能够按照计划前进。这个我走了一些弯路。一开始我尝试完全脱离我们的代码来进行项目管理，但是很快我便发现在技术项目中这么做是举步维艰的。因为如果不了解每个人实实在在的工作，那么我很难判断他们是否完成了这一阶段的任务，并且和他们一同讨论下一步的方向。感谢吴昊和蒋叶，让我迅速了解了咱们整个程序的具体框架，之后项目的统筹规划自己才感觉更游刃有余。这是一个很有意思的事情，我需要了解具体的程序以制定项目的前进方向和我们要实现的功能，但是我又没有必要精通每一个细节，因为那样我就越权了。如何保持这么一个平衡是对技术类PM的一个挑战。：）

在项目的关键时候，在团队中出现争论的时候，仲裁和做出最后的决策是我的责任。这方面我有功有过。在Alpha版出来前，决定我们完善UI而暂时放弃历史记录的设计，我觉得是我做得好的。在历史记录基本完成后，看到林添UI部分的压力太大，进度跟不上时，决定之后的工作重点在于推进UI，放弃设计更多Feature，并且在最后关头组织大家一起突击攻关，我觉得是SmartMe得以最后发布最关键的几个时间点。但是这些决策我做得还是不够及时和果断。如果我们能够更早地意识到UI的巨大工作量并且平摊，如果我们能够更早地在一起协同攻关，那么我们的SmarMe肯定会更早地发布。

我必须要对SmartMe用心，团队中的其他人才会对SmartMe用心。我向整个团队道歉，在项目的前期，因为自己的事情，拖累了团队和项目的进度。之后的日子，我一直在努力用行动弥补我的过失，维护好咱们的Blog，做好项目进度管理，了解每个人的工作量， 督促大家同步前进，最后一起突击攻关。这些其实还不够，Beta之后的日子我还会尽好我的职责，因为这样我觉得才对得起大家共同的努力。

我是幸运的，能和4位如此踏实靠谱的兄弟一同工作。谢谢林添，你的投入让我牢牢记着自己身上的责任，鞭策我用心努力工作。你对整个软件理念、对软件框架和UI设计的贡献不可磨灭。谢谢吴昊和蒋叶，你们脚踏实地的工作是我们最后能够成功发布的根本保障。谢谢马成龙，你最后阶段的付出让SmartMe锦上添花。

11:52 PM | Add a comment | Permalink | Blog it | Software Engineering

我的软工总结 By Chenglong Ma

软件工程感想 By Tian Lin

软件工程这门课，对于我来说是一次软件开发，发布，团队协作的一次实战。尤其是在Team Project中，跟大家一起努力，实现我们的梦想！
SmartMe对于我来说，有一种特殊的感情。它起源于我之前的一个想法，用技术最大化信息获取的渠道，让用户享受信息尽在指尖的体验。
在理念的提出阶段，或许SmartMe是最受争议的一个项目。它本身是新颖的，在市场上并没有一款现成的产品可以作为模板，大家都看不到vision。所以在最初的时候，我们经历了很多次讨论以达成。为了便于宣传和理解，我们以最快的速度完成了Technical Preview。
或许提到SmartMe，每一个团队成员和用户看到最多的是技术。而我觉得从项目本身来看，我最大的收获就是学会了如何事实说话。我们的每一个feature都是从survey开始的，都是投入和成本的权衡。当在技术上证明其可行性之后，我们首先检验是否符合我们的vision。这让我们能够很好的走下去。在发布之后，我们收到了很多用户的反馈，而大多数反馈的内容，都是跟我们的计划相match的。
另外一个感受用一句话概括就是，The only limit is your imagination。相信很多的人都会有这种体会。即便是在搜索这个相对成熟的领域，仍然有可以做的空间。无论是最初的输入伴侣或是现在的搜索资源管理器，SmartMe于我来说都是实现着一个相同的理念。这也是对我个人来说最为鼓舞的一件事情。
而最为感动的是能够加入有这么一个优秀的团队：我们的PM吕诚，团结起整个团队的感情，让大家充满斗志，为软件的推广做出了不可磨灭的贡献；吴昊，实现了非常稳定的kernel，给软件的集成打下坚实的基础；蒋叶，勤勤恳恳地付出，实现了我们一个又一个实用的功能；马龙，给我们提出了很多宝贵的建议，为软件稳定提供了保证。 9:58 PM | Add a comment | Permalink | Blog it | Software Engineering

软工感想收获 By Ye Jiang

    IProject比较扯吧，先是从wiki上知道这个问题被人做出来了，然后花了三天时间才找到论文（《稳操胜券》这本书真NB），又花了一个小时写代码。听吴昊说他用程序生成了8000+行的代码，orz……我觉得这个作业的题目不好，不应该选这种已经有结论的题目。
    PProject I，唐神花了不到五分钟的时间搭好了一个框架，让我大开眼界。
    PProject II，只是简单的用了贪心，没想到效果还不错。另外多亏老朱的最后的测试数据比较温和，不然我的程序的bug就会被发现了。另外杨松写的描述太赞了！
    TProject，SmartMe最初的定位并不太明确，中间在理念上和技术上也经过了一些转变。不过幸好我做的最主要部分——从 络抓取结果——基本没有怎么变化。比较遗憾的就是，没有从一开始就用后来林添提出的基于javascript的方法，而是用了一个类似SAX那样的解析器，导致后来吃了不少苦头，而且功能上不够灵活，扩展性不足。而词典部分选用了 Dictcn这个 站也不太靠谱，在我们快发布时居然大改版，而且还挂掉了一段时间，访问速度也不快。当初选择它主要是觉得它页面结构最为合理，处理起来也最方便，现在看来似乎有点得不偿失了。后来做了一点点的UI，感觉做UI还是挺麻烦的，林添真是辛苦啦。另外就是，每次开会的时候林添，吴昊和马成龙总会争论，然后吕诚就会仲裁，从中我也学到了不少social skills。 9:57 PM | Add a comment | Permalink | Blog it | Software Engineering

软件的艺术

— Created by Hao Wu  

软件工程课明天就要完结了，尽管我们还计划了后续的工作，但是对于此课程应该没有什么影响了。对于这门本科阶段最“工程”的一门课程，我总觉得还是应该留下点什么的。也许将来我不会以做软件谋生，但是对这门课程，乃至整个软件工程的体会予以总结，也许在若干年后回来看的时候，会有什么深刻的感想也说不定。为了给将来留念，特此写下此文。闲话休提，言归正传，就以软件工程课最后的团队项目——SmartMe的感想来收束我的软件工程课吧。

最新的技术不一定是最好的，因为用户很可能有一台不能使用这种技术的计算机。尽管.NET确实是非常好的技术，而且我们5组当中有4组使用了此技术，但是我们的目标用户群当中，有不少使用的是Windows XP的机器，并且没有装.NET Framework，这使得一些人未能选择试用我们的软件。但我觉得此牺牲是必要的，因为对于我们来说，三要素（时间、资源、质量）中其实最缺乏的是时间——质量好固然好，资源也可以想办法获得，但是时间是定死的——无论如何一定要在1月4日交付，而且越早交付越好，获得的好处甚至可能超过质量。因此，为了节省Dev的编程时间和测试及调试的时间（如果用C++&MFC实现，肯定将要多花很多时间，这是看iHunter的Blog总结出来的），做这一点牺牲应该是必要的。

模块化编程，但是尽早综合到一起。我们从一开始就把所有代码综合在一个Solution当中，尽管不同的Dev编写不同的模块，但是模块之间从一开始就是能放在一起工作的，避免了某些小组出现的一开始各写各的模块，最后发现无法综合到一起的问题。不过这种方法也有缺点，就是大家发现不能运行的时候，有可能会选择改动别人写的代码的Bug，而不是交由编写该模块的人去Debug。事实上最后我基本上所有文件都修改过，其他Dev也差不多。

尽早开始测试工作。我们启动测试有点晚了，结果1月4日才能将所有问题Fix，比预定晚了1天发布。关于测试还有一个问题，就是是不是即便有已知Bug的软件也要发布欣老师虽然举了一个例子（Excel的纪年，将1900年记做闰年），但这是一种特殊的情况。我最初一直觉得最好不要发布，但在1月4日之后我发现这是不对的，因为我在书上看到这样的话（忘记那本书谁说的了），“推迟半个月发布或许是个好主意，但是只有在竞争对手不会在这半个月发布的时候”。有的时候，发布早也是优势，甚至是一个很大的优势。即使早一小时发布，也是能有很大很大的收益的。

要使用管理工具，比如Google Code。如果不使用的话，我难以想象那些Bug是怎么Fix的，不同人写的代码是怎么同步的，怎样避免冲突代码带来的问题。Google Code确实是很好用的平台。它最大的好处是，所有源代码、剩余bug/issue，软件文档等等，都记录了下来，而且只要Google Code本身不出问题，这些东西都能轻易转移到以后想接续开发的人手里！使用TFS管理或许方便很多，但是如果那台服务器Down掉的话，数据可能就丢失了。而且将来的接续开发者很可能不能再访问这台服务器，这样他们获得源代码和文档等就比较麻烦了。

要写单元测试。这个对复查代码是必要的，而且也能检验局部代码（例如，一个类）是否正确，避免到综合起来之后才发现问题。而且，当代码修改或者重构之后，通过这些单元测试，可以验证修改后的代码没有破坏原有的逻辑，方便了测试工作；而且在写代码出错的时候可以用来快速区分是破坏原有代码还是新出现的问题，这也方便调试。

最后，这些方法，不是做好软件的全部，甚至不是最重要的部分。我看了《走出软件作坊》这本书，这本书的主要宗旨是如何做好一家小型的软件公司，也许跟我们的项目关系不大。但是，这本书讲述了一些很基本的道理，这些不仅仅是在软件工程上，而是在其他工业活动当中也是有借鉴意义的。例如，做一款软件，或者说，做一个项目或产品，真正的目的是什么于一个小公司的老板来说，目的可能是为了赚钱；对于一个开源项目的管理者来说，目的可能是为了扩大自己的影响等。而对于我们来说，目的究竟是什么曾经认为我们的目的很清楚，是要做一款足够优秀的软件。但是，在读过《梦断代码》之后，我发现这一目的，正是Chandler项目走向困境的主要原因，因为事实上这根本不能称为是目的。或许我们的目的是“无论如何，一定要在1月3日或之前发布我们的软件，并且以任意方法宣传以尽量增加我们软件的下载量”似乎是说，我们写软件的目的就是为了分数（但说不定这才是我们写此软件的真正目的吧）。跟这种迷惘相比，用不用什么管理工具，方法好不好之类的问题都是小Case了。我们究竟如何处理做软件和课程管理之间的矛盾也许才是做SmartMe过程中最大的问题吧。

         谨以此文，献给陪伴一个学期的软件工程课，邹欣老师，贝小辉助教，LunaR全体成员(吕诚同学，林添同学，蒋叶同学，马成龙同学)，尹杰同学，印奇同学，以及一起参加软件工程课的其他同学们！