您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
   
 订阅
  捐助
规模化敏捷框架SAFe学习有感
 
来源:网络 发布于: 2017-6-2
  3067  次浏览      18
 

当前,互联网+快速发展,对金融行业产生巨大冲击。互联网金融的到来,更是使传统银行业面临如何尽快占领互联网金融市场的挑战,在互联网金融新特性的驱使下,实现传统银行业务电子化的科技手段成为先导及载体,其是否能快、好、准的实现业务价值,将是市场竞争中的重要因素。

另外,软件开发方法从十七世纪培根提出“假设、实验、评估”的迭代雏形到1971年的瀑布开发方法,再到二十一世纪Agile的诞生,根据其自身的需要经历着不断优化与创新。到2000年初,敏捷思想逐渐进入中国,给中国的软件开发产业尤其是互联网相关的软件开发产业注入了新鲜血液,人们不断注意到agile在应对市场的灵活性以及应对客户的高满意度方面表现出来的强大优势。面临着软件开发方法的不断变革,作为软件行业自身,势必进行着内部不断优化。

在如此内、外部压力下,传统领域的软件行业均迅速反应,做出应对,在如何快速实现业务价值、如何不断优化自身开发方法方面应进行着agile 尝试及创新。但银行业的软件开发也有其特殊性,原有大型组织架构也是敏捷转型的一大障碍,如何在现有银行体系下进行本地化敏捷导入,进行敏捷适应性调整,将会是转型以及长久应用的关键。因此,近期借着中心组织规模化敏捷框架SAFE培训的机会,对SAFE框架进行了系统的学习。

一、SAFe是什么

1、整体框架

SAFE框架提供了三层管理模型,分别由项目组合、项目集、实施团队构成。具体详见下图。

项目组合级别:主要通过EPIC看板系统进行企业级业务、架构等战略决策的集中处理,并通过多部发布火车进行分布式实施,此过程通过投资主题为版本发布火车提供运营预算;

项目群级别:关注某一个基本产品、解决方案或价值主题目标的产品或团队工作的特性和组件之间有高度的相互依赖的产品在一辆发布火车中,通过项目集层面的节拍与同步化,多个团队在进度、范围方面产生对齐,帮助管理风险,并与组织价值流保持一致,实现企业级愿景;

团队级别:各实施团队利用现有的SCRUM、XP实践实现增量交付,创建项目群的愿景、架构和用户体验。

2、需求管理模型

大型复杂需求在企业是很常见的,这些需求特性可能来自多个产品团队,很多特性存在相互依赖,也存在优先级的冲突,这样拥有共同商业价值的需求会被放进一个共同的计划中,由多个团队紧密合作来实现。SAFE框架为这个挑战提出了三层管理模型的解决方案。那么现在再来审视这个框架,这里对需求进行了层次化管理从投资主题到篇章,从篇章到特性,再到故事以及实施任务。

从项目组合开始,通过企业级的投资场景看板来提取出符合企业发展愿景的高优先级epic,传递给项目集的产品管理团队来产生特性及通过优先级排序的特性待办列表。项目集的产品管理团队是由项目集的产品管理人员和各个项目团队的产品负责人组成,最终由各个团队实现相关的故事,因此能够保证产品管理的一致性。

3、架构管理模型

需求与架构是硬币的两面,反映在需求表达中的“系统必须做什么”和反映在架构结构中则是“为了满足需求,系统将如何构建”,因此他们不是孤立的。对于架构方面来讲,也应像需求一样存在组织级大规模企业架构到项目集架构最终到团队开发层级可控的架构层次。同时,在系统本身也存在纯架构方面的大型调整,比如影响多种产品和服务的技术变化、公共的架构治理、通过基础设施与避免重复工作量而进行的通用架构调整、结构创新等等。虽然敏捷中未定义架构师这类角色,认为设计架构是涌现的,是全权由团队负责的,但面对如上所述的全局或企业级、多产品级架构时,架构师或技术委员会必不可少。参考SAFE中提到的看板制度,具体如下。

由架构管理部门识别所有的大型架构需求,将满足决策准则的内容提升到待办事项队列中。

对投入到待办事项队列的大型架构内容需要进一步评估,包括成本、价值、技术层面调查。此时随着投入的增加,队列需要有WIP限制,以便限制过程中的活动条目数量。

到达分析阶段,需要进一步的分析架构内容,此时需要架构师负责并启动与开发部门的积极协作,在WIP限制下进行替代方案设计、建模或确定采购/内部开发之类工作。

从分析到实现,是一个重要的经济决策,因此需要产品/技术进行审批把控,最终到达实现层级的架构内容,需要架构师辅助团队直到其对所需完成的工作充分理解。

SAFe带来什么

对以上规模化敏捷SAFe的具体内容思考,它能给我们带来什么?

首先,其引入了大型需求、架构如何从愿景到实施团队的层次化管理。

其次,业务师、架构师、PMO、质量管理等人员可以考虑如何在各层级的介入,比如在项目组合级别、项目群级别如何介入;考虑需求及架构的识别、评估、分析、分割、排优等。

第三,对传统项目、传统管理方法的启发。比如如何利用精益敏捷方法对传统需求价值评估、如何从“项目管理”到“持续内容管理”转变、对传统单项目管理思维的优化、从里程碑治理到基于事实的治理等。

以上是本人在学习中的所思、所感,具体的想法还需在专业领域中不断的摸索、实践,也许存在不合适的地方,欢迎拍砖。

   
3067 次浏览       18
 
相关文章

CMM之后对CMMI的思考
对软件研发项目管理的深入探讨
软件过程改进
软件过程改进的实现
 
相关文档

软件过程改进框架
软件过程改进的CMM-TSP-PSP模型
过程塑造(小型软件团队过程改进)
软件过程改进:经验和教训
 
相关课程

以"我"为中心的过程改进(iProcess )
iProcess过程改进实践
CMMI体系与实践
基于CMMI标准的软件质量保证