敏捷 - 什么时候运作良好,什么时候不运作？

Question

我们的团队正在讨论我们是否想要变得敏捷.我们谁都不熟悉敏捷.我想对敏捷何时运行良好,何时不运行有所了解.

为了给出一点背景知识,我们是一小组开发人员,总共六人.我们有更多的工作要做.我们的优先事项经常变 今天有什么高优先级,可能不是明天.我们有许多应用程序来创建和维护.我们已开始涉足敏捷实践,以至于我们每天都有scrums和两周的Sprint周期.

如果您需要更多信息来回答这个问题,请随时提出.

谢谢.

Answer 1

Ralph Stacey的复杂度矩阵通常用于说明敏捷的最佳位置:

替代文字http://nooperation.typepad.com/.a/6a00e54ff8b9c1883400e553fdfccb8834-400wi

对于简单项目(需求和技术都众所周知),可预测性很高,因此预测方法(瀑布)运行良好.

对于复杂和复杂的项目(以及绝大多数IT项目),可预测性较低且预测方法不起作用,应首选自适应方法.这是敏捷运作良好的地方.

当需求和技术都未知时,无论方法如何,你都会接近混乱,失败的几率非常高.

Answer 2

我只是根据经验说话; 因人而异.

我的团队在开展敏捷工作方面没有成功.IMO,原因是:

• 开发团队第一次听到一个项目,它是一份需求文件和截止日期.
• 利益相关者通常不愿意花时间去研究冲刺工作的结果,因此如果他们认为项目走向了错误的方向,他们就不会在冲刺之间采取行动.
• 当我们向利益相关者展示我们的工作时,他们通常都很好.他们会谈论他们想要什么,我们会回答"这可以在大约X时间内完成",他们会回答,"唔没有必要超过截止日期."
• 部署过程漫长而复杂,阻碍了频繁部署.所以在实践中,我们经常在完成2个月的项目时进行部署,而不是在冲刺结束时.
• 我们的sprint计划会议耗时长,效率低.
• 除了scrum布道者之外,似乎每个人都对scrum是什么(以及我们的流程是什么)感到困惑.

所以我很确定我们做错了.你也不错.

有些东西已经加快我们,这是我们继续使用:

• 适用于每个人机器的自动构建(巨大的帮助!)
• 我们的代码库的正式安排
• 学习如何将应用抽象机制应用于UI代码
• 重构
• 单元和集成测试
• 持续集成

我想你可以说我们的代码更敏捷,尽管我们的方法不那么灵活.然而,在我们无法跟上需求之前,现在我们可以.

(我不是说敏捷是坏的;我只是报告我的经验.另外,请理解我不选择我们使用的方法.)