老师，在线吗?
青润 15:02:40
在。
北京-FireSpider 男 15:03:33
老师，敏捷开发的需求过程好像和常规的需求过程不太一样！？
青润 15:03:50
没有什么不一样的，敏捷开发也只是一种开发过程形式。
需求也有各种不同的采集形式，不能认为你所熟悉的就是常规需求过程，实际上需求的获取本身就是多种多样的。
北京-FireSpider 男 15:05:32
敏捷的用户故事，从表述上来看，更像是用户零散提出来的需求，不具有整体型，无法做整体的需求分析。
青润 15:06:00
其实，实际的项目中的需求，用户也是零散提出来的，不要太关注形式，要关注需求内在的联系。
北京-FireSpider 男 15:06:09
哦
青润 15:07:14
只不过就在于用户是否坐在一起给你提出需求而已。
敏捷只是把这种提出需求的形式更灵活化了。
实际上在十多年前我做的电信mss系统调研中，我们也是分成两个组分别在集团公司和各省公司进行需求调研采集，在集团公司这边，我也是一个一个用户进行询问，经过多次往复确认的过程采集下来的。
北京-FireSpider 男 15:07:12
需求的这一系列过程，在敏捷开发中也是一样的做法？
青润 15:08:11
从一个一个用户存在和出现的随机性上可以看到，这其实也是零散的，在外表上并不是系统化的，唯一可以控制的系统化需求的表现在内在，也就是说，所有的需求都是与你调研的业务相关的，而无关的业务都会被你所忽视或者放弃。
每一个单独的需求的全过程看起来，也都是一样的做法，最多是顺序有些不同。
北京-FireSpider 男 15:08:52
哦，是这样。
青润 15:09:02
当你到了元用例层面进行需求处理和开发的时候，就会发现，其实都是一样的。
北京-FireSpider 男 15:09:34
我没执行过敏捷开发，在开发之前的需求阶段通常是一次性获取需求，然后如果用户有变化的化，再做需求变更。
青润 15:09:52
而很多只懂得追逐潮流和本本主义者往往强调其个性，而忽视其内在的联系和本质。
所以，很多所谓极端的敏捷开发者，刻意强调自己的特立独行和与众不同，实际上是很荒谬的做法和言论。
北京-FireSpider 男 15:09:56
但开发的过程，通常是类似敏捷的。
嗯，确实是。
青润 15:11:18
一次性获取需求在新的用户环境下往往不大可能。
注意拆分出来，注意条理性，注意分阶段的获取，注意用户深层次需求的挖掘，这些往往比一次性获取需求可以得到更完善的需求信息。
而一次性获取的时候，用户因为个人原因或者某些因素会遗忘一些需求的细节，或者描述不清楚一些内容，开发者也会因为自己的想象去假设一些需求的内容和细节，于是就会造成需求的实现与用户所需之间的差异。
结果，系统后期的变更就会非常多。
系统开发的延期就不可避免了。
北京-FireSpider 男 15:11:58
是的，通常系统在开发出来之后，会发生很多需求变更，导致软件出现较大的重构。
这个时候是最痛苦的，毕竟软件已经做了，再改动，很困难的。
青润 15:12:30
实际上系统中后期的变更也都是需求的再次调研和采集过程，而很多项目的乙方为了让甲方不会因此感觉到自己的系统开发能力不足，就用各种借口来遮掩这样的问题出现，实际上结果就是欲盖弥彰，却又不得不如此。
北京-FireSpider 男 15:12:45
将变化尽量控制在前期，我觉得搞系统原型是最好的办法。
是的，系统做得死，是无力应付变化的根本原因。
北京-FireSpider 男 15:13:50
系统能够较容易应付变化，系统就得要做得更加灵活，这确实需要在平台层面下功夫。
青润 15:14:03
只能说把可以找寻到的变化尽量控制在前期，另外在开发过程中随时准备应对变化。
这个不仅仅在xp，在up和其他过程中也都有介绍。
北京-FireSpider 男 15:19:45
老师，如何控制需求范围？有的时候，客户漫天瞎提需求。
青润 15:20:42
关于控制需求的问题在我曾经的培训中提到过几种方法。
1、关系处理
2、技术影响
3、用户信任
4、实际讨论
5、明确责任
青润 15:21:42
大体上这几个方面，不一定完善。
总之，我一般是在用户那里树立很好的技术形象，用户对我的信任，我提出对需求的异议的时候，用户会非常相信认同，并配合我进行相应的风险处理和思考解决方法。
青润 15:23:03
如果你做不到，那往往是被用户牵引着到处走，因为你无法让用户信任你。
那就是用户说什么你做什么了。
北京-FireSpider 男 15:24:23
是的，和客户的关系得处，处好了，怎么都好说，处不好，很难开展工作。
我还记得02年在搞大兴安岭资源局的项目，那个项目我们在需求上犯了很多错误。
青润 15:25:08
不是单纯处得好，而是要让用户对你这个人或者对负责技术沟通的人的技术和经验的信任。
北京-FireSpider 男 15:27:43
1、为对客户业务进行仔细深入的研究，两周的调研，仅仅是拿回来一大堆单据（这个我没参与，我是之后到这个公司的）和一份简单的科室业务与单据的关系描述。开发人员面对一堆单据和描述文档，无从下手，只是推着做，做到哪儿算到哪儿。结果哪给客户一看，全盘否定，没有几个是他们要的。
得出结论：需求阶段没有调研到客户真正想要的东西。
倒是拿来一大堆垃圾需求。
青润 15:30:13
嗯。这种现象很常见。
北京-FireSpider 男 15:30:16
2、客户一看这样不行，要求我们现场开发，我们到业务科室，一边看着他们工作一边开发。但是每个科室都“只见树木，不见森林”，到科室间数据交互时，再次遇到问题。
青润 15:30:30
需求人员其实不懂得什么是需求，也不懂得如何进行需求提取，于是就只能拿回来很多东西。
北京-FireSpider 男 15:31:53
09年我到这个公司，好很多，因为这个公司在石油石化行业打拼很多年了，行业基础好，需求调研人员很专业，这种问题很少出了。
但是需求人员也重来没有用UML建模，更很少搞界面原型。
青润 15:32:38
嗯。
北京-FireSpider 男 15:33:02
所以也会有些问题，不过很少。这可能主要是靠公司的积累对客户需求的覆盖和引导，以及需求调研人员的经验。
可以说，直到目前，包括我本人在内，也从未用UML真正做过需求调研。不过我在用UML，但是只是用于自己整理思路。
青润 15:34:26
用好了uml是不错的，但是很多往往用不好，其实，哪怕只能部分用好也能对需求起到很好的引导作用。
北京-FireSpider 男 15:34:30
嗯
UML是好东西，不过我用的也是前期引导思路，后期上了编码，就是编码引导思路了。
青润 15:35:12
我的书中有例子，2002年电信mss系统的初始UML需求是何等的混乱，那张uml图业内很多朋友看过后都很震惊。
我过去处理后的分层结构图一下子一切都明晰了。
北京-FireSpider 男 15:35:29
哦，有一张图，很大的，是吧？
在42页。
北京-FireSpider 男 15:38:41
老师，我觉得UML可能就像我说得作法比较现实：用于前期引导思路、后期重构时的思路梳理。真正开发起来，还是得靠代码去引导思路。
安全提示：如果聊天中有涉及财产的操作，请一定先核实好友身份。发送验证问题或点击举报
青润 15:38:49
我忘记在哪一页了，那张图还是删掉了十多个用例后的，否则根本摆不下。
实际上，从设计引导代码，会是最好的解决办法。
程序员习惯于从代码思考，往往取之片面，容易形成精巧的小业务系统，却无法处理大而复杂的综合性系统。
青润 15:40:20
uml给了一种更好的从整体视角到局部视角的系统设计视角，让我们可以从设计着眼，而不是从代码层向上看。
北京-FireSpider 男 15:40:32
北京-FireSpider 男 15:41:59
这是一个手持终端通讯台的前期设计，我用UML梳理思路，等到编码开始后，我就再也没有更新这个图。因为，代码可以引导思路了。
青润 15:42:26
呵呵，如果你能从设计引导思路，那时候，你会看到另一片更好的天地。
北京-FireSpider 男 15:43:07
但，我不清楚，如果这个设计给别人用，会事什么样子。因为我发现底下人搞开发，你得给他指得非常明白才行。所以这种粗略的设计，他们恐怕无法去做。
青润 15:44:29
你把我书中设计到代码的章节都看懂了，应该能明白。
北京-FireSpider 男 15:45:06
嗯，我正在细看，也是一边看，一边用UML的方式把书中的内容量化出来。
北京-FireSpider 男 15:46:34
这是我做的量化，呵呵。
青润 15:46:43
我用了9年的时间写的东西，里面没有垃圾和任何无用的信息，不要疏漏任何一点。
如果为了赚钱，我就不会用9年来写一本书了，也不会写得这么薄，随便扔点java基础和uml基础，都可以翻一倍以上的容量。
呵呵，没事，任何尝试都是有价值的，我不怕别人做得更好。
北京-FireSpider 男 15:47:45
嗯，老师，您的书确实是经验的积累，很实用。现在很多计算机书籍跟实践脱轨，导致无法应用的，不在少数。真正体现出实用价值的确实很少。
北京-FireSpider 男 15:49:12
多谢老师耐心指点。
Normal 0 false 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE转载于:http://blog.itpub.net/257598/viewspace-749963/
4404
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
