你的项目有一个大泥球么? 有什么解决办法？
大泥球这个问题在之前我遇到过，但是不知道它就是大泥球。在我最早写代码的时候由于代码量小，而且写一次代码之后我不会再去看他，所以我在程序结构上和变量的命名方式上没有多大的考虑，是要能够加快我的这次开发就行了。这造成了我的代码可读性比较差，而我也不喜欢读自己之前写的代码。
你的团队是用什么方式建造软件?
我们组的设计模式是大教堂模式，我认为，在我们这样的小规模编程使用大教堂模式要比集市模式好得多，因为我们的人数比较少，使用大教堂模式可以让我们分工明确。我认为，集市模式更适用于开源社区这种人流量够大的地方，集市模式可以让人们自由地参与到软件中来，这其实是用数量弥补了质量。
这些情况在你的团队中出现过吗？
作者主要讲述了开源软件中的过度依赖问题，这个问题在我们的工程中也遇到过。
这是后来大家说的 “瀑布模型”，它有什么特点?
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。
你的团队在开发中用了那些敏捷的思想和做法？
- 每日站立会议
每日站立会议是老师要求的，但是我觉得这个很有用，每天我们的队员在一起汇报一下今天完成的任务和规划一下明天的任务，这是很有实用价值的。我觉得最大的作用在于鞭策队员每日按时按量完成自己任务。 - Scrum
Scrum 是一个敏捷开发框架，我们团队是分为了不同的角色，PM，开发人员，测试人员。不同的角色做不同的事，大大提高了开发的效率
软件工程的方法论到底有多少好处？同时好好读一下两个文章的评论。
软件工程在之前有了解过，但几乎没有过实践，觉得理论的都是空的，但是真的用过软件工程的方法之后我觉得软件工程的方法确实在某些方法很有用。例如迭代，以前遇到一个大的问题不知从何入手，感觉完全没有方向，总是想要找到一个完全的解决方案，然而在迭代中，每次开发一个小的版本，一点一点添加，最后形成最终版，我觉得这个很有用，可以逐渐解决问题，至少能够尽快开始问题。又比如说极限编程，极限编程中有四个核心价值沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）。 XP用“沟通、简单、反馈、勇气”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。总之，软件工程的学习对于我们进行软件开发是很有好处的。