【个人阅读作业】软件工程M1/M2总结

链接：”看《快速软件开发》的五个问题“

http://www.cnblogs.com/leiyy/p/4027759.html

一、较为明白的问题

1. 在文章的第一个关于Square_Tech的案例中，代码测试和优化都是在所有程序完成以后才进行的，这应该也不符合快速软件开发的要求吧。如果测试工程师在最开始的时候就加入到软件开发中的话，软件开发进程会不会更快呢？

　　在团队项目之前，虽然并不是特别了解测试工程师的工作内容，但想到既然是软件开发项目中的一个单独列出来的角色，那就肯定大有用处。当初为什么提出这个问题，也是因为在写程序的时候都是自己设计测试用例，而且都是代码编写完了以后做测试。但是看了《快速软件开发》这本书以后，觉得测试工作应该是在软件开发初期就开始的。由于这本书没有具体介绍这方面的问题，所以我就参考了其它书和博客园里的其它博客。然后发现测试工程师不只是编写测试用例，他有的时候扮演着产品经理的角色，要站在用户的使用和需求角度去思考软件的测试和问题报告，同时还要根据能够想到的问题和需求与软件开发工程师进行协商，协助SDE 的开发工作。在M1阶段的时候，我们团队并没有考虑到测试的问题，只是想着如何去实现学长的这个项目，更详细点说就是怎样把这个APP移植到安卓手机上来。或许是第一次接触的原因，根本不知道该如何下手，联网阶段出现问题以后，项目就搁置了，因为预先不知道未出现这个错误，所以怎么也调试不好。

2. 我一直分不清楚几个PM之间的区别。虽然在网上查了一些资料，但还是不明白Product Manager 和 Program Manager之间的区别是什么。在《编程之美》一书中了解到微软中的PM属于R&D,就是说Program Manager属于研发岗，但是《移山之道》在移山公司最初成立的时候又说PM不用写代码，是这样的吗？

　　现在想想，这个问题一下子就暴露出了自己捉急的智商和对软件行业的不了解。产品经理和项目经理除了都有一个后缀”经理“以外，应该就没有什么相同之处了吧，也不知道当时自己是怎么想的。打个比喻说的话，产品经理就是一座桥，连接了用户和项目团队；也可以是一个集市，供用户和项目团队交易。而项目经理就是leader，如果把项目组成员比作神经元，那么项目经理就是神经中枢。

3. 其实我不懂既然有了有效开发，为什么还需要快速开发。因为从《快速软件开发》做的比较可以看出，有效开发的产品要好于快速开发的，而且进度和成本不会太差。我知道软件行业竞争力很大，谁的产品先出来，谁就有可能抢占市场，但是如果没有足够好的产品，当更好的产品出来后，不也是会被取代吗？就算可以先上市后在做调整，但是 有可能因此而花费的精力会更大，所用时间会更长。

　　这个问题我现在是这么想的，”快“和”精“，也就是”快速开发“和”有效开发“往往难以取舍。有的东西你为它的精致负责，它不需要，这是我在北航门户网站实习明白的一些东西。实习的时候，我希望每个我负责的专题都能够达到自己想要的效果，能做吗？负责的老师跟我说，只要想做都是能够做出来的，但是划算吗？有个词叫做”性价比”，性价比不高的话，又何苦呢。另外一方面，就是不能偏科的道理，任何一个具有功利性质的项目，包括商业项目和课堂大作业都是这一类，商业项目求得是赢利，而要赢利就肯定要打败竞争对手，市场变幻风云，当然时间就起了很大的决定性作用，先打入市场总会占得一定的先机，有更加充足的时间进行下一步的布局和调整等等有利的因素。而每一个课堂大作业都有一个deadline，团队项目之间存在竞争，这个时候时间就成了定值，也就是说时间是一定的，就看你是走到撒哈拉还是好望角了。总的来说，就是两个东西，在有效开发的前提下提高效率，或者在快速开发的前提下提高质量。怎么感觉说了跟没说一样。

4. 一个小型项目团队中，到底是产品经理还是测试工程师(假设都只有一位)更了解这个产品？

　　我这个问题应该是没有问好，没有界定小型项目团队到底是多小的团队。不过就我们团队和软件工程这么课的其它团队而言，我发现最了解产品的不是测试工程师也不是产品经理，而是程序员。因为在一个小项目里面，对于产品的用户要求和其它非技术因素并不是程序员不能应付的，所以小项目的核心是技术，它不需要繁复的产品调研和设计，也不需要花哨和充满想象力的运营。百度和阿里虽然在各方面都不弱，但是由于两个公司的价值观和定位不同，百度更重技术，阿里更重其它。

二、还是糊涂的问题

5. 一个首席程序员团队的核心是首席程序员，但是这样的团队对于风险控制有极大的要求，如果这个团队中的首席程序员因为什么原因在中途离开了这个项目组，那么要保证这个项目的正常进行，这个团队可以怎么挽救，需要改造成其它什么形式的团队

　　其实我们这个团队应该就算是一个首席程序员团队。编程能力最强的一位队员顺理成章地成为了首席程序员，而且主动承担了最为艰巨的任务，虽然我们一开始并不知道联网这一块儿会这么棘手。庆幸的是他一直没想着离开这个团队，如果离开的话，或许这个项目就是宣告失败了。但是有一个问题就是，当他一个人在那儿研究并不断深入的时候，有一个问题会出现，就是其它队员会越来越难以介入，最终导致项目一步一步地往后推。而且首席程序员的情绪直接影响到其他成员，高兴的时候大家都高兴，焦躁的时候全别这种气氛笼罩。现如今，项目总算是有点点成果了，大多半都是依靠他的不断探索和努力，很感激他。不过我原来提的那个问题，因为自己并没有遇到，也很难找到一个其它例子，还是有些糊涂。

三、冒出来的新问题

1. 通过怎样的方式能让项目组的每一名成员都能发挥他的最大价值？对于一个小型项目团队来说，怎样进行项目分工更科学？

2. 一般来说，同一个软件开发项目在不同平台的实现都是一个团队完成的，而我们有好几个项目是接手上一届团队的，最开始的时候以为这是件好事，只是做维护而已，但是后来发现，这不是再创造的问题，而是重做。学长的代码是用oc写的，我们组没有一个会oc的，还有就是交流问题，毕竟不是团队成员，所以在沟通上总会不方便。所以我想问的是老师当初选了一些上一届的项目给我们继续做是出于什么样的考虑？

四、读文章的新体会

1. 大泥球问题。这个问题应该是软件工程初学者都会出现的问题吧。工程素养都还没有达到一定的水平，不会像高级软件工程师和老师们那样高屋建瓴地去看一个工程，或者是一个功能的一段代码实现，更多的是想到哪儿写到哪儿，所以系统性不够强，就形成了典型的大泥球问题。在后面做测试的时候发现需要修改好大一部分。只想着早知如此，何必当初。有了教训以后，我们后面做了充分细致的设计以后在进行实现，质量和效率都提高了不少。

2. 大教堂和集市问题。我们团队还是用了大教堂的形式。不过出现的问题就是当教堂里面的神父们水平都很低，参悟不了一些问题的时候，还是得把问题抛到市场上去聚集各方力量。我们在得知靠自己的力量搞定不了开发中的问题的时候，也只能厚着脸皮不断地请教老师，同学，学长了。

五、课程最后的总结

总结就一点，课程设计没错，是自己不够付出，基础不到位。不过一分耕耘一分收获，无论是大是小，做了，总是有点收获的。