结论简单,教训深刻:一个大型项目关于需求工程的反思
发布于 2024-10-01
1447
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
项目回顾摘要
某公司在开展一个新行业的大型软件项目时,面临了多个挑战。项目计划工期为2年,实际用时2.5年,投入了近100人年的工作量,但浪费了约25人年,主要因需求返工所致。项目结束后,作为外部咨询顾问,我参与了项目的回顾过程,并总结了以下经验教训。
保持的做法:
- 小范围的需求沟通与交流更有效,有助于清晰透彻地理解需求。
- 每日召开例会来准备和总结需求调研,确保调研的方向和重点。
- 多轮面对面沟通和现场调研,以深刻理解客户需求。
放弃的做法:
- 避免没有领域专家参与需求调研与分析,以免理解不透彻。
- 不依赖中间人传递的需求,减少误解和返工。
- 制定销售人员作业规范,避免过多不实际的客户承诺。
- 确保需求决策者直接参与项目,防止需求确认延误。
- 及时让客户确认需求,避免大规模返工。
- 对参与需求调研的人员进行专业培训,提高需求质量。
新增或加大投入的做法:
- 在需求描述中明确系统能做和不能做的事项。
- 设立组织级需求规范,指导需求分析。
- 需求访谈前准备问题清单。
- 了解客户背景和企业文化。
- 让测试人员参与需求调研,评价需求的可测试性。
- 在开发前确认需求原型。
- 项目结束后总结领域经验,构建知识库。
- 对紧急需求修改采取结对设计、结对修改模式。
项目管理铁律:
- 项目中一定要有领域专家参与。
- 让客户进行阶段性验收,以三个月为最长周期。
- 采用迭代或增量模型开发,而非瀑布模型。
- 在开发前使用原型法确认需求。
- 保证项目参与者对项目真正负责。
总结上述经验,我们认识到大项目的失败往往在于宏观的项目管理策略,且在项目进行中难以意识到选择的错误。这些惨痛的教训是我们成长的宝贵财富。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 829.7K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
案例:建立工作量分布过程性能基线
某应用软件开发公司积累了最近3年的29个项目的工作量分布历史数据,试图建立工作量分布的过程性能基线。在该公司内对项目从3个维度做了项目分类:规模:大,中,小;开发方法:全新开发,修改;类型:常规,紧急,优化,外包。 原始数据如下表: 对工作量分布的数据与项目类型做了方差分析,发现:对这些原始数据采用箱线图的方法进行分析后得到如下的结论:
快速学习COSMIC方法之十七:如何寻找更简单有效的规模度量方法?
很多企业都在探索合理估算工作量的方法,而工作量的多少主要取决于软件规模的大小,因此在估算软件工作量之前需要先估算其规模。传统的规模估算方法是进行代码行的估算,但是对于同一个需求,不同经验的人员去估算,结果差别很大,不同的实现语言,估算结果差别也很大,即使不同经验的人员针对同一种需求去实现,实际的代码行数也差别很大,并且实际情况中,往往一个需求可能需要多种语言结合才能实现。因此,使用代码行作为衡...
Lehman的软件演化定律
自20世纪70年代以来,M. M. Lehman通过对软件系统演化现象的观察,陆续总结了8条定律,称之为定律并非那么严谨,但是对于认识软件维护的规律,改进软件维护的过程具有很好的指导意义。1 (1974年)持续变更定律。系统必须持续调整以适应各种变化,否则这些系统将变得越来越不令人满意。2 (1974年)复杂度增长定律。随着系统的演化,其复杂度会逐渐增加,除非采取措施来降低或保持其复杂度。3 (1974年)自我调整定律。软件演化过程的是自调整的,每次演化版本的度量数据近似正态分布。4 .
唐僧团队是否是一个优秀的Scrum团队?
唐僧团队通常被认为是一个成功的团队,因为他们是不同风格的成员组合在一起,经过了磨合后,同心协力达成了最初的目标,封神成佛。一个成功的团队,未必是一个优秀的Scrum团队。如果站在Scrum的角度来检视唐僧团队,他们有哪些突出的待改进之处呢?1 不是学习型团队在整个团队组建以后,团队成员的技能没有发生变化,孙悟空仍然还是那些绝技,猪八戒沙僧也没有学到新技能。每次打完妖怪后,没有总结经验教训,如何更好、更快地降服妖怪,打完一次妖怪,团队的整体技能没有提升,说明该团队不是一个学习型团队!...
对软件开发过程可重复性的思考
硬件的生产过程是可重复的。因为对产品功能、质量的要求是相同的、生产设备是相同的,生产流程也是相同的,硬件的生产力来自于设备,因此硬件的生产可以要求生产能力又准又稳,要求生产系统可以持续地生产出满足需求的产品。而每个软件项目的需求是不同的、人员的经验与数量是不同的、开发方法与开发过程是不同的、外部干扰的频次是不同的,软件的生产力来自于人,因而软件过程满足需求的能力相对于硬件的生产过程是偏弱的。人操作硬件,硬件生产产品,人对生产质量有影响,但更重要的是硬件。需求是原材料,是抽象的,每个项目的原材料是不同的。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线