我们的团队正在辩论我们是否想要变得敏捷。我们谁都不熟悉敏捷。我想对敏捷何时运作良好以及什么时候不运作有所了解。
为了给一点背景知识，我们是一小组开发人员，总共六人。我们有更多的工作要处理。我们的优先事项经常变今天有什么高优先级，可能不是明天。我们有许多应用程序来创建和维护。我们已经开始涉足敏捷实践，只要我们有每日scrums和两周的Sprint周期。
如果您需要更多信息来回答这个问题，请随时提出。
感谢。
答案 0 :(得分：17)
Ralph Stacey的复杂度矩阵通常用于说明敏捷的最佳位置：
alt text http://nooperation.typepad.com/.a/6a00e54ff8b9c1883400e553fdfccb8834-400wi
对于简单项目（需求和技术都众所周知），可预测性很高，因此预测方法（瀑布）运行良好。
对于复杂而复杂的项目（以及绝大多数IT项目），可预测性较低且预测方法不起作用，应首选自适应方法。这就是敏捷运作良好的地方。
当要求和技术都未知时，无论方法如何，你都会接近混乱，失败的可能性非常高。
答案 1 :(得分：8)
我只是根据经验说话; YMMV。
我的团队未能成功完成敏捷工作。 IMO，原因是：
所以我很确定我们做错了。你也不错。
已经加速我们的一些事情，我们将继续使用：
我想你可以说我们的代码更敏捷，尽管我们的方法不那么灵活。然而，在我们无法跟上需求之前，现在我们可以。
（我不是说敏捷是坏的;我只是报告我的经验。另外，请理解我不选择我们使用的方法。）
答案 2 :(得分：3)
重新发布我的related answer：
讨论通常是对瀑布的敏捷，对吧？我正在链接article，但它是葡萄牙语，所以我会尝试传达它的一些想法：
瀑布就像国际象棋。你思考和计划很多，尽快预见每一个可能的问题。有很多计划，但只有在稳定和知名的领域才有意义，而这些领域的变化并不多。
敏捷就像足球（或许多集体运动）：决策是在游戏中完成的，应该快速完成。没有太多时间分析每一个后果。对于动态和不稳定的域而言，它是“理想的”，在这些域中，始终需要进行更改（例如，Web应用程序往往属于此类别）。需要注意的另一点是：即使你拥有最好的球员，如果他们不能成为一支球队，你就不会成为胜利者。
恕我直言，Scrum会很有用，因为：答案 3 :(得分：1)
对于Agile或Waterfall这两种方法，您的优先级似乎变化太频繁了。随着优先级的频繁变化，您可能会进出项目，而其中很多项目都已完成。敏捷总是准备释放可能会有所帮助。根据我的经验，采用一种方法可以提高生产率。
你的情况让我想起了我所从事的一个项目。该项目的开发人员在一开始就问了一个问题：“你想让我做得对吗还是做出回应？”当我进入为期六个月的项目两年时，我就参与了这个项目。一周，周一，周三和周五实施了相同的功能。周二和周四用于删除功能。
我建议你开始采用敏捷的做法。安排短暂的冲刺期可以帮助改变优先级。在一周或两周的时间内保持优先级可能更容易，并且可以更容易稳定优先级。你还需要一个积压（听起来你已经有一个大的积压）。
如果你能在一两个星期内将他们插入冲刺，管理层可能更愿意推迟新的优先事项。您还可以识别优先权权衡。如果您在下一个sprint中添加了一些内容，那么将删除的内容。
考虑让团队的一部分工作敏捷，而其他团队维持现状。在获得经验时，每个sprint轮换一名团队成员。考虑让整个团队参加每日站立状态会议和冲刺后审核。一旦您展示了提高生产力和回报公司，您应该能够使用您的方法增加完成的工作量。
敏捷是一种适应性方法。期待在新的一年或两年内对您的方法做出重大改变。最终，你应该进入一个你正在进行微调的阶段。
答案 4 :(得分：0)
根据我的经验，你绝对需要以下敏捷（至少XP或Scrum）才能工作。没有这些先决条件，您可能会失败。硬。
只要你保持values，你就可以解决这些问题。