这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

Team

关于团队、打(ZHI)工(YE)人(REN)

1 - 如何构建基础库

简介

提供一个库，沉淀共性的功能点。

是Library，而不是 Framework。

有哪些内容呢？

参考1 Gitlab Labkit

LabKit is minimalist library to provide functionality for Go services at GitLab.

  • Correlation
  • Loggging
  • Masking
  • Metrics
  • Monitoring
  • FIPS
  • Tracing
  • ErrorTracking

参考2 go-zero

  • 鉴权
  • 加解密
  • 日志记录
  • 异常捕获
  • 监控报警
  • 数据统计
  • 并发控制
  • 链路追踪
  • 超时控制
  • 自动熔断
  • 自动降载
  • 缓存控制

参考3 Micro

Micro Architecture

Wrapppers are a form of middleware that can be used with go-micro services, They can Wrap both the Client and Server handlers

  • Breaker
  • endpoint
  • Monitoring
  • ratelimiter
  • service
  • trace
  • validator

参考4 Dapr

2 - 团队建设

贝尔宾的团队的九种角色

roles in team

类型 特征 团队贡献 不足
执行者
实干家		 保守、尽职、中规中矩、通达常理 灵活性一般，对新想法不敏感
ME, Monitor Evaluator 个性小心谨慎、聪明、拥有广阔视野，能顾全大局并作出最有利的判断 有时过于吹毛求疵或按规矩办事

对于团队成员而言，一个人可以同时具备多种角色，而且一个团队随着工作项目发展阶段的推进，某些角色的优先度也会发生变化

对以上角色进行归类，分别为执行团队任务活动的「行动导向型」、协调团队内外部人际关系的「人际导向型」、以及负责想法创意与提供专家智慧的「谋略导向型」角色。

roles cat

理解和驾驭团队发展的五个阶段

纵向团队和横向团队

高效团队的特点

  1. 共同目标
  2. 职责分明
  3. 共同的价值观
  4. 成员个人能力强
  5. 集体能力高
  6. 自我管理和自我激励
  7. 个性互补
  8. 能力互补
  9. 有效决策
  10. 相互支持
  11. 灵活性
  12. 系统思维，了解十加一的危与机
  13. 不断学习
  14. 不责备他人

未完待续…

组织能力的杨三角

“杨三角”理论框架图

“杨三角”由员工能力、员工思维模式和员工治理方式三个方面组成

参考

[1] R.梅雷迪思•贝尔宾（R. Meredith Belbin）: 团队角色

[2] 莱恩：【團隊管理】管理者想建立高績效團隊，先找到這9種成員－貝爾賓團隊角色理論(Belbin Team Roles)，你的團隊需要那些角色？

[3] MBA 智库百科：杨三角理论

[4] 杨国安： 《组织能力的杨三角 - 企业持续成功的秘诀》

·End·

3 - 基于Git Flow规范分支和发版问题

背景

一个人一个小的微服务, 多个人一个微服务开发的时候，流程还是很要必要的

方式

Git Flow 和 pull request 结合

Standard-Version

参考

git-flow 备忘清单, 这大概是了解到清晰的flow了


·End·

4 - Scrum & Jira 使用问题记录

Scrum 结合 Jira

Story

  • Story的时间不能超过3天的时间。如果超过了三天，先拆解。
  • 技术Story和Story必须拆分subtask，估时和工时在subtask上填写
  • 所有的Story需要关联需求。
  • 处于”测试中“单： 根据测试种类处理
    • ”开发人员测试“ ， 创建测试subtask， 开发人员部署测试环境，开发自测接口， 测试完成后”点击测试通过“
    • ”无需测试“， 开发人员直接点击”测试通过“
    • ”测试人员测试“， 开发人员跟测试人员沟通测试完成时间，并跟进，直到测试人员完成并点击”测试通过“ ； 当测试人员无时间测试时，开发人员改为修改subtask的assignee为自己，并自行测试。
  • 处于”验收中“， 可通过GT 找BA或者Leader进行验收。
  • 当jira单处于”Done“完成状态时，可以不用做任何操作了，如果上线，联系leader创建运维单。
  • Story的时间超了，怎么处理？
    • 在原来的Story的subtask上log上超出的时间。前提是这个subtask确实需要花这么时间。
    • 新增subtask，在新的subtask上log上时间。 前提是这个Story里还包含了一开始并没有考虑到其他的子任务。
    • 新增Story，前提是存在一种情况，时间评估差距很大，这个Story的完成需要依赖于其他的Story。

Subtask

  • 不创建无关的subtask
  • Story状态是否需要更改 是根据subtask完成情况来定
    • BA或者Leader对Story宣讲完成后， Story状态更改为 ”待开发“
    • DEV对Story以及subtask有了解清楚并没有疑问后，Story状态更改为“待开发”
    • subtask已经开始开发了，Story状态更改为“开发中”
    • subtask里开发工作已经完成，Story状态更改为”待测试“
    • subtask都完成后，Story状态更改为”待验收“

通用

  • 使用明确的形容词， 避免使用类似如下形容词 ：
    • “相关的”
    • “ 部分
    • “
  • 每日 log work。（如果你做不到每日更新，可以至少两天做一次更新）
  • Sprint 启动后 jira 单（技术 Story+Story）的增加修改删除由 scrum master 来操作， 勿擅自操作。
  • 周中会议前更新会议内容
  • 不管是 Story、技术 Story、运维单还是 BUG 单，找 reporter 验收。
    • 为什么 Story Owner 找 reporter 验收？ 正常逻辑是我做完了改状态就 OK 了，才符合流水化作业。
  • 不做的单 拒绝
  • Jira 单拆分时并不了解需求。

Sprint指标

Sprint不仅仅有完成率的指标，另外还有更多的指标可以了解Sprint的状态

  • 迭代变更率： = 插入和移出任务数、计划任务数 * 100% （任务数仅限：story + Tech Story）
  • 迭代投入比： 迭代工作投入比 + 运维投入比（Jira 总投入时间 / 团队总数108）
  • 需求积压：
  • 平均开发周期：Story、Tech Story 在看板中启动开发到完成所耗的平均天数
  • 迭代逾期关闭

运维

类似“线上问题和故障”

每天都会在产品和研发群发布”线上问题日报“， 以报表形式展示每个业务团队的问题存量，以及这些问题的持续时长 — 来自有赞

针对运维单的问题，可以同样的思路来处理。运维单不处理最终积压的问题会在某个时刻点爆发。

TODO: 如何整理出这样的报告？

Bug 管理

“Bug 看板”中统一管理

Bug 流程

测试 Bug 必须关联到 Jira 模块、影响版本和解决版本， 我们可以根据“模块”和“经办人”来统计某个版本中遗留的测试 Bug 存量分布。

Bug 描述标准模板

重现步骤、实际结果、期待结果、抓包数据

复盘

使用“海星图”， “KISS”或“做的不错的 / 应该做的更好的”方法进行复盘 ，复盘的改进措施会被录入到“复盘 Action 跟进看板”， 每个 Action 必须是可执行的具体措施，且有一个主要负责人（JIRA 经办人）和完成日期（JIRA 到期时期）。

Scrum 之星

激励动机，利出一孔

  • 即时激励四个原则
    • 提倡什么，反对什么
    • 注重精神激励，同时兼顾物质激励，前者为主
    • 及时给员工反馈
    • 公开透明、有理有据、有事实

定位

PM (Program Manager)

负责的事情有：

  • 和客户交谈，组织用户调查，发现用户需求
  • 了解和比较竞争对手的产品
  • 怎么让软件变得可用 (Usable)、有用（Useful）
  • 怎么改进团队的流程

更全面的任务有：

  • 带领团队形成团队的目标 / 远景，把抽象的目标转化为可执行的、具体的、优美的设计
  • 管理软件的具体功能的生命周期（需求 / 设想 / 设计 / 实现 / 测试 / 修改 / 发布 / 升级 / 迁移 / 淘汰）
  • 创建并维护软件的规格说明，让它成为开发 / 测试人员及时准确的指导，而不是障碍
  • 代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级
  • 分析并带领其他成员形成对缺陷 / 变更需求的一致意见，并确保实施。
  • 带领其他成员确保项目保持功能 / 时间 / 资源的合理平衡，跟踪项目进展，确保团队发布让客户满意的软件。
  • 收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中优缺点，推动项目成员秩序改进，从而提升士气。

PM 做开发和测试之外的所有事情

Program Manager vs Project Manager

Project Manager Program Manager
是团队的行政领导者，带领大家在项目中工作 和大家平等工作，推动团队完成软件的功能
通常是团队外和外界打交道的唯一代表 一个团队可以有很多的 PM
对项目的功能有最后的决定权 和其他团队成员一起大形成决议
管事也管人 管事不管人
不一定做具体的工作 一定做具体的工作

为什么不让 PM 领导开发和测试人员，这样 PM 工作起来不是更梳理“ ?

如果 PM 得到团队成员的支持，会是怎样的呢？

成为项目流程的主人 — 驱动流程，组织会议，实践 Scrum，保证进度；代表团队向上级 / 伙伴团队 / 客户 / 市场部门报告项目进度；团队成员都乐意和你交流，你赢得了大家的尊重；你不用自己写一行代码，也同样可以积极影响项目和产品。

反之， 如果得不到团队成员的支持？

你会在各种会议或流程中浪费大家的时间，发一些大家不读的 Status Mail， 不能凝聚团队，形不成共识；你对团队的状态不太了解。也不能有效和准确的像有关方报告团队的情况并获得支持；你对行业和产品的发展方向把握不准，对项目和产品造成负面的影响。

软件设计和实现

从 Spec 到实现

一个开发人员拿到设计文档 (spec) 之后，他会做下面几个事情。

  1. 估计开发任务所需的时间
  2. 会试着歇一写快速原型的代码，看看效果会怎样。期间发现了若干问题，与 PM 沟通后，最终达成了一致意见。
  3. 在看到初始效果和了解实现的细节后，开始写**设计文档（Technical Spec、Design Document），写好之后，可以请同事一起来复审设计文档（复审可选，因为一般情况下任务都不大）
  4. 设计文档写好之后，按照设计文档写代码。在实现过程中，他又发现一些意想不到的问题，与 PM 沟通后，找到了解决方案。
  5. 写好代码后，对照设计文档和代码指南进行自我复审，重构代码。
  6. 创建或者更新单元测试
  7. 进行单元测试（不仅要自己创建或更新单元测试，还要通过整个模块或者系统的单元的测试）
  8. 得到一个可以测试的版本，交给相关的测试人员测试，或者在网上进行公开测试，如 A/B 测试等。
  9. 修复测试人员或者用户发现的问题，等到问题都被解决得差不多了，在请同事进行代码复审。
  10. 根据代码复审的意见修改代码，完善单元测试和相关的文档，然后把代码签入到代码仓库中。

Testing Process in Scrum

敏捷测试在实践中出现两种声音：

  • 将测试与 Sprint 分离， 看做是与开发截然分开的“下一个阶段”
  • 测试作为 Sprint 的一部分，当 Sprint 结束时所有的测试工作也结束

前者带来的问题

  1. 导致在实践敏捷开发过程中遇到种种问题： 要么是忽略了代码质量，导致在频繁的迭代过程中，每个迭代的问题层出不穷；
  2. 沿用原有的方法安排对系统的系统测试，导致测试团队疲于奔命，却总也赶不上开发所要求的的进度。

什么是敏捷软件测试 #TODO

敏捷开发中不把测试单独拿出来描述的原因，恰恰是在敏捷开发中，测试不再是一个单独的，和开发独立的过程，而是变成了驱动开发、衡量产出的主要手段，成为敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。

究竟什么是敏捷测试

敏捷测试是基于自动化测试的

详细Scrum的敏捷测试。

  • Product Backlog, 测试需要考虑客户的价值大小（优先级）\工作量基本估算外，需要认真研究与产品相关的用户行为模式，产品的质量需求，哪些质量特性时我们需要考虑的？
  • Sprint Backlog， 需要明确具体要实现的功能特性和任务，作为测试，这个时候后特别关注“Definnition of Done”， 任务完成的验收标准。
  • 在每个Sprint实施阶段，主要完成完成Sprint backlog所定义的任务，这时出了TDD或单元测试之外，应该进行持续集成或者通常说的 BVT （build virification Test)。 如果有专职的测试人员角色，一方面可以完成测试用例、集成测试框架，协助开发人员进行单元测试；另一方面可以按照针对新视线的功能进行更多的探索式测试，同事开发验收测试的脚本。如果没有专职的测试热源角色，这些事情也是要完成的。只是由整个团队来完成。
  • 验收测试可以自动化测试工具万恒，但一般情况，不可能做到100%的自动化测试。

来自 Best Practices for Testing Process in Scrum

In Scrum, a cross functional Development Team has all the resources needed to complete a ‘Done’ Increment by the end of a Sprint.

Solution One

Breaking each selected product backlog item into many small subtasks which can be devlivered and tested.

Taking the help of testing team during integreation testing itself

the testing team starts writing test cases based on each task.

testing team helps dev team during the integration testing and they test each sub-story deployed in test enviroments.

Solution Two

Testing should be factored during sprint circle

As per definition Development Team are cross functional team and they should be able to test the solution, during the sprint cycle.

Solution Three

QA Team write test cases accourding to Acceptance criteria DoD for each Story

so Dev Team will take the responsibility of the testing for each cases in the story.

Test Cases will be part of DoR for the story

来自 知乎：敏捷流程中测试如何开展

来自 Kaverjody: 我的测试之旅

问题：

  • 每个迭代里， 开测试计划评审会议， 产生测试计划文档并得到批复的话，将会是一笔非常大的管理开销，而且每个测试计划的重复信息都很大。
  • 缺陷追踪实践，记录版本的时间长，修改这个问题可能几分钟搞定了。
  • 迭代开始时，测试人员却很空，空的无事可做，到了迭代结束的时候却是忙的不得了。

解决：

  • 开发项是新提出的概念，将软件的规格说明书撰写、设计、实现和测试封装在一起，作为最小的原子化产品组件（Component）。原子化的意思是保持开发项之间的互相依赖在可以做到的最低水平；移除或重排任何开发项的时候，对其他开发项不产生（或产生最小的）影响。
  • 在迭代开始前，先有技术报告或需求文档，由此而产生出开发项；然后是和以往的项目一样的入口阶段，确实项目日程并且生成相关的高阶文档，包括集成计划文档，项目计划文档，模块测试策略以及开发测试计划文档都在此时创建。
  • 所有开发项相关的测试活动都在 Sprint 内完成，这些测试被称为 DIT（开发项测试），测试用例本身还是属于以往的功能测试级别。但是开发项的测试计划、测试执行、报告等一些列过程全部都要在一个 Sprit 中完成，测试用例的自动化比例未做硬性规定
  • 项目成员主要分为开发和测试两类工程师，但是角色的定义并不是拿来当做不可以逾越的红色使用，必要的情况下，开发工程师也可以承担部分测试任务甚至整个人投入测试，或者测试工程师也会与开发一起，结对开发代码。
  • 开发人员的工作安排会受到测试工作的影响，每日站会或者平时工作中，可能会发现软件不容易测试，就需要开发人员协助检查以及修改代码提高软件的可测试性。

参考

基于 JIRA 的产品需求全生命周期管理实践

The Role of Automated Build Verification Test (BVT) in Agile-DevOps Methodologies

<现代软件工程构建之法> by 邹欣

BVT & BAT（版本验证测试和版本验收测试）


·End·

5 - 《卓有成效的管理者》之决策

背景

任务繁多，决策是其中一项。
当遇到如何决策的时候，特别费脑，不知道如何决定，应该是不知道如何去决定的。缺少思路，被各种杂乱无章的问题围绕，跳不出来，也迟迟没有给出最终的决定。
而通过这边文章，Get一种方式，帮助理清楚思路，快速做出决策。

方法论

待补充

后续

时间管理也是一个问题，工作中事情并不是有计划的单一事项，而是各种无关的事情需要处理。
如果每天在这种杂乱的事情中周旋，时间长了必定没有任何特别的产出。
理想的状态是： 保持一条重要事情的主线，其他事情围绕主线可慢可不做的开展。


·End·

6 - 《卓有成效的管理者》之我能贡献什么

背景

最近思考的一个问题之一： 怎么让团队有明显的产出，虽然有这个问题，但又因为日常工作中的琐事太多，往往很少有时间去思考这个问题。时间久了慢慢忘记了，特此在此记录下来。

标题来自《卓有成效的管理者》by 彼得·德鲁克

方法论

WHAT

我能有什么贡献？

WHY

重视贡献是有效性的关键
重视贡献的管理者，其所作作为是与众不同的
重视贡献能挖掘工作中尚未发挥的能力

WHAT

贡献

管理者若想做点贡献，就必须在这三个方面下功夫。

  • 直接成果
  • 树立新的价值观以及对这些价值观的重新确认
  • 培养和开发明天所需要的人才

WHO

作为管理者，能为这个团队做（或贡献）什么

作为团队中的成员，能为这个团队做（或贡献）什么？

HOW

如何使专业人员的工作卓有成效

知识分子有责任让别人了解自己。
“为了便于你为机构作出贡献，你需要我做些什么贡献？ 需要我在什么时候，以哪种形式，用什么方式来提供这些贡献”

正确的人际关系

相互沟通：

“我们的组织和我，期望你作出怎样的贡献? 我应该期望你做什么呢？如何使你的知识和能力得到最大的发挥？”

团队合作： 强调贡献有助于横向的沟通，因此能够促成团队合作

“谁需要我的产出，并使它产生效益”

自我发展： 个人能否有所发展，很大程度上在于你是否重视贡献

“我对组织能有什么最大的贡献”

培养他人： 重视贡献的管理者启发他人寻求自我发展

管理者的标准是以需求任务为基准，要求很高，高度的期望，远大的目标，是具有重大冲击力的工作

有效的会议

从会议中得到什么，会议的目的是什么，应该是什么


·End·

7 - Team Topologies 团队拓扑

Conway’s law、Dunbar 鄧巴係數、Team Fist Mindset、Minimal Cognitive Load

起初，对"Cognitive Load" 一词非常好奇，又了解到在 Matthew Skelton 的 《高效能团队模式》 中介绍其与团队的建设有密切的联系，在查找书籍过程中，也有读后感的文章对此书进行了总结，比如 Team Topologies - 團隊優先思考模式，觉得非常好，得好好细读，一直放在浏览器标签上舍不得关闭，今早早起趁此赶紧消化下，顺便记录下来，往后查阅。

名字解释

文章涉及几个专业名词。

名词 解释
Conway’s Law 組織內團隊組成的架構，就會直接影響你的軟體系統架構會長成什麼樣子。因為團隊架構決定溝通模式，溝通模式就會影響軟體系統架構
Dunbar 鄧巴係數 团队中可以深入互相信任且 share working memory 的人数基本上大概是 5 个人左右，极限就是 15 人。而能互相信任的上限大概是 50 个人， 当超过 150 人时就已经高过了社交认知的上限，就连要记住对方的名字都难。
Team Fist Mindset 团队优先思考模式，
Minimal Cognitive Load 話說我們每個人的 working memory 其實是很有限的，所以要慎選佔用我們記憶體的事物
谷仓效应 各部门就像一间「小公司」，各自为政、自负盈亏，只专注在自身的营运利益，而非整个企业的利益，最终导致整个组织功能失调、企业走向衰败。
Stream-aligned Team organized around the flow of work and has the ability to deliver value directly to the customer or end user.
Digital platform A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product.

Team Dynamics

Team dynamics describe the behavior relationship between the member of a group .

Team dynamics are the unconscious, psychological forces that influence the direction of a team’s behaviour and performance. They are like undercurrents in the sea, which can carry boats in a different direction to the one they intend to sail .

Google 内部研究，影响 Team Dynamics 的因素有哪些？

  • Team Size
  • Team Lifespan
  • Team Relationship
  • Team Cognition 团队的认知

好的团队基础就是小巧精干且长存的团队。5-9 人， 固定的团队成员一起为了一个目标工作得时间至少一年以上。

Tunkman’s stages of group development

这个说明了为什么团队至少一年以上。从团队组成到真的可以产出绩效，至少经历以下四个阶段

  • Forming
  • Storming
  • Norming
  • Performing

来自 Principles of Management

Team Fist Mindset

团队优先思考模式， 是什么？

  • 团队对某个软件负责，并且持续的关注与改善
  • Daily 要承诺参与并且不要迟到
  • 团队对于内部事务要持续讨论
  • 专注于 Team Goal
  • 帮助他人移除 blocking thing
  • Mentor 新人，相互帮助成长
  • 避免争输赢的争论，要能包容探索各种可能性的言论

Minimal Cognitive Load （最小化的认知负担）

如果要让团队能以高效的模式运转，首先要以小巧精干的长期的团队为单元，并且限制或与减少不必要的沟通。随着系统越来越复杂，团队与团队之间要建立沟通的规范。

  • Intrinsic Cognitive Load
  • Extraneous Cognitive Load
  • Germane Cognitive Load

如何最小化认知负担？

  • 好的 IDE 和 tool 或者是培训来降低 Intrinsic Cognitive Load
  • 通过 SOP 或者专业的 Infra Team / DevOps Team 来帮助建设优化开发部署流程，消减工程师的 Extraneous Cognitive Load
  • 让工程师更专注于产生价值的 Germane Cognitive Load， 设计更好的系统来解决客户的问题。

另外，Three ways to reduce team cognitive load and improve flow[2]:

  • Create well-defined team interaction patterns
  • Use independent,stream-aligned teams[1]
  • Build the thinnest viable platform (TVP)

团队的拆分

按照康威定律，团队的切分与组织的沟通模式会决定你的系统架构

好的 API

好的 API 是团队间的好的沟通模式，如果没有可能造成谷仓效应。 怎么定义好的 API[5]：

  • OPENAPI 定义 API
  • 使用文档 / Wiki
  • 好的用户体验
  • 版本 and testing approach
  • 最佳实践和原则
  • Work Info （未来的路线和 bug 修复时间）
  • Communication preferences (when/how)

把其他团队当成顾客。

管理依赖

Track dependencies using simple tools and remove blocking dependencies

管理团队间交流

Consciously design inter-team communications using team interaction mode

好的文档

Overcommunicate using just enough written documentation

Digital platforms

  • Digital platforms[6] are portfolios of technical products.
  • Developing a digital platform is a strategic decision and not to be taken lightly. Besides the direct financial considerations, digital platforms also exert pressure on the relationships within your organisation.
  • Digital platforms are force multipliers（火力加乘）, so there is a fine line between developing a competitive advantage and introducing a significant productivity blocker.

参考

[1] Organizing Agile Teams and ARTs: Team Topologies at Scale Overview

[2] Matthew Skelton and Manuel Pais: Forget monoliths vs. microservices. Cognitive load is what matters

[3] Justin Kitagawa: Platforms at Twilio: Unlocking Developer Effectiveness

[4] 阿贝好威： Team Topologies - 團隊優先思考模式

[5] Matthew Skelton and Manuel Pais: Are poor team interaction killing your devops transformation

[6] Cristóbal García García and Chris Ford: Mind the platform execution gap