思步网

查看: 108230|回复: 52
打印 上一主题 下一主题

[活动体会] 思步每月微话题“敏捷开发写不写文档”总结

  [复制链接]
摘要:敏捷认为诸如需求文档、设计文档、测试用例……都缺少客户最终价值,可以将这些中间文档略写或者不写。但这样一来,导致一些重要的文档被“敏捷”掉了,给产品后续的开发与维护带来很多的障碍。到底该不该写文档呢?


一、正方观点:需要写。(以下为摘录的部分观点)
        1:现在是敏捷了,可给后来人带来了很多痛苦,有些文档还是要写下,比如需求。
        2:写文档不是目标,而是依据过程规程来写,要写能体现价值的文档。
        3:从项目的延续性好的可维护性来看,文档必须的,只是写得清晰程度的把握而已,也要结合项目组人员的能力来把握详细程度和表达的方式。
        4:有些记录还是要的,不然后面维护起来很麻烦。
        5:曾经听大牛说过,敏捷只是把好用的东西无限放大,因此是否需要文档要看这个团队对于文档的使用是否对团队有利,如果有利也要加以放大。
        6:敏捷宣言说“……工作的软件高于详尽的文档……尽管右项有其价值, 我们更重视左项的价值。”,够用就行的文档还是需要的。当然,形式和载体不强求,Team能沟通就行。
        7:我提倡文档应该是少而精,不是没有 ,比如游戏开发协议,游戏策划的大纲,美术需求,整体架构的设计和功能模块的划分……但是我现在依然不知道如何在游戏开发中使用敏捷,只能眼看着好些人苦逼加班且效率低下,哭。
        8:肯定要写,再敏捷也需要文档的记录,特别是一些关键的文档。一家之言哈。
        9:需要写,文档一定要“够用”,不一定是“大而全”。所有的软件、产品的研发都会转入投入使用后的维护,这时“够用”的文档是非常重要的。
        10:敏捷和文档并不冲突,而且文档在敏捷中的重要性是更高的,快速迭代没有文档保证,几个迭代之后就会忘记掉最初的东西而陷入僵局。
        11:我觉得敏捷的核心实现是主动、灵活的应对变化,不是一味的省略和裁剪,应该根据需要编制相应的文档,原本写在不同类型的文档中的内容可以适当的进行归类合并,减少文档的数量,但是不能没有,否则前面的流程是敏捷了,后续的维护将是一个极度痛苦的过程。
        12:个人觉得敏捷写不写文档已经成为一个做不做敏捷必考虑的一个问题了。现在看到很多公司都在试行所谓的”敏捷“,且不论形式或者结果怎么样,但是绝大部分是没有文档输出的,没有文档成了敏捷的标志。个人觉得文档这回事有几种情况下还是需要的,一个就是对于一些例如政府部门的客户,在签订的合同里面可能已经规定了验收的时候必须提供哪些文档,这个时候,我觉得还是需要提供的,因为合同里面已经有规定了,你不能说自己是敏捷开发就不提供文档,毕竟客户不管你是CMMI还是敏捷的。还有个就是对于开发的人来说当然敏捷使他们更高兴了,觉得自己都在做自己关注的事情,没有花费时间写文档之类的,但是对于维护人员呢?这个维护人员不仅仅是客户方的,还是公司内部的,我们知道每个项目都有一定的保质期,1年到5年不等,如果没有文档,只是一个backlog和一套源码给维护人员,就足够了吗?肯定是有一定问题的吧。所以个人认为有些必要的文档或者记录还是需要的,这和是不是执行敏捷不是一回事,也不是执行敏捷的理由。
        13:从项目的延续性好的可维护性来看,文档必须的,只是写得清晰程度的把握而已,也要结合项目组人员的能力来把握详细程度和表达的方式。
        14:写文档不是目标,而是依据过程规程来写,要写能体现价值的文档。
        15:不要拿敏捷做为不写文档的借口,我认为应该是少文档,或者说找到了更好的方式替代文档,但并非不写文档啊。
        16:肯定要写,再敏捷也需要文档的记录,特别是一些关键的文档。一家之言哈。
        17: 需要写,文档一定要“够用”,不一定是“大而全”。所有的软件、产品的研发都会转入投入使用后的维护,这时“够用”的文档是非常重要的。
        18:有些记录必须要有,再敏捷也需要有文档的,老话说:“好记忆不如烂笔头”,就是这个道理。
        19: 需要写,特别是一些关键的文档,不写文档不是实施敏捷的理由。
        20:是否需要写文档以及写多少文档是根据项目目标来的,敏捷并没说文档不重要。我们刚开始实施敏捷,新员工多,研发能力不足,就得老实写文档。
        21:敏捷和文档并不冲突,而且文档在敏捷中的重要性是更高的,快速迭代没有文档保证,几个迭代之后就会忘记掉最初的东西而陷入僵局。

二、反方观点:不需要写。(以下为摘录的部分观点)
        1:可以不局限于文档,统一使用软件管理story和case等等,达到1准确记录 2控制变更 的目的就可以。
        2:文档有时候真没必要,花了很长时间写出来的东西根本没用,如果仅仅是为了交差,那还是不写了吧。写了这么多文档,回过头来看,没有一个是起作用的。
        3:从历史经验来看,确实不需要写。以前瀑布的时候,写了一堆没用的,后面的各种模型也是,特别是CMMI之后,文档就是拦路虎,纯粹是应付。代码注释写清楚,完全不用文档。
        4:做敏捷的至少都要有两把刷子,所以,这些人具备不写文档就能搞定的技能,那怕是几年后的产品维护。



上一篇:第二届中国项目管理办公室(PMO)发展大会将于6月7-8日在京召开
下一篇:从《项目管理知识体系指南(PMBOK)》改版看项目管理的最新趋势

火花官方【VIP2企业演示站】

所属行业:其他组织
会员折扣:8折  
品牌等级:
在线客服:点此给我发消息
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 支持支持 反对反对
回复 论坛版权

使用道具 举报

有料,收藏了。
个人的观点,关键性文档还是的,比如需求、设计类的,不一定要十分附件,简单易懂就行。
不能到现场真是遗憾。
好活动,下次一定要参加。
好活动,下次一定要参加。
想参加,不知道什么时候还有。
下次有相关活动时再说一下哦~
看起来不错
我了个去,顶了
这个一定得回复!
不能到现场真是遗憾。
果断MARK,前十有我必火!
支持,赞一个
看帖看完了至少要顶一下哦~
您需要登录后才可以回帖 登录 | 注册

本版积分规则

思步组织思步科技|思步网|火花学堂|思步文库|思步问答|思步英才|天下心
© 2007 思步网 浙ICP备10212573号-4(首次备案号:浙ICP备07035264号)|邮箱:service#step365.com(将#换成@)|服务热线:0571-28827450
在线培训课程|求职招聘|思步文库|官方微信|手机APP|思步问答|微博平台|官方QQ群|交流论坛|软件工程透析|关于我们|申请友链|
点击这里给我发消息     点击这里给我发消息
思步 step365 过程改进 CMMI中文 质量保证 质量管理 流程体系 需求跟踪矩阵 敏捷开发 Scrum 软件度量 项目评审 全员改进 流程管理 人力资源 6sigma 信息安全 ISO27001认证 IT服务管理 ISO20000认证 ISO9000认证 软件测试 SQA 配置管理 IPD 软件工程 PMP认证 PMP试题 PMBOK中文 精益研发 agile 顾问式管理培训
返回顶部