银弹：

　　我觉得在beta阶段我们采用了一个算是银弹的方法，就是重构代码吧，由于在我们组之前已经有两组碰了这个项目，很多代码都冲突和冗余，重构的话能够删除很多没有用的代码和加深理解，但是收效甚微，重构导致了进度变慢，实际的新东西也不是很多；可能也是人员少、时间少、分配不均的原因，很多时候都要等待重构完成才能对接。但这种做法可能是一种银弹，就是对我们这个工程的帮助没有显现出来，反而算是有一点帮了倒忙的样子。但如果能够为下一届或者以后的同学起到加快项目进度作用应该算是一个银弹吧。

大泥球：

　　大泥球是我们组遇到的一个巨大问题，而且这个泥球不是一般的大，由于是接手经过两个队伍改动后的项目，可能一开始是个小泥球，然后等它的表面干了，又弄上了泥，成了两层的泥球。在拿到这个项目的时候很明显能感觉到它的很多地方都是分开的，其中有几个功能在绑一起，但有的功能由于调用了另一个外部框架的原因又是独树一帜， 我们发现在调用很多东西的时候本不应该从数据库中调的东西它存在数据库中，网页的框架里面用了另外的框架，导致我们看代码的时候进度极慢，新增代码更是难上加难。我们是想要解决这一问题的，我们的方法是重构代码。但相对的，新增的东西也少了很多。而且在我们新写的时候也有泥球产生，比如两个人在改同一段代码，然后两个人都加入自己认为有帮助的代码，虽然是在理解了对方的基础上，但在使用对方的代码的时候会比较偷工减料，这样也是会产生许多不可复用的代码。

大教堂和集市：

　　我们的项目是采用集市的办法，但虽然项目公开，具体有权限修改的只有开发人员。

Worse?Better?：

　　我认为如果真正要做软件工程，还是不能“worse is better”，因为除了把项目做出来，软件工程还包括之后的维护工作和其它很多东西，要有维护性，首先就要完整，不能让让几个功能拖慢了整个项目的进展，想这次我们接手别人的任务之后，也感受到了一开始引入的一个小的错误变量，后来可能引发严重的后果，有的时候当下看起来能够快速解决问题的办法在长远看来反倒是像埋下了一个炸自己脚的炸弹。

瀑布和敏捷：

　　我认为瀑布对我们来说还是早了一点，第一我们时间有限，而在我们现在的水平基础具体编码和修改代码占的时间比重上比较大，经验也不多，导致了瀑布的前几个流程可能分配的时间少，说着说是收效甚微；我认为瀑布还是适合那种大型公司，有足够的时间和专门的人员监督瀑布的每一个流程。相比之下，敏捷坑能还是更加适合我们和一些小型公司，针对需求而做变化，用实际的软件衡量成果，这也在一定程度上把我们和自己做的软件距离拉近，也增强了同伴之间的沟通，增加做下去的动力。

方法论：

　　还是要自己动手才知道，虽然方法论的前景美好，但是一味的谈论理论也只是纸上谈兵，实际有很多需要随机应变的东西，也需要考虑人的情感和能动性等因素。