人工智能-机器学习

深入核心的敏捷开发

2021-02-20  本文已影响0人  yeedom

前言

image-20210219145336644 image-20210219145358123 image-20210219145922348
  1. 第一是必须每次提交触发构建;
  2. 第二是每次提交必须基于上次的成功构建

这两条纪律是底线。

image-20210219145955374 image-20210219150200493 image-20210219150214232

基于效能和周期时间的持续改进

image-20210219150315347

基于客户深度参与的统一团队

  1. 迭代站会不超过15分钟
  2. 需求澄清每次不超过一个小时
  3. 展示会一个小时以内
  4. 回顾会不超过两小时

ThoughtWorks敏捷开发管理体系

  1. 需求管理:包含从需求澄清到需求最终实现的整个生命周期。
  2. 技术管理:包含开发、测试技术的选择和运用。
  3. 质量管理:包含开发过程中的质量管理及软件交付前的质量保障。
  4. 迭代管理:包含开发团队迭代运作规则及纪律。
image-20210219150455375 image-20210219150521220

  1. 《代码管理核心技术及实践》
  2. 《敏捷软件开发:用户故事实战》
  3. ThoughtWorks洞见网站 :https://insights.thoughtworks.cn
  4. Thoughtworks洞见公众号

第1章 敏捷宣言到底有几句

敏捷软件开发宣言

  1. 我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:
  2. 个体和互动 高于 流程和工具
  3. 工作的软件 高于 详尽的文档
  4. 客户合作 高于 合同谈判
  5. 响应变化 高于 遵循计划
  6. 虽然右项也具有价值,但我们认为左项具有更大的价值。

第2章 开发人员的客户思维


第3章 基于统一迭代节奏的全功能团队

自组织全功能团队

  1. 首先,所有的工作被高度并行化。例如我的车最多的时候有四个人在同时施工,一个人在缝真皮方向盘套,一个负责贴车左侧窗户的膜,一个负责贴车右侧的膜,一个负责贴前后挡风的膜。
  2. 其次,大家并没有清晰的角色划分,缝方向盘套的人在完成手头的工作后,立刻自觉加入到贴膜的工作之中;而两侧的膜贴完后,两名工人立刻开始帮车打蜡和做内饰清洁;整个过程自然而连贯,完全自组织,
  3. 所有人都掌握了缝方向盘套、贴膜、打蜡和内饰清洗的工作技能,并没有严格的角色分工,很难说清楚谁是贴膜师,谁是打蜡师,他们每个人都像一个专业的全栈工程师。
image-20210219151351527

领导与管理

image-20210219151418703

团队的精进之道


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

估算的目的

需求风险的坏味道和对策

识别坏味道

一个优秀的项目管理者首先需要做的是让客户完全了解你的工作量估计系统是如何工作的,并不断强调你的工作量估计是合理、公平和有效的。

这代表你的客户不理解在软件开发中,“需求分析”也是工作量的一部分

这代表你的客户正在抛开自己的决策责任,尝试用最不负责任的方式逼迫你答应需求,一旦成功,这种行为就变成一个肆无忌惮的借口。

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

尽可能靠近决策者

做系统决策人

  1. 是否应该引入新的概念
  2. 是否应该将某一概念变复杂
  3. 是否应该建立新的关系
  4. 是否应该将某一关系变复杂
image-20210219152008858

不要给选择

  1. 采用完美的系统思维逻辑帮助客户认定我们选定的就是最优选择
  2. 对我们的方案给出完整的思考和选择过程、而不是最终方案而已
  3. 给出大量的假设让客户认为反正都不知道最后结果是怎样,选什么其实都没那么重要
  4. 最后才是给出多个方案,对优缺点进行分析

管理结果而非解决方案

image-20210219152104077

建立游戏规则

  1. 没有东西是免费的:所有东西都是有价格的,花时间的,这里包括需求的讨论、编码、改动、测试、调试、沟通等等。
  2. 讲不清楚的需求很可能是没价值的
  3. 这是系统思考:任何一个新概念的产生或者一个新关系的出现,都意味着系统其他部分的成本、变动、甚至破坏,谨慎一切新概念、新关系的产生。
  4. 社交游戏:复杂问题最终都是复杂的社交游戏,能通过政治或者社交解决的问题,尽可能不用技术解决,
  5. 每个阶段都有该阶段专属的规则:特别在需求的前期,讨论越多需求,流入后期的需求范围就越大。在一开始就应该建立“需求规则”的概念,什么该谈、什么不该谈,而不是简单跳过
  6. 交付大于一切:永远不进行项目延期,目标是在交付期中保证交付既定的结果,而非之前约定的需求列表,可以容忍瑕疵、但不容忍延期。
  7. 尊重估算:不要尝试花时间质疑估算,你所有的怀疑会变成工程师巧妙的“套路”,他们会在另外的地方找补回来,反正你不懂,若相信,请深信。

需求的冰川

  1. 用户需求:从用户自身角度出发产生的“自以为的”需求
  2. 产品需求:由综合提炼用户的真实需求而产生的符合组织和产品定位的解决方案。

用户研究与验证

『了解用户』无法一劳永逸

保持好奇,保持初心

浅谈软件项目规模估计,到底在估什么

非功能需求

  1. 浏览器的兼容性问题:兼容哪些浏览器和兼容版本?
  2. 移动端的兼容性问题:兼容哪些手机设备、操作系统和版本号?

开发部署环境

与三方的集成

测试

  1. 自动化测试,包括单元测试/集成测试/功能测试
  2. 迭代内探索性测试
  3. 业务回归测试
  4. 性能测试
  5. 安全测试
  6. 代码质量测试

验收交接流程

软件项目规模估计,怎么估?

估计者的估算的点数是否能代表团队估算的点数?

是否有故事卡片之外的工作时间没有考虑到?

  1. 回复电子邮件(沟通成本)
  2. 面试(内部耗损)
  3. 参加会议(包括内部会议,比如站会、retro、code diff、技术研讨会议和客户沟通会议等)
  4. 为当前发布提供支持(上线支持)
  5. 培训?(内部的)
  6. 任务之间切换/被人打断(程序员出栈入栈的消耗……)
  7. 修复bug(一定会有bug,一定会花时间修……)
  8. 写各种文档(对于比较看重文档的客户,这一部分会占用不少的时间)

故事卡的需求是否清晰呢?

问题可能的答案

  1. 首先,要进行集体估计。集体估计可以缓解因为个人能力不同所引发的单点偏差,不同开发成员对某个需求从不同角度进行的阐述,也容易让大家对需求有更全面的理解,也易于发现潜藏在需求中的风险。
  2. 其次,是方法。《敏捷估算与规划》介绍了两种基本的方法:理想人天法和故事点法。

理想人天法

故事点法

功能缓冲

进度缓冲

不是小结的小结

  1. “输出高于结果”(output over outcome)。客户更关注功能列表的完成,而不是产生的业务价值。
  2. 开发团队倾向于裁剪用户故事的功能,3个点的故事卡,尽量控制在规定时间内完成,即使可以花更多时间把事情做得更好
  3. 控制需求变更。可以进行需求变更,但这个过程更像是一个异常的情况,而不是喜闻乐见的
  4. 当我们发现更好的业务点和想法的时候,会倾向于隐瞒,以免额外的业务功能会增加工作量。需求变更往往会涉及客户谈判,尤其是在客户观念是传统供应商管理策略时,即“我来控制需求的全景,能多做点就多做点”
  5. 在客户合作和谈判的天平上,客户关系会向谈判的方向倾斜。

  1. 《敏捷估算与规划》

第5章 基于持续集成和测试前置的质量内建

关于Gitflow

image-20210219153531245

合并就是合并

如果不用Gitflow呢?

image-20210219153631172

改善单元测试的新方法

我们为什么要写单元测试?

基于用例的测试(By Example)

  1. Given:初始状态或前置条件
  2. When:行为发生
  3. Then:断言结果
  1. 第一是测试的意图。用例太过具体,我们就很容易忽略自己的测试意图。测试即文档,既然是文档,就应该明确描述待测方法的行为,而不是陈述一个例子。
  2. 第二是测试完备性。因为省事省心并且回报率高,我们更乐于写happy path的代码。

生成式测试

超越“审,查,评”的代码回顾

image-20210219153855821
  1. 团队7~8位程序员,下班前半小时聚在会议室里,在一位主持人的引导下做代码回顾。
  2. 主持人问:“咱们今天回顾哪段新写的代码?”一位志愿者在投影仪上调出今天编写的一段代码的新旧对比图。
  3. 主持人说:“我们知道,如果代码编写得好,那么作者以外的其他的人就能在没有作者帮助的情况下读懂。我希望一位不是这段代码作者的志愿者,来为大家解释一下这段代码是做什么的。”一位非作者的志愿者上来逐行解释代码,并回答大家的疑问。
  4. 主持人等代码解释完后,问大家:“这段代码大家还有看不懂的地方吗?”
  5. 大家都看懂代码后,主持人问:“大家说说这段代码有没有好的编写模式咱们可以继续发扬?”
  6. 提完了好模式,主持人问:“大家说说这段代码有没有可以改进的反模式?”大家开始提反模式。注意,不要提谁是作者。
  7. 主持人在整个过程中注意计时,快到半小时的时候,可以这样结束代码回顾:“今天时间也快到了,代码回顾的重点在识别模式,而不是看全部的代码。希望大家继续发扬今天识别到的好模式。另外在明天做代码回顾时,把今天识别到的反模式改进为好模式。”

不做代码审查又怎样

沟通的收益和成本

测试金字塔

交付价值高于遵循实践

结对编程的正确姿势,你学会了吗?

结对编程

结对编程的好处

培养新人,促进沟通,提升团队整体能力。

更好的知识共享和信息交流,促进团队协作。

促进团队成员的沟通,提升团队凝聚力。

如何进行结对?

image-20210219154222285
  1. 领航员和驾驶员(Driver-Navigator),键霸出没,请小心
  1. 乒乓模式
  1. 鼠标和键盘模式

几点提示

  1. 多沟通:彼此尊重,多沟通。
  2. 确定开发任务列表。协商开发任务列表,能够提高对开发任务理解的一致性,确保开发节奏顺利进行。
  3. 定期交换小伙伴。定期交换小伙伴可以使得知识得到充分分享,
  4. 可持续的结对工作。真正的结对会比一人工作更专注,紧凑,所以一天8小时的结对会很累,比如一个小时或两个小时休息一次,从而保证可持续的工作。
  5. 多给新人机会。与新加入的小伙伴结对,需要耐心,多给予她/她上手的时间与空间。通常建议开始时多讲解,多展示,给她/他学习的机会;比如一开始可以由熟悉代码的小伙伴写测试,而新加入的写实现;随后可采用鼠标键盘方式或者乒乓结对方式。
  6. 勇敢加勇敢。对于新加入的小伙伴,如果跟不上怎么办?要勇敢地叫停,打断结对的小伙伴,弄懂这个问题,这样做才是达到了结对的目的。更推荐及时解决,当然,深度需要把握得当。
  7. 反馈。反馈往往是最后一环,也是最有效的一环,是帮助自己和结对小伙伴的必要工具之一,温暖的“小黑屋”是可以经常光顾的。
  8. 不是所有的场景都适合结对。对于那些结果需要维护,能够促进沟通、知识传递等价值的开发行为,都建议结对。诸如方案调研和一些非常简单的问题(微小的缺陷修复如拼写错误)等是可以不用结对。

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

开不好站会?因为不同阶段站会的目的不一样

  1. 组建期
  2. 激荡期
  3. 规范期
  4. 执行期
  5. 休整期

组建期和激荡期:建立信任

规范期和执行期:关注价值流动

执行期:仪式感

展示会的七宗罪

准备工作没做好

正确做法:充分做好准备工作

从业务的角度把整个要演示的功能尽可能串起来,准备好展示的步骤。 演示数据也需要准备好,展示的时候可以直接使用,只需要操作所演示功能部分,不需要临场创建准备数据。 演示环境要提前准备好,包括部署好需要演示的应用程序版本,而且要告诉团队不要破坏准备好的环境。

没有上下文铺垫

正确做法:开始演示前要先介绍上下文。

逐条过AC

正确做法:以功能为单位演示。

不要一个一个用户故事的演示,而是将整个功能串起来,

企图覆盖所有路径

正确做法:只演示最关键路径。

过多提及跟演示功能无关内容

正确做法:只提及要演示的功能。

展示可以考虑只演示最主要的功能,那些小的反馈就不需要展示了,

也不要提及任何还未完成的功能模块,特别是对于团队正在开发的技术卡或者还不成熟的技术方案等,一定不要提及。

认为展示仅仅是BA或QA的事情

正确做法:人人都可以展示

尽量多参加展示会,这是一个了解系统、听取客户反馈的绝佳机会。

不熟悉的新人负责展示

正确做法:展示前先充分了解系统和业务

但不建议采用给青涩新人提供展示机会的方式来帮助他们提高能力,如果要给新人锻炼机会,可以让新人在结

浅谈敏捷离岸团队沟通

按需互访

image-20210219154843532
  1. 在项目的重要节点,例如合作初始、项目里程碑、检查点进行在岸交流
  2. 设立双向固定互访周期,如每三个月/半年

巧用工具

image-20210219155206818

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

三个角色

角色一:PO的任职资格

角色二:Scrum Master的悖论

角色三:开发团队自组织的假象

四个会议

Sprint计划会议:实际上就没课分开的两个会

IPM

IKM

总结一下,PO自己搞定规划,PO和团队一起开工,团队自己搞定怎么做。IPM不占开发团队时间

每日站会:关注接力棒,而不是运动员

Sprint回顾会议


第9章 技术领导者即服务

  1. 技术决策者
  2. 流程监督人
  3. 干扰过滤器

责任拆解

  1. 制订适合该项目要求的技术方案。他要参与架构设计,了解平台和编程语言、主要的框架和库、集成点、部署策略、数据迁移策略,确认总体技术方案能够支撑系统的业务要求
  2. 保障交付顺利开展。他要确保环境的一致性,搭建和管理持续集成流水线,指导并监督团队遵循持续集成的流程和实践
  3. 管理和提升团队的能力。需要确认团队是否熟悉用到的技术栈和工具,帮助团队成员组织刻意练习来提升能力

技术栈管理

image-20210220075555803

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

  1. 团队目标不一致
  2. 团队成员不熟悉
  3. 信息发布不顺畅

敏捷的项目管理:追求最大价值的成功

image-20210220080207683

那么,这个定义是正确的吗?

用户故事

  1. 角色:谁要使用这个功能
  2. 活动:需要完成什么样的功能
  3. 商业价值:为什么需要这个功能,这个功能带来什么价值

展示形式:作为一个<某种类型的用户角色>,我要<达成某些目的>,只有这样我才能够获取<商业价值>

image-20210220080347937

估计和迭代计划

image-20210220080455746

站会和用户故事开卡

代码审查和回顾

  1. 团队经过一天高强度的思考与编码,适当停下来,看看其他人写的代码,同时将自己的代码讲解出来,往往能获得一些意外的灵感,或许能解决自己面临的阻碍
  2. 互相了解设计思路,获得更好的建议和进行思路重构,提高代码质量
  3. 及早发现潜在缺陷,降低事故成本:如果这个时候发现代码的坏味道和一些需要改进的地方,代码审核结束后可以花少量时间进行更改
  1. 项目开发
  2. 敏捷成熟度
  3. 团队角色和职责
  4. 人员技能提升
image-20210220080924185

最大程度的可视化

image-20210220080938509 image-20210220081015663

沟通计划

  1. 以什么频率、什么形式作项目的更新。比如说每周五以周报的形式作一些主要信息的更新;
  2. 站会和迭代会议什么时候召开,需要邀请哪些人,比如业务负责人和技术负责人等
image-20210220081203821

团队目标不一致

  1. 用电子墙和物理墙展示 用户故事、需求全景图、项目进度燃尽图
  2. 通过迭代会议和功能演示会议对齐迭代计划,项目进度、识别项目风险

团队成员不熟悉

信息发布不顺畅

  1. 共享信息,制定沟通计划
  2. 最大程度的可视化

行为心理学家研究认为

  1. 21天以上的重复就会形成习惯。任何一个运作,重复21天就会变成习惯性的运作
  2. 任何一种想法,重复21天或者重复验证21次,就会变成习惯性的思维方式

结语

  1. 守:最初阶段须遵从老师教诲,认真练习基础,达到熟练的境界
  2. 破:基础熟练后,试着突破原有规范让自己得到更高层次的场景化
  3. 离:在更高层次得到新的认识并总结 ,自创新招数,另辟新境界

第11章 也谈精益

  1. 追求快速价值交付的小批量生产模式
  2. 追求极致卓越的匠艺文化
image-20210220081623286

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

阶段1:建立敏捷流程,缩短交付周期

image-20210220081839788
  1. 培训,给团队培训敏捷流程、各角色的职责以及各种工具的使用
  2. 现场指导,先带领团队走完整的敏捷流程,通常会有几个迭代;然后观察团队自己执行流程,并帮助团队改进;最后不再参与这类活动
  3. 需求梳理,指导PO和BA建立需求全景图(比如用户故事地图)、拆分Story、排优先级以及和团队其他成员协作等;制定Story编写规范,Story价值流和建立Story看板

阶段2:引入技术实践,质量内建,减少返工

image-20210220082126135
  1. 单元测试
  2. 集成测试:包括API测试和组件测试、契约测试等
  3. UI自动化测试
  4. CI:将以上测试定期运行并可视化报告,让所有团队看到。同时要求团队第一时间修复CI
  5. CD:建立自动部署流水线到生产环境,并集成冒烟 测试,同时实现回滚
  6. Git:建立使用git规范,建立分支策略或者指导客户做纯主干开发,培训客户使用git高级功能
  7. Operation相关技术:指导客户实践蓝绿部署、云和容器、金丝雀发布等
image-20210220082335812

阶段3:提升价值交付效率和响应力

  1. 更高级的能力建设:如引入微服务、代码共享和特性团队等
  2. 以教练指导为主:我们教的内容会变少,指导的内容会变多,会让客户自己组织更多的分享,鼓励客户自学,并建立学习型文化
  3. 与业务走得更近:团队可以更好地理解 业务,同时能给业务提供更有价值的建议,因此很多业务在决策早期就会引入技术团队的成员

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

敏捷转型过程中的必然挑战

image-20210220082618053

绩效考核的困境

image-20210220082649891

如何破局?

正如《管理3.0:培养和提升敏捷领导力》所说,所有变革最后的失败都是管理的问题。应该把绩效考核这种管理手段当成『敏捷铁三角』中一角来对待,那就是调整约束

image-20210220082755692 image-20210220082903186

清华大学管理学教授宁向东一针见血地批出,管理,其本质就是关于如何『破局』的智慧。所谓『局』就是管理者周围的各种资源相互联系,相互作用的一种状态。以上约束,也是软件工程表现出来的组织复杂性,也是一种局

  1. 《管理3.0:培养和提升敏捷领导力》

第14章 一个交付故事


第15章 又一个交付故事

比如自动化测试技术干掉了传统的测试部门,数据库的自动化技术干掉了DBA,部署、运营的自动化干掉了运营,云化、安全内嵌也许将要干掉采购和安全。当这些东西,因为技术的进步而标准化后,当全面的数字化平台就绪之后,那么剩下的就仅仅是业务解决方案、技术栈与实现代码了,王老师把决策权交给开发团队是一个自然而然的选择……


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

工程师文化的特征

小团队

7-12人的团队是比较适合的团队大小。有人用毕节团队来形容一个团队大小(两张比萨可以喂饱这个团队)。脸书和谷歌经常有两三个人的团队。小团队特征

  1. 不破不立
  2. 以少为多,精准打击
  3. 勇敢追求卓越

技术创新

技术决策权大

技术数据可视化

分享多会议少

测试原则

  1. 用given/when/then语态写单元测试
  2. 要让测试代码更容易写
  3. 合理使用mock/stub技术,测试你要测的,让你的测试更有效
  4. 异步测试不要用sleep
  5. 最好的debug手段就是测试
  6. 单元测试耗时最短,多用单元测试覆盖代码逻辑
  7. 越是集成测试数量应该越少,因为代价很大,性价比不高
  8. 静态代码质量分析应该伴随每次持续集成

分支策略

image-20210220101910212

结对编程

  1. 一个主机,两个键盘,一个显示器
  2. 新老员工结对是新员工掌握实践的最快手段
  3. 结对让员工有机会互相学习对方良好的编程方式,形成团队独有的代码风格,而不是个人代码风格
  4. 时不时的结对不会降低开发效率,会提高学习热情

代码回顾

  1. 团队代码回顾,总共最好1个小时左右
  2. 每天代码回顾
  3. 每个人的代码都要回顾,每个人都要讲解
  4. 发现的问题当天就改掉

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

  1. 集中控制管理
  2. 微观管理

杰克 韦尔奇先生的一句名言:『在GE,我做得最棒的一件事情是创造了一台准确报时的钟』在企业中,即使是仅仅管理一个小型团队的一线管理者,管理者的目标也应该是打造一座可以自动运转并精确报时的时钟,而不是自己去报时

敏捷转型下管理者应该如何自处?

需要团队管理者首先要做到信任和放手

  1. 《走出硝烟的精益敏捷:我们如何实施Scrum和Kanban》
上一篇 下一篇

猜你喜欢

热点阅读