建议用 Firefox 85+、Safari 14+、Edge 87+ 浏览
我的文章 我的评论 我的书评 我的知乎*
书单 书讯 书评
需求知识体系 特性 用例 统一用例方法 用户故事 需求工具
业务建模 UML OOD
敏捷知识体系 敏捷方法 敏捷问答 敏捷工具 敏捷评论 敏捷资源
业务模式 需求模式 架构模式 设计模式 大道至简:实话设计模式 Web 应用架构模式
.NET Java JS 笔记
Amazon* ITPub* Martin Fowler* 教程
需求分析需求模型非功能需求业务需求分析
SpringJSF
> >
在线/26 登录/0

案例:一个典型传统团队的敏捷改进

阅读数:6.8K
基本

首先感谢作者 dearChloe 分享了真实的项目经历,以及她在实际工作中所遇到的各种困难和真实想法。尽管这些项目有的很小,甚至是些微型项目,但是我觉得这些项目、团队所遇到的问题在国内其实非常典型,对国内其他有类似境遇的软件项目经理们应该会有很高的借鉴价值。

主要有这样几篇文章:

1、对微型项目管理的思考 (2008-04-19)

2、项目一: 方案阶段 (2008-05-10)

3、以前的抱怨贴 (2008-05-10)

4、之前项目总结 (2008-05-10)

案例概要


行业类型:航空业

公司类型:“在一家大公司,虽然不是国企,但与国企没区别,就当国企了。”

所在部门:IT 部

团队类型:甲方研发团队

我们不是软件公司, 即没有一套标准,人员配备也很杂,所以,要按标准软件开发那一套, 很困难。我也在摸索,也在见机行事。
团队规模:小型、微型

主要问题:

1、业务部门查抽随便更改需求,并且不通过 TL;

2、程序员不根据设计文档开发,随心所欲;

3、有部分模块,设计做的不够详细;

4、项目进度拖延。

以下是我补充的:

5、“至于测试,我们确实做的很少。”

组织的问题

看了之后,我的总体感受是:可能作者介绍过多的是从自己和团队内部来总结经验教训,而对团队外部、整个公司/组织的因素总结的不够。

我感觉,这家公司的整体软件工程成熟度是很低的,显然缺乏组织级别的软件过程规范。用 CMM 的术语说,大概只有 L1 或 L2 之间。从敏捷的角度看,也可以说一点不敏捷。

正是因为没有组织级别的软件工程规范,有效、合理的软件开发过程来协调业务部门和 IT/开发部门,才出现了业务部门可以查抽随便更改需求,并且不通过 PM/TL 的情况。

作者作为 PM,给出了较好的解决办法:

我只能跟程序员说,以后不要答应他直接给你的需求,必须要经过我,或者跟我商量。但业务部门领导,我就不好这样跟他说话了。业务部门的人员(任何其他人)这样做,都是会让项目失控。最后得不尝失。
我建议作者应该及时地向自己的领导、CTO 或 CIO 提出建议,关注自己公司整体的软件工程成熟度,从制度、企业文化的根本上解决问题。如果只从开发团队内部考虑,而忽略了团队外部环境的影响,那么这种改进的整体效果是非常有限的,而且今后依然麻烦不断也是可以预期的。

至于组织级别的改进目标、路线和方向,是参考 ISO、CMM/CMMI,还是参考 Agile?从目前 dearChloe 介绍的情况看,我建议先从 light-weight 的敏捷过程改进开始可能是最佳方案。

团队的问题

在团队自身的经验教训方面,作者总结得比较充分。我印象最深的是:人和。天时、地利、人和,最重要的是人和。人和,就可能等到天时和地利;人不和,任何工作的成功都无从谈起。

如果要我给本案团队提建议,什么是下一步的改进重点,我觉得从瀑布到迭代是一个关键,而据我观察,这也可能是国内大部分软件研发团队(我个人估计大概超过 70%)所面临的一个主要改进任务。可以这么说,如果您的团队到目前为止,还不知道为什么要迭代,如何迭代,如何在瀑布和迭代之间作出选择的话,那么你们团队或企业落后国外软件工程的先进、成熟水平至少 10 年以上。

目前作者制定的过程大致是这样的:

   1)方案(TL)

   2)讨论(TL)

   3)架构设计

   4)设计(TL)

  * 以上几步都形成文档;

   5)开发(程序员)

   6)阶段性交付(程序员)

   7)需求变更(客户、TL)-> 需求变更文档(TL)

   8)评审、结束

这是瀑布改良型,本质上仍然是瀑布过程。瀑布过程的主要问题是效率较低,难于适应需求的变化,不符合大多数项目开发的实际状况,因而总体面临的风险较高。

当 TL 在前期做需求分析、架构设计的时候,程序员在做什么?是闲着无所事事,还是在忙其他项目?

实际上,在迭代式开发中,当我们知道一部分关键需求已经明确,设计完成后,就可以马上进行编码和测试了,没有必要等到开发阶段在来写代码。这种并行、并发的开发方式,显然效率更高。

关键是项目的需求、架构设计都必须通过编码实现、测试验证之后,才是真正稳定和可靠的。而且一旦在瀑布过程中所谓的开发/编码/实现/交付阶段,需求定义和架构设计,出现了问题,怎么办?必然要重写需求,重新调整设计,而这样的需求、设计调整(rework)是需要耗费时间和资源的,所以如果还要根据原来不可靠的项目计划执行,出现进度的拖延可以说是必然。

如果不采用迭代、递增的开发方式,通过一个个时间片中的编码和测试来验证不可靠、不稳定的需求和设计,控制风险,缩小预测与现实之间的差距,而指望根据理想的瀑布模型来“按时”完成项目、交付产品,可能性很小,或者说风险很大。

传统与敏捷

经过 40 多年的发展,软件工程的管理和技术可以说已经超级成熟了。作者团队所遇到的这些问题,并不是多么高深、难以解决的问题,可以说都有很多现成、成熟的解决办法,国内外许多 leading 企业和团队的做法就是榜样。

如今,迭代、递增开发在国际上早已成为主流。而正像 10 多年前软件工程发生的一次重要技术变革、范式转换(paradigm shift) —— OO 技术取代传统结构化技术成为主流 —— 一样,敏捷软件工程也正在成为主流,它们取代传统软件工程,也将是本世纪初软件工程领域最重要的 paradigm shift 之一。

评估作者团队的现状,可以说许多方面都还没有达到敏捷的要求,后面我还会做进一步的分析,说明他们什么地方是不敏捷的,敏捷团队应该怎么做。而即便从传统软件工程的角度看,目前他们的成熟度也是较低的。

我觉得,在软件研发团队实施改进过程中,信息不对称是一个主要的风险。如果看的书不对,获得的文献或资料有误,接受了传统、落后、过时的、原本应该被淘汰的观念和方法,那么结果必然会达不到改进、优化、提升竞争力、超越同行的效果。所以软件项目经理不但要熟悉项目管理的基本理论和原则,软件工程、软件工艺流程的基本原理和方法,而且要准确、及时地了解软件工程管理技术的来龙去脉、最新进展和发展趋势。

好消息是,作者得到了领导的信任,拥有一个融洽的、具有凝聚力的团队,而且他们对自身的缺点、现状和面临的问题也有着比较清新的认识。尽管我们目前还没有看到本案团队走向敏捷的迹象,然而作为敏捷 OO 顾问和教练,我当然期待的是他们朝着更加成熟、更加敏捷方向的改进。

作者的团队又开始了两个新项目,祝他们好运!

(待续)

<帮助> <全部评论> 共 0 个主题 0 条评论 (DearChloeCase)
首页 | 使用指南 | 站点地图 | 版权声明 | 联系方法 | © 2005-2021 张恂 版权所有. 沪ICP备15017521号-2