首先谈一谈对这几篇文章的理解吧。
银色子弹：在软件工程开发中，银弹指的是一种能够迅速并且有效提高软件工程实现效率的方法。听起来这个概念很美好，但是在No Silver Bullet: Essence and Accidents of Software Engineering一文中，作者指出所谓的银弹是不存在的，没有什么东西能奇迹一般的大幅度解决软件工程问题。然而在文章中，作者也给出了一些潜在的很优秀的解决方案，例如Ada等编程语言，人工智能领域中的专家系统等等，虽然不能够称为银弹，但是如果能够将其运用于软件工程中，效果还是会十分显著的。与之相反，在There Is a Silver Bullet文章中，作者显然对银弹的存在持比较乐观的态度，作者认为类似于面向对象设计思想，代码模块重用等设计理念都是有可能能够成为银弹的。综合考虑两篇文章可以看出，虽然两个作者的观点不一致，但是都认为一些设计理念或者设计方法是能够在软件开发中有效提高工作效率的。
就个人观点而言，我觉得银弹是不存在的，因为我认为没有什么东西是以及万能药，能够解决软件工程中的所有问题。此外，由于软件工程领域的发展十分迅猛，某一时期的方法也不一定能够一直适用。
我们这次做的项目还谈不上银弹，毕竟都是第一次接触软件开发，软件工程中的所有理论对于我们来说都是全新的知识，都是第一次尝试，更多的是学习怎么样实现一个软件的开发。但是，其中的一些思想，例如面向对象，代码重用等等还是很值得去借鉴使用的。
大泥球：大泥球指的是在代码编写时，由于只是一味地追求完成的速度，只为了实现某种特定的功能而写出的一次性的代码。这样写出的代码对于整个工程的危害是非常大的，因为在软件开发的过程中，功能是有可能不断在变化或者增加的，这个时候就需要对模块的接口或者实现进行修改，如果只是一次性代码，那么对模块进行维护和扩展就会非常的艰难，很有可能就会因为一个小小的改动浪费大量的时间。除此之外，有的时候代码编写的人可能在代码需要进行修改的时候已经不属于这个团队了，这个时候如果原先的程序员留下了一个大泥球，那么将会成为整个里面非常棘手的问题。
在我们团队现在的开发过程中，由于项目还比较简单，还没有出现非常明显的大泥球，但是在迭代轮数的不断增加，功能的不断更改，代码的不断维护，以及人员的转会，这种现象是不可避免的。一旦大泥球出现，我们也会在最快的时间内将其解决以免产生更为严重的后果。
在Lost in CatB一文的阅读中，作者讲解了许多软件开发中的专业名词和术语，所以导致文章不是特别容易理解，不过文章有指出的有一些问题还是很值得注意的。文章中讲到，虽然代码模块化设计，代码重用是非常好的思路，但是在绝大多数的情况下，由于设计出一个完完全全独立的模块是一件不可能完成的任务，所以如果想要实现模块的复用，就必定会导致多个模块之间的互相依赖，互相纠缠，从而使整个项目看起来一团糟，最后就变成了“代码越重用，浪费越严重”。
我们小组选择的开发方式是大教堂式的开发模式，因为我们的软件还处于非常非常初期的阶段，所以我们一致认为这样的开发模式是更为有效的。毕竟作为一个刚刚开始的项目，采用这样内部的模式是十分正确的。
瀑布模型：所谓瀑布模型，就是将一个软件的开发周期划分成几个固定的阶段（包括制定计划、需求分析、软件设计、程序编写、软件测试和运行维护），然后每个阶段完成以后才会进入下一个阶段，如果某个阶段出现问题，那么就会回溯到上一个阶段去解决出现的问题。瀑布模型的特点是十分显著的，由于阶段划分十分明确，所以每个成员负责的阶段也能够十分清楚，而且可以在每个阶段之后都能够很明确的知晓当前阶段的任务有没有完成。此外，作为一个非常基本的模型，在软件开发的每一次迭代中都可以使用瀑布模型。不过瀑布模型也存在一些问题，例如如果在某个阶段中，用户的需求出现了变化，那么可能会需要重头来过，如果出现的问题没有得到及时解决而在最后阶段才发现，那么后果会很严重。另外，由于瀑布模型要求在每个阶段结束后要进行很详细的文档说明，在无形中也增加了团队成员的工作量。
接下来要将的是敏捷开发，在我们的团队工作中，个人认为我们的团队在这个方面做得还是不错的。相比较于仅仅是在QQ或者微信等网络平台上联系，我们的scrum meeting选择以当面模式进行，并且一直坚持了下来。在交流的过程中，我们会讨论当前阶段出现的问题，接下来的任务布置，不仅使项目能够更为有效地完成，也让所有团队成员有了更强的参与感，让每个人对自己做的项目的整体结构有了更为清晰的认识。
在Why Software Development Methodologies Suck文章中指出了为什么有的时候软件开发中的方法在实际使用起来并没有那么理想的效果。在文章中作者重点强调了划小开发周期以及提升反馈效率这两条法则，不过由于是英文版的文章，更详细的内容还需要更仔细阅读。