思步网

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

[Scrum] 敏捷开发生态系统系列之一:序言及需求管理生态(客户价值导向-可工作软件-响应变化)

  [复制链接]
本帖最后由 北大浪子 于 2014-9-11 11:39 编辑

所谓生态系统,就是指互相依赖方能生存的一系列生物。生态系统常常不是单向依赖的,而是互相依赖互相促进。

敏捷开发中的实践也是如此。典型地,当一个实践很难实施时,一定不要认为简单的制度可以保证其实施,而是要思考是什么导致了它的失败。比如每日立会,如果发现大家都不按时开会甚至不开会,马上要做的不是要求大家按时开会+开会迟到给大家买水果+统计每月按时比例+……而是要想一想为什么这些人不按时来,他们一定觉得这个会议不是很重要,会上讲的东西听的东西不能帮助自己的工作,反而耽误时间。进而就能发现会议开不好的根本问题。


敏捷开发中需求管理生态大致如下(请配合插图,黑体字即插图中的元素):



客户价值导向敏捷开发需求管理的主要思想。

敏捷开发相信密切与客户协作比编写详尽的文档更能弄清楚客户的需求;而利用阶段性的可工作软件外加邀请客户参与评审会,比让客户评审需求文档更容易让客户正确地补充需求和验收产品。

☺ 由于相信变化后的软件一定比变化前的对客户更有价值,所以敏捷崇尚响应变化。提供可工作产品来引导客户变化,可保证客户更能正确翔实地描述变化;而迭代交付则使得重要的、必要的变化可以提前交付,而不是像瀑布模型一样最后才发生。

☺ 通过需求优先级排序和迭代交付,首先可保证重要的需求一定可以交付到客户手中;其次可以保证重要的变更来临时,可以放弃尚未开发的次要需求作为交换;再次可以保证产品负责人(PO)会优先分析重要的需求,不会让它们在模糊状态进入开发。

☺ 只有最高优先级的需求才会进入下一迭代,因此很少有变更比它们更重要,而且这些需求也被较深入地分析过,产品负责人就有信心承诺迭代期内无变更,以换取团队承诺,进而保持交付以可持续的步调发生。

拥抱变化是一种由客户协作、优先级排序、可工作软件等各种实践支撑下的、主动的可控过程,而不是被动地“被变化拥抱”,“迭代期内无变更”和“拥抱变化”的对立统一,必须建立在这些实践的基础上。

客户价值导向-可工作软件-响应变化这三条是需求管理生态的核心内容。下面从一个问题的分析来看需求管理生态的工作原理。


“为何客户在评审会上不置可否,只说让我们继续开发一些功能后再说?”

这是一种很常见的场景,简单粗暴的处理方法包括:

1. 若评审会上没有意见,就表明认可了功能。

2. 评审会结束后必须书面验收已经完成的功能。

3. ……

不过这些仅仅是粗暴地执行Scrum的实践,而没有获得Scrum的精神。

仔细分析一下,客户这样做的原因很多,其中一些我们不容易控制,另外一些则相反:

1. 客户送来的代表是个“小角色”,无法替客户决策。

2. 我们的软件在客户眼中不是一个“可工作的”软件,因此他不能或不想太早下结论。

3. ……

针对1这类“不可控”问题,在实际环境中其实都有各种解决方法,只是作用大小而已。比如将每次的评审功能抄送给对方的负责人以引起重视;让功能的最终使用者参与评审等等,具体情况具体分析,这里就不多说了。

针对2这类“可控”问题,可做的就很多了。

什么是可工作软件?在研发人员眼中,可工作软件很容易等同于可运行的软件,“它能跑在我们的测试服务器上,我们还有自动化脚本能自动运行和测试其功能……”但在客户和用户眼中,可工作软件是那种他们现在就可以拿回去用的软件。比如一个Word软件,如果能编辑但是不能分段;能插入标题但是字体一样大;能插入图片但暂时只是一个链接需要双击才能打开……这三样功能都是至关重要的功能,但把它们临时凑在一起的软件,并不能让用户真正使用起来。还不如做一个“暂时只能编辑,不过可以分段、缩进,适合写简单的无复杂格式的文本,比如私人邮件(现在Outlook中还有个选项是用Word编辑邮件)”,看到这样一个软件,尽管客户不会接受这就是他们最终得到的产品,但是却可以理解在这样的场景中,这个软件到底好不好用,如果要改进改进哪里等等。

或许为了制造这个软件,我们一定程度上打破了优先级排序(“插入标题”比“缩进”要来得重要),但却使得“可交付”和“客户评审”成为现实。其实从这个角度看,我们反而在以客户价值驱动的方式生产着软件,也就是说“可运行软件”要从“客户价值驱动”的角度来定义

好了,要解决这个问题答案就出来了:我们多半会把Product Backlog划分为若干故事群,每个故事群大致可以完整交付;我们提前让客户参与制定故事群开发的排序工作,这样客户就知道什么时候将发布什么功能,以及自己来评审什么功能;在完整地看到一组功能后,客户更容易得出“这一切是否可行”的结论;如果他们愿意,还可以提前部署上试用一下……


个人感觉在应用敏捷实践时,虽然不能迷信其普适性,但也千万别在遇到挫折的时候马上否定,或将问题归结为文化和公司环境;作为开发和管理人员,我们极有可能少或多做了什么事情。


转自陈勇的博客




上一篇:硝烟中的Scrum和XP(简体中文版)
下一篇:敏捷开发生态系统系列之二:敏捷生态系统-计划跟踪 I(跨职能团队-共同估算-每日立...
[发帖际遇]: 浪子行 在网吧通宵,花了 9 (金) 金币. 幸运榜 / 衰神榜
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 支持支持 反对反对
回复 论坛版权

使用道具 举报

很有借鉴意义,先收藏了,谢谢楼主。
[发帖际遇]: sunny 在网吧通宵,花了 1 (金) 金币. 幸运榜 / 衰神榜
学习下我只是路过,不发表意见……
看起来不错
支持,赞一个
看起来不错
我了个去,顶了
还不错哦,如果再能多分享一些就perfect了!
有空一起交流一下。
以我的经验来看,楼主的想法是可以执行的~
以我的经验来看,楼主的想法是可以执行的~
very good.
很有借鉴意义,先收藏了,谢谢楼主。
支持,赞一个
打酱油的人拉,顺便赚点金币
您需要登录后才可以回帖 登录 | 注册

本版积分规则



思步组织思步科技|思步网|火花学堂|思步文库|思步问答|思步英才|天下心
© 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 顾问式管理培训
返回顶部