2012年2月14日,星期二10:38

敏捷需求和项目文档如何一起生活

撰写者

及时适时

敏捷开发人员的工作条件是不确定性如此普遍并且变化如此之大,以至于任何前期的体系结构和设计都不可能完全正确或不适合进一步发展。因此,使用重构的体系结构和设计方法,开发是迭代且尽可能简单的。

敏捷开发团队从一个想法开始,将其分解为功能和特性,编写高层次的需求,然后开始使用。目标是记录足以进行构建的文档,完成每个sprint中的一组最高优先级需求,在积压中收集需求,并提供任何人在使用该软件时都可以使用的文档。

拥有任何人都可以使用的文档是值得称赞的目标。但是,在某些情况下,本应适合所有人的文档最终却没人适合。

维护文档差距

现在,许多关键业务项目(例如商务应用程序或门户)非常敏捷。在这些项目中,通常有一个外部敏捷开发商店来创建应用程序。该车间在项目上工作了12-18个月,然后将其移交给需要应用程序的公司或其他供应商进行维护。

尽管轻量级的故事和需求工件确实可以很好地用于构建,但它们不能仅按原样进行维护。这些故事和工件由于多种原因而没有维护应用程序所需的信息。

通常,当团队进入一个大项目的中间时,事情会发生变化,而这些变化可能不会使其重新回到文档中。态度是该软件已经交付,现在该进行下一个冲刺了。因此,维护工作将以过时的文档结尾。此外,敏捷文档通常非常简单,没有维护团队经常需要的概述。

审计文档差距

在某些行业中,通常存在应用程序必须遵守的外部规则和规定。由于可追溯性在大型项目中很重要,因此大型敏捷团队经常使用工具链接工件以实现可追溯性,但是有时这些工具还不够。

例如,我为一家制药公司设计了一个大型门户网站。这是一个内部门户网站,涉及药物研究的数据。在这种情况下,不仅要对数据访问进行审核,而且还要对数据访问门户本身进行构建。尽管我们链接了工件,但是我们非常专注于开发应用程序和网站,并且当审核员出现时,文件和要求的可追溯性都非常混乱。

与维护文档一样,信息审核员的需求也不一定在“一刀切”的需求文档中找到。将可追溯性附加到项目还不够。审核员需要证明合规的文件。

敏捷文档

可以通过采用与交付代码相同的方法来交付敏捷项目所生成的文档与维护团队和审核员的需求之间的鸿沟。与其提供每个人都应该可以使用但不能使用的文档,不如考虑将维护和审核文档作为单独的交付物提供。

在我从事的项目中,我们将需求,故事和工件分离开来,并创建冲刺中的其他可交付成果。对于维护,我们根据维护需要构建一些框架。我们从敏捷需求中收获东西,然后查看存在哪些差距。冲刺的一部分正在填补空白。

对于审计文档,我们获得了完整的要求,并将其作为故事的一部分。实际上,直到我们运行报告和合规性矩阵并将它们与该故事相关联后,该故事才算完整。我们认识到,我们可能必须增加更多的可追溯性,合规性和审计法规在不断发展和新兴,并且我们需要跟上发展。

共存

需求,工件,维护文档和审核文档可以共存,不一定在同一位置,而是作为不同冲刺的一部分。而且,当您采用及时且适合用途的方法时,所有这些方法都包括在可能的情况下利用可重复使用的零件,则生成文档会更加容易。

毕竟,当您查看维护手册或管理指南时,您会发现它们包含设计文档中的某些元素。审计师要求的某些可追溯性类似于敏捷项目团队想要的,例如业务需求,开发工作项和验收测试之间的链接。

在我从事的敏捷项目中,我们确定了这些相似之处,发布了一个外壳,并构建了一个带有轮廓的模板,该轮廓包括业务流程或架构图的摘录。我们在其他工具中创建的某些对象可以插入手册中。这种方法的结果是“微型机会”。我们的维护微型文档甚至比旧的大型设计文档更受欢迎,因为维护团队可以直接向发现缺陷的地方移动。他们不再需要处理难以导航的庞大文档。

结论

由敏捷开发团队基于需求,工件和故事构建的应用程序文档在需要用于其他目的(例如维护或审计)时会显得很短。如果您采用敏捷方法,则可以提供适合不同目的的文档。预先确定文档需求,并在冲刺中包含不同的文档版本,您将为所有涉众提供正确的文档解决方案,包括维护和审核。

不要忘记在下面留下您的评论!


库尔特·索拉特(Kurt Solarte) 是在悉尼的IBM澳大利亚工作的管理顾问;专注于敏捷开发方法。 Kurt最近在美国的IBM Global Business Services工作了8年,担任高级业务分析师。他专门负责保持业务分析的生命力,并与电子商务,Web门户和业务分析项目的敏捷交付相关。

库尔特·索拉特(Kurt Solarte) 的最新作品

©BA Times.com 2020

麦格雷戈徽标白色网站