我是一个软件开发团队的成员，从事一个小项目。 我们认为我们可以在连续工作2或3个月后发布测试版的产品。
由于这是我们的第一次团队合作，我决定问一下，对于少数开发人员（少于10人）的小项目，您会建议使用哪种软件开发方法？
答案 0 :(得分：6)
软件开发有两种方法：
他们都有他们的追随者，并且都以各种名义反复弹出。每一代新一代软件开发人员（即大约每2年，这是一个快速变化的行业，软件开发人员拥有mayfly的生命周期）拒绝上一代的方法，重新发现前一代使用的方法，重新命名它时髦，宣称它是一种真实的方式。
方法之间的选择应该取决于（a）客户组织的文化和（b）在较小程度上，供应商组织（即您的软件开发团队）的文化。
因此，如果您为一个扣人心弦的保守企业工作，则表示方法1。如果你向下看并看到你穿着冲浪短裤并且今天早上在你的滑板上工作，那么请选择方法2.
而且，如果你已经阅读过这篇文章，那么最重要的一点就是在最后一篇文章之前的一段，即一篇以“选择......”开头的段落。这是一个文化/组织问题，而不是技术问题一。这两种方法都被用于许多成功的项目，也没有垄断不成功的项目。
答案 1 :(得分：2)
这确实取决于您打算构建的内容。如果项目是你想要建立的东西并且有定期的交互，那么像Agile / Scrum这样的东西就非常适合。
但这实际上取决于项目是什么来确定发布迭代等等。
答案 2 :(得分：1)
我认为您需要从 Joel Test 开始，并尝试实施此列表的大部分内容： http://en.wikipedia.org/wiki/The_Joel_Test
随着产品开发使用KISS = Keep It Simple＆amp;愚蠢，首次发布
另一个非常好的开始是获得真实的书，可从37个信号中免费获得： http://gettingreal.37signals.com/toc.php
答案 3 :(得分：1)
这确实取决于您的客户。
如果客户可以接受修复 时间，固定资源，固定质量 （100％工作代码），稍微 变量范围，我建议选择 灵活的方法论。
如果客户不能接受 以上，即前提条件 使用敏捷方法不是 目前，我建议选择任何 您喜欢的方法。
重要的是，您确实拥有一种方法论，了解当前的工作原理，并运用这些知识来调整方法。
答案 4 :(得分：0)
不要做瀑布，这从未奏效，永远不会奏效。思考瀑布是一种工作方法，就像思考撞墙一样好，因为即使是最坚固的墙也必须在某些时候崩溃。
我会采用合理的敏捷方法，比如Scrum（XP有点苛刻）。另外，介绍像TDD，DDD，DBC这样的东西你应该没问题。
答案 5 :(得分：0)
我不认为这是最好的答案，没有更好地了解背景和情况，但我个人成为精益/看板方法的粉丝。总的来说，我发现许多敏捷/ scrum方法可能是以开发人员为中心的，而且有时几乎是反管理者，这有时是合适的但并非总是如此。精益方法倾向于解决整个价值流而不仅仅是发展本身。
了解更多相关信息