再谈敏捷项目管理

标签: IT咨询 | 发表时间:2014-11-26 00:37 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
前面谈敏捷开发和敏捷项目管理的文章已经很多了,由于最近在整理敏捷项目管理的培训材料,在整理材料的过程中又思考了一些离散点,特做记录。

在敏捷里面我们一直在强调团队的动态自适应和调整能力,要知道一个高成熟度的敏捷团队一定是一个能够高度高效率的进行自适应,自学习和自我调节的团队。那么传统的层级结构一定是不适合的,包括原来传统的按阶段划分的流水线式生命周期结构,取而代之的是多个小团队之间的网状结构,在这种结构下能够通过高效的消息传递快速的发送消息,接受反馈,并进行自我调整维持在一个动态平衡的状态。个人理解这个很类似在《失控》里面提到的看似无序而实则有序的一种高效的以消息为中心的组织架构模式。

在引入了软件工程后,我们始终期望能够通过工程学和借鉴工厂批量自动化生产的方法来解决软件开发质量和效率问题。而对于软件本身,从需求到测试完成都属于研发过程,而只有最终的光盘刻制才能够属于生产过程。在软件工厂的概念下,自然是将软件生产过程中的很多方法引入到了研发过程。对于一个产品研发或生产的复杂性问题的解决,我们有两个途径,第一个途径是将其进行产品生命周期阶段的划分,然后再按阶段进行分工和上下游协作,形成标准化的SOP方法和步骤,降低对单个阶段或人员过多的技能要求和依赖。第二个途径则是一开始就做好顶层设计和分解,然后在并行的进行各个部件的研发和生产,最后再进行集成和组装,在这种情况下往往是顶层设计和后续组装难,但是中间并行过程相当容易。

第一种途径有一个关键的假设,即标准的SOP已经制定完成并多次验证有效,那么每一个阶段的人员只需要关注上游的输出并经过加工和作业后提供给下游,他们并不需要对整体负责而只是对工序负责,即在这种模式下往往并不存在需要跨阶段或流程节点进行沟通的场景。但是要做到这种程度在软件领域是相当困难的,这种方式好像就在说我们的编码人员不需要关注需求,只需要看设计文档就足够了,而我们的需求人员也不用关心最终的开发测试产出,只需要把需求传递给测试就可以了。但是事实上再严谨的软件工程方法,包括瀑布模型都很难真正做到这点,其真正的原因还是在于我们将生产方法应用到了软件研发过程域中。

第二种途径相对来说也是我们常用的方法,即在进行完高端业务建模和技术架构设计后再进行分解,然后并行开发后再进行集成。这个好像和第一种途径并没有太大的区别,但是注意如果我们的需求仅仅高端业务建模,集成仅仅是后续额UAT测试的话,那么我们的中间过程就变成为了一个个并行的小流水线,我们关注的是这些并行的流水线团队本身足够小,足够相互不影响,同时我们不再关心流水线内部是否有严格的需求,设计,开发,测试各个岗位和阶段的划分。这也是前面谈到的对于稍微大一点的项目仍然可以在做好顶层设计后分解到多个敏捷小团队高效协作的原因。

在scrum里面我们看到有两个重要的角色,一个是product owner,一个是scrum master,要注意这两个角色本身是不能重叠的。对于产品负责人重点是需求本身的优先级,每一个user story本身对产品和用户的价值创作;而对于scrum master更加关心的是每个sprint能够按约定的范围,按进度按质量高效完成,保证团队尽可能的免于外部干扰,这个和我们传统划分产品经理和研发项目经理还是比较类似的。一个是站在用户和产品价值层面,要保证做正确的事情,而一个是站在进度和质量层面,要确保正确的做事。

敏捷项目管理我觉得最重要的不是方法论或最佳实践或工具层面,而最重要的还是敏捷团队。而对于一个敏捷团队最重要的包括了两点,一个是高效沟通和协同的意识和积极态度,一个是本身已经积累的协作默契和差不多的知识技能积累。两种缺一不可,只有都具备了才可能最大化的减少无效沟通,这也是对于一个刚逐渐的团队敏捷往往并不是最好方法的原因,刚逐渐的团队更加需要的仍然是通过传统的软件工程方法积累知识技能和团队词汇表,做为后续能够敏捷的基础要素。

我们不可能完全避免犯错误,但是我们可以通过短周期迭代和team review等多种方法尽早的发现错误和纠正错误。敏捷里面有个重要思想就是不是理想化的去要求需求不变化,而是尽可能的及早发现变化并适应变化。基于这个思想下的原型方法,持续集成和构建,短周期迭代发布,可视化看板等都是为了这个服务,即尽早的发现和纠正问题。以避免传统软件工程中缺陷遗漏到最后引来的巨大的坏质量成本。

在类似scrum的敏捷项目管理方法论里面,我们看到通过prodcut backlog->sprint backlog->task形成了一条完整的围绕user story的跟踪流水线,真正实现了最小粒度单元的用户故事(需求)的端到端跟踪和实现,这是一个完全理想化的条目化的过程。在这里面一致困扰我的地方还是在于对于一个复杂系统的顶层设计或保证概念完整性的架构设计究竟在哪里?我的理解是只有完成了高层架构设计和分解后才能够进行条目化的并行作业,以保证整个软件系统的概念完整性,否则我们后续在集成上会出比较大的问题。

在sprint的计划会议上,团队中每个人的估算,每个人的承诺准确性都直接影响到整个计划执行的有效性。如果制定出来的计划不断出现延期或无法履行的情况,对整个敏捷过程的破坏是相当大的。因此一个敏捷团队首先要求的是团队中的每一个人是敏捷个人,能够很好的知道自己的工作质量和工作效率,做事情能够有明确的个人计划和目标性。

敏捷项目管理不是没有方法或不重视文档,相反敏捷方法对纪律和文档输出的要求往往更加苛刻。同样,敏捷方法不是不关心过程,而是去除冗余没有价值创作的过程。还是一句话,越严格的纪律下往往对于高度自律的人才容易得到最大的自由。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [谈敏 项目管理] 推荐:

再谈敏捷项目管理

- - 人月神话的BLOG
前面谈敏捷开发和敏捷项目管理的文章已经很多了,由于最近在整理敏捷项目管理的培训材料,在整理材料的过程中又思考了一些离散点,特做记录. 在敏捷里面我们一直在强调团队的动态自适应和调整能力,要知道一个高成熟度的敏捷团队一定是一个能够高度高效率的进行自适应,自学习和自我调节的团队. 那么传统的层级结构一定是不适合的,包括原来传统的按阶段划分的流水线式生命周期结构,取而代之的是多个小团队之间的网状结构,在这种结构下能够通过高效的消息传递快速的发送消息,接受反馈,并进行自我调整维持在一个动态平衡的状态.

项目管理入门PPT

- - 堇| 网络 产品 读书 睡觉
无意看到一个项目管理的PPT,虽然标题是《轻松项目管理之电信项目管理实务》,所写内容在互联网行业也颇为适用. 地址: http://doc.mbalib.com/view/05ee6199c3b3885c59e878a5cbd8cd53.html.

项目管理ppt下载

- - 人月神话的BLOG
项目管理培训的ppt前年做了部分,一直没有做完,今年准备花些时间全部做完,并全部共享出来. 最近做完的主要是项目成本管理和项目质量管理. 成本管理: http://vdisk.weibo.com/s/dyHc0/1348535220. 成本管理涉及到比较多的财务的内容,包括财务上的预算管理,成本核算,概预核决,资金管理.

Excel项目管理工具

- - CSDN博客研发管理推荐文章
版权所有,转载请注明出处: http://guangboo.org/2013/10/27/excel-project-management. Excel强大的表格功能在项目管理中同样具有大用处,作者通过在实践中实际运用Excel进行项目管理的经验,简单介绍Excel在项目管理中的应用. 本文主要介绍Excel如何做项目计划和项目进度跟踪,项目计划和项目跟踪是项目周期中最重要的环节,无论是几个月的小项目,还是几年的大项目,计划和进度始终是保证项目正常推进、按时交付的重要手段.

项目管理总结

- - 研发管理 - ITeye博客
【一】开发环境和测试环境部署和配置:具体包括JDK、TOMCAT、Eclipse、SVN、ANT   、Maven,以及缺陷库环境的搭建,以及用户权限的分配. 【三】数据库服务器环境的部署、搭建、并根据项目需求情况,建立相应的表空间、用户对象、并制定数据库备份计划. 【四】 SVN环境的部署及配置,并建立版本库和对应的项目目录结构、常用知识库目录结构等.

未来项目管理发展趋势

- tiod - cnBeta.COM
根据ESI国际项目管理培训公司的分析,项目管理作为一门学科越来越被接受. 公司项目管理将起到关键作用,无论是开发新的产品和服务,或确保日常的日常工 作顺利进行. 项目经理可以组织本地或远程团队,在许多情况下还是虚拟团队,不同的群体的人为一个项目一起工作. 对于组织,人才和项目经理是一个有效的竞争 优势,根据ESI执行副总裁J LeRoy的 分析,这种情形在2011年仍将继续.

IT项目管理工具总结

- 腾 - 博客园-首页原创精华区
阅读: 3434 评论: 16 作者: Lynn. 发表于 2010-06-02 10:27 原文链接.          俗话说"工欲善其事必先利其器",在一个项目开发流程中,如果搭配一个比较完善的项目管理工具,必将取得事半功倍的效果. 本文搜集了目前项目管理界比较有规模的管理工具,给予了简单介绍,同时为了发扬免费开源的精神,重点总结了免费开源工具Dotproject 和Redmine.

一份项目管理提纲

- 黎明 - 最新文章 - UCD大社区
这是一份工作笔记,我的做项目管理的方法,相信大多数有经验的项目/产品经理对此必定了如指掌,或者有更优秀的经验. 提案过程是公司内部的一次自我营销,方案好坏、沟通高低决定公司对项目能投入多少资源. 提出解决方案——PPT提纲.ppt. 撰写产品需求文档PRD.doc、制作页面原型.rp. 以PPT提纲和页面原型进行共享、论证、评估.

互联网项目管理要点

- - 月光博客
  互联网项目,会定一个计划发布日期,然而这个项目有个隐藏的实际合理发布日期. 因为软件开发并不是一个直接添加资源就可以加快速度的过程,所以这个实际合理发布日期是在现实资源合理利用前提下一个客观存在的最可能早的完成时间. 项目进展的过程,其实也是发现这个隐藏的合理发布日期的过程.   从管理的角度来讲,当然是尽可能的赶上计划的发布时间,或者尽可能快的完成项目.

一些项目管理经验(1)

- - 曉生
要尽早的参与到产品的需求当中,在讨论过程中给出自己的专业建议. 设计是整个团队的一部分,考虑的不只限于我应该做什么,而是可以为整个产品做什么. 设计与产品不可避免会有意见上的冲突,设计抱怨产品策略没有想清楚,强调流程上产品给出明确的文档之后设计再开始参与. 如前期能帮助制定产品策略,会扩大设计的影响力.