2017-11-24 11:15:19 kic18 阅读数 1389
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

敏捷开发中文档的取舍

 先说需求文档,分为两部分,一方面是框架性的需求文档,对功能、交互方式、出错或边界情况的表现进行总体描述,这种文档不需要过于细致,因为产品经理组织语言写文档,开发读文档,理解文档都要消耗大量时间,最好是以总体概括的方式来做,开发在做需求设计时候与产品人员进行频繁密切沟通,最终一起形成完整文档,这中间开发、测试人员对于文档严谨性是有很大贡献,不必要求产品经理全部把边界细节都写出来。另外一方面,作为良好的协作习惯,任何沟通产生的结论都应该存档!邮件是一种比较好的形式。每次会议结束,问一句结论呢?谁出纪要?不是说文档不重要,而是通过见面沟通,把需要文档描述很细节的内容达成共识。概要设计详细设计,视需求逻辑难易,规模大小而定。逻辑复杂的项目,概要设计作为帮助开发理解需求的一种手段。大型项目,详细设计架构设计不可避免。一句话规模的需求,随便做做就算了。这其中都要不断的当面沟通!  

文档的功能

追本溯源,我们应该先问的是“为什么要文档?”,我相信答案应该是“为了沟通”。关于沟通,有一个图表,大家应该知道:“沟通渠道丰富度和沟通成效的关系”

沟通

 图上的虚实两条曲线,大家只需要关心上下两个端点即可:最左下角“Paper”,也即基于纸面阅读的单向交流,是沟通效果最差的;而右上角“面对面交流”,则是效果最佳的。
基本上也是因为这个原因,在[敏捷宣言](http://agilemanifesto.org/iso/zhchs/principles.html)遵循的原则中明确说到:“不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。”

关于敏捷文档,敏捷大师 Scott Ambler 有一篇著名的文章详细探讨了这个话题:

Agile/Lean Documentation: Strategies for Agile Software Development

敏捷开发是不是不用写需求分析、概要设计、详细设计之类的文档了啊?
概要设计文档、详细设计文档是源自传统软件工程的说法。  
如今传统的 Word、PDF 版的详细设计文档通常可以省略,大部分这类文档可以结合代码注释用工具自动生成,Web/HTML 版的详细设计/代码参考文档才是更好的做法。在敏捷开发中,需求文档、概要设计(改成架构设计)文档通常是不能省略的。
2011-03-29 17:55:00 cheny_com 阅读数 2625
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

最近被两次问到同一个问题:如果一个软件需要大量密集的设计工作,导致存在独立的设计和开发团队,应如何实施敏捷开发?

整体上讲,敏捷开发不希望存在设计和开发的分离,因为这样就会产生“设计文档”这种东西,而且因为两个团队分离,设计文档一定相当详尽,而且在交接的时候多半要进行评审,否则很难保证开发团队能理解并按其编写代码,最终还可能会导致两个团队的矛盾。

在敏捷开发中一般这样处理这种情况:将设计人员下放到开发团队中,由于他们一般技术水平高于开发人员,所以可以作为139团队的骨干(请参考“139团队”相关的博文),一方面继续自己的设计工作,另一方面带领自己的小组进行开发。由于两者关系拉近,设计文档即使不能被取消,也不会需要编写得过于详尽,尤其可以忽略那些“没有就开发不出来产品,而产品开发出来后就没用了”的内容。此外设计人员的高水平也会在日常工作中带动开发人员的设计意识,达到“设计人员在设计的同时考虑到如何开发,开发人员在开发的同时理解为何如此设计”的水乳交融的状态。

对于真的需要多个人碰头才能完成的架构设计工作,则需要这几个负责设计的人员共同完成(就是139中的13人员)。这里顺便说另外一个刚刚被问到的问题:倘若敏捷团队是一个新建的项目人员还在扩张,应如何计划人力资源?答案是应该优先选择和招募骨干人员,让他们先把需求分析/架构设计这些困难的工作做起来(在Sprint0里边打基础,之后每个Sprint完善),之后在迭代中逐步吸纳初级人员,做过游戏开发的一定对这个过程不陌生。

另一个相关的问题是:不要把一堆新手凑一个开发团队来独自做低级编码工作。这个喜欢玩球类运动的人一定知道:如果团队中没有高手带着,大家的水平并不会因为工作经验积累而有实质性的提升,相反引入若干高手指导其工作,才是让团队尽快成长的良策。这一点也支持将设计与编码团队合并的方案。

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2013-03-28 10:23:57 zhouyong0 阅读数 2415
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师
传统的软件开发过程,总要按需求分析,可行性分析,概要设计,详细设计,测试,维护
的软件周期来进行,随着敏捷开发方法和敏捷开发工具和技巧的发展,软件过程中的
一些步骤被新的开发颠覆甚至忽略。
模块耦合度低的项目,开发人员往往在概要设计、项目结构建立之后,就拿着需求文档在做各自的子模块,
需要程序依赖和数据依赖不大,但是总体没有详细设计,这样的开发,表面上看来是比较快,开发周期短,
代码一旦提交到测试环节,项目测试人员和项目经理就会发现,测试周期比计划中要长,长得多。
在集成测试中,模块之间会出现数据同步性和完整性问题,引发的程序错误,这是必然的。
不管你需求分析文档再怎样准确和完整详细,由于开发人员的水平不同,相同的需求,在不同人的手里,会有截然不同的实现,
采用敏捷开发方法的开发,为了达到敏捷的目的,可采用两种方法
第一种:设计人员应完成概要设计之后,把需求
分给开发人员,让其完成详细设计,最后提交 类图,状态图,及IPO到设计人员,这个方法要求开发人员水平相对要高,有开
发经验,设计人员在审核过程中可以开发人员交流使设计趋向完整并具全局性,适合模块较多的大项目,
第二种方法:设计人员提交比详细设计简单的‘简明设计’,主要着重于比较复杂的详细算法,全局的业务管理,合法输入,预期输出,
其它实现细节将被忽略,由开发人员自己完成。
敏捷开发,在设计和实现上占用的时间,将是个矛盾,合理处理这个矛盾,将决定项目的成功与否,
对于本人设想的开发方法,您如果有什么意见和想法,请您给我留言
2017-04-18 20:27:23 huver2007 阅读数 437
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

写不写文档?

敏捷宣言更强调“可以工作的软件胜过面面俱到的文档”,但并不是说不需要文档。敏捷的目的是尽量减少浪费,所以采取了极端的逻辑,把所有的文档都视为浪费。但并不意味着文档可以被完全抛弃掉。文档对于团队信息传递来说是很有用的(特别是扩展规模时,或者团队不稳定时)。

要理解敏捷开发的出发点不是不写文档只写代码,而是减少浪费,以便能按照自己项目的特点,灵活选择文档的数量,在过度设计返工之间找到平衡。过度设计返工是造成浪费的主因,不同类型项目中两者比重不同。

大型项目尤其是系统工程级别的项目,比如军工、航空、大型通信设备项目,设计的工作量很大,原因是这种投入毕竟是可控的;而一旦由于设计不充分,导致严重的返工,则往往不是简单的费用问题,可能造成项目被终止。

因而在这类项目推广敏捷,应该适当增加文档的数量,以便长期项目能够按计划完成。

在互联网、消费电子行业则正好相反,返工主要是由于业务变化而不是错误或不足的设计引起的;相反过度设计往往在未被付诸实现之前就已经过时,反而形成浪费。

因此在此类项目推广敏捷,应当适当降低文档的数量,以便在业务变化时轻装上阵,而不需要同步修改大量设计文档。但也并非完全不需要,可以根据项目过程定义裁剪。

2011-11-01 17:32:32 cheny_com 阅读数 8222
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

这是敏捷开发智慧敏捷的第二篇。(之一之二之三之四之五之六

 

缘起

“我们产品已经做完了,客户说要补上需求文档,可我们只有用户故事,这个文档应不应该写呢?”

“没有这个文档,客户能验收吗?”

“不能,客户要开课题评审会,这个是评审会材料之一。”

这个文档要不要写呢?写,为什么?不写,为什么?写怎么写?不写,怎么不写?

为什么敏捷不写文档?

先把话说绝点,敏捷就是不写文档。那为什么不写文档?

为了减少浪费。

敏捷认为所有中间产品,需求,计划,设计,测试用例……都缺少客户价值,客户最想要的价值,无疑是最后的可运行的软件。因此所有中间文档都应该省略省略再省略,直到不写。

不在对客户没有价值的东西上面浪费时间,这是敏捷不写文档的真实含义。

只是从实践上看,最浪费时间的无疑是那些无用的文档。但倘若文档是有用的,而且甚至是客户价值的重要部分,一切就变了。

怎样写这个需求文档?

就这个文档而言,它是为了验收所用,和开发没有关系(已经开发完了),和日后维护没有关系。

那怎么写?这个问题就不回答了,当然是按验收的写法写。

所以,所有文档的所有写法,在每个企业都不相同,不应该问“敏捷开发应该怎样写XX文档?”,而是应该问“应该怎样写上面那个文档?”,而若能这样发问,答案已经明确了。

“写不写文档”的常见做法

常见的文档虽然很多,但下面几个维度几乎永远存在,具体某个文档通过几个维度的分析,处理方法各不相同:

信息长期/短期有效的文档

    长期有效比如竞争对手分析文档,架构设计文档,需求管理文档(用户故事),产品路线图……

    长期文档适合详细描述,用语应完整(就是写Word那种写法),甚至可以动用图形和建模工具。

    短期有效比如评审发现的问题,PO在计划会上讲解的内容等。

    短期文档适合粗略描述,典型的就是用纸或Word凌乱地写一些关键内容,无需长期保存,月末一般就无用了。

不可/可被”可运行软件“替代的文档

    上面举例的文档中,竞争对手、架构设计、用户故事、路线图都无法从代码中看出来,适合文档化。此外,一些科学计算的公式、复杂的设计也属于此列。

    而界面设计、数据库表结构设计、流程图、伪码等,一旦软件做好了,更容易在可运行软件中看出,就不要着大量笔墨于此。

    若感觉后者处于”没有就做不出软件,但做出软件又没用了“的尴尬境地时,应采用轻量级设计

 

敏捷的文档

阅读数 90

敏捷开发

阅读数 53

没有更多推荐了,返回首页