发布时间:2018-08-01         浏览人次:         发布人:睿创咨询
【睿见】敏捷IPD专家一文带你了解敏捷研发

上海睿创敏捷产品开发.jpg

前言
在《人月神话》(1975年)中,软件大师Fred Brooks描绘了大型系统软件开发的“焦油坑”, 开发人员就像是被焦油坑淹没的魔兽,形象的比喻了大型系统开发是极其复杂的事情! 大师很早就告诉我们,靠加人赶进度、大团队作战、瀑布式研发、一次性研发、寻找银弹……,都是不可能完美解决问题的。有过大型复杂系统开发经验的工程师,或多或少都有过踏入“焦油坑”经历。笔者的研发生涯里,在公司未引入敏捷之前,就曾深陷过坑里。公司征调顶尖专家会诊指导,功能团队无你无我紧密协同,尊重规律高风险先行,小颗粒循序渐进,团队成员付出艰苦卓绝努力,使出了所有能想到的招数,最终延迟一年交付给客户。 其中的心酸苦累自不必多言,回顾出坑的各种“招数”,很多核心机制都和业界的敏捷开发理念、方法一致。在此从5W2H几个维度小结一下敏捷研发,希望对各位有帮助!

一、WHY-为什么需要敏捷开发?


  • 复杂系统开发中,面临着重大技术和需求的不确定性,按照1~2年甚至更长的周期收集需求、系统设计、硬件/软件开发、测试阶段进行,要么需求早就千变万化(不是客户所需),要么是在后期测试阶段面临无休止的疑难技术难题、无法上市。

  • 采用传统软件开发方法,约64%的功能几乎不被使用,这部分浪费是最棘手的问题。主要原因,一方面是需求提出者仅仅代表个体往往不具普适性,另一方面需求具有的时效性、渐进清晰性因时间不同而变化,还有就是信息传递过程失真。

二、WHAT-敏捷开发是什么?


敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法!


在2001年2月11日到13日,17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地Snowbird雪场。与会者包括XP、Scrum、DSDM、适应性软件开发和其他支持此类方法的方法学代表,它们都需要选择一种方法来替代重量级的软件开发过程。经过两天的讨论, “Agile”这个词被全体与会者所接受,用以概括一套全新的软件开发价值观,共同签署了《敏捷宣言》。

敏捷宣言.jpg

敏捷开发包括一系列方法,Scrum、Crastal、XP、FDD、ASD、kanban等敏捷开发方法论,其中Scrum和XP最为常用,并且互联网企业持续丰富着敏捷实践,然而敏捷开发不仅局限在互联网企业软件开发,还在复杂系统得到应用:


  • 复杂系统领域(硬件+软件):如电信系统,由软硬耦合互锁,向专用硬件通用化、软硬件解耦、软件定义一切……的趋势发展。以华为、爱立信为代表的传统B2B电信设备领域,也从原先的研发模式(如华为的IPD)向软硬协同的大规模IPD敏捷演进,也开创了System Anatomy(解刨)、Systemakut(系统紧急问题处理)、特性端到端、Show Demo 等。在加速新业务发放速度,同时联合客户创新、开放实验室、客户参与规划等敏捷实践,使得需求捕获更准确、业务运营效率更高。

  • 硬件为主的超复杂度系统:如SpaceX的火箭系统,也开始采用分阶段渐进实物集成等工程措施,使得火箭的研发周期缩短一倍、成本降低数倍。



三、WHEN -什么时候适用敏捷开发?



  • 技术确定、需求不确定时:通过小颗粒价值需求(或最小价值系统)开始尝试,不断挖掘真实需求、深层次需求,最快、最优命中“靶心”。如微信第一个版本只做了通讯录加好友、点对点通信,形成最小价值系统,之后逐步增加了朋友圈、摇一摇、公众号、微信钱包、微信红包等特性,逐步形成“微信帝国”。

  • 需求确定、技术不确定时:通过可掌控的初步技术起步实施,先构建一个最小可用系统,后续继续通过技术更新,快速升级系统。例如,摩拜单车最初采用摩擦生电方式为GPS和通信系统供电,之后通过太阳能板供电。

  • 需求不确定、技术也不确定时:这种情况属于“海市蜃楼”,敏捷也搞不定。

  • 需求确定、技术也确定时:是否采用敏捷已无关紧要。但是当需求很多、工作量很大时,依然建议采用敏捷,原因是多个需求或多个修改会导致新的不确定性事件。



四、WHERE- 敏捷开发应用于哪里?



  • 中小软件系统、中小颗粒云服务:适合采用通用敏捷方法,如Scrum+XP+……,实现持续交付,甚至是DevOps。

  • 大型复杂系统:大规模敏捷+联合客户商业敏捷,软硬解耦、软件松耦合,特性驱动。

  • 硬件为主的超复杂系统:商业敏捷+硬件敏捷+软硬协同敏捷,风险技术先行,早仿真、早集成。

  • 其他系统:这里的“系统”可以是软件/硬件,还可以泛化到其他各种形式的产品研发。

  • 转型变革:敏捷转型变革本身也可以采用敏捷思想和方法论。



五、WHO-敏捷实施的关键角色?



  • “规律”:之所以引入这样一个奇怪的角色,在于人对未知自然界的认知,是逐渐逼近真相的,这个角色会“强制”你不得不按照她的指引走,否则会撞得鼻青脸肿且难以前行半步,与其被动应对不如主动挖掘、应用。比如笔者曾做的一个大系统,起初希望一次规划、设计、开发、集成成型,实际结果是到了集成验证阶段问题不断、寸步难行,后来不得不重新从架构能力基础开始,按照小粒度逐个集成,一步步健康成长。

  • 销售、项目管理、产品管理、研发、服务、制造、采购、财务,都影响到敏捷的实施。纯软件领域,最为关键的是客户、项目管理、产品管理、研发,Scrum团队的三个角色协作 PO、Scrum Master、Develpor,团队具有自主需求决策和排序权力。在多Scrum团队协同情况下,需要版本火车规划和多团队协同管理;在涉及模块、器件的硬件领域,需要考虑制造、采购的特殊性,数字仿真、标准化、战略合作方式实现敏捷。

  • 客户:不论是ToB还是ToC、不论是硬件软件、亦或是其他类型产品和服务,都需要客户尽早加入, 客户的加入和必要的交流,是敏捷成功的关键。 减少中间信息传递环节,让Scrum团队直接和客户沟通互动,始终从价值和用户体验角度做最有用的需求。



六、HOW-怎样实施敏捷?



  • 明确商业目标,达成一致,上下同欲一条心。敏捷转型势必带来企业的阵痛,如果没有强大的商业驱动力则难以实施。

  • 按照一场变革(John Kotter)实施敏捷,选择敏捷变革模式,自上而下,或者自下而上的开展,也可以两者结合。亚马逊采用的是自下而上的自然生长方式,华为采用的是自上而下的高压方式。

  • 明确敏捷的实施方案,包括敏捷框架选择、敏捷实践选择、流程适配、架构适配、组织适配、渐进试点和推行计划、制定敏捷度量指标、实践总结分享和交流(敏捷大会)、持续改进。例如以IPD为基础的企业融入敏捷方法,大规模敏捷理念与IPD核心理念并不矛盾。在流程实例化时,按不同业务场景形成场景化IPD,使得流程服务好业务,敏捷融入流程中。



七、HOW MUCH-敏捷做到什么程度?



  • 相关业务目标达成。高质量、快速的价值交付(TTM,Time To Market),需要来自客户的评价,自我的认识,与竞争方(含潜在竞争方)的对比,能力要处于领先集团。

  • 管理实践成熟度较高。角色能力成熟,表现为组织扁平、角色间协同好、角色足够精简、具备自主决策能力、自我激发;需求管理能效高,表现为积极快速响应变化、自主决策、聚焦价值、滚动排序,并且信息传递有效;项目计划以客户价值驱动、全员参与、及时更新、进展全员可视;团队成员自主性程度高、自我驱动。

  • 技术能力匹配到位。持续架构设计或及时重构,设计进迭代,满足敏捷实施;持续CI、CD,能够高频率交付;流程无人值守,工具集成质量门禁、自动判决;环境使用代码化,自动化测试(含DFX),全量测试进迭代;并行、独立配置管理,全配置项可回溯、可追踪。


Finially ,remind you:Be Agile, not Do Agile (骨子里的敏捷,不做形式上的敏捷)


本文作者:江行,敏捷IPD专家

商业转载请联系作者,非商业转载请注明出处


地址:上海市黄浦区淮海中路222号力宝广场26层

电话:021-60314103/ 0755-33584198

E-mail : market@jswbc.com


关注我们:
点击更换验证码

©2010  睿创咨询  版权所有  

友情链接:  

快三彩票 快3彩票 快三彩票 极速快三 湖南快乐十分 快三彩票 快3彩票 快三彩票 快三彩票 快3彩票