[原创] 敏捷软件开发管理实践 (三) ——尽可能并行工作

原创 2004年11月02日 23:21:00

作者:李文华
注:本文为原创,任何使用必须经得本人同意.



尽可能并行工作

1.1. 各种角色可以协同工作

       敏捷的特征就是要是使工作更加高效。很少有公司仔细考虑过项目成员在工作流程上的优化可以为项目提高多大的工作效率。但是,只要我们想一想,项目中的每个成员其实都是一颗能够独立计算并完成任务的CPU,那么我们是否会像IBM的网格计算专家一样去不断优化这些CPU的工作流程以达到一个新的世界记录呢?

       千万不要认为必须完成所有的需求后才能够开始开发,完成开发后才能开始测试。软件管理者应该要非常清楚,所有的项目成员都是可供利用的CPU资源,无论在项目的任何阶段,你都不应该让这些CPU资源过分闲置。  项目的工作推进要想CPU的流水线一样,不要形成顺序流程,而要尽可能并发开展,这样才能最大限度利用资源。

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

       需求分析还在进行,开发人员干什么呢?

       设计还在进行,需求人员可以干什么呢?测试人员又可以干什么呢?

        

       作者不是善于剥削劳动力的资本家,问这些问题是为了启发大家明白“人力资源”是非常富有弹性的东西,很多时候感觉“资源不足够”并不是真正的不足够,而要问问自己“是否让资源充分发挥了价值”。

        

       下面这张表是作者提供给大家参考的一个敏捷工作计划。在这个计划里,作者要强调几点:

1.         软件项目中存在很多隐性的工作,要尽量在项目立项的时候就考虑到,并排入计划。比如培训,制定规范,组织公用工具开发等

2.         清晰的角色划分,尽量明确每个人的工作职责,会使整个团队工作得更积极、有序。

3.         不要忽略了协调的层次,项目组内,部门内,跨部门都需要良好的沟通渠道和协调资源。

 

阶段      角色

需求师/人机工程师

架构师/设计师

开发工程师

测试工程师

需求调研

l         与客户沟通

l         编写用例和需求规格说明(功能需求、非功能需求)

l         培训(业务背景)

l         组织需求评审

l         架构设计

l         与需求师确认需求

l         构造原型

l         培训(工具使用指南、编码规范、环境搭建、调试指南、性能问题处理)

l         组织公用工具开发

l         参与需求评审

l         安装并熟悉工具

l         了解业务背景

l         培训和学习

l         开发公用工具

l         参与需求评审

l         列写测试计划

l         编写测试用例

 

分析/设计

l         持续确认需求

l         细化功能清单

l         细化逻辑检查清单

l         界面需求

l         参与设计评审

l         架构设计精化

l         模块概要和详细设计

l         编写接口文档

l         编写性能测试计划和性能保障计划

l         组织设计评审

l         参与设计评审

l         编写针对接口的单元测试

 

l         细化测试用例

l         准备测试环境

 

 

实现/测试

l         持续确认需求

l         检查功能实现

l         检查界面规范

l         代码走查(代码结构、接口、异常处理、性能瓶颈)

l         难点公关

l         微观性能测试

l         编码实现

l         对照逻辑检查清单编写单元测试

l         修改bug

l         参与技能培训

l         功能测试

l         宏观性能测试

l         集成测试

                  

                  

1.2. 始终做最该做的

让整个团队都可以尽可能地并行工作,这看起来似乎非常理想。但是要在项目管理实践中做到这一点,并不容易,需要整个团队有统一的价值观,并遵从一个工作原则,那就是“始终做最该做的”。

这里的“始终做最该做的”原则包括:

1.         依赖项优先

2.         接口优先

3.         关键路径优先

4.         广度优先

 

1.1.1.依赖项优先

       大家都知道,并行工作的关键就是要让每个任务处理尽可能没有依赖,这样每个任务就可以单独进行下去。但是,任务之间往往不可避免存在各种依赖项,依赖项使任务的执行变成了串行。

       在项目中,每个人每天的任务往往很多,这些任务中有些是独立的,早点完成还是晚些完成对别人没有影响。有些任务是被依赖的,如果自己不完成,他人也就不能完成。依赖项优先的原则就是要求整个团队的各成员树立一个意识:始终优先解决他人对自己的依赖项。一个这样做,还看不出效果;但是如果整个团队都能真正奉行这一原则并落到执行的实处,那么整个团队的协调工作量就会大为减少,整个团队也就会持续保持在较高的工作效率状态。

       案例:测试人员A等着需求人员B为其提供一个功能检查清单f 才好对某个模块进行有效测试。那么f AB的一个依赖项。如果B手头的其他事都只影响自己的工作,这是时候需求人员B应该优先完成f,以免测试人员A无法进行自己的工作。

       这里也有另外一个问题值得一提,那就是,每个人有应该清楚,如果自己的工作发生了依赖项,除了协调对方尽快去解决外依赖项外,还应该明白,自己绝对不应该就这么干巴巴等着。而应该切换去处理其他工作,一旦依赖项被解除,再切换回原来的工作。

 

 

1.1.2.接口优先

       尽管“接口”一词让面向对象的程序员理解起来更为容易,但是这里把这个概念推广。“接口”用来表达两个部分组合到一起的交接部件,可能是代码,也可能是文档。

       接口优先的原则就是强调要优先把双方的依赖项明确下来,并尽可能使之稳定。有了接口,双方遵从接口即可并行工作。接口优先是依赖项优先的特殊形式。

       接口优先要求:

A.      尽早定接口

B.      谨慎定接口,提供方和使用方共同确定接口,并要求接口评审

C.      接口变更要受控

从实际项目中看来,围绕接口制定太晚,而导致返工的现象十分突出。一个典型的场景就是等到项目集成了才发现接口并不符合需要,而这个时候修改接口往往伤筋动骨,重构的代价很大。

另外,就是制定接口需要很丰富的经验,要充分考虑到接口将来存在的变更可能。可是实际项目中经常看到的一个现象是:接口的使用方往往一开始并不关心接口的具体细节,接口由提供方自行制定,而到了集成阶段,接口的使用方才提出接口无法满足自己的需要,并要求接口提供方进行变更。大家应该非常清楚,这个时候的接口变更不仅要求接口提供方修改内部逻辑代码,更大的隐患是牵一而动全身,一个接口的变更会引起所有接口使用者的代码调整。

作者比较建议推行“接口评审”制度,评审会上必须要求接口的制定方和使用方共同派代表参与,明确接口的需求和形式。这样做往往能够形成好的气氛:

第一,接口的使用方参与了接口的评审,有助于他仔细考虑自己的需求是否能够满足。

第二,接口的形式是经过使用方评审的,使用方要为日后接口的变更负责任。这样可以促使接口的使用方提前充分理清自己的需求。

第三,双方见面进行沟通,明确了相关人,便于日后工作中的协调处理。

 

1.1.3.关键路径优先

       学过图论的读者都知道关键路径的概念,项目管理理论也告诉我们,关键路径上的任何活动的推迟将使整个项目推迟。

         关键路径要求:

1.         项目管理团队需要清楚项目的哪些工作是关键路径

2.         项目管理团队要制定可行的计划保证这些关键路径的完成。

 

 

1.1.4.广度优先

       广度优先也是图论中的一个概念,表示在树搜索的时候优先从广度上处理。这里沿引过来表示始终要要优先分解任务,而不是处理任务。

考虑整个团队任务的并行处理效率,如果说任务A可以如下图分解为子任务A1,A2,A3,并且子任务A1可能继续分解为子任务A11,A12。团队中的每个成员应该这样处理:

       第一,考虑把任务A分解为几个子任务A1,A2,A3

       第二,考虑如何处理任务A1,发现A1可以分解为两个子任务A11,A12OK,这个时候不要钻进去处理A11或者A12,而是处理A2。发现A2只需要处理子任务A21。接下来去处理A3,A3分解为A31A32

       第三,这个时候可以处理A11了,处理完A11就处理A12,玩了在处理A21等等。

       从广度上优先处理问题.jpg

       <?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />

       为什么要这样做?我想这是大家想知道的。原因如下:

1.         培养大家的大局观,不要急于钻进一个细节问题

2.         始终把能做的先做,比如分工

3.         先把任务从广度上划分,有利于在某个子任务遇到依赖项时切换到另一个任务去处理

有利于资源共享。任务先在广度上有了一个划分,当出现新的资源时,很容易把其分解的子任务分配出去,从而保证任务始终在并行处理的状态。

<SCRIPT type=text/javascript><!-- google_ad_client = "pub-4219279482676588"; google_ad_width = 728; google_ad_height = 90; google_ad_format = "728x90_as"; google_ad_channel =""; google_ad_type = "text_image"; google_color_border = "578A24"; google_color_bg = "CCFF99"; google_color_link = "00008B"; google_color_url = "00008B"; google_color_text = "000000"; //--></SCRIPT> <SCRIPT src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type=text/javascript> </SCRIPT>

敏捷项目管理实践

背景:         我们是一家专为政府开发软件的企业,前些年可能是项目任务多、或是管理上的问题,大部分的项目无论是进度、质量上都出现了问题。所以2013年开始采用项目管理的方式,试图解决这些问题。...
  • metecyu
  • metecyu
  • 2014年05月25日 22:38
  • 1272

敏捷软件开发:原则、模式与实践的学习笔记

第四部分   打包薪水支付案例20.包的设计原则 通常以包的形式,对应用程序从高层次进行组织。这里从两个方面考虑:一方面是根据什么指导原则把类划分到包中,另一方面是怎么处理包之间的相互关系。 包的粒度...
  • lindan1984
  • lindan1984
  • 2007年07月20日 13:02
  • 891

《敏捷软件开发原则、模式与实践》读书笔记(一)

一、敏捷联盟宣言(The Manifesto of the Agile Alliance)● 个体和交互               胜过       过程和工具● 可以工作的软件       胜过 ...
  • jasmine1987
  • jasmine1987
  • 2007年06月06日 23:36
  • 981

《敏捷软件开发:原则、模式与实践》读书笔记

1、敏捷软件开发宣言 个体和交互         胜过 过程和工具 可以工作的软件     胜过 面面俱到的文档 客户合作           胜过 合同谈判 响应变化           胜...
  • backard
  • backard
  • 2013年07月19日 17:20
  • 1139

敏捷软件开发—原则、模式与实践.pdf 免费下载

下载地址: 敏捷软件开发—原则、模式与实践.pdf
  • jiongyi1
  • jiongyi1
  • 2018年01月27日 10:31
  • 81

敏捷软件开发:原则、模式与实践-读书笔记1

单一职责链原则(SRP): 为何要把两个职责分类到单独的类中:因为每一个职责都是变化的轴线,当需求变化时,改变化会反应为类的职责的变化,如果一个类承担了多于一个的职责,那么引起他变化的原因就会有...
  • boer521314
  • boer521314
  • 2016年09月11日 23:51
  • 648

敏捷软件开发中的配置管理

敏捷软件开发方法目的是适应需求的快速响应,能够快速的发布和快速的交付使用。 在敏捷中的如何实现配置管理,如何通过配置管理来管理敏捷开发过程中的需求、代码、版本等,这是应该是一个专向的课题。 ...
  • dongjian764
  • dongjian764
  • 2013年12月26日 12:59
  • 1131

Java程序员的推荐阅读书籍之七《敏捷软件开发 原则、模式与实践》

在robbin的那个贴下回了一下,问我要电子书的tx陆续有几个了,本来想通过邮件发的,但是无奈太大,一一发邮件太费神了,所以想了一下,还是我放在博客上,有需要的就下载吧。   根据robbin的那...
  • huangyuanmu
  • huangyuanmu
  • 2013年11月18日 13:26
  • 1170

《敏捷软件开发》--读书笔记

《敏捷软件开发》--读书笔记 注:
  • ggf123456789
  • ggf123456789
  • 2015年01月27日 16:47
  • 719

[原创] 敏捷软件开发管理实践 (一) ——让人的资源多起来

敏捷软件开发管理实践 (一) ——让人的资源多起来第1部分   开篇语         项目管理作为一门独立的学科,已经发展了很多年,并为实践提供了丰富的理论依据。而软件开发的项目管理,虽然也属于传统...
  • cloudward
  • cloudward
  • 2005年02月02日 00:07
  • 1828
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:[原创] 敏捷软件开发管理实践 (三) ——尽可能并行工作
举报原因:
原因补充:

(最多只允许输入30个字)