银弹
关于软件工程中的银弹我比较认同这篇博客上的说法
No Silver Bullet - Essence and Accidents of Software Engineering - Brooks 软件工程是没有银弹的。银弹一词来自《人月神话》,原本应该是指某种策略、技术或者技巧可以极大地提高程序员的生产力。该博客中提到“现代软件最精简的本质特性是复杂性，一致性，可变性和不可见性。”针对这四个特性来说，软件工程的复杂性不仅会带来各种技术问题，还会存在许多管理上的问题；而其要求的一致性在实践中实现又存在着许多困难，不同人员的设计开发等等问题会给软件工程带来大量的不确定性，导致一致性实施起来实际困难重重；同时在现实中，软件受到的不断的压力变化会导致其需要可变性，面对新环境都会导致软件做出改变；更为重要的是不同于实际物体软件存在着不可见性，这就导致在设计中各关系之间存在着许许多多的复杂关系；这其中的每一种特性都很难通过银弹去解决。因此，我认为软件工程的这些本质特性导致了软件工程在实践起来并没有银弹，仍然需要复杂的需求分析，设计，开发测试等等。
大泥球
大泥球是指软件在设计时比较随意导致在开发过程中修修补补，比较混乱。在我们开发过程中，相对来说还是存在一些大泥球的。首先在结对项目中虽然我们开始有确定好代码规范，但在实施过程中仍然存在一些问题，为解决这样的问题，我们采取了代码复审和结对编程的方式比较好的解决了这样的大泥球问题。在团队项目上，开始我们的设计有些混乱，导致在开发过程中边设计边开发，进度有些缓慢。通过代码复审，结对编程，完善设计，及时维修的方式我认为可以比较好的解决大泥球问题。
什么是大教堂？什么是集市？
在大教堂模型中，每个软件版本都提供了源代码，但在两个发行版之间开发的代码仅限于一组独立的软件开发人员。以GNU Emacs和GCC为例。
在集市模型中，代码在开发时就通过互联网公布于公众。Raymond 称Linux内核项目的领导者Linus Torvalds是这个过程的发明者，还提供了他自己实现这个模型的Fetchmail项目
我们的项目在开发时就会在GitHub上公布，属于集市模型，但代码的修改只能由我们自己进行，有人员负责版本控制，因此未出现迷失的情况。
Worse?Better?
我认为有一定的道理，首先我们在功能开发时会保证功能的完整性，确保能够执行一定的流程保证实现完整的功能来满足用户对于这方面的需求，其次追求设计的简单性。
瀑布
瀑布模型是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段。
你的团队在开发中用了那些敏捷的思想和做法？
每周通过scrum meeting的方式汇报一周进度以及后期的任务计划，并通过GitHub的issue来控制任务的进度实现和任务分配
软件工程的方法论到底有多少用处？
对于软件工程方法论，有两大原则可以大体上指引我们进行好的软件工程实践：缩小开发周期和提升反馈效率。缩小开发周期的关键优势是小变化集。小变化集更容易理解，测试和整合。提升反馈效率意味着可以更频繁地验证核心假设，并且在冗余（即非增值）方面花费更少的风险。