如何在开发长期复杂系统时使敏捷方法发挥作用?

时间:2009-11-10 00:02:06

标签: agile complexity-theory

我的团队正在构建一个产品,其中包含许多相互依赖的组件。例如,每当我们向系统添加新类型的数据时,我们还必须添加日志记录代码以跟踪使用该数据类型的更改。或者,当我们添加新的UI屏幕时,我们必须确保其字符串被外部化以便可以进行翻译。这些事情几乎减慢了我们所做的每一项任务,有时其中一个步骤会被遗忘。

处理此问题的传统方法是添加必需的清单和文档等。敏捷方法如何处理它?<​​/ p>

7 个答案:

答案 0 :(得分:5)

您描述的设计听起来可能有点过于紧密耦合。重新关注企业模式(例如控制反转,接口编程等)可能会有很大帮助。

如果你正在进行结对编程,你应该检查对方的工作,确保所有的i都是点缀的并且t是交叉的。

如果您正在进行测试驱动开发,那么在满足开发工作的特定部分的所有要求之前,您的测试不应通过。

如果您正在开发一个庞大而复杂的系统,那么您需要有经验的开发人员来理解设计和开发过程。您可能还需要一个可以监督整个过程的动手(阅读:编码)架构师。

哦,清单(尽管它们具有传统性质)也很好。

答案 1 :(得分:4)

我建议阅读Alistair Cockburn的“敏捷软件开发:合作游戏” - 他对敏捷采取了一种非常明智的方法,主要是“完成工作”。这可能会帮助你找出如何获得某种清单/文档到你正在做的事情而不会使一切都非常沉重。

通过更好的测试可以解决一些问题吗?当你谈到不做需要做的事时,我的第一个想法是“为什么没有测试失败?”也许您需要查看用于测试用户界面的工具? (编辑:甚至是提交时的一些小脚本,用于表示需要翻译字符串的代码以及对具有翻译的文件进行检查?)

此外,你可以改变你的设计,使它更少耦合,并“强迫”你做正确的事情。也许使这些数据类型实现记录器委托给的日志记录接口,或类似的......?

答案 2 :(得分:1)

根据您的IDE,有各种工具可以帮助识别需要外部化的字符串,但如果您习惯于不插入静态字符串,则可以避免这种情况。

如果您需要添加日志记录,我建议使用AOP,因为在某些时候您会想要删除日志记录代码,并且您可能会破坏应用程序。

但是,一个长期,复杂的系统是敏捷开发的理想选择,因为在您开发过程中,客户/客户的需求可能会发生变化,您可以适应它。

您需要确保客户定期获得反馈(理想情况是每天,并且在一个完美的系统中,客户会有代表提出问题)。

当我有许多必须完成的步骤时,尤其是数据类型之类的东西,我将使用电子表格,因此,您添加数据类型,向电子表格添加一行。然后,您可以跟踪在数据类型完全添加到应用程序之前需要完成的所有操作。

答案 3 :(得分:0)

拥有跨组件团队。这样,当您添加一些功能时,日志记录组件中的成员将更新其部分,并且翻译器将更新字符串。

答案 4 :(得分:0)

我认为重要的是要理解敏捷方法只是一个流程框架,而不是一个流程本身。例如,它表示遵循测试驱动的开发并进行结对编程,但它没有说如何来编写测试,或建议审查清单或建议编码指南或说出要编写的文档。这些部分完全取决于您或您的组织定义和遵循。

规划功能时,您可以添加名为“审核”的工程任务并为其分配时间。您可以以最适合您和您的组织的方式执行审阅任务。如果结对编程不适合您的正式检查,则应进行正式检查。

答案 5 :(得分:0)

做需要做的事,但不是更多:

  • 更好的完成定义(完成的定义对我来说是一种清单),
  • 更好的测试,
  • “足够”文档(敏捷!=没有文档),

答案 6 :(得分:0)

好吧,在我工作的地方,我们有QA可以捕获一些错误,如果有缺少的要求或滑倒的东西。我不是说开发团队故意搞错,但随着代码库的增长,在检查所有内容时变得越来越难以保持灵活和彻底。

Wiki可用于捕获用于尝试获得最清晰要求的方法。明确表示我的意思是故事卡不太可能列出所有要求,并且可能会与最终用户或业务分析师讨论以了解所需要的内容。我们签署的部分内容涉及让最终用户在离开开发环境之前查看功能并批准它。

每一次冲刺,我们可能会进行大部分冲刺,专门用于修复错误/重构,这样就可以清理一些因为它们不太重要而无法完成的事情。这可能是化妆品缺陷或破窗,虽然它们最初具有很小的商业价值,但从长远来看可能很有用。