2016 年 8 月 4 日

敏捷开发实践(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优先级的产品负责人,真的不容易。在我们项目组是采用几个人一起扮演产品负责人的角色。
        写不写文档?答案已经很明了了,文档要写,根据项目特点有所取舍。
        我有一个没有实践的想法,如果在项目团队中增加一个专职的文案,这个文案必须懂技术,虽然增加了沟通成本,会不会进一步减少团队成员的文档负担,提高效率?不成熟的想法,有待以后实践。

最新文章

  1. 网站改版要注意什么事项
  2. 自助建站怎么样?需要考虑哪些方面?
  3. 企业建站用什么CMS建站系统会更好 三大系统优缺点对比
  4. 开源CMS系统哪个比较好 如何选择
  5. 企业外贸网站制作的要求及注意事项
  6. 如何做好网站建设方案的制定 这些一定要懂
  7. 怎样知道一个网站是否需要重新设计
  8. 好的网页设计需要注意什么事项
  9. 网站改版不可忽略的重要原则
  10. 免费有效的网站推广方法有哪些

最新案例