【SBE】由需求管理谈起

简介:

中午有同事提出一个问题,其实我觉得根本不值得一谈。但很多人有争议,在这里简单记录,并阐述一下自己的观点。

先看故事背景:

某TM   类似于http://192.168.100.100:8080/browse/DAEG-1110 这类已经无效的需求,我们是否有必要不放到任何一个版本里面?因为即使关闭了,它也占了一个数,大家怎么看?

某TM    查看的时候,如果不一个个点开,是不知道是否是无效的,无效的需求也混在有效需求里面,虽然也有一个状态表明是无效的,但是多余啊,--这个不就是坑吗?这个才会增加管理难度的

某PM  统计的时候过滤掉就是了

某TM   如果是无效的,为什么还要专门过滤它呢?新建一个Empty版本,无效的移动到那个版本里。

某TM   有些浪费脑力哈,无效的根本就不应该被展示和被关注,应该淡出到考虑范围之外。而不是要时刻提醒自己有一个个的坑。

某PM  无效的及时关闭,还挖啥坑啊。不要增加管理难度嘛

       ……

       存在矛盾和问题。我们回头看看,其实这里讨论的事情,都涉及到了什么:需求管理、项目管理、项目度量、版本管理…

       我给出的看法是:

首先,无效需求也是需求。只不过是在执行过程中才发现和前期预想的不一致,它和Won't fix或者无法重现的bug类似,都是在项目前行过程当中经历过的一些记录;虽然最终的交付并非有效价值,但也包含了一段思考和分析在其中;

其次,无效需求也应当被统计。它是属于某一个版本下的产物,在项目结束时候,项目总结需要进行统计,和初期的项目计划所提需求对应。

然后,Empty版本没什么阶段属性,即使统计也应当基于一定时间一定版本周期内,脱离这两点单独建立Empty版本统计无效需求是没有实际意义的;

再者,从度量的角度,这些存在也是合理的,即使电信项目严谨一些要求 5个9,那么也存在0.00001的瑕疵在其中。发布标准定的一般是实现80%,而无效需求存在于剩下的20%中。

越是创新型的项目,探索的越多,这种无效需求的可能性就越多。如果没有经过失败的尝试,那么就没有最终的正确结果。

所以个人认为,这个问题没有什么争议的必要。

      

现在大家都在倡导敏捷精益,倡导快速迭代,各种Agile、XP、SCRUM、甚至还有“他爹的TDD开发模式”(Test Driven Development),还有“他妈的TMD开发”( Team Meeting Driven),完了有些人连ATTD的全称是什么都不知道就开始大谈ATDD的好处,可见我们的Manager们是多么的浮躁,个个以为考了一个PMP就可以了,随便拍拍马屁,这事就成了?而殊不知,正式如此,才导致了项目逐渐的走向死亡。

一个项目的成功,离不开一行一行写代码和DEBUG的“屌丝码农”,和一次次搭环境尝试各种不同场景下的运行状况的“测试童鞋”们。他们才是支撑项目的最初原动力。当然架构师也功不可没,一个“大脑袋”的视野和高屋建瓴版的精妙设计决定这项目的定位。他们才是最可爱的人。他们才是项目的驱动力来源,而绝对不是整天穿梭于各个会议室拿着喇叭催进度的Managers。

我们不需要不懂技术的PM和TM。因为他们一人拿着底下三五个人的薪水,却干着一些拿着没什么真实意义的事情,还美其名曰“度量”,画画Excel,喊喊口号,一天就过了,却不干多少实事。纯粹是对项目成本的一种浪费。还不如用来给底层搞技术的码农们来点加班饮料。呵呵,说的有点过了,就当作开玩笑罢了。

现在BDD和SBE也号称比较火,这个不是什么SB Engineer,而分别是行为驱动开发、需求实例化。我想不论采取什么模式,瀑布还是基础模式,不论玩什么开发方法学新花样,CMMI也是基础。万变不离其宗,如果这二者都没练熟,其他都是瞎扯。



本文转自 念槐聚 博客园博客,原文链接:http://www.cnblogs.com/haochuang/archive/2013/04/12/3017580.html,如需转载请自行联系原作者

相关文章
|
5月前
交付成果 提高IT领导力的七大窍门
交付成果 提高IT领导力的七大窍门
|
敏捷开发 监控 数据可视化
从一个小角度观察敏捷实践
从一个小角度观察敏捷实践
106 0
从一个小角度观察敏捷实践
|
敏捷开发
《精益产品开发》读书笔记之三
何老师的这本书是一本非常“好”读的书,深涩的概念也是讲得深入浅出,触类旁通,而且故事感十足。
167 1
《精益产品开发》读书笔记之五
何老师的这本书是一本非常“好”读的书,深涩的概念也是讲得深入浅出,触类旁通,而且故事感十足。
168 0
《精益产品开发》读书笔记之五
|
定位技术
《精益产品开发》读书笔记之四
何老师的这本书是一本非常“好”读的书,深涩的概念也是讲得深入浅出,触类旁通,而且故事感十足。
177 0
《精益产品开发》读书笔记之四
|
固态存储 Java 区块链
浅谈技术管理之日式管理的殊途同归
《周易》说,形而上者谓之道,形而下者谓之器;降龙十八掌里有履霜坚冰,夕惕若厉等招数;坤卦爻辞中也有含章可贞,或从王事等管理和做人规则。 看完上面几句,大家可能会想,不是说日式管理嘛,怎么说起中国传统哲学了?其实无论是西方的还是日式的管理方法与经验,其理论来源都是中国的哲学思想,无论是德鲁克的任务、责任、实践的管理理论,波特的差异竞争论,哈默尔的核心竞争力,还是明茨伯格的战略和经理人角色,科特的领导与变革,归根到底这只不过是一些管理的方法和手段而已,这些手段和方法,在浩淼的中国传统哲学中都能找到与它们几乎一致的理论,可以说中国的哲学思想是世界管理学的源头活水。 说到日式管理,很多人也都耳熟能
185 0
|
数据可视化 项目管理 芯片
《精益产品开发》读书笔记之一
何老师的这本书是一本非常“好”读的书,深涩的概念也是讲得深入浅出,触类旁通,而且故事感十足。
362 0
|
Devops
阿里敏捷教练何勉:论精益思想及精益产品开发实践体系
精益求精是工匠精神实现的最佳方法,通过引入实践精益思想的原则和方法进行精益产品开发,打造对客户最好的产品进行交付,其次通过精益思想的理念降低企业的运营成本,提高企业的运营效率。阿里资深解决方案架构师、畅销书《精益产品开发:原则、方法与实施》作者何勉,全面分享精益思想的来龙去脉和应用及精益产品开发的实践体系。
6434 0
|
运维 测试技术 持续交付
|
持续交付
敏捷软件开发宣言--常读常新
敏捷软件开发宣言 http://www.agilemanifesto.org/iso/zhchs/ 我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观: 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档  客户合作 高于 合同谈判  响应变化 高于 遵循计划 也就是说,尽管右项有其价值,我们更重视左项的价值。
1046 0