你的项目有一个大泥球么？有什么解决办法？
有，一开始开发软件的时候，团队成员们都是根据自己的经验来进行开发，组件放置的位置，颜色，大小也是凭借自己的喜好来设置的，这就是我们项目中的大泥球。为了解决这个问题，我们团队后来采用Material Design规范对组件进行整改，对组件的位置，颜色，大小都做出了统一的规定，让我们的app看上去更加规范，用户体验更好。
什么是大教堂？什么是集市？
大教堂：每次软件发布后代码都能被看到，但是代码只能被一个特定的团体修改。
集市：代码的在公众的视线下被修改。
你的团队是用什么方式建造软件？
我们团队是用大教堂方式建造软件的。
这些情况在你的团队中出现过么？
没有出现。为了美化我们团队的软件，同时又为了省时省力，我们会在github上寻找别人写好了的现成的组件并应用到我们的项目中（比如日历组件和滚轮组件）。因此我们需要下载安装相关的依赖包，但是没有造成混乱。
这是后来大家说的 “瀑布模型”，它有什么特点？
1.为项目提供了按阶段划分的检查点。
2.当前一阶段完成后，只需要去关注后续阶段。
3.它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
4.各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
5.由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
6.通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
7.不适应用户需求的变化。
你的团队在开发中用了那些敏捷的思想和做法？
我们团队的项目进行了α和β两个阶段的开发，并且每当一个阶段的软件开发结束就交付一个阶段的可用开发成果，并且保留可更改能力的情况下对代码进行优化，总结和经验分析，为下一阶段的发布做准备。由于一开始的设计涵盖的功能有限，我们团队成员需要在迭代过程中收集用户反馈，响应用户需求的变化，通过沟通和交流从而提出新的功能。由于我们团队开发的是轻量级应用，所以添加新功能并不需要对核心代码进行很大的整改，再加上团队规模不大，所以交流也很方便，所以敏捷开发对于我们的项目来说相当实用。
软件工程的方法论到底有多少用处？
各种软件工程方法论的涌现让我们对软件工程方法论的实际用处产生了怀疑。我认为软件工程的方法论用处有多大关键取决于你如何使用。这些方法论只是我们实际进行软件开发的一些指导与策略，我们既不能一味的迷信也不能全盘否定，而是应该让方法论与实际相结合。比方说在进行小型项目开发时我们可以采用敏捷开发的方式使项目容易修改，节省开发周期。而在大型项目开发时采用瀑布模式会更好，做更多的工作让项目变得稳定，减少bug出现的可能性。所以说软件工程方法论只是一个参考，我们要根据实际情况做出自己的选择。