【读书笔记】深入核心的敏捷开发:ThoughtWorks五大关键实践

亚马逊买的电子版,2天看完。

有时间再慢慢来谈感悟,下面分享俺的Kindle读书笔记:


第1-3章  

ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60%Scrum+40% XP”的经典答案

ThoughtWorks敏捷开发的核心原则:价值驱动与技术卓越。

Scrum的燃尽图并不推荐,原因是很容易营造一种遵循计划的假象。

ThoughtWorks持续集成纪律有两个核心:第一是必须每次提交触发构建;第二是每次提交必须基于上次的成功构建。这两条纪律是底线。

评审会,Sprint Review Meeting —>Showcase展示会

ThoughtWorks敏捷开发实践方面特别注意不会聚焦到个体,比如我们说到的Story估点和Velocity统计都是团队为单位,不会指定或统计到个人。 迭代过程中的缺陷也不会追溯到某个特定开发人员。

该项目经理是个高人,他在项目开始的时候,问清楚每个人擅长的部分,然后让每个人去做自己不擅长的部分,不会?去找擅长的人帮忙。

在ThoughtWorks,我们认为,软件开发中的一切问题,根本上都是人的能力问题。如何发展每个成员才是问题的关键。如果成员没有进步,始终是治标不治本的。所以我们采用的一切实践,不管是以前曾采用的还是以后会采用的,核心目的都只有一个:发展人的能力。因此才有了那个听起来很耸动的口号:“把项目成功交付当成能力建设副产品。”

把交付过程中的一切活动都看作能力建设,把整个团队构造成促进每个成员成长的生态系统。

因为大部分的IT项目都可能失败,成功对于IT项目而言很可能是“不失败”。

而“控制需求”成为了“控制风险”中最重要的一环,换言之,对于一个失败的项目而言,需求未得到有效的控制,往往是最重要的原因。

“没有这个功能,我们不能上线。” 必须据理力争,请坚信,没有阻止上线的功能,只有阻止上线的、不理智的、缺乏安全的客户。


第4章 基于用户故事的需求及范围实时管理 

“控制需求”成为了“控制风险”中最重要的一环,换言之,对于一个失败的项目而言,需求未得到有效的控制,往往是最重要的原因。

业务分析师常常被形容为产品和交付之间的桥梁,产品经理把握产品走向,聚焦产品成长;业务分析师则往返于产品经理和程序员之间,专注如何迅速有效地让产品落地。

在拆分完成进行复检时,敏捷团队(而不仅仅是 BA),可以问自己下面这几个问题。

1. 客户所处的行业是什么?

2. 本行业有没有固定的业务领域模型?

3. 客户想做的是哪个模型的扩展?

4. 有没有类似的竞品可以参考?

5. 有没有考虑系统交互的全部的用户角色?

6. 有没有系统自动推进、不需要用户交互的任务?

7. 有没有考虑全部的业务场景?

8. 正常的场景和异常的场景?

9. 每个场景的每一步是如何对接的?

10. 具体的详情是什么?

11. 是否可以进行进一步拆分?

12. 每个环节使用的用户数量是多少,会有性能要求么(精确到每个指标)?

13. 系统边界是什么?

14. 待开发系统和待集成系统各自完成的业务功能是什么?

15. 是全新的系统,还是需要与旧有系统做数据迁移,逐步替代?

16. 是否有逐步替代的计划和方案?


第7章 组建人人深度参与的统一团队 

对于“坐在一起”的敏捷团队,沟通会在工作和相处中自然而然地发生。

远程协作编辑软件市面上的远程协作软件

1. Keynote- Collaborate Mode: Keynote算得上我们目前使用最为频繁的演示软件,而它的 Collaborate Mode这项高能技巧好像并不是那么知名。

2. RealtimeBoard

3.即时通讯工具:常见的主要有 Skype, Lync( Skype for business), Slack, HipChat, Hangouts等。目前我们项目正在用的是 Hipchat,比较突出的亮点是不用翻墙,可以与 Jira, Github集成,缺点主要是记录保存时间较短。


第8章 为什么你的Scrum会失败?

换句话讲, PO通常是资方而不是劳方的人, PO要么是给项目提供资金的人,要么是他的代言人。通常出钱的人是老板,很忙,在大的组织里不太可能直接出任 PO,但他必须把他的职责代理给某个人,而这个人是要对产品的成败负责的,出了事之后他要负主要责任。

在我见过的运行比较好的 Scrum团队中,担任 PO的人都满足上述任职资格,包括客户本人,包括从头到尾负责一个产品很多年的人等。而运行的不好 Scrum团队中, PO通常由原先开发团队中的业务分析师担任,仅具备一定的业务能力,而没有商业上的资格和权威。

Scrum Master的使命就是把自己做没,不是做媒,是做没。

如果团队在众多内部关于流程/活动/角色/职责等事情上需要 Scrum Master的干预,则离自组织还很远。

那为什么球队永远都需要一位教练?答案很简单,因为球队教练的职责是赢球,而不是教会球员自组织。如果他通过让球员在场上自组织来赢球,那球队确实对他的依赖会减少。

 PO自己搞定规划, PO和团队一起开工,团队自己搞定怎么做。 IPM不占开发团队时间, IKM两个小时足够,其他的讨论分散在开发过程中。

站会/回顾/评审会议,都涉及调整。开完会后没什么调整,这个会就白开了。


第9章 技术领导者即服务 

技术领导者需要扮演三种重要的角色:技术决策者、流程监督人和干扰过滤器。一支团队能否有效采用架构最佳实践、交付流程最佳实践和项目运作最佳实践,很大程度上取决于技术领导者把自己的工作完成得多好。


第10章 项目管理中的敏捷实践 

唐僧师徒可以被看作敏捷中的全功能团队:团队有共同的目标“取到真经”;他们历经了九九八十一难,好比九九八十一个迭代,每次打怪成功都是完成了一次交付;在不断迭代的过程中,这个团队不断地收集反馈、持续改进,一步步地完成了最后的目标。取到真经,意味着完成了项目的交付,同时使得团队能力得到质的提升。这是一个美妙的结果。

-----大强评:唐僧师徒这段是印象最深刻的描述-----

ThoughtWorks,有一个非常有名的活动叫 Inception。 Inception是启动软件设计和交付项目的方法,通过集中式、互动式的设计工作坊,帮助客户在最短时间内对项目范围达成一致,快速进入项目交付。而 Inception的一个产出就是沟通计划( Communication Plan)。比如在这个沟通计划中会讨论:以什么频率、什么形式作项目的更新,比如说每周五以周报的形式作一些主要信息的更新;站会和迭代会议什么时候召开,需要邀请哪些人,比如业务负责人和技术负责人等。


第12章 团队敏捷转型的三个阶段

有些人说为什么不从技术实践开始?设想一下在瀑布式开发中,开发团队几周甚至一个月才交一次版本给测试团队,在这种情况下,开发怎么会有动力写自动化测试?运维怎么会有动力做自动部署?需求没有妥协的空间,设计没有妥协的空间,导致团队的痛点永远是按时交付,质量一定会被牺牲掉的。因此只有先强制缩短交付周期,让团队痛点转移,才能改变开发人员对质量的观念。至于这个过程中导致的交付速率降低,我们的观点如下。在敏捷转型前期一定是有所付出的,然而你投入越多,进展就会越快,收益就会来的越早。没有质量的交付不能称为完成,只能叫半成品或者次品。

很多财大气粗的企业一定想知道有没有什么捷径,我的答案是有:敏捷转型的过程就是培养大家能力的过程,既然终点是所有人都拥有很强的能力,那为什么不在一开始就找这样的人来工作呢?


第13章 绩效考核,敏捷转型的鸿沟 

传统管理方式跟敏捷价值观之间的冲突,其表现如下。经理:敏捷追求的是打造自组织团队和成员能力多样化,那么我如何考核某个员工做得好还是不好?有哪些新的 KPI?经理:是不是可以按照一个员工完成的用户故事点数来考核他的年终绩效?经理:怎么样才能促进团队成员之间多协作?一个团队成员请假,这部分工作就搁置在那里了,要是能多协作,就可以替补一下。经理:小李,你看这个任务你来吧,这周五能不能完成?(殊不知,小李心里想的是本周五休假陪老婆过生日) Scrum Master:为什么站会的时候大家都各自更新各自的,没有任何“相互关心”的交流,站会没啥用啊!团队成员:我在迭代开始已经认领卡,我这周快做不完了,为什么要帮他啊?而且我的确不懂他那一块啊!团队成员:今年的绩效考核我的目标已经定好了,如果达不到,我的工资就加不了多少,我还是多关注自己的事情吧。以上表现,究其本质原因,就是传统的绩效考核方式跟敏捷价值观和原则的冲突。

为了打造高绩效敏捷团队,结合传统公司的管理方式,作为启动,管理者需要把握三个关键“考核”思想的转变。 

1.从考核个人绩效转移为考核团队成效;以产品的好坏来评价团队表现。 

2.从横向比较员工绩效转移为纵向比较个人成长;对于个人的成长,企业应该定义清楚每个角色的胜任力模型,从而帮助员工设定自我提升计划,而不进行员工之间的横向比较。

3.从长周期考核转移到及时反馈与调整;缩短反馈周期有利于及时改进,相互反馈有利于增进成员之间信任和理解。

最后,绩效考核的未来有不少探索者认为是没有绩效考核。


第14章 一个交付故事 

“平台风险”( The Risk of Platform)这样的概念,每个成功的互联网公司都有一个基础平台来更好支撑和实施自己的业务战略,这正是现在 A记想要前去的方向。而平台思维的关键并不是如何吸引开发人员,更多的是把开发者当作平台的客户,专注在如何提升开发团队的体验、关注在如何打造一个平台来为开发团队提供更多的自治,从而释放出更大的生产力。


第15章 又一个交付故事

我们建议客户能够更多的分享上下文,而不是做决策,决策由团队来出,但是客户保留否决的权力。


第16章 一个遗留系统自动化测试的七年之痒 

UI测试不是着重去测试某个功能是否工作,更关注的是用户在使用系统时能否顺利实现某个业务目标。


第17章 如何在团队建设工程师文化?阿里资深技术专家这么做 > 

如果没有技术 KPI,技术就会总被放在次优先级。

一个软件技术团队的最终产出物是可交付的软件本身,所以不管什么花里胡哨的管理方式都没有一份安全和稳定运行的代码来得给力。

好的代码应该要有设计的痕迹:简单粗暴地还原业务或多或少给未来埋坑。

IDE永远不能忽略 IDE对编程效率带来的影响。 IDE是工程师每天面对的工作环境,任何跟工程效率相关的思想都应该以 IDE PLUGIN的方式让工程师们每天可用,每天受益。 IntelliJ作为 Java神器存在有其必要的原因是因为它把能帮到工程师的每一个操作都简化和方便到极致。团队使用 IDE的技能是否出神入化一定程度反映了这个团队的编程效率是否高。这是结对编程的另一个重要好处:一个团队使用同一套快捷键写代码,而这套快捷键是整个团队每个成员快捷键使用心得的合集。


 第18章 敏捷转型下的团队管理:来自一线管理者的思考 

首要的就是要培养团队成员间的协作意识,进而形成自组织,而站立会议是促成这种成员间协作的主要形式之一。可是我又不知道该如何处理,因为,仅仅告知团队成员说话的时候不要看你或者当你不存在是虚伪的,这种所谓的建议在实际操作层面毫无意义。敏捷教练给我的建议是,你不妨缺席几天站立会议。

管理者是有“神光”的,特别是相对于你直接考核和管理的成员。这种所谓“神光”有的时候是有用的,它可以让懒散、推诿和各种组织里的不良风气见光而散。同时,它也是有害的,它让团队成员不自觉的产生依赖和等待指示的心态。

作为团队管理者,不能仅仅关注团队这一次把事情做对了,关键是,团队通过自己的成长持续的把事情做对,以致做得更好。

团队管理者要打造敏捷的自组织团队,必须给予团队足够的属于团队自己的空间。因为既然是“生命体”,就是有隐私的,就不像“时钟”一样,随时都可以打开看看里面的齿轮转得怎么样。需要一些不同的沟通方式和管理方法。

受访者来自不同行业,其中来自互联网企业的 26%、信息科技 21%、通信 16%、金融 17%。

企业敏捷实施的团队规模大部分( 79%)在 100人以内。其实,这是一个趋势,随着技术和工具的发达,一个人能做的事越来越多,所以团队规模也自然变小。更重要的是,自主小团队和网络式组织结构,更灵活、更能够产出成绩。这也符合敏捷理念。只有特别复杂的系统,才需要大规模 100人以上的团队。我们仔细分析了 500人以上的敏捷实施团队,他们大部分实际上是多个独立产品线并行交付。单产品的交付,大部分还是 100人以内。

敏捷实施周期与效果:坚持 6个月,必有效果

敏捷虽然可以提供快速验证产品的机制,但是并不能指定产品方向。这还是依赖于有智慧、有眼光的产品负责人。有能力的产品经理,加上一个有效的敏捷运作机制是一个完美的组合。

实施敏捷的时候,首先要先从一批意愿比较强的成员入手,同时也要考虑当前的绩效管理体系是否会促进或阻碍协作。

如果一个团队说他们很敏捷,但是没有站会,没有工作跟踪,没有自动化测试,更没有持续集成,你觉得他们能够敏捷起来吗?

我们发现企业采用的步伐通常都是先实施团队级的敏捷,然后端到端交付敏捷,最终实现企业级敏捷。