扫码阅读
手机扫码阅读

敏捷需求管理 ∣ 听说我以后再也不用写需求文档了?

111 2024-03-22

#
产品经理必聊的100个话题



第17期:敏捷下的需求管理

当有人宣称敏捷下要轻文档,甚至是无文档的时候,很多人都很喜欢这个观点,于是就开始在文档方面开始草率了。

实际情况是怎样的呢?还是在真实世界探讨比较能够得到合理的结论。



产品都是长生命周期的


Business Analysis





产品往往都是长生命周期的,并不是开发之后就不管了,后续还有升级、维护等各种工作。如果当时没有建立足够好的需求文档,则之后会因为需求文档的不全面等各种质量问题,而引起系统难以升级等各种问题。具体表现如下:

1.代码成了唯一可信源,却难以使用

当文档管理比较草率的时候,代码是系统运行的唯一依据,所以只有代码是作为最终唯一的可信源。无论设呢么事情都要从代码中去寻找逻辑。然而,代码又写的并不是很好读好懂,代码的命名一团糟。从而造成了,唯一的可信源代码也是难以使用的。

2.不知道当初为什么这么写代码
当代码中出现一段逻辑的时候,虽然逻辑可能比较清晰,但是当初为什么原因要加这段逻辑,到底是为谁解决了什么问题都不清楚。而文档已经不可参考了。一般来说的做法就是:绕开这段代码,另写一段。

Backlog是用后即拋型用品


Business Analysis





1.Backlog里不应该管理需求详细
很多团队会在Backlog里以附件的形式附加需求文档,作为backlog的附件,但是其实需求文档可能是整体文件的。所以,打开的时候还需要从需求文档中查找具体的backlog所涉及到的内容的具体位置,才能够找到内容。这样阅读很不方便。
2.需求文档是经常变化的
需求文档是经常变化的,所以,需求文档如果作为附件放在Backlog里的话,那就会经常的变更需求文档。维护的工作量也会变得很大。
3.Backlog用后即拋
当迭代结束后,Backlog就会被关闭掉。然后作为附件的文档就会被关闭掉。这时候再想找到历史的需求文档就是很困难的事情了。因此,文档不应该是作为附件放在backlog里的。
4.引用式是最佳的解决方案
由于Backlog是用后即拋的,而需求文档是长生命周期的,所以,需求文档应该是长期保留的。所以,最好的方式是,在Backlog中对需求文档的内容进行引用。而很多管理平台的软件产品都是按照引用的方式进行设计的。

文档版本管理是头疼的事情


Business Analysis





除了上述问题之外,需求文档还有版本管理问题。在瀑布模式下,需求文档一次写完,进行开发。但是敏捷模式下,需求文档需要按照迭代拆分,就形成了迭代间的需求变更问题。因此额外会多了几个需求文档管理的问题。
通常的做法就是把需求拆分的零碎了,然后在迭代中进行管理。但是这种方法造成了需求文档的不连贯,导致了开发人员和测试人员无法整体的理解需求。而如果一次性全部写完又变成了瀑布,所以产生了困惑。
到底敏捷下应该如何管理需求文档?

敏捷项目如何管理需求文档


Business Analysis





1.采用片段来管理文档
因为需求文档的内容太多了。所以文档要按照具体的内容进行拆分成片段进行管理。
这样可以根据具体的情况进行片段的选择和组合。更容易的组合成各种内容。并且利用Tag的方式对版本进行管理,容易识别各个版本迭代中的具体任务。这样即使在梳理下个迭代的需求的时候,也不影响当前迭代的开发。

2. 采用引用的方式进行backlog管理
为了能够管理好backlog,需要从backlog中引用对应的文档片段内容的集合。比如说:

UI设计、界面校验、界面互动处理、点击按钮后的后台逻辑

作为一个集合,引用到backlog里
当片段发生变更的时候,Backlog不需要进行更新,直接就可以获得最新版。
原文链接: http://mp.weixin.qq.com/s?__biz=Mzk0MzM2OTQzOA==&mid=2247484221&idx=1&sn=768d210b27b1b69cf537875388ba3ca7&chksm=c335be8cf442379a86689f3f40d2c5b69699237adf6239624d7cd00b4a6af56d835a7a8005ac#rd