作者：奋斗的筱清年 | 来源：互联网 | 2023-05-17 16:47
这个是我今天听了Nokia的IRM项目会议后，一个很启发性的思考。原因是这样的，项目经理说，以后所有的用户故事都应该有文档，并且文档补完了之后才能close用户故事。这让我想到了过去我们做日本项目的时
这个是我今天听了Nokia的IRM项目会议后，一个很启发性的思考。原因是这样的，项目经理说，以后所有的用户故事都应该有文档，并且文档补完了之后才能close用户故事。这让我想到了过去我们做日本项目的时候，有的时候是需要先上船后补票的。就是说，我们先完成代码部分，然后利用剩下的时间，进行补那些设计文档。当然这里的Nokia需要补的是，业务文档。
很多地方的敏捷做法是，JIRA既然管理了用户故事以及其依赖关系，那么就此废除了项目文档这个做法。这种我认为并不可取，原因是这样一来，以后维护的时候就无据可依了。所以这么看来文档的确是必不可少的。
敏捷界也有另一种做法是，需求条目化。这样的话，每个需求都是可以追述到的。区别是，我们可以沿用过去常用的一个大份的需求，然后在需求的每个细节角落，标识出子需求的号码和位置。这样，开发的人员看到的就是一份更细粒度的，更可实现的子需求了，条目化后就可以改叫用户故事了。那么拆分的任务就需要PO帮助Scrum Master和团队一起来识别，并且条目化后的需求，就可以让团队来承担了。这也是一种方法，当且仅当业务PO不那么敏捷，而IT希望敏捷的前提下。并且这样做，文档就自然而然的留下来了。
再回到补文档的问题，先开发后补文档，但是必须在同迭代完成，这个做法，我一半认同。另一半不认同的理由是，既然可以沟通好，并且让团队进行开发，为什么这个可以交流的文档不能算呢？还需要补的是哪类文档呢？这个问题也许并没有确切的解释。
文章到这里，也留给大家一些思考，究竟什么是真正的敏捷，怎么样的敏捷是纯正的。
京公网安备 11010802041100号