在经过个人作业和结对作业的磨练和现在正在进行的团队作业的考验中，我对自己软件开发的一点得失有了些许感悟，同时读了老师推荐的文章后，自己也是有了一些感受。
- 首先在“No Silver Bullet”一文中，我深刻体验到了：
非线性的complexity,项目单模块的复杂度以及整合之后出现的大量耦合问题；
conformity的困难，一致性因为个人代码习惯和沟通的不充分导致软件的整合过程漫长而复杂；
changeablity，数据挖掘源的数据结构变化导致了整个爬虫的整改，甚至上升到软件本身的层次，能够感觉到，用户需求的快速变化加剧了软件开发的复杂度；
invisibilty，我们的软件在UI，后台上都进行了大量的整改，服务器端的连接也是很麻烦，这一切都因为我们自己想去极大的增强客户体验，通过不断修改来增加交互的友好性；
那么在经历的这些小工程的开发过后，我也是深刻体会到了软件工程方法的重要性，但是我对作者悲观的“No Silver Bullet”的想法表示不赞同。
- 再来我感受较深的"Ball Of Mud"一文中，对软件架构的描述也是和这次团队作业产生了共鸣：
计划的不充足，让整个软件工程的开发过程出现大量的技术性意外，对于项目进度的把握十分不到位；
技术的不深入，对于软件架构的理解不足，对于功能模块的设计和技术需求没有仔细，让技术死角没有在项目的计划部分就显现出来，后期的弥补耗费大量时间；
再来，由于以上两个原因所导致的bug以及技术难题几乎可以在大项目里随着时间成指数式增长，我们对于问题的修复越来越像打补丁，哪里有问题就补哪里，项目本身的代码框架从原有轨道开始慢慢偏移，冗余度大，架构零散，像一个Ball Of Mud。
Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system.
Therefore, do what it takes to maintain the software and keep it going. Keep it working.
希望这两句话能够给我们团队在剩下的开发过程中有一点帮助与启迪。
- 我们团队在开发过程中使用了BAZAAR模式，模块的开发过程会有测试人员同步设计测试用例，模块完成后就立即进入测试环节
有人负责，才有质量。
所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外。
这两句令我感触颇深。
总结：我想谈一下本次团队项目中自己作为PM的得失以及整个团队出现的问题。
我完成了：
对于人员优点的看重并在团队后让成员选择了最适合自己的部分；
从软件层面分析项目，认真分析；
我的问题：
项目计划不仔细，对突发情况应急措施不足；
对于技术难点没有提前分析，但还好进行任务重分配后能解决问题；
保持团队气氛，与成员保持进度沟通与技术沟通，调整各模块的人力资源分配；
我们团队的问题：
成员之间沟通少，需要PM调动，积极性够，但是感觉女生不爱说话，完全不主动沟通。
对项目的技术难度低估了，我们的遇到了相当大的技术困难，好在正在顺利的解决中。
就这样吧，希望剩下的路我们能够成功继续。