敏捷的HARD模式：产品经理视角 Be Agile The Hard Way — from PO Perspective

窦 涵 之

敏捷的HARD模式： 产品经理视角

Be Agile The Hard Way — from PO Perspective

窦 涵 之

June 08, 2012

Scrum Gathering Shanghai 2012 Conference

自我介绍(short)

窦涵之 Dou Hanzhi (http://weibo.com/hanzhidou) 15年软件从业经验，做过程序员、开发组长、项目经理、架构师、产

品经理, 6年多敏捷实践经验, 其中约3年时间领导诺西LITE部门百余人团队持续探索敏捷实践, 最终获得高度认可

2011年3月创办苏州簇格软件(http://cugesoft.com)，致力于打造新

一代软件产品研发管理敏捷工具与支撑环境 如今依然坚守代码一线,身兼数职走在艰辛之路上的创业者、思考者、

人生意义的探寻者 苏州敏捷社区发起人和组织者(http://q.weibo.com/572814), 马拉松

跑爱好者

内容

什么是敏捷? 敏捷的HARD模式 PO的原点与力量之源 结合自身经历的案例分析

什么是敏捷: 动态行为判断法

如果它看起来像鸭子，游泳像鸭子， 叫声像鸭子，那么它可能就是只鸭子

什么是敏捷: 敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法，

身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 也就是说，

尽管右项有其价值，我们更重视左项的价值。

什么是敏捷: 敏捷宣言遵循的原则(1)

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

什么是敏捷: 敏捷宣言遵循的原则(2)

可工作的软件是进度的首要度量标准。 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

以简洁为本，它是极力减少不必要工作量的艺术。

最好的架构、需求和设计出自自组织团队。 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

敏捷的HARD模式： 以戒为师

诸恶莫作，众善奉行，自净其意

责任，勇气，专业, 热情，自律，利他 原点思考，现场中心，注重实效 对软件产品而言, 源代码即为现场

敏捷的HARD模式： 体察情景，以不确定性和约束为友

承认现实，立足现实，不抱怨，不放弃 拥抱变化，警觉时机，力促变革，谋求突破

循环上升，永无止境

敏捷的HARD模式： 培养胆识，坚持愿景

走出舒适区, 大胆冒险，接近危险边缘,不断打破与重建信心

革新精神，雄心壮志，网状组织，团队协作

设立目标时以将来的能力为基准，努力提高自身与团队能力去达成目标

敏捷的HARD模式： 刻意练习，持续改进

有意注意，聚焦提高，养成优良的行为习惯

不断练习使直觉接近于真相，使本能按训练的方式反应

反思,前瞻，审视与调整 付出不亚于任何人的努力

产品经理: PO的原点

从愿景到交付:做自己负责产品的CEO, 企业家精神

对产品客户而言，代表开发团队 对开发团队而言，代表客户 利益博弈时的选择： 恪守价值观与原则 多赢思维 生态链系统思考，长线布局

产品经理: PO的力量之源

专业能力带来信赖 优秀的PO,既能领军打仗，又能单兵突击 平衡需求与架构,恰当排定优先级，准确把控进度 以团队成长为核心,优秀产品是优秀团队的自然结果

态度与意识引领未来 从知识，见识到胆识;从感知，预见到布局 创新意识与冒险精神, 突破困境的意志力 注重实践,给出结果

抛弃层级思维，多维度构建虚拟网状关系, 提高沟通与协作能力与效果

不计较短期个人得失，有勇气选择HARD模式 有兄弟，不孤单 感恩的心

产品经理: 什么背景的人适合做PO?

架构师？ 项目经理？ 质量经理? 业务分析师？ 谈判高手? ... 取决于产品风险所在, 以及具体个人的快速学习和适应能力

案例：L团队敏捷之路 虚拟架构组 - 事件与目的

事件：07年上半年我作为工作在普通Scrum小组中的架构师开始筹备组建虚拟架构组(Virtual Architecture Team), 简称VAT。 成员来自各个Scrum小组，皆为在各Scrum小组具有技术影响力的开发人员,部分成员有我直接邀请指定，部分由Scrum Master或Line Manager推荐，完全以能力和需要而定，可走可留，不看此人的Job Grade, Title,也不看工作经验

目的: 协调架构设计，确保系统的概念完整性和逻辑一致性,

共同讨论解决技术问题, 做出的决定必须执行

案例：L团队敏捷之路 虚拟架构组 - 缘由

我在此之前，长期负责一个CCC的技术支持小组，该小组是虚拟的，我并无任何直线经理权限,运作一直良好, 对虚拟组织能发挥的作用比较有信心。

同时在此之前的Scrum团队工作中，感受到过度强调“Team

Decides”,对“team”概念的狭隘理解而导致的各小组之间的不一致和缺乏系统整体观, 希望借助VAT能得到纠正

案例：L团队敏捷之路 虚拟架构组- 结果

VAT大获成功，完全依靠VAT, 产品技术问题得以解决，不再需要一个专门的架构师组织,依然保证了产品的高质量

VAT机制被复制到老产品线和其它部门。 以VAT的原则，同下游产品

部门的技术交流也得以建立 后期VAT也邀请了来自老产品的技术专家，无须触动组织结构，使经

验交流和技术讨论得以顺利进行 部门人数渐多时根据领域拆分出了各个VAT, 同时保留总的VAT VAT成员个人也得到了良好的发展

案例：L团队敏捷之路 虚拟架构组 - 感悟

组建强大的核心团队,热别是具有自我更新能力的团队是成功的基础

不要太在意自己是否得到正式授权，要有勇气去发起自己认为对的事情

自组织的团队更有激情，更高效, 自己的实践印证了这一点

问题？

致谢

感谢在诺西工作期间一起奋战过的所有兄弟们在过去数年的鼎力支持 感谢在我敏捷之路上的所有导师和朋友, 有的从事敏捷教练工作,有的是老同事，有的

来自社区 感谢冯欣邀请提交话题 (@大熊Stanley http://weibo.com/cudb ) 感谢大会组委会提供的分享机会及改稿意见 感谢敏捷苏州社区的朋友们在试讲中提供的意见 感谢分会场主持人程小又的组织 (@Corrine_Cheng

http://weibo.com/u/1867489074) 敏捷宣言与原则采用的是徐毅主持翻译的官方版本(@徐毅-Kaveri

http://weibo.com/kaverjody) “源代码即为现场”来自陈加兴 的微博(@陈加兴 http://weibo.com/silentriver) 图片来自互联网

谢谢！

更多内容...

L团队敏捷之路及我的PO历程 基本背景

L团队早期核心成员来源于公司05年底Scrum试点产品开发组，我06年上半年作为Linux计算平台架构师加入该产品线

数月后该产品线大部分工作暂停，除留下少数人继续开发外，其他人回归老产品线，我任了一段时间的临

时PO 07年初迎来新机会,该小组被分派开始做一个基于全新硬件和Linux的产品F, 由于诺基亚网络部门与西门子

通信部门合并，从西门子吸纳了一些新成员，又从社会上招聘了一些,逐渐形成了三个开发组, 大部分人不具有老产品线开发背景,典型的“乌合之众”。 在此期间，一个来自西门子的德国同事任PO，此时所有该产品人员在Scrum小组工作，我也不例外, 同时依然任架构师，并辅助德国同事的PO工作

08年６月所在部门开始开发另一个全新产品Ｌ，产品Ｆ开发工作移交给印度, 我开始担任正式PO.产品L功能

要求与老产品线一样，但硬件架构和软件架构不同，由于老产品线 进度紧张，几乎所有有老产品线经验的人都撤回去了，老产品线的架构师组、SCM组，集成测试组等等在产品Ｌ开发早中期阶段都没有参与, 一切皆须靠自己

产品L的开发和管理人员借助敏捷实践, 怀着激情与梦想、自组织与自我领导, 主动求变, 依靠“杂牌军”在

起初不受重视的新产品领域团结协作，不断创新与寻求突破，从开始的三个开发组发展到我离开时的100多人，在有芬兰和印度竞争的情况下，负责领域越来越多,产品质量和进度获高度认可，可谓夹缝中的野蛮生长

L团队敏捷之路及我的PO历程 影子核心：虚拟架构组

事件：07年上半年我作为工作在普通Scrum小组中的架构师开始筹备虚拟架构组(Virtual Architecture Team), 简称VAT. 成员来自各个Scrum小组，皆为在各Scrum小组具有技术影响力的开发人员,部分成员有我直接邀请指定，部分由Scrum Master或Line Manager推荐，完全以能力和需要而定，可走可留，不看此人的Job Grade, Title, 也不看工作经验

目的: 协调架构设计，确保系统的概念完整性和逻辑一致性, 共同讨论解决技术问题, 做出的决定必须执行 缘由： 我在此之前，长期负责一个CCC的技术支持小组，该小组是虚拟的，我并无任何直线经理权限,运作一直良好, 对虚

拟组织能发挥的作用比较有信心。 同时在此之前的Scrum团队工作中，感受到过度强调“Team Decides”,对“team”概念的狭隘理解而导致的各

小组之间的不一致和缺乏系统整体观, 希望借助VAT能得到纠正 结果： VAT大获成功，完全依靠VAT, 产品技术问题得以解决，不再需要一个专门的架构师组织 VAT机制被复制到老产品线。 以VAT的原则，同下游产品部门的技术交流也得以建立 后期VAT也邀请了来自老产品的技术专家，无须触动组织结构，使经验交流和技术讨论得以顺利进行 部门人数渐多时根据领域拆分出了各个VAT, 同时保留总的VAT VAT成员个人也得到了良好的发展 感悟： 组建强大的核心团队,热别是具有自我更新能力的团队是成功的基础 不要太在意自己是否得到正式授权，要有勇气去发起自己认为对的事情

L团队敏捷之路及我的PO历程 最佳实践基石：ATDD & CI

事件一：自08年以来, 我和具有开发背景的直线经理，以及部分VAT成员，开始推动ATDD的工程实践，我们做了大量的讨论和对员工的培训，以及邀请自动化测试专家辅导团队， 着力改善工作方式

事件二：08年夏在产品Ｌ开发之初，在一次VAT会议上痛感当时CI与理想差距甚大，大家觉得应由强有力的高手专门负责CI，秦之远主动请缨，遂当场决定由他全面负责CI改善

目的: 希望借助ATDD与CI的结合大大提升软件质量和交付能力 希望扭转不利局面. CI对加速质量反馈和提高工作效率的益处大家都清楚，在任务艰巨，状况不佳的境况下加大投入，

大胆授权,由专门高手负责可使状况发生根本改观，进而培养全体人员的良好习惯。 缘由： 自新产品F开发以来，CI就一直在运转，但仅停留在编译和UT阶段, 相较其它部门，当时也算处于领先水平，但由于CI

维护由Scrum小组轮流负责，投入不够,离理想局面相距甚远。 我在产品L启动之初，就曾计划全面的分层CI概念，从最基础的UT、功能性验收测试，到高可用性(Availability)和性能

(Performance)驱动的验收测试框架，但只是停留在纸面上和在VAT的内部讨论上。专人负责建立强大的CI系统是全面实施我想法的必要步骤

结果： CI系统确保了产品的高质量和按时交付, 我最初的设想大部分得以实施，同时也发展出更好的做法 经过几年的坚持，L团队的CI系统逐渐得到认知，并得到全公司范围内的官方认可, 很多做法在其它产品线得以传播. 秦

之远也成为负责包括老产品线的范围很大的CI系统的PO 感悟：有些实践必须要足够的人员投入. 激发任用有激情的人很关键。在实施的过程中，由于很多创新做法，常常

受质疑你为什么跟别人不一样，只要有好的结果，一定要顶住压力，坚持创新，以成果说话，最终会获得认可

L团队敏捷之路及我的PO历程 开疆拓土：扩大负责范围

事件一：定位之争, SCM流程之辩：负责底层开发的部门尝试定位L为Module, 我们坚持定位为Middleware, 进而定位为涵盖底层的新一代平台.

事件二：负责范围从DC到Transport, 再到CM 缘由： 新产品L严格说来只是整个产品里的Middleware, 底层服务有公司国外另一部门负责，由于是新产品，大家对产品的理

解有差异，有很多模糊地带职责不清。如何构建产品级的SCM流程是需要讨论决定的事情之一, 有些工作上层经理也不知道应该谁负责, 如何做，最早杭州负责的只是DC部分

从本地员工和团队发展出发，本地管理人员和员工都希望能多一些有挑战性的工作拿到本地. 做法: 我以前曾担任了几年公司一种开发环境的Key User, 对SCM相对熟悉，作为PO, 同时作为SCM“专家”，通

过同SCM同事的合作，从整个系统的角度，提出详尽的解决方案， 本着专业精神，据理力争。 激发团队，把现有工作做好，提前作布局，研究学习相关领域，用实力和事实说话 同相关经理紧密合作，配合他们的工作 建立多通道直接对外联系，在第一时间提供专家参与早期需求技术讨论，逐步增强话语权。 这些负责高层需求的人员

很希望能有真正一线的技术专家参与讨论，很多由谁做如何做的决定也是在此类会议上很快定下来的，就像我们VAT团队决定了很多似乎超出职权范围的事情一样。

结果： 几经波折，事实证明我提供的SCM方案是真正可以执行的，赢回了主动。 通过实力和结果，在各个技术领域，负责范围也是越来越广 感悟：我们需要从全公司整体利益出发考虑问题，同时在不损害该前提下，也要照顾到工作最密切的相关经理们和

员工们的愿望，营造多赢局面。否则一味死脑筋或不作为，很可能丧失自己的影响力基础 预见力与提前布局，以及有勇气接受挑战并战而胜之很重要

L团队敏捷之路及我的PO历程 Agile Scaling：PO Team

事件：到了09年下半年，随着负责范围的增多，人员也越来越多，一个ＰＯ直接负责的Scrum Team已经多到无法承受。其它部门也一直有PO对应team太多的问题，变革势在必行.

缘由: 由于一个PO对应的team太多，其它部门已经出现有team抱怨一个Sprint都见不到PO的现象，经过产品经理

团队和相关负责人讨论，上层决定各PO可以扩展成PO team, 具体安排由PO和对应的直线经理负责 做法：我组建了一个多职能的PO team, 从原VAT中挑出两人各全职负责几个team, 另外增加一人负责整体架构，

另一人负责整体测试, PO team只是他们工作的一部分. 结果： 通过此种安排，分担了PO工作量的同时，也保证了PO仍然能够在需求上掌控全局，通过同架构师和测试专家的紧密合

作，有助于预知风险和采取应对措施 同时也很好地培养了后备队伍，任何人的离开，包括我，不会影响到大局 感悟：不要墨守成规, 变则通, 在变化中抓住机会实施自己的想法

L团队敏捷之路及我的PO历程 其它创新实践

TPE(Team Performance Evaluation) Overall Sprint Review Quality Audit Day Tech Talk Afternoon Continuous Planning and Review Item Box within Sprint Time Box Backlog Grooming with 6Hats Availability Testing Framework Performance Testing Framework ATDD Template Token based CI Stop & Fix Rules DoD Checklist Triangle Communication Meeting Etc.. (Note: 这些实践并非全由本人发起)

自我介绍(long)

窦涵之: 1997年3月硕士毕业于浙江大学, 15年软件行业从业经验, 先后在不同类型公司担任过软件工程师,开发小组主管，项目经理，技术负责人，软件架构师以及Scrum模式下的产品经理(Product Owner)， 现为簇格软件创始人兼CEO

1997年以C语言为主开发证券行业相关软件 1998年首次作为小团队负责人成功主导基于Microsoft IIS,SQL Server, ISAPI, C++语言的B/S架构信息系统开发 1999年至2002年8月, 担任开发小组主管,项目经理和技术负责人开发了多个特定行业信息管理系统及软件部件. 工作方式以

类传统模式和RUP为主. 2002年9月加入诺基亚, 从事通信设备产品开发, 负责嵌入式操作系统内核以及分布式核心系统服务开发与维护, 并领导杭州

内核及分布式计算平台专家组向全球同事提供技术支持. 期间开始接触并实践极限编程,代码与文档评审,测试自动化之类工程实践, 并参与流程改善讨论, 测试自动化框架开发. 同时作为CVS, Clear Case, Subversion关键用户(Key User)及管理员(Concept Owner)对版本控制与管理积累了丰富经验.

2005年底公司开始推行敏捷转型, 2006年初作为Linux平台软件架构师加入Scrum团队, 期间由于转换开发另一新产品, 担任了数月过渡期的Product Owner.

2007年继续担任基于全新硬件及Linux平台的软件架构师,并作为Deputy Product Owner辅助德国同事的PO工作, 领导虚拟架构师专家组, 并主导推行新的工程实践和流程改进, 包括多层次测试驱动开发,分级持续集成, 代码评审等等

2008年正式担任Product Owner, 领导从开始的3个Scrum teams逐步发展到2010年的100多个工程师, 16个scrum teams, 期间组建了Product Owner小组以应对规模扩展, 通过不断改进团队协作方式及工程实践, 产品开发速度和质量获得上层高度认可, 在此期间积累了丰富的大规模团队实施敏捷的实战经验, 逐步形成了自己的敏捷思想体系.

2010年4月在Scrum Gathering Shanghai 2010作为讲师分享了主题为ATDD和CI 的演讲 2011年3月初开始自主创业, 创办苏州簇格软件有限公司(http://cugesoft.com), 致力于开发基于云平台的新一代软件产品

开发敏捷管理工具,软件开发测试环境和支撑平台, 并提供敏捷转型,相关咨询和培训服务. 2012初发起和组织敏捷苏州社区活动(http://q.weibo.com/572814)，致力于推广敏捷思想,方法论和最佳实践,希望籍此增

进苏州IT业人士技术和管理交流，同时能够作为苏州与其它敏捷社区交流的平台和桥梁. 马拉松跑爱好者，参加过厦门马拉松，杭州马拉松，苏州半程马拉松以及2010年的拉萨马拉松挑战赛

谢谢! once again:-)