“敏捷文档”是否自相矛盾?
对于许多敏捷开发团队,“文档” 被视为一个禁忌词。毕竟,敏捷团队的工作前提是,不确定性是如此常见并且变化迅速,以至于花太多时间进行提前架构或设计在很大程度上或完全是不正确的。相反,敏捷开发人员一般选择短期的、频繁的迭代方法,采用重构方法进行架构和设计。
简言之,敏捷开发团队从一个想法入手,将它分解为特性和功能,编写高级需求,然后开始实施。他们的目标是编写足以继续构建工作的文档,在每次迭代中完成一组选定的高优先级需求,收集一个工作项列表中的需求,以及生成可供任何人在使用该软件时使用的文档。
拥有任何人都可使用的文档是一个值得称赞的目标,但在某些情况下,一个本想适合任何人使用的文档最终却变成不适合任何人使用。随着敏捷团队规模不断扩大以及不断融入更大的企业环境,敏捷团队必须设计更加成熟而又具有同样敏捷性的文档策略。
维护文档鸿沟.
许多业务关键型项目(比如业务应用程序或门户)现在正在他们的项目上采用敏捷实践。在这些项目中,常常会让一个外部敏捷开发团队创建应用程序,这个应用程序将在 12-18 个月内转交给雇佣公司本身或另一家第三方供应商,以提供持续维护。
尽管轻量型的案例和需求工件确实很适合构建,但他们可能对持续维护而言还不够。出于许多原因,这些案例和工件没有拥有维护应用程序所需的信息。
常常,当一个团队进入到大型项目实施中期时,事情就会发生变化,而且这些变化可能不会记录回文档中。人们的看法是软件已交付,是时候进入到下一次迭代了。所以,维护最终会得到过时的文档。此外,敏捷文档常常非常简单,没有维护团队通常需要的概述。
审计文档鸿沟
在一些行业中,比如金融服务和医疗行业,应用程序必须遵守一些外部规则和制度。因为可跟踪性在大型项目中非常重要,所以大型敏捷团队常常使用工具链接工件来实现可跟踪性,但这些常常并不够。
例如,我参与过一家医药公司的一次大型门户实现。它是一个内部门户,涉及来自药物研究的数据。在这种情形下,不仅数据访问要接受审计,数据访问门户结构本身也是如此。尽管我们链接了工件,但我们高度专注于应用程序和网站的开发,并且当审计人员出现时,仍然会抢夺文档和必要的可跟踪性。
比如维护文档,审计人员需要的信息不一定能在 “一体适用的” 需求文档中找到。向项目中添加可跟踪性也不够。审计人员需要能证明合规性的文档。
敏捷文档:
当敏捷团队面对这两个扩展因素(独立的维护团队和外部审计需求)时,Disciplined Agile Delivery 框架和 Document Continuously 这样的实践都是不错的起点。要消除为敏捷项目生成的文档与维护团队和审计人员的需求之间的差距,可通过采取与交付代码相同的方法来交付文档。不要生成每个人都应该使用但却实际无法使用的文档,可以考虑在迭代过程中提供独立交付成果形式的维护和审计文档。
在我参与的项目中,我将需求、案例和工件彼此分开,在迭代中创建其他交付结果。对于维护,我们基于维护需求构建一些框架。我们从敏捷需求中获取一些结果,然后查看存在哪些差距。每次迭代的部分工作都涉及到弥补这些差距。
对于审计文档,我们获得全部需求并将它们包含在案例中。事实上,在我们运行报告和合规性指标并将它们连接到案例之前,这个案例并不完整。我们认识到必须添加更多可跟踪性,认识到合规性和审计制度在不断发展和出现,而且我们还需要跟上这些变化。
共存计划
需求、工件、维护文档和审计文档都可以共存,它们不一定要在相同位置中,而是包含在不同的迭代中。此外,当采用即时和符合要求的方法时(这些方法都需要尽可能利用可重用的部件),生成文档会更加简单。
毕竟,当您查看维护手册或管理指南时,您可以看到它们包含设计文档中的一些元素。审计人员需要的可跟踪性类似于敏捷项目团队想要的东西,比如业务需求、开发工作项和验收测试之间的链接。
在我参与的敏捷项目中,我们发现了这些相似性,发布一个文档外壳并构建一个模板,模板带有包含从业务流程流或架构图提取内容的概述。我们在其他工具中创建的一些对象可被插入到手册中。这种方法的结果是创建 “微型文档”。与较老的大型设计文档相比,我们用于维护的微型文档更加流行,因为维护团队可正确定位检测出缺陷的位置。他们不再需要处理难以导航的大型文档。
结束语
在面对独立维护团队或常规审计的扩展因素时,敏捷开发团队基于需求、工件和案例而构建的应用程序文档就会表现出不足。如果采用敏捷方法进行扩展,那么提供适合不同用途的文档是有可能的。在工作过程中不断确定文档需求,将不同的文档版本包含在您的迭代中,您可以为所有涉众(包括维护和审计)提供正确的文档解决方案。
上一篇:同时实施CMMI和敏捷哪个为主 下一篇:【infoq发布的文章,我们也讨论下吧】衡量开发者效率、Bug统计是在浪费时间 |