银弹
我觉得没有银弹。开发是一个庞杂的事，不能一概而论，普适规则很难走得通。
你的项目有一个大泥球么？有什么解决办法？
A BIG BALL OF MUD is a casually, even haphazardly, structured system.
有的。就后端来说，我们在进行查询的时候为了方便可能随手就写一个小函数进行数据库查询返回filter结果。
在写任何新代码前规范好接口。不要随意写新的接口。
大教堂与集市？
大教堂：代码公开，但是只有特定团队能改。
集市：代码完全自由。
我们团队是大教堂模式。公布在github上，但只有我们团队能够修改。
Worse is better?
我觉得有一定道理。毕竟现在是利益至上的社会，质量的高低不是评判的唯一要素。所以我们在开发的时候，有时候会牺牲一些性能来保证功能的实用。
瀑布模型
划分块定期检查；按照某个模式运作；每个阶段都有每个阶段的任务，严格一个接一个执行；设定里程碑；每阶段都有文档。
你的团队在开发中用了那些敏捷的思想和做法？
每周5次开展scrum会议分析进度与接下来的工作。每开发出功能进行汇总。
效果显著，比线上交流效率高。而且每天分析有利于持续发展。
alpha和beta同样划分多个issue进行迭代。
不会墨守成规，转变思维。
软件工程的方法论到底有多少用处？
国有国法，家有家规。软件工程的方法论就像是程序员进行开发的法典。
小到个人的发展，大到企业的管理。都离不开软件工程的方法论。它对于我们每一个人的代码规范有很重要的作用，同样对于企业的管理也是不可或缺的，可以想象一个没有规范的世界是多么混乱。我可以感受到我们的项目正是在软件工程的思想下才能基本井井有条地往前进行，否则每个人各写各的会非常难以合到一起管理。
但软件工程的理论也不是完美的。正如《Why Software Development Methodologies Suck 》一文的作者所言，没有一个评价标准等缺陷是存在的。
