用设计文档去driven, 这是什么方法学?

Dan.and.Andy

和manager白板，今天，拿个笔记本光忙着做笔记了，他笑着说咱们是讨论，可是到头来是一白板的东西和一头的浆糊，我倒是没怎么说话，我以为自己3天就能写完的程序，确是这么复杂的流程和设计，起点很泛泛，很大，很空，很飘渺，很“云端”的感觉，让人觉得无法实现，又或最后的结果肯定是真实的和实现并不依赖于这些空洞的东西。目的虽然很清晰，manager笑言越长时间的准备和计划，越少时间的写程序，越多的文档时间越知道自己要做什么。可是我一写文字就想睡觉，好困啊。

你们都是怎么开始新项目的？没Agile过，Agile怎么开始？

pinkdreamer

正常的sdlc

yuba

sounds like not agile at all.

pinkdreamer

你们软件开发不是正规的公司吧？

Dan.and.Andy

原帖由 pinkdreamer 于 2011-12-8 19:24 发表
你们软件开发不是正规的公司吧？

正规是什么意思？你指开发产品的？

典

软件产品开发(将被不同的组织使用)
和项目型开发(只限这个企业使用）
是大不同的

内部开发同外部开发又大不同

HISOKA

DDD Document Driven Design

bb33

原帖由 yuba 于 2011-12-8 19:13 发表
sounds like not agile at all.

是waterfall吧
一開始就document好所有requirements

agile就像走一步看一步
不需要document所有的detail requirements,而是做做改改

菜地一块

是否写设计文档跟采用什么开发模式是没有必然关系的，不是说CMM（waterfall）就要写很多文档，Agile就没有文档。
好的设计文档能够指导后续开发和测试活动的开展，增加研发项目成功的机会，同时也能够为后续工作（例如，同一软件的新的版本）打下基础。
其实写代码在一个健康的SDLC里面，占的比重是很少很少的，你如果不从一开始就养成良好的习惯，喜欢一上手就编码，看着是很爽，但后续会陷入越来越混乱的问题中，可能要消耗大量精力去修改一个没有设计好的环节。你的MGR我觉得是非常出色的，你应该还是新手，所以也不了解这些文档的作用，看着就犯困。别气馁，坚持下去，一定会很快成长起来的

dcc82

我记得早些年在大学读书做最后的毕业设计时候，老师也是这样教的，又是写文档，又是画图，说文档全部搞清楚了，剩下的编程实现就能很快了，基本上照文档要求实现，想都不用想，因为都帮你画好了，简单吧？？记的很清楚，带队的人信誓旦旦地说80%时候做文档设计，剩下的20%时间才是编程的，我当时那个惊讶啊～～～原来编程这么廉价。。。
工作多年后，我现在唯一的感受就是被骗了～～

[ 本帖最后由 dcc82 于 2011-12-8 22:24 编辑 ]

pinkdreamer

原帖由 菜地一块 于 2011-12-8 21:52 发表
是否写设计文档跟采用什么开发模式是没有必然关系的，不是说CMM（waterfall）就要写很多文档，Agile就没有文档。
好的设计文档能够指导后续开发和测试活动的开展，增加研发项目成功的机会，同时也能够为后续工作（例如，同一软件的新 ...

同意，这就是我想说的

floodp

我现在早就不做编程了，但是清楚的记得当年毕业设计做程控交换机的程序，文档和流程图老师是先写好的，编程真地很容易。

无视

Document-driven的开发方法是非主流开发方式，它跟agile/scrum很不同，如果说沾边的话，我猜可能是scrum中的PBI中有description && acceptance test, 不过它更倾向于解释性的和test driven的。

agile/scrum适合team的开发方式，一个人怎么做都行，不一定用scrum，只要hand over的时候给他们一个high level的架构和流程图就好了。

kr2000

我做的项目一般文档就是需求文档
设计文档非常少

典

起点很泛泛，很大，很空，很飘渺的时候，
先做BPM, 再复杂的东西，总归能落实到BPM图上，如果没有BPM画图工具，可以直接在Excel上画， 一张BPM的图胜过几十页的文档

至于设计方面的文档，应该不是一次会议就能定下来的，你那个可能算会议记录，
很泛泛很飘渺的时候，做设计文档还早了点

yuba

原帖由 dcc82 于 2011-12-8 22:21 发表
我记得早些年在大学读书做最后的毕业设计时候，老师也是这样教的，又是写文档，又是画图，说文档全部搞清楚了，剩下的编程实现就能很快了，基本上照文档要求实现，想都不用想，因为都帮你画好了，简单吧？？记的很清楚，带队的人信誓旦旦地说80%时候做文档设计，剩下的20%时间才是编程的，我当时那个惊讶啊～～～原来编程这么廉价。。。
工作多年后，我现在唯一的感受就是被骗了～～

同意，这就是我想说的

典

如果是公司内部的三五个人开发的小项目，我们是50%左右的时间开会讨论需求/proposal, 一轮又一轮，
剩下50%的时间做开发

我们设计方面的文档很少，只有项目方面的文档（非技术方面）

设计方面的文档我觉得在以下情况下比较有用
1）项目设计的开发人员比较多，5个以上？
2）有请第三方做开发的时候，需要界定范围，有利于扯皮，推诿责任，但是如果项目不大且甲方不特意要求的话，也可以不写设计文档，直接用需求文档/流程图干活
3）产品型的开发

[ 本帖最后由 典 于 2011-12-9 08:51 编辑 ]

无视

原帖由 典 于 2011-12-9 09:48 发表
如果是公司内部的三五个人开发的小项目，我们是50%左右的时间开会讨论需求/proposal, 一轮又一轮，
剩下50%的时间做开发

我们设计方面的文档很少，只有项目方面的文档（非技术方面）

设计方面的文档我觉得在以下情况下比较有 ...

my guts feeling is you guys might need BA to help out. Dev’s hourly rate is collectively much higher than BA’s

交易人生

这个不像agile，文档很耗时间，1）先找他要requirement 文档，让他列出来需求，不能让他总扯淡。2）你写个design specification，概括性实现方案，然后再找他谈，同意就签字。3）写functional specification，把design spec细化，讲如何具体实现。4）做estimation，根据func spec做计划，看多少人年能够完成，不写不知道，一看吓一跳，100人年，再去找你的manager们，行不行，不行？让他们去该requirement，加加减减，一直到能够match plan。5）finalize 所有文档，都签字。6）要qa team写testing plan 同时你去做 coding.qa会搞test cases.

很耗时间从1-5)不断重复，属于有钱又有闲的公司才搞，不断重复1) -5).

workflow

原帖由 交易人生 于 2011-12-9 10:56 发表
这个不像agile，文档很耗时间，1）先找他要requirement 文档，让他列出来需求，不能让他总扯淡。2）你写个design specification，概括性实现方案，然后再找他谈，同意就签字。3）写functional specification，把design spec细化，讲如何具体 ...

这套流程放到大项目里是非常管用的，我前几年做过一个ACN大概1000多人的项目，时间大部分都在文档和流程上

交易人生

所以公司要有钱，雇佣很多人。和agile比起来，各有千秋。

workflow

原帖由 交易人生 于 2011-12-9 11:27 发表
所以公司要有钱，雇佣很多人。和agile比起来，各有千秋。

嗯，我在这套体系下干了１０年，都被洗脑了，文档必须要签字，不签字就不开工

无视

原帖由 workflow 于 2011-12-9 11:29 发表

嗯，我在这套体系下干了１０年，都被洗脑了，文档必须要签字，不签字就不开工

are there alternatives?

huaxianz

原帖由 dcc82 于 2011-12-8 22:21 发表
我记得早些年在大学读书做最后的毕业设计时候，老师也是这样教的，又是写文档，又是画图，说文档全部搞清楚了，剩下的编程实现就能很快了，基本上照文档要求实现，想都不用想，因为都帮你画好了，简单吧？？记的很清楚，带队的人信誓旦旦地说80%时候做文档设计，剩下的20%时间才是编程的，我当时那个惊讶啊～～～原来编程这么廉价。。。
工作多年后，我现在唯一的感受就是被骗了～～

还有一种说法是，20%的时间在编码，80%的用在测试。

greed

原帖由 dcc82 于 2011-12-8 22:21 发表
我记得早些年在大学读书做最后的毕业设计时候，老师也是这样教的，又是写文档，又是画图，说文档全部搞清楚了，剩下的编程实现就能很快了，基本上照文档要求实现，想都不用想，因为都帮你画好了，简单吧？？记的很清楚，带队的人信誓旦旦地说80%时候做文档设计，剩下的20%时间才是编程的，我当时那个惊讶啊～～～原来编程这么廉价。。。
工作多年后，我现在唯一的感受就是被骗了～～

这个理论没错。只是这是建立在BA很强大，对用户的需求完全把握住，系统设计师对已有和将有系统所有细节都很清楚的而且个人能力比较强的前提下。一个搞不清状况，思路混乱的人写出再多文档也是废纸一堆。往往现实中这样的team是可遇不可求的，所以80/20基本只是停留在理论上。不过不可否认，coding前尽可能的沟通有助于明确需求和时间表，也有利于统一技术方案。此外，文档对今后的系统维护也起着指导性作用，当然前提是文档要及时更新。

典

原帖由 无视 于 2011-12-9 09:39 发表



my guts feeling is you guys might need BA to help out. Dev’s hourly rate is collectively much higher than BA’s

大点的项目才用BA,几个人的小项目我们自己就做BA了，前期的项目范围等，我们经理就能搞定，后期具体的需求会议，我都会参加，BA就在我脑袋里，也是不写需求文档的，会写些BPM， 流程图等，因为是内部开发，所以不担心扯皮，
把握需求是非常关键的，用户的需求是在面上的，需要有比较强的判断力做筛选
有的需求是少数用户的意见，没有代表性，打回去让他们讨论取得共识再说
有的需求是nice to have,没有也不要紧的，hold再说，美其名曰放到下一阶段，实际上后面大家都忘记了
有的需求可以在财务/BI等其它系统里实现，直接推出去。
等等...

yuba

黑白无常

要看什么项目的，比如核电站，军舰都要用formal method来先论证，绝对不可能agile边做边改那样 。

wkp

原帖由 yuba 于 2011-12-15 14:40 发表
494264

这个工具是什么？ 让我脱离原始社会吧