敏捷开发实践(2)-要不要文档？

背景

        自从我们使用scrum进行项目开发后，出现了这样那样的问题，有些是因为我们对scrum的理解不到位，有些则是客观因素导致的，针对这些问题，在每次迭代的总结会上，我们进行了反思，并根据具体环境对scrum进行了一一调整，想通过几篇文章和大家分享一下我的经验。

我说的不一定正确，只是描述问题，然后说说我对问题的看法，采取的解决方案，希望使用敏捷开发的大牛提供宝贵意见。

到底要不要文档？

        以前我们做项目多采用传统的瀑布模型，前期有详尽地需求文档，设计文档，如果发生变更，还要遵循复杂地变更流程，很多时候文档得不到及时地更新，项目做完了，但是项目跟文档根本对不上，而且偏差很大，给维护人员造成了很大的麻烦，所以弱弱地说一句，瀑布模型不太适应变化。文档成了让我们头痛的问题。

        从去年开始，我们开始采用scrum开发，让我们眼前一亮的是，“scrum不提倡写文档” （真的吗？） 。所以我们在得到基本地需求后，就开始上马开发了，但开发了一段时间后，被一个领导L叫停了，他让我们准备整个项目的wbs，甘特图，搞清楚我们到底要完成哪些任务，这些任务的轻重缓急，有个整体地规划。而另一个领导X，也就是我们scrum的领路人并不提倡我们写这些文档。我们夹在两个领导之间，着实郁闷了几天，最后我们遵循了领导L的意见。

        但项目进行中，我们并没有写需求文档，只是根据简单地需求描述，就开始实施设计，开发。开发过程中，发现设计不合理，改设计，发现需求理解不到位，接着该设计，在开发人员频繁地修改中，总算是满足了基本的需求。不可否认， 遇到问题，能够及时解决问题，scrum的确能快速地响应变化，但这样真的没问题吗？我们遇到了两次这样的冲突，“你当初就是这么设计的，是你让我这么开发的”，“我绝对没有这样设计，我当时的意思是……”，“你做的根本不能满足需求”，“需求就是这么说的”。好吧，需求，设计，开发之间地扯皮，推卸责任开始了。

        面对这种情况，scrum master该如何处理？我继续翻阅相关资料，发现我们犯了一个致命地错误，scrum并不是不提倡写文档，而是不提倡冗杂过度地写文档。回想起领导L说的那句话，“我感觉，你们有用敏捷开发当挡箭牌，拒绝写文档的味道”（大概是这么个意思吧，懒得再查阅email了），现在看来，当时刚接触scrum，如获至宝，感觉终于可以摆脱文档了，一激动，就理解片面了。 发现问题后，我们决定采用wiki工具（后面会单独写篇博客，谈谈敏捷开发的工具）对文档等进行管理，对需求（用户故事）等核心文档进行逐步完善，使变化可追溯，不至于出现需求，设计，开发互相互相扯皮的情况，少了很多争吵，说好听点，让项目组更和谐了。

------------------------------------------------------------------------------------------------------------------

查阅scrum资料的时候，发现了一些大牛博客中说得很有道理，列在下面，供大家参考：

        大型项目尤其是系统工程级别的项目，比如军工、航空类项目，设计的工作量很大，原因是这种投入毕竟是可控的；而一旦由于设计工作不充分，导致严重的返工，则往往不是简单的费用问题，还往往造成项目被终止。因而在这类项目中推广敏捷，应该适当增加文档的数量，以便长期项目能够按计划完成。在互联网、消费电子行业则正好相反，返工主要是由于业务变化而不是错误或不足的设计引起的；相反过度设计往往在未被付诸实现之前就已经过时，反而形成浪费。因此在这类项目中推广敏捷，应当适当降低文档的数量，以便在业务变化时轻装上阵，而不需要同步修改大量设计文档。

        应当理解敏捷开发的出发点不是不写文档只写代码，而是减少浪费，以便能按照自己项目的特点，灵活选择文档的数量及其形式，

在过度设计和返工之间找到平衡。                              --------------摘自火星人，陈勇http://blog.csdn.net/cheny_com

        忽视文档的另一大原因，是将敏捷思想中的“可工作的软件重于面面俱道的文档”理解为“软件开发可以不写文档” （ 敏捷宣言中用的是“ 面面俱道的文档 ”，而不是“言简意 赅 的 文档 ” ） 。相信不少团队正是将这一敏捷思想当作不写文档的“挡箭牌”。

                                                                                    ------------李云 http://blog.csdn.net/hzliyun/article/details/7880217

------------------------------------------------------------------------------------------------------------------

        回头最初领导L要求的wbs，甘特图，其实他的初衷并不是让我们写繁杂地文档，只是让我们有个全局观，分清任务地轻重缓急，有个整体的计划，有计划总比没计划要好。直到后来，因为项目之初没有把系统接口放在网络图的关键路径上，导致后续开发延误，我才真正意识到领导L当时的苦衷，其实领导L要求的文档，在scrum上就是一个具有优先级的backlog，而当时我们并没有对此足够重视，我们的backlog不断更改，也给我们的工作造成了不少麻烦，感触很深，如果能 找到一个既有非常熟悉需求、又有资格和权力设置Story优先级的产品负责人，真的不容易。在我们项目组是采用几个人一起扮演产品负责人的角色。

        写不写文档？答案已经很明了了，文档要写，根据项目特点有所取舍。

        我有一个没有实践的想法，如果在项目团队中增加一个专职的文案，这个文案必须懂技术，虽然增加了沟通成本，会不会进一步减少团队成员的文档负担，提高效率？不成熟的想法，有待以后实践。