2017-11-29 15:40:38 redxun_cn 阅读数 3460
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

1. 敏捷开发平台简介

红迅JSAAS敏捷开发平台是广州红迅软件有限公司面向合作伙伴以及有IT运维团队中大型企业提供新一代的企业级的数据IT一体化的业务管理平台工具,它基于流行的JAVA开源技术上构建,扩展容易,学习成本低,可快速构建企业的一体业务管理中心,即满足企业以下的管理需要。

  1. 统一主数据管理
  2. 统一业务单据管理
  3. 统一业务流程管理
  4. 统一组织架构管理
  5. 统一数据门户
  6. 统一数据移动审批
  7. 统一数据报表管理
  8. 统一业务运营管理
  9. 统一知识文档
  10. 统一对外协同
  11. 统一对内协同

它将是您的企业在移动互联网下实现对企业的运营数据管控的得力助手。

适合应用场景

  1. 需要打通内部各系统,实现内部统一业务审批如EIP系统
  2. 建立全新的业务管理系统,如Oa,客户关系管理,合同管理,项目管理,成本控制管理
  3. 需要与ERP打通进行所有业务单据的审批,如销售订单、采购订单、合同订单审批,
    同时可在移动端、微信单进行同步审批及消息推送。
  4. 需要与用友NC、U8、U9、金蝶、顶捷等ERP进行数据单据整合,并且需要流程统一管控。
  5. 需要类似零售行业,实现与内部业务与外部供应商信息联动业务协同处理
  6. 需要实现类似政府公文的业务管理
  7. 需要有一块快速自定义的平台框架适应企业或单位的业务变化
  8. 需要构建企业内部的ERP系统

适合企业或单位

  1. 已有团队,需要建立企业内部平台运营
  2. 尚未有团队,需要全新建立企业IT运营团队
  3. 有新的信息化系统需求,含中大型国企
  4. 有开发小团队,尚未有成熟的开发平台
  5. 有业务项目,需要快速交付

采用红迅快速开发平台,可保证企业类的系统信息化的项目可按时按质交付,保证可观收益。

快速开发平台包括:

2. 应用框架技术

红迅JSAAS敏捷开发平台采用流行Spring轻量级框架,并且结合大量成熟的开源框架,满足企业级的开发与运营的需要。

  1. Spring Core核心容器
  2. Spring  MVC 4
  3. Spring AOP
  4. Spring Security
  5. Groovy动态脚本语言
  6. MiniUI前端JS框架
  7. Jquery javascrip库
  8. JPA、MyBatis Or JDBC数据持久层框架
  9. Maven版本控制
  10. Log4j Java XML API
  11. Scheduling Quartz定时任务
  12. Alfresco Activiti 5
开源技术框架详细介绍
JSAAS平台框架使用开源技术汇总
后端框架
1 Spring基础框架 spring-security-core 3.2.3 RELEASE
2 spring-security-web
3 spring-webmvc 4.1.2 RELEASE
4 spring-jdbc 4.1.2 RELEASE
5 spring-core 4.1.2 RELEASE
6 spring-orm 4.1.2 RELEASE
7 spring-jms 4.1.2 RELEASE
8 ORM框架-Hibernate JPA hibernate-entitymanager 4.3.6 Final/hibernate-jpa-2.1.api
9 ORM框架-MyBatis mybatis-spring 1.2.2
10 mybatis 3.28
11 任务调度 quartz 2.2.2
12 消息管理 Apache Active MQ 5.10
13 流程引擎 activiti-engine 5.18
14 activiti-spring 5.18
15 activiti-modeler
16 Office文件读写POI poi 3.10.1
17 报表引擎 Jasper Report 6.2
18 缓存读写 redis 2.9.0或memcached 1.5
19 JSON序列化 fastjson 1.2.32/json-lib 2.4
20 邮件引擎 javamail 1.4.4
21 XML读写 dom4j 1.6.1
22 模板引擎 freemark 2.3.18
23 JSP标签库 JSTL 1.2
24 规则与动态脚本引擎 groovy 2.3.0
25 日志库 log4j 1.2.15 slf4j 1.7.5
26 Http客户端 Httpclient
27 数据库连接池 druid 1.0.26
28 其他工具类 apache commons-dbuils 1.4 ,common-io 2.4,commons-lang 2.6等
前台库
1 JQuery jquery-1.6.11
2 MiniUI组件 mini-ui 3.7
3 Ueditor 1.4.3
4 CodeMirror代码编辑器
5 echart 3.7.1
手机端
1 Vue 2.0x/YDUI Touch

 

3.业务功能定制与在线配置

平台提供简单易用的并且功能强大的代码生成器配合开发人员来进行功能开发,以保证用户基于平台上快速构建所需的功能。满足您在不同的业务场景下的数据展示与应用的开发需要,实现真正上的业务的运营需求。

3.1. 代码生成器生成多层架构代码

mul-tiplelayer

  1. 支持不同层次的代码分层,让开发人员分工合作。
  2. 支持对外配置化的Restful WebService的配置你化需要
  3. 支持不同的数据库,如MySql,Oracle,SqlServer,Db2或国产的关系数据库
  4. 支持多种不同的客户端,如PAD,PHONE,PC

3.2. 在线的主数据及单据维护管理

系统提供在线的主数据单据配置,用户可在平台上通过大量使用不同的组件及数据类型,可映射至系统平台中,实现对主数据的可视化配置及管理,如下所示,在线配置项目的基本信息及其维护管理界面,同时手机端与微信端同样也可以实现这些数据的查询与管理。

主数据维护管理

系统允许开发人员或业务管理人员实现对以上的多种主数据的管理,可配置以下系统功能:

  1. 配置子系统
  2. 配置菜单
  3. 配置功能按钮
  4. 配置打印报表
  5. 配置移动端数据
  6. 配置数据权限
  7. 配置子系统、菜单、按钮的权限

3.3. 多种系统风格的支持

系统支持多种风格的子系统、菜单、功能列表的数据展示风格,可满足企业对UI的美观要求

高雅风格

平民风格

经典风格

 

3.4. 子系统与功能菜单在线配置

平台提供多个子系统统一集中管理,支持不同的功能面板配置,支持菜单下的功能按钮的配置与管理,让您的应用像积木一样,越建越好,并且越来越协同。

 

4.灵活组织架构管理

平台提供了灵活的组织架管理,可支持通过API直接从外部组织架构获得人员与部门数据来实现业务,也支持从其他组织架构源,如HR用户中心,AD或LDAP组织架构中心获得用户数据。JSAAS平台同时也提供了灵活强大的用户组织架构构建数据工具,可以满足企业的各种复杂的业务架构的运营需要。它通过组、用户、关系三大组织架构要素来支持组织的复杂运算。如默认中系统支持以下特性:

  1. 系统支持不同类型的机构,如平台可以给企业内部组织,外部供应商,经销商组织协同使用。
  2. 支持自定义的不同用户组,如部门、角色、岗位、职务、项目、销售区域等
  3. 支持自定义用户的多种业务关系,如汇报、上下级、销售汇总关系等
  4. 支持用户与组的多种关系定义:如主负责人,汇报关系人,部门领导等。

【组织架构管理】


角色授权

  1. 平台提供全面的功能权限管理,包括访问页面、数据、资源权限,有效满足不同企业、单位对数据权限的不同要求。
  2. 提供基于角色控制,可控制访问资源页面、功能按钮,过滤不同部门、不同分公司、不同组织的业务数据。

 

5. 业务单据管理

每个企业在运营过程中都会有不同的业务单据数据,需要进行录入、流转、归档、决策分析等。JSAAS敏捷开发平台是一个强大的单据管理平台中心,它提供了大量的可视化及编程式的工具,支持业务运营人员设计与部署满足企业运营需要的数据处理流程。

5.1.表单的可视化设计工具

表单的中的设计工具支持丰富的控件,可用于不同的应用场景下使用表单,支持可视化的工单配置,也支持编程式的工单配置管理。编程式的工单可保证能实现复杂的表单数据展示。 表单工具支持大量的常用数据展示控件,如:

  • 支持的控件类型有:
  • 文本控件
  • 复选控件
  • 复选列表控件
  • 单选择列表控件
  • 下拉列表控件
  • 日期控件
  • 月份控件
  • 时间控件
  • 编辑型按钮控件
  • 按钮控件
  • 自定义查级联查询控件
  • 多行文本控件
  • 富文件控件
  • Office控件
  • 下拉树控件
  • 自定义查询对话框控件
  • 用户选择控件
  • 部门选择控件
  • 组织架构选择控件
  • 子表控件
  • 图片上传控件
  • 附件上传控件
  • 组框控件
  • 日期相减控件
  • 金额大小转换控件
  • 子表数据统计控件
  • 条件展示的div
  • 隐藏域字段控件
  • 审批意见控件
  • 审批历史展示控件

业务表单方案

通过绑定表单方案及对表单的数据处理,可提供灵活的在PC端与手机端展示的建单功能。如:

5.2.单据数据列表设计工具

平台提供强大的数据列表生成功能,可以实现数据的普通列表展示,导航分类列表展示,树型数据展示。业务人员仅需要学会SQL语法,通过以下单据数据列表的工具,配置数据源、列表展示的表头、查询的字段、功能按钮及表单代码编辑。通过配置完成后,其可以展示以下的功能界面:

工具配置过程:

1.自定义SQL定义数据

2. 自定表头

3.自定义功能按钮

4.自定义查询条件

5. 一键生成PC端与手机端源代码及界面

同时也支持多种数据展示风格,如下左右导航树数据展示:

同时支持志生成列表的功能同时兼容手机端录入数据的界面,保证PC与手机功能一致。

红迅的业务单据满足实现企业级的单据应用的需求,它能满足:

  • 单据管理功能配置化及授权访问
  • 单据数据权限控制的控制访问
  • 单据按钮权限控制访问
  • 单据的数据的导入与导出
  • 单据的多种打印模板
  • 单据的流程配置及审批
  • 单据的统计报表制作
  • 单据流程的业务分析与管理

6.BPMN2中国式流程支持

JSAAS平台支持非常强大的流程服务,特别是中国特色的流程审批服务,包括:

  • 流程串行、并行审批
  • 子流程的审批
  • 流程版本变更
  • 流程的自由流程
  • 流程的人员变更处理
  • 流程任务的分发与汇总
  • 流程定义的会签
  • 流程的催办
  • 流程超时跳过
  • 流程的工作日历
  • 流程表单的在线配置
  • 流程分支的配置处理
  • 流程的组架构整合
  • 流程表单的权限配置控制
  • 流程消息通知
  • 流程的回退与追回
  • 流程的抄送与阅读控制
  • 流程表单的模板打印等

多种流程开发工具集的支持

流程在线定义、表单自定义配置、查询设计、列表设计、表单方案设计、流程方案设计、组织架构设计、数据字典、选择对话框设计、数据源设计、流水号设计、流程授权设计等,可以满足各种流程的业务扩展需求。

流程在线定义

平台整合Activiti Modeler Designer,支持丰富的BPMN2的元素语法,可描述简单与复杂的流程业务需求,为企业、机关单位制作完善的业务流程提供了完好的支持,结合平台本身的表单与流程解决方案工具,让流程业务落地变得简单。

bpm_designer_800

流程方案配置

提供组装流程业务的解决方案的管理,把流程定义、审批人员、流程表单、审批时的事件及交互脚本调用等组装起来,实现真正意义上的BPMN的流程业务规则。如审批时,执行写入其他数据库的操作。支持各种事件的脚本交互处理;同时可让平台扮演流程管理中心,支持第三方平台的流程应用调用。

 

待办任务处理

任务干预

提供用户多种途径对正在运行的流程实例进行干预处理,防止流程人为出错后,系统有效提供手段进行人工纠正。

7.手机审批

通过在手机端进行模板配置,无需要进行功能开发,即可实现手机上进行待办处理,大大方便企业的管理人员。

8.报表管理

平台提供流行的在线报表管理功能,客户可线下进行报表设计,设计完成后,上传配置即可在线报表查看,并可配置于公司首页、部门首页或个人的首页、菜单等,展示风格可根据报表模板来定,同时实现在线报表展示及导出。

report-design

上传后的报表展示

report

9. 基础服务支持

邮件服务

  1. 平台整合开源的邮件服务器,邮件服务器可独立部署也可嵌入式部署,但邮件量比较大时,建议分开部署处理,平台可以在线收发邮件,邮件可为内部邮件、也可为外部邮件。
  2. 邮件账号合并系统中的人员管理的账号,有效实现一号统一,邮件密码可与系统登录的密码不一致也可一致

文件附件管理

  1. 平台中大量的文件、附件、图片均需要进行统一的管理,系统对每个账号的附件上传的文件的类型、大小、访问安全提出严格的控制
  2. 提供文件全文索引管理,有效提高附件的搜索速度

支持在线的文档预览

内部消息通知管理

平台提供内部的短消息的收发处理,可有效在系统内进行消息的通知。结合后面外围的即时消息,可有效实现消息的即时收发。

短信消息管理

  1. 平台整合流行第三方短信网关,通过发送短信XML至网关,以达到有效给相应的人员推送短信消息
  2. 平台整合腾讯的信鸽云推送,可有效实现免费的消息推送

微信公众号

平台提供不同的微信开发管理功能,包括订阅号、微信公众号、企业号的菜单自定义、消息自动回复、企业公告等功能,为现在的企业的微营销带来便捷的体验。

企业微信

平台实现了企业微信的账号及用户组织架构同步,为流程的消息通知开通实时的企业微信通知服务。

数据交互处理

平台提供方便的数据映射及接口开放的功能处理,通过JSON\XML\JMS\WebService等数据格式有效实现数据接口处理。

自定义PORTAL

支持栏目模板自定义,支持门户布局配置,支持不同风格的部门、单位、个人的首页门配置。

其他基础功能工具

如菜单管理、数据字典管理、系统参数管理、系统访问日志管理、系统流程号管理,数据源管理,自定义SQL管理,任务调度管理,平台的工作日历,系统开发文档管理等。

 

10.SAAS功能的支持

平台可根据参数配置,是否打开SAAS的功能支持,一旦打开,即支持同一套应用同时提供给多个租户使用,默认采用以下的第二种方式SAAS的应用支持

layer6

 

支持多企业在线注册及使用

11.如需了解深层的技术与项目交流,请联系:

  • QQ: 1361783075

2016-07-13 11:43:58 phil_code 阅读数 1496
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师


1.      制定版本计划

由技术leader,产品leader,项目经理,老板达成一致,根据各公司情况,制定每个版本的周期,

一周或者两周一个版本,由于ios的发版流程需要appstore审核,流程比较复杂,可安排android的发版时间比ios提前两三天,由android版本经过灰度用户验证后,再灰度ios

 

2.      输出需求列表

由产品经理,产品经理leader,老板达成一致,输出当前版本的需求列表,并对每个需求标注优先级

 

3.      需求评审会

由项目经理或者产品经理发起需求评审会,技术团队和测试团队人员参加。产品经理在会议上讲述需求的详细功能点,并解答其他团队成员提出的问题

 

4.      需求排期

由技术leader、测试leader、设计leader组织团队成员对产品需求文档评估工作量,输出项目计划。

测试团队输出测试用例

 

5.      开发

由技术经理和项目经理组织团队成员开发,监控项目进度。

 

6.      功能测试

技术团队先根据测试用例自测后再提交测试团队

 

7.      集成测试

开发人员把代码版本合到主干发布分支,并编译出版本。

在集成测试阶段,后台服务要发布到线上环境。

测试人员用客户端版本联线上后台服务测试。

 

8.      灰度上线

Android版本先灰度,通过后台控制部分用户客户端的自动更新功能

Ios版本发越狱市场,例如pp助手

 

9.      全量上线

Android版本提示所有用户客户端安装,并发布到渠道市场

Ios版本提交appstore审核

10.  版本总结会

由项目经理组织所有团队成员对当前版本的项目情况做总结,提出问题,制定措施避免下版本有同样的问题。


2009-12-26 21:19:03 hhwgaoshu 阅读数 10
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师
转自程序员杂志
一些敏捷团队在实施敏捷开发中忙于编码、忙于Unit Test、忙于沟通、忙于Build等,虽然也有编码审核阶段,但大都浮于表面,流于形式,效果不佳。本文结合实践,介绍笔者对敏捷开发中CodeReview的理解和相关经验。

文/ 陈序明

敏捷开发中Code Review的目的及内容
做任何事情,首先要清晰为什么要做,才能有目标和动力把事情做得更好,Code Review 也是如此。只有清晰明确了敏捷团队进行CodeReview 的动机,才能以此为方向开展后续工作。下面我们推荐的敏捷开发中常见的Code Review的目的:

设计合理性Review
在笔者的另一篇文章中《敏捷开发中的架构设计》谈到,敏捷开发中崇尚Code is design,对开发人员提出了比以往更高的要求,即需要开发人员不断地重构出合理的设计。所以敏捷开发中的Code Review也需要承担一部分“结对设计”和“设计把关”的职责。
这部分的Code Review 包括:设计的合理性(如实现方法,数据结构,设计模式,扩展性考虑等),是否存在大量重复代码和其他组件是否有重复的代码,包结构设计是否合理等。
笔者了解的一些项目中, 进行敏捷开发后, 提高了开发效率, 但是设计的质量却下降了。如Repeat Yourself 的现象(特别是跨组件之间的Repeat Yourself 现象);更有甚者,在笔者看到一个某银行的应用中(不是国内的),数据库连接和操作是直接在JSP中写SQL语句。
像这些Bad Design 的例子还是很多的。这些在重构的时候应该由开发人员解决。但考虑到不同开发人员之间技术功底不一,很有必要在Code Review阶段进行Review和讨论。

互为Backup
这是很容易被忽略,但是又很重要的一个Code Review的目的。
我们知道,敏捷开发中强调高质量的代码胜过详细的文档,所以某种程度上来说Code is Document。敏捷开发中的代码承担了一部分Document的职责,即传递技术的作用。
Code Review 中,Review 的开发人员了解代码的设计和实现,传递了技术,开发人员互为Backup,方便后期的维护,也减少了项目风险。

分享知识、设计、技术
这也是很容易被忽略的一个很重要的目的。敏捷开发是一个中央集中控制到个体发挥积极性的过程,中央集中控制的优点就是有统一的视图和控制,经常开大会,开长会,这样知识和经验也较容易集中。敏捷开发中,分散在两个Scrum Team的开发人员之间,如果没有好的机制,相互沟通也会相对较少,造成知识和好的经验无法在整个团队传播。
笔者参加的项目中就碰到了类似情况, 当时我们整个团队分成三个Scrum Team,其中一个Scrum Team负责一个Eclipse 工具的开发, 其中用到的一些功能和知识在其他ScrumTeam上以前都有涉及过。当时负责开发的同事非常优秀而且能力突出,但由于不知道其他Scrum Team同事有这方面的经验,没有很好地分享以往好的经验和知识,以至于最后导致浪费了一些学习的成本。
Code Review是一个学习和享受的过程,一个开发人员的能力有限,而Code Review正是这样的一种机制,让好的知识、设计在团队中分享,实现整体团队的成长和整体的效益最大化。

代码可读性
如上所说,敏捷开发中强调高质量的代码胜过冗余的文档,所以Code某种程度上是Document。敏捷开发中,代码的要求不止是能运行功能正确的代码,而是有了更高的要求,即Code for maintenance。
可维护的代码,需要清晰,可读性强,这里可读性代码检查不是指代码格式(代码格式可以通过工具检查出),而是指代码语义。在笔者的文章《软件可消费性设计》中有一些这方面的讨论和建议。

Code中的“地雷区”Review
代码中的逻辑,除了业务逻辑,还应该包括技术逻辑。技术逻辑就是实现逻辑, 比如数据库连接打开是否忘记关闭,是否正确使用线程,Exception 处理,密码是否加密存储等。
我把这些最常出现错误的地方,而且是测试不容易发现的地方,称为Code中的“地雷区”。这些“地雷区”在Code Review 中是值得花费一些时间进行维护和检查的。
建议,在整个团队中维护并共享“地雷区”注意事项列表,以及统一的处理方式和机制。并在编码和Code Review过程中都按照团队的最佳实践进行。

发现代码中的业务逻辑错误
业务逻辑指的是代码开发的功能是否符合业务需求,如一个加法函数,检查其是否真的实现了加法的功能。
笔者了解的一些敏捷团队中,把发现代码的业务逻辑错误当做目标和内容,但往往效果都不是很好,基本都是从形式上泛泛检查一番。原因有两个:
1.业务逻辑的检查是从需求到代码的全方位检查,需要花费大量时间,投入产出比失衡。
2.业务逻辑的检查和业务需求紧密关联,已经超出了检查人员的能力范围(一般Code Review是开发人员,不是业务人员)。
笔者认为,发现逻辑错误,不应该是Code Review 的目的和内容。应该是Unit Test,功能测试,集成测试的目的。从投入产出比考虑,不应该花费太多时间在Code Review 阶段去进行逻辑错误检查。

敏捷开发中不推荐的Code Review的目的及内容
下面还有一些常见的Code Review目的和内容被很多团队广泛使用,但作者认为这些并不是敏捷开发中的主要目的和内容,团队应该把时间花费在重要的目的和内容上,而不应该投入精力在下面的这些Code Review目的和内容上。

发现性能问题
有些团队把性能问题,也作为Code Review的目的和内容之一,然后提出一些如String应该使用StringBuilder,而不能使用+,类似这样的看似有用其实无用建议。
笔者认为,性能问题是需要量化的衡量和精确定位, 很难通过Code Review检查出来。而一些粗浅的性能问题可以通过一些工具方便地扫描出来,而无须花费时间去进行Code Review。
如图1是RAD V7.0 (IBM Rati onal Application Developer) 中的Software Analyzer工具带有的Performance检查:

所以笔者认为,开发人员提交的代码,需要是经过工具检查后的代码。而代码审核人员则无须花费时间在性能相关的Code Review 上。具体的性能问题交给性能测试。

发现开源的授权法律问题
开源软件也可以借助一些检查工具, 统一通过工具扫描, 无需在Code Review 阶段花费时间。

其他问题,如国际化,J2EE Best Practice等
这些问题开发人员可以在提交代码之前通过工具发现和解决, 不是Code Review 阶段的职责和目的,也无须花费时间去处理。
像FindBugs 和RAD 这样的工具就具备类似的代码检查功能,如RADV7.0 中的Software Analyzer 工具带有如下的检查功能:

1.设计原则(5):用于面向对象编程的设计原则的规则。
2.全球化(47):基于全球化编码最佳实践的规则,有助于确保代码在局部环境中正确地运行。
3.J2EE 最佳实践(32):基于最佳的 Java™ 2 Platform Enterprise Edition( J2EE)开发实践的规则,以及支持瞄准 IBM® WebSphere® 服务的Web 项目的规则;
4.J2EE 安全性(17):验证代码符合 J2EE 技术安全性需要的规则;
5.J2SE 最佳实践(71):基于最佳的 Java™2 Platform Standard Edition (J2SE)开发实践的规则;
6.J2SE 安全性(9):验证代码符合 J2SE 技术安全性需要的规则;
7.命名(2):关于 Java 代码中命名约定的规则;
8.性能(26):加强在 Java 应用程序中提高性能和减少存储器足迹的建议的规则;
9.私有 API (3):定位那些不属于 Java 代码的 API 的规则。

敏捷开发中如何开展Code Review
在清晰明确了敏捷团队进行Code Review 的目的和内容后,下面介绍如何有效地开展Code Review。

沟通、协作、互助、学习的团队氛围
Code Review 中,Review 人员和开发人员不是对立的关系,而是互助、沟通、协作和学习的过程。团队形成互助、互学的气氛,既能互相增长团队的知识和经验,还能把产品做得更好。
Code Review协作过程:
a)先由代码的开发人员向检查人员进行大体的介绍,包括设计思想、数据结构、程序代码结构介绍等。
b)双方进行讨论、交流。
c)检查人员单独进一步进行Code Review,并记录Review结果和建议。
d)由检查人员和开发人员一起,检查人员反馈Code Review结果,并和开发人员一起讨论改进方法,重构。
e)最后把可重用的Code Review的经验总结编码规范,或者记录到“地雷区”中。便于整个团队复用经验。

开展以上过程可以以开发人员为主,辅助以工具。但无须规定系列的文档、流程、Check List 等,这反而会影响开发人员的积极性。
Code Review是发现问题的过程,同时也是学习和交流过程。需要是灵活、自由、主动的态度,而不是行政上的控制和规章流程。笔者建议:和敏捷开发的核心思想一致,让团队明确Code Review 的思想、作用和目的内容后,充分发挥个体的积极性和学习分享的动力。随时随地地进行Code Review,讨论,重构,改进。

增量式Review
大家都知道,软件开发中存在长鞭效应,即一个问题越在后期发现造成的影响会越大,Code Review 也是
如此,如图4所示:

软件的开发过程中, 应该阶段性地进行Code Review,而不是等到所有代码都开发完毕后再做一次性的Code Review。那时如果发现问题,造成的改动成本比增量式的检查来的大得多。
笔者了解的一些开发团队,他们在软件开发完毕,并测试后,才临时确定Code Review的人员,然后再安排半天左右的时间进行Code Review。结果尽管发现一些结构或设计方面问题,但由于修改成本大,也无法进行改进。
正确的方式是,在早期就参与设计开发过程,抱着互助、沟通、协作、学习的思想,阶段性的参与讨论、学习并贡献自己的意见。具体Review的频率、次数则可以由开发人员抱着主动、积极的态度,按照敏捷的思想自己去把握决定。

利用工具进行Code Inspection
有很多的工具可以辅助Code Review :
1.如代码格式检查Checkstyle 工具,检查如过大的类、太长的方法和未使用的变量等这样违反编程规范的问题。
2.RAD中的Software Analyzer工具,可以基于规则进行国际化、J2EE最佳实践、性能、安全等检查。3.CSAR,用于扫描代码检查开源软件等。
4.JDepend,可以检查包依赖关系。
5.CPD工具,Eclipse 的 PMD 插件提供了一项叫做 CPD(或复制粘贴探测器)的功能,用于寻找重复的代码。
6.Eclipse 的Metrics 插件,提供了很多有效地查出代码复杂度的功能。
辅助以工具和自动化流程,能花很少时间轻松完成很多基本的Code Inspection 工作。让团队有更多的时间和精力去做更重要的Code Review。

持续自动化Code Inspection
工具检查可以由开发人员自行检查并修正, 但一种更可持续的做法是自动化的集成工具进行Code Inspection,可以通过自动化脚本在每日进行Build 前进行扫描,并呈现报告给相应人员。

Code Review协作工具
为了快速有效地进行人工Code Review协作,可以使用诸如Jupiter这样的工具辅助进行。可以帮助开发人员有效管理Code Review任务、问题、建议等。

总结
Code Review 的核心是:互助,沟通,协作,学习的过程,这是一个美妙而享受的过程,是跨越需求分析、架构设计、编码等各阶段的过程。敏捷团队应该统一达成Code Review 对产品、对团队、对个人的巨大好处的共识,发挥出个体的积极性,相信会改变“流于形式”的现状,发挥Code Review巨大的威力。
附件Pdf为完整的文章。
2010-10-23 11:49:00 qyongkang 阅读数 485
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

(本文来自《程序员》杂志0912期)http://www.programmer.com.cn/1310/ITPUB个人空间 v2Bu+j-u Y.sy%A
ITPUB个人空间&r0Y;F~ v;J!k,l%v
ITPUB个人空间FTd/kY&?

     一些敏捷团队在实施敏捷开发中忙于编码、忙于Unit Test、忙于沟通、忙于Build等,虽然也有编码审核阶段,但大都浮于表面,流于形式,效果不佳。本文结合实践,介绍笔者对敏捷开发中CodeReview的理解和相关经验。


j5~,a i@0

 

文/陈序明黄彦军

 

敏捷发中Code Review的目的及内容

做任何事情,首先要清晰为什么要做,才能有目标和动力把事情做得更好,Code Review 也是如此。只有清晰明确了敏捷团队进行CodeReview 的动机,才能以此为方向开展后续工作。下面我们推荐的敏捷开发中常见的Code Review的目的:

ITPUB个人空间 E,~3[ ~C x7|!b(e

 

设计合理性Review

在笔者的另一篇文章中《敏捷开发中的架构设计》谈到,敏捷开发中崇尚Code is design,对开发人员提出了比以往更高的要求,即需要开发人员不断地重构出合理的设计。所以敏捷开发中的Code Review也需要承担一部分“结对设计”和“设计把关”的职责。

这部分的Code Review 包括:设计的合理性(如实现方法,数据结构,设计模式,扩展性考虑等),是否存在大量重复代码和其他组件是否有重复的代码,包结构设计是否合理等。

笔者了解的一些项目中, 进行敏捷开发后, 提高了开发效率, 但是设计的质量却下降了。如RepeatYourself 的现象(特别是跨组件之间的Repeat Yourself 现象);更有甚者,在笔者看到一个某银行的应用中(不是国内的),数据库连接和操作是直接在JSP中写SQL语句。

像这些Bad Design 的例子还是很多的。这些在重构的时候应该由开发人员解决。但考虑到不同开发人员之间技术功底不一,很有必要在CodeReview阶段进行Review和讨论。

 

 

 

互为Backup

这是很容易被忽略,但是又很重要的一个Code Review的目的。

我们知道,敏捷开发中强调高质量的代码胜过详细的文档,所以某种程度上来说Code is Document。敏捷开发中的代码承担了一部分Document的职责,即传递技术的作用。

Code Review 中,Review 的开发人员了解代码的设计和实现,传递了技术,开发人员互为Backup,方便后期的维护,也减少了项目风险。

ITPUB个人空间 Y z-/p,`9N

 

 

分享知识、设计、技术

这也是很容易被忽略的一个很重要的目的。敏捷开发是一个中央集中控制到个体发挥积极性的过程,中央集中控制的优点就是有统一的视图和控制,经常开大会,开长会,这样知识和经验也较容易集中。敏捷开发中,分散在两个Scrum Team的开发人员之间,如果没有好的机制,相互沟通也会相对较少,造成知识和好的经验无法在整个团队传播。

笔者参加的项目中就碰到了类似情况, 当时我们整个团队分成三个Scrum Team,其中一个Scrum Team负责一个Eclipse 工具的开发, 其中用到的一些功能和知识在其他ScrumTeam上以前都有涉及过。当时负责开发的同事非常优秀而且能力突出,但由于不知道其他 Scrum Team同事有这方面的经验,没有很好地分享以往好的经验和知识,以至于最后导致浪费了一些学习的成本。

Code Review是一个学习和享受的过程,一个开发人员的能力有限,而Code Review正是这样的一种机制,让好的知识、设计在团队中分享,实现整体团队的成长和整体的效益最大化。

ITPUB个人空间 [/y*M)^l{

 

代码可读性

如上所说,敏捷开发中强调高质量的代码胜过冗余的文档,所以Code某种程度上是Document。敏捷开发中,代码的要求不止是能运行功能正确的代码,而是有了更高的要求,即Codefor maintenance。

可维护的代码,需要清晰,可读性强,这里可读性代码检查不是指代码格式(代码格式可以通过工具检查出),而是指代码语义。在笔者的文章《软件可消费性设计》中有一些这方面的讨论和建议。

ITPUB个人空间OBVoPn^-@x

 

 

 

Code中的“地雷区”Review

代码中的逻辑,除了业务逻辑,还应该包括技术逻辑。技术逻辑就是实现逻辑, 比如数据库连接打开是否忘记关闭,是否正确使用线程,Exception 处理,密码是否加密存储等。

我把这些最常出现错误的地方,而且是测试不容易发现的地方,称为Code中的“地雷区”。这些“地雷区”在Code Review 中是值得花费一些时间进行维护和检查的。

建议,在整个团队中维护并共享“地雷区”注意事项列表,以及统一的处理方式和机制。并在编码和Code Review过程中都按照团队的最佳实践进行。


rS5Qq;m'HvT3N0

 

 

 

发现代码中的业务逻辑错误

业务逻辑指的是代码开发的功能是否符合业务需求,如一个加法函数,检查其是否真的实现了加法的功能。

笔者了解的一些敏捷团队中,把发现代码的业务逻辑错误当做目标和内容,但往往效果都不是很好,基本都是从形式上泛泛检查一番。原因有两个:

1.业务逻辑的检查是从需求到代码的全方位检查,需要花费大量时间,投入产出比失衡。

2.业务逻辑的检查和业务需求紧密关联,已经超出了检查人员的能力范围(一般Code Review是开发人员,不是业务人员)。

笔者认为,发现逻辑错误,不应该是Code Review 的目的和内容。应该是Unit Test,功能测试,集成测试的目的。从投入产出比考虑,不应该花费太多时间在Code Review 阶段去进行逻辑错误检查。


1y&[QH![B7pOe0

 

 

 

敏捷开发中不推荐的CodeReview的目的及内容

下面还有一些常见的Code Review目的和内容被很多团队广泛使用,但作者认为这些并不是敏捷开发中的主要目的和内容,团队应该把时间花费在重要的目的和内容上,而不应该投入精力在下面的这些Code Review目的和内容上。

ITPUB个人空间(a6J.y} {8/M O

 

 

 

发现性能问题

有些团队把性能问题,也作为CodeReview的目的和内容之一,然后提出一些如String应该使用StringBuilder,而不能使用+,类似这样的看似有用其实无用建议。

笔者认为,性能问题是需要量化的衡量和精确定位, 很难通过CodeReview检查出来。而一些粗浅的性能问题可以通过一些工具方便地扫描出来,而无须花费时间去进行Code Review。

如图1是RAD V7.0 (IBM Rati onalApplication Developer) 中的SoftwareAnalyzer工具带有的Performance检查:

 

图1 RAD Software Analyzer中的Performance检查

图1 RAD Software Analyzer中的Performance检查

所以笔者认为,开发人员提交的代码,需要是经过工具检查后的代码。而代码审核人员则无须花费时间在性能相关的Code Review 上。具体的性能问题交给性能测试。

ITPUB个人空间&G!V9Ptf

 

 

 

发现开源的授权法律问题

开源软件也可以借助一些检查工具, 统一通过工具扫描, 无需在Code Review 阶段花费时间。

ITPUB个人空间wz%a[)X%V|?-s

 

 

其他问题,如国际化,J2EE BestPractice等

这些问题开发人员可以在提交代码之前通过工具发现和解决, 不是Code Review 阶段的职责和目的,也无须花费时间去处理。

像FindBugs 和RAD 这样的工具就具备类似的代码检查功能,如RADV7.0 中的Software Analyzer 工具带有如下的检查功能:

 

图2 RAD Software Analyzer中检查规则列表

图2 RAD Software Analyzer中检查规则列表

1.设计原则(5):用于面向对象编程的设计原则的规则。

2.全球化(47):基于全球化编码最佳实践的规则,有助于确保代码在局部环境中正确地运行。

3.J2EE 最佳实践(32):基于最佳的 Java™ 2 Platform EnterpriseEdition( J2EE)开发实践的规则,以及支持瞄准 IBM® WebSphere® 服务的Web 项目的规则;

4.J2EE 安全性(17):验证代码符合 J2EE 技术安全性需要的规则;

5.J2SE 最佳实践(71):基于最佳的 Java™2 Platform Standard Edition(J2SE)开发实践的规则;

6.J2SE 安全性(9):验证代码符合 J2SE 技术安全性需要的规则;

7.命名(2):关于 Java 代码中命名约定的规则;

8.性能(26):加强在 Java 应用程序中提高性能和减少存储器足迹的建议的规则;

9.私有 API (3):定位那些不属于 Java 代码的 API 的规则。


o(DWC0ZY&kQ2ig"d0

 

 

 

敏捷开发中如何开展CodeReview

在清晰明确了敏捷团队进行CodeReview 的目的和内容后,下面介绍如何有效地开展Code Review。


%/i*i2Y6R5y/uo0

 

 

 

沟通、协作、互助、学习的团队氛围

Code Review 中,Review 人员和开发人员不是对立的关系,而是互助、沟通、协作和学习的过程。团队形成互助、互学的气氛,既能互相增长团队的知识和经验,还能把产品做得更好。

Code Review协作过程:

a)先由代码的开发人员向检查人员进行大体的介绍,包括设计思想、数据结构、程序代码结构介绍等。

b)双方进行讨论、交流。

c)检查人员单独进一步进行CodeReview,并记录Review结果和建议。

d)由检查人员和开发人员一起,检查人员反馈Code Review结果,并和开发人员一起讨论改进方法,重构。

e)最后把可重用的Code Review的经验总结编码规范,或者记录到“地雷区”中。便于整个团队复用经验。

 

图3 Code Review是沟通、协作、互助和学习的过程

图3 Code Review是沟通、协作、互助和学习的过程

开展以上过程可以以开发人员为主,辅助以工具。但无须规定系列的文档、流程、Check List 等,这反而会影响开发人员的积极性。

Code Review 是发现问题的过程,同时也是学习和交流过程。需要是灵活、自由、主动的态度,而不是行政上的控制和规章流程。笔者建议:和敏捷开发的核心思想一致,让团队明确Code Review 的思想、作用和目的内容后,充分发挥个体的积极性和学习分享的动力。随时随地地进行CodeReview,讨论,重构,改进。


+~cJV-D:ZU0w.r @0

 

 

 

增量式Review

大家都知道,软件开发中存在长鞭效应,即一个问题越在后期发现造成的影响会越大,Code Review 也是

如此,如图4所示:

 

图 4 Code Review中的长鞭效应

图 4 Code Review中的长鞭效应

软件的开发过程中, 应该阶段性地进行CodeReview,而不是等到所有代码都开发完毕后再做一次性的Code Review。那时如果发现问题,造成的改动成本比增量式的检查来的大得多。

笔者了解的一些开发团队,他们在软件开发完毕,并测试后,才临时确定Code Review的人员,然后再安排半天左右的时间进行Code Review。结果尽管发现一些结构或设计方面问题,但由于修改成本大,也无法进行改进。

正确的方式是,在早期就参与设计开发过程,抱着互助、沟通、协作、学习的思想,阶段性的参与讨论、学习并贡献自己的意见。具体Review的频率、次数则可以由开发人员抱着主动、积极的态度,按照敏捷的思想自己去把握决定。

ITPUB个人空间4A@-^6] rG)vY

 

 

 

利用工具进行Code Inspection

有很多的工具可以辅助CodeReview :

1.如代码格式检查Checkstyle 工具,检查如过大的类、太长的方法和未使用的变量等这样违反编程规范的问题。

2.RAD中的Software Analyzer工具,可以基于规则进行国际化、J2EE最佳实践、性能、安全等检查。3.CSAR,用于扫描代码检查开源软件等。

4.JDepend,可以检查包依赖关系。

5.CPD工具,Eclipse 的 PMD 插件提供了一项叫做 CPD(或复制粘贴探测器)的功能,用于寻找重复的代码。

6.Eclipse 的Metrics 插件,提供了很多有效地查出代码复杂度的功能。

辅助以工具和自动化流程,能花很少时间轻松完成很多基本的CodeInspection 工作。让团队有更多的时间和精力去做更重要的Code Review。


[)O0S!UAV#I//%T5h Jf.Q0

 

 

 

持续自动化Code Inspection

工具检查可以由开发人员自行检查并修正, 但一种更可持续的做法是自动化的集成工具进行CodeInspection,可以通过自动化脚本在每日进行Build 前进行扫描,并呈现报告给相应人员。


,|dgR*Io%U0

 

 

 

Code Review协作工具

为了快速有效地进行人工CodeReview协作,可以使用诸如Jupiter这样的工具辅助进行。可以帮助开发人员有效管理Code Review任务、问题、建议等。


"i@_a2I&D0

 

 

 

总结

Code Review 的核心是:互助,沟通,协作,学习的过程,这是一个美妙而享受的过程,是跨越需求分析、架构设计、编码等各阶段的过程。敏捷团队应该统一达成 Code Review 对产品、对团队、对个人的巨大好处的共识,发挥出个体的积极性,相信会改变“流于形式”的现状,发挥CodeReview巨大的威力。

ITPUB个人空间}x*?~H#`J9L
(本文来自《程序员》杂志0912期)http://www.programmer.com.cn/1310/
N1mM}+Q.MG,V0ITPUB个人空间&C{ D E;v e7O?k

2011-05-17 10:45:00 angel_rabbit 阅读数 2703
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

from:

http://www.tup.tsinghua.edu.cn/Resource/tsyz/035257-01.doc 

 

 

 

 

 

 

 

 


敏捷项目管理模式

 

 

 

 

 

本书的第1版重点介绍了敏捷流程架构的几个主要项目阶段。然而,在过去5年中,敏捷方法已经开始广泛应用于较大型的项目和组织中,因此构建一个较为全面的敏捷企业架构显得尤为必要。例如,在大型跨国组织中,其项目并非都是敏捷项目,即使都是,某些地区可能使用不同于其他项目的敏捷方法。一个机构地区用Scrum,一个用极限编程(Extreme ProgrammingXP),而另一个使用功能驱动开发(Feature Drivern DevelopmentFDD),这种情况一点也不稀奇。并且,应该鼓励使用这种多样性的方法!因为很有可能的情况是,在中国的项目可以得到Scrum的良好支持(如培训、辅导等),而澳大利亚的项目得到FDD支持会更好些。

敏捷开发的信条之一是适应不同情况。《相互依赖宣言》的6个原则之一是:通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。因此,很难在一个跨国组织中,只使用单一的标准化敏捷方法。然而,使用一个共同的架构,而且能在其中选择各自不同的敏捷方法,对于较大型组织来讲,无疑具有很大的吸引力。

5.1  敏捷企业架构

敏捷企业总体架构如图5-1所示。投资组合治理层提供一些常见的检查点;项目管理层对各种项目的管理提供指导。项目管理层和迭代管理层不同,其差异可以洞察运行项目、制定发布计划和日常短期迭代管理的不同。最后,区分迭代管理层和技术做法层,有助于把核心技术做法融合到几个项目或者迭代管理方法中去。

5-1  敏捷企业架构

这个结构有利于组织采取混合的敏捷方法,即每层使用不同的敏捷方法,以满足组织的特定需要。该架构倡导底层(技术实践层)具有较大灵活性,上层(项目管理层)灵活性较小。这种结构认同没有哪一种敏捷方法适合所有层次。事实上,组织中使用的所有敏捷方法都是混合型的。例如,一个组织的项目管理层可能采用APM(和部分PMBOK的组合),迭代管理层用Scrum, 而在技术层选用XP做法。通过汲取几种敏捷方法的优点,公司可以构建高效的混合方法,或者可以为组织的不同部分构建几种不同的组合方法。

5.1.1  投资组合治理层

大公司拥有数以百计(如果不是数以千计)的项目。其中,有的敏捷,有的传统;有的使用这种敏捷方法,有的使用另外一种;有的使用敏捷和传统的混合方法。即使一个组织已经决心向敏捷组织转变,在维期几年的转变期间,将会混合使用各种方法。主管们需要的就是一个通用的架构,可以用来评估所有项目。这个架构涉及主管们所关心的主要问题——投资和风险。主管们想知道项目的价值(及投资回报率)和获取该价值的确定性和不确定性。他们不会真的关心需求文档是否完成了。他们想了解项目进程、投资和风险。因此无论项目是什么类型——敏捷或是其他,都需要创建一个管理机制,解决这两个关键的代表项目属性的指标。第12章将会详细讨论投资组合治理层。

5.1.2  项目管理层

许多人认为项目管理即是与核心小组的外围利益相关者打交道,而迭代管理与核心小组的内部利益相关者打交道。这的确是两者差异的一部分,但只是一半。另一个很大的不同是一个是管理发布,一个是管理迭代。一个完整的项目发布计划(见第7章和第8),涉及构建产品和团队构想、开发项目范围、设定边界和制定全面的功能发布计划。

项目管理还包括与核心小组外围的利益相关者和供应商合作。因此,项目管理层关注全面的项目/发布活动,协调多功能团队和管理项目外围事件。除此之外,像风险分析、合同管理等凡是对项目有用的做法,无论敏捷与否,都属于这个管理层的管理范畴。(这些做法可能来源自美国项目管理协会的PMBK)

需要指明的是项目管理和迭代管理是可以是同一个领导者,也可以是不同的领导者,取决于项目的大小。例如,一个有4个团队的大项目可能每个团队有一个迭代经理,整个项目有一个项目经理。

5.1.3  迭代管理层

迭代管理层关注每个短期迭代的计划、执行和团队领导。本章最后一节会概述一下区分迭代和项目管理层的原因,基本上区分的是发布和迭代工作,以及项目内部和外部的管理活动。

5.1.4  技术实践层

软件项目中的技术实践,包括从持续集成到结对编程,从测试开发到重构等做法。硬件项目可能采用一系列工程做法,从电子到机械不等。虽然本书的重点是其他三层,但是项目有效执行的基础在于技术领域。在各种各样的组织中,变革技术实践是实施敏捷方法的关键。例如,持续集成和自动化测试是不能忽略的核心敏捷软件做法。

分离出技术实践层的另外一个原因是,使敏捷项目管理更适合各种项目和产品类型。尽管我很难做到让电子工程师或者机械工程师准备结对编程,但是事实证明,敏捷软件的等值做法在各种产品开发领域都很有价值。此外,除了硬件项目中可能存在较长时间的迭代外,投资组合治理层、项目管理层和迭代层适用于想要把敏捷方法应用于非软件项目的公司。

5.2  敏捷交付架构

流程也许不如人那么重要,但它绝非不重要。在敏捷圈内,流程被指责为静止的、常规的和难以改变的。就流程本身而言,不应该是负面的,它必须同企业目标联系起来。如果目标是重复性的制造,那么常规性流程是完全合理的;而如果目标是可靠的创新,则流程架构必须是有组织的、灵活的和容易适应的。敏捷交付架构需要体现前几章描述的原则,除了支持企业目标之外,该架构还需要:

          支持构想、探索、适应文化;

          支持自我组织、自律的团队;

          根据项目的不确定性程度,尽量提高可靠性和连贯性;

          保持灵活和易于适应;

          支持流程的透明化;

          合并知识;

          囊括支持各个阶段的做法;

          提供管理检查点。

敏捷项目管理模式的结构:构想推测探索适应结束,重点在交付(执行)和适应(如图5-2所示)。它基于Adaptive Software Development(海史密斯,2000)一书提出的一个模式。

5-2        敏捷项目管理交付架构

该架构中各阶段的命名与传统的阶段命名(如开始、计划、定义、设计、构建、测试)完全不同,其意义重大。第一,“构想”代替较传统的“开始”,指出构想的重要性;第二,推测阶段代替计划阶段。每个词都传达一定的意义,而各个意义来自他们长期的系统用法。“计划”一词已经与预测和相对确定性相关联,而“推测”表示未来是不确定的。许多面临不确定未来的项目经理仍在试图“计划”排除该不确定性。我们必须学会推测和适应,而不是计划和建造。

第三,敏捷项目管理模式用探索代替通常的设计、构建和测试阶段。以迭代交付的方式,很明显探索是非线性的、并存的、非瀑布式的模式。在推测阶段提出的问题需要“探索”。鉴于结果不能完全预测,推测暗示着灵活性的需求基于现实。敏捷项目管理模式强调执行以及探索性而非确定性。实施敏捷项目管理的团队密切关注构想、监控信息,从而适应当前情况,这就是适应阶段。最后,敏捷项目管理模式以结束阶段收尾,这个阶段的主要目标是传递知识,当然它也是一个庆典。

总之,敏捷项目管理的5个阶段是:

          构想:确定产品构想、项目目标和控制要素、项目社团以及团队如何共同工作。

          推测:制定基于性能和/或功能的发布计划,确保交付构想的产品。

          探索:在短期内计划和提供它经测试的功能,不断致力于减少项目风险和不确定性。

          适应:审核提交的结果、当前情况以及团队的绩效,必要时做出调整。

          结束:终止项目、交流主要的学习成果并庆祝。

5-2展示了所有的阶段和工作流程;图5-3表示的是两个主要的合作周期(构想周期和探索周期)中的相同活动。构想周期包括构想和推测阶段(产品构想、项目目标和约束、发布计划);而探索周期包括探索和适应阶段(迭代计划、开发和审核/调整)。图5-3强调周期而不是流程,说明在整个项目中,全部或者部分构想周期可能会多次执行。例如,可能(应该)每次或者每两次迭代就需要构建一个修改后的发布计划。在费时较长的项目中,可能会定期修正整个构想周期的结果。

5-3  敏捷项目管理的构想和探索周期

5.2.1  阶段:构想

构想阶段为客户和项目团队创建构想,该构想包括什么、谁提供提供和如何提供。如果没有构想,其他的项目启动活动都是无用之功。用商业用语来说,构想是项目早期“成功的关键因素”。首先,我们需要构想提供什么,即产品及项目范围构想;其次,我们需要构想参与者都有谁:客户、产品经理、项目团队成员和利益相关方组成的社团;最后,项目团队成员必须构想他们打算如何共同工作。

5.2.2  阶段:推测

“推测”一词首先让人们想到的是不计后果的冒险,但实际上字典上它的定义是“根据不完全的事实或者信息猜测某事”,这正是这个阶段要做的事情[1]。“计划”一词具有确定和预测的含义,至少对于探索性项目来说,计划的更有用的定义是基于不完全的信息推测或者猜测。肯·德科尔评论道:“人们认为制定计划就是引进确定性,但事实并非如此。他们带来的只不过是衡量绩效的东西,而一旦这个衡量尺度与现实出现偏差,他们又不能重新计划。”敏捷项目管理包括的构想和探索比计划和执行要多,它迫使我们面对这样的现实:不稳定的商业环境和变化多端的产品开发环境。

推测阶段包括:

          收集初始的、广泛的产品要求;

          将工作量定义为一个产品功能清单;

          制订一个迭代的、基于功能的交付计划

          把风险降低策略纳入计划;

          估计项目成本,并生成其他必要的行政管理和财务信息。

5.2.3  阶段:探索

探索阶段交付产品功能。从项目管理的角度看,这个阶段有3个关键的活动区域:第一,通过管理工作量和使用适当的技术方法和风险降低策略,按计划交付产品功能;第二,建立协作的、自我组织的项目社团,这是每个人的责任但需要由项目经理和迭代领导者推动;第三,管理团队与客户、产品经理和其他利益相关方的相互交流。

5.2.4  阶段:适应

控制和纠正是这个周期阶段常用的术语。计划制订了,结果监控了,纠正也完成了:这个流程意味着计划是正确的,而如果实际结果与计划不同,则表明计划是错误的。适应意味着修改或改变而不是成功或失败。如果项目是以《敏捷宣言》的价值观“适应变化比执行计划更重要”,则将失败归罪于对计划的变动是没有成效的。非常特别的流程并不能从错误中吸取教训,而吸取教训是敏捷项目管理的关键部分。

在适应阶段,需要从客户、技术、人员和流程绩效,以及项目状况等方面对结果进行检查。该分析将会对比实际结果和原计划结果,但更重要的是,要根据项目得到的最新信息,思考实际的与修订后的项目前景。修改后的结果将反馈并应用到重新计划工作中,以开始新的迭代。 

自构想阶段以后,其循环通常是推测探索适应,每次迭代都不断地优化产品。但是对团队收集新信息来说,定期修正构想阶段也尤为重要。

5.2.5  阶段:结束

在某种程度上,项目由开始和结束来界定。由于许多组织没有明确项目的结束点,而导致与客户之间发生很多问题。项目应该以庆功典礼为结束。结束阶段(以及每次迭代末尾的小型结束)的主要目标是:学习并将学到的东西融入下一次迭代工作中,或者传递给下一个项目团队。

5.2.6  不是完整的产品生命周期

有人提醒说,本章及后面章节介绍的敏捷流程架构的几个阶段不能构成一个完整的产品生命周期。产品生命周期的前后两个阶段(早期的概念构想阶段和晚期的配置阶段)没被包含在这个架构中,不是因为它们不重要,而是因为它们超出了本书的范围。

5.2.7  选择和整合做法

接下来的几章将介绍APM交付架构每层的具体做法。这些做法应该看作是一个做法系统,因为只有作为一个系统,他们才能相互补充,从而与价值观和原则保持一致。但他们并不局限于保持一致,他们还着眼于实施。没有做法的原则只是个空壳,而没有原则的做法经常会被毫无判断地生搬硬套。没有原则,我们就不知道如何实施做法。比如说,没有简单原则,人们往往会过多地看重做法的形式和仪式。原则指导做法,做法用实际例子证明原则,两者是相辅相成。

使原则和做法保持一致昭示了这样一个现实:“最好做法”只是虚假的无法实现的梦想。对于某个项目团队非常奏效的做法也许对另一个团队是极其糟糕的。做法就是具体做法,它仅是实现一些目标的方式。一个具体做法只有在特定的环境中,才能知道它是好是坏,这个特定环境可能包括原则、问题类型(如探索性)、团队动力和组织文化。

没有最好的做法,只有更适合具体情况的做法。

后面章节中论述的做法已经在多个不同场合得到证明,其中一些可能在生产型项目中也很有用途,就像本书中没有提到的一些做法同样对敏捷项目也有用一样。在选择和使用这些做法时,作者采用了如下指导原则:

          简单的;

          再生的而非常规性的;

          与敏捷价值观和原则一致的;

          关注交付活动(增值)而非合规活动;

          最少数量(刚好可以完成工作)的;

          相互支持的(做法系统)

在后面章节中描述,基本上不是新的做法。其中一些是其他人描述的某类做法的变种,一些是为人熟知的,其他的则是人们不太了解的。例如,风险控制做法在项目管理书籍里被广泛论述,而其他的(如参与式决策)则很少论述到。因此,对于风险控制这些通用做法,将作简要论述,或者只提供其他的参考资源,而对于其他地方很少涉及的做法(如决策),将在本书中较详细地论述。

5.2.8  需具备的判断力

因为产品和项目管理长期以来受到顺序开发流程的熏染,所以看起来像图5-2那样的图例都被认为是顺序开发。尽管项目可能遵照一般的构想、推测、探索、适应和结束这个次序,但人们不应该将整个模式看作是固定的。生产型模式所用的阶段名称暗示着一个线性和重复的模式:开始、计划、定义、设计、构建、测试,而这里选用的敏捷项目管理术语是用来表示迭代演变:推测、探索、适应。

过分强调线性会导致停滞不前,而过分强调演变会导致无休止的、最终证明是盲目的变化。对于任何一种模式,开发团队成员、产品团队成员和高级主管在应用时都需要作出敏锐的判断。

关于敏捷项目管理的一个最常见的问题是:“计划、架构和需求阶段如何?”最简单的答案是:这些是活动而不是阶段。敏捷方法中这些活动所用时间和传统的序列方法一样多,只是在敏捷方法中这些活动被分配到几次迭代和多次功能开发中。

第二个令人关注的是:在初始的软件架构工作中(这节的讨论指的是构建、计划和需求)忽略了一个关键项目,而导致的敏捷开发返工的风险问题。其实与其相当的一个的更大难以形容的风险——即前期架构工作出错——在顺序开发中也存在。在序列开发过程中,早期的架构决策在项目晚期及实际的构建出现时才能得到验证。到那个时候,已经花费了大量的时间和金钱。到时再改变这个架构,就成为一项重大的耗时的决定,但通常已经不可能修改了。

一切工作都应该是循序渐进的,即使是架构开发。序列开发中前期架构出错通常意味着长期适应性较差,因为没有人能够承受得起在项目晚期再改变架构。

5.2.9  项目规模

敏捷项目管理的核心价值观和原则适用于任何规模的项目,相似的,在后面章节描述的做法也适用于任何规模的项目。但是,对于超过100人的项目团队,可能除了本书中描述的做法外,还需要其他做法或本书描述做法的延伸,其中一些在第11章会有所论述。随着项目团队不断扩大,通常需要有更多的文档、有其他的协调做法、增加仪式或者其他合规活动(如财务控制),这些扩展的做法同样也受敏捷项目管理的价值观和原则的指导。例如,简化原则仍然适用于大型项目,只不过意味着采用最简单的、适用于150人而非15人的团队的做法。

一个500人的团队可能不如一个10人团队敏捷,但它可以比竞争对手的500人团队更敏捷。只要将重点集中在价值、交付、自我组织和自律,即使团队再大,面临的协调问题再复杂,它也能随时应对商业、技术和组织的变化。

5.3  扩展的敏捷交付架构

5-4展示的是敏捷交付架构的扩展版。在这个层面上,该架构确定了做法,也有效地成为混合方法的开始。它把探索阶段细化分成在迭代期的工作。这个扩展板的架构也指出了其他每一个阶段的做法。在接下来的几章中,将会详细描述这个架构中概述的做法。

5-4  扩展的APM交付架构

5.4  结束语

像敏捷项目一样,敏捷架构应该在结构和灵活性之间保持平衡。随着组织中敏捷项目的数量和规模不断增大,组织就需要有一个通用的架构、一些通用的指导原则、少许标准做法和一套通用的价值观。同时,假如一个项目团队在中国北京,另外一个在华盛顿的西雅图,他们有着不同的团队成员和不同的环境,他们就需要拥有适应这个通用架构和做法的自由权。这就是“敏捷艺术”,即平衡结构和灵活性的能力。它用有效的领导力和敏捷经验去发现每个组织的最佳平衡点。



1. 摘自微软的电子百科全书中的世界英语词典,该书1999年和2000年版权属于微软公司。

敏捷项目管理实践

阅读数 1767

敏捷中,尴尬的pm

阅读数 904

没有更多推荐了,返回首页