“中分狗子”
以始为终, 任务分解, 沟通反馈, 自动化
摘抄自《10x程序员工作法》- 郑晔，详细内容请登录 极客时间 官网购买专栏。
以终为始总结
章节记录
- 02 | 以终为始：如何让你的努力不白费
- 任何事物都要经过两次创造：头脑中和实践中
- 对做软件的人来说，我们应该把终定位成做一个对用户有价值的软件
- 以终为始的方式，不仅仅可以帮我们规划工作，还可以帮我们发现工作终的问题
- 践行以终为始就是在做事之前，先考虑结果，根据结果来确定要做的事情
- 总结：遇到事情，倒着想
- 03 | DoD的价值：你完成了工作，为什么他们还不满意？
- DoD：完成的定义，Definition of Done
- DoD是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况
- DoD的检查项应该是实际可检查的(可视)
- DoD是团队成员间彼此汇报的一种机制
- 做事只有两种状态，做完和没做完
- DoD是一个思维模式，是一种尽可能消除不确定性，达成共识的方式。
- 总结：在做任何事之前，先定义完成的标准
- 04 | 接到需求任务，你要先做哪件事？
- 功能列表式的需求描述方式，将一个完整的需求敲成了碎片
- 验收标准非常重要的一环是异常流程的描述
- 验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量
- 最好维护的代码是没有写出来的代码
- 总结：在做任何需求或人物之前，先定好验收标准
- 05 | 持续集成：集成本身就是写代码的一个环节
- 写代码是程序员的职责，但我们更有义务交付一个可运行的软件
- 一个好的做法是尽早把代码和已有代码集成到一起，而不是等着所有代码完成，才提交
- 总结：尽早提交代码去集成
- 06 | 产品经理不靠谱，你该怎么办？
- 我们必须要有自己的独立思考，多问几个为什么。
- 总结：默认所有需求都不做，直到弄清楚为什么要做这件事
- 07 | 解决了很多技术问题，为什么你依然在“坑”里？
- 当你对软件开发的全声明周期都有了认识之后，你看到的就不再是一个点了，而是一条线
- 总结：扩大自己工作的上下文，别把自己局限在一个程序员的角色上
- 08 | 为什么说做事情之前先要推演?
- 通向结果的路径才是最重要的
- 总结：在动手做一件事之前，先推演一番。
- 09 | 你的工作可以用数字衡量码？
- 直觉也是一种大数据
- 直觉不适用与复杂到一定程度的事情
- 从数字中发现问题，让系统更稳定
- 总结：问一下自己，我的工作是不是可以用数字衡量
10 | 启动开发之前，你应该准备好什么
DoD，确定好完成的定义，减少团队内部的理解不一致
- 用户故事，细化出有价值的需求
- 持续集成，通过尽早集成，减少改动量，降低集成的难度
- 精益创业，减少过度开发不确定性产品带来的浪费。
-
思维转变：
任何事物都要经过两次创造：一次是在头脑中的创造，然后是才是付诸行动
- 在更大的上下文内发现自己的“终”
- 通过推演，找到通往“终”的路径
-
思考框架例
当一个产品经理给我交代一个要开发的功能特性时，我通常会问他这样一些问题：
为什么要做这个特性，它会给用户带来怎样的价值？
- 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
- 达成这个目的是否有其它手段？是不是一定要开发一个系统？
-
实战指南
面对问题时，用思考框架问问自己，现状、目标和路径
- 遇到事情，倒着想。
- 在做任何事之前，先定义完成的标准
- 子啊做任何需求或任务之前，先定好验收标准
- 尽早提交代码去集成
- 默认所有需求都不做，直到弄清楚为什么要做这件事。
- 扩大自己工作的上下文，别把自己局限在一个程序员的角色上
- 在动手做一件事之前，先推演一番。
- 问下自己，我的工作是不是可以用数字衡量
-
额外收获
作为程序员，你可以管理你的上级
- 拿老板说事的产品经理，你可以到老板面前澄清
- 喜欢无脑抄袭的产品经理，让他回去先想清楚到底抄的是什么
-
留言精选
以终为始，最常见的一个实践就是计划倒排了。先定时间，然后看功能是不是做不过来得砍掉一些，人力是不是不够需要补充一些，提前预知规避风险。
- 推演可以发现达成目标会涉及到哪些部门、哪些利益相关者，需要哪些资源，以及他们需要何时怎样的配合
知识点/读物推荐
- togaf学习理论
- 《精益创业》
- 《卓有成效的管理者》
任务分解总结
章节记录
- 11 | 向埃隆·马斯克学习任务分解
- 将一个原本毫无头绪的问题分解，分成若干个可以尝试回答的问题。
- 一个大问题，我们都很难给出答案，但回答小问题却是我们擅长的
- 不同的可执行定义差别在于，你是否能清楚地知道这个问题该如何解决
- 如今软件行业都在拥抱变化，而任务分解是我们拥抱变化的前提
- 总结：动手做一个工作之前，请先对它进行任务分解
- 12 | 测试也是程序员的事吗？
- 软件变更成本，它会随着时间和开发阶段逐步增加。
- 对于每个程序员来说，只有在开发阶段把代码和测试都写好，才有资格说，自己交付的是高质量的代码。
- 越是底层的测试，牵扯到相关内容越少，而高层测试则涉及面更广
- 小事反馈周期短，而大事反馈周期长
- 不是用单元测试框架写的测试就是单元测试
- 总结：多写单元测试
- 13 | 先写测试，就是测试驱动开发吗？
- 测试先行开发和测试驱动开发的差异就在重构上
- 重构和测试的互相配合，它会驱动着你把代码写得越来越好。
- 从测试看待代码，从而引起代码涉及转变
- 写代码之前，先想想怎么测
- 总结：我们应该编写可测的代码
- 14 | 大师级程序员的工作秘笈
- 大多数程序员之所以开发效率低，很多时候是没想清楚就动手了
- 如果你有一个微习惯，坚持就不难了
- 一个经过分解后的任务，需要关注的内容是有限的，我们就可以针对着这个任务，把方方面面的细节想得更加清晰。
- 总结：将任务拆小，越小越好
- 15 | 一起练习：手把手带你分解任务
- 很多人可能更习惯一个类一个类的写，我要说，最好按照一个需求、一个需求的过程走，这样，任务是可以随时停下来的。
- 检验每个任务项是否拆分到位，就是看你是否知道它应该怎么做了。
- 每做完一个任务，代码都是可以提交的。
- 总结：按照完整实现一个需求的顺序去安排分解出来的任务。
- 16 | 为什么你的测试不够好？
- 主要是因为这些测试不够简单。只有将复杂的测试拆分成简单的测试，测试才有可能做好。
- 把测试写简单，简单到一目了然，不需要证明它的正确性。
- 一般测试的四段：前置准备、执行、断言和清理
- 测试一定要有断言。
- 你真正应该做的是，多写几个测试，每个测试覆盖一种场景
- 测试标准：自动化(Automatic)、全面的(Thorough)、可重复的(Repeatable)、独立的(Independent)、专业的(Professional)
- 总结：要想写好测试，就要写简单的测试。
- 17 | 程序员也可以砍需求吗？
- 绝大多数问题都是由于分解的粒度太大造成的，少有因为粒度太小而出问题的。
- 分解标准：独立的(Independent)、可协商的(Negotiable)、有价值的(Valuable)、可估算的(Estimatable)、小(small)、可测试的(Testable)
- 用户故事，之所以是故事，就是要讲，要沟通
- 估算的结果是相对的，不是绝对精确的，只要给出一个相对估算就好
- 总结：想要管理好需求，先把需求拆小
- 18 | 需求管理：太多人给你安排任务，怎么办？
- 重要+紧急 = 立刻做，重要 + 不紧急 = 投入精力， 不重要+紧急=委托别人，不重要+不紧急=少做
- 如果不把精力放在重要的事情上，到最后可能都会变成紧急的事情
- 当员工想不明白的事，换成老板的视角就全明白了。
- 总结：尽量做最重要的事
- 19 | 如何用最小的代价做产品
- 我们要做的事验证一个想法的可行性，甚至不是为了开发一个软件，开发软件只是一种验证手段。
- 当时间有限时，我们需要学会找到一条可行的路径，在完整用户体验和完整系统之间，找到一个平衡。
- 想要在实践中运用好最小可行产品的理念，就是要用最小的代价找到一条可行的路径。
- 总结：做好产品开发，最可行的方式时采用MVP（最小可行产品）
行业最佳实践
- 测试金字塔
- 行业中测试组合的最佳实践
- 多写单元测试是关键
- 测试驱动开发
- 测试驱动开发的节奏是：红——绿——重构，重构是测试驱动开发区别与测试先行的关键
- 有人把测试驱动开发理解成测试驱动设计，它给行业带来的思维改变是，编写可测的代码
- 艾森豪威尔矩阵
- 将事情按照重要和紧急进行划分
- 重要+紧急 = 立刻做，重要 + 不紧急 = 投入精力， 不重要+紧急=委托别人，不重要+不紧急=少做
- 最小可行产品
- 刚刚好满足客户需求的产品
- 在实践中，要用最小的代价找到一条可行的路径
思维转变
- 尽量不写static方法
- 主分支开发模式是一种更好的开发分支模型
- 好的用户故事应该符合INVEST原则
- 估算是一个加深对需求理解的过程，好的估算是以任务分解为基础的
- 好的测试应该符合A-TRIP
- 分而治之，是人类解决问题的基本手段
- 软件变更成本，它会随着实践和开发逐步增加
- 测试框架把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来
- 极限编程之所以叫极限，它背后的理念就是把好的实践推向极限
- 大师级程序员的工作秘籍是任务分解，分解到可以进行的微操作
- 按照完整实现一个需求的顺序安排开发任务。
实战指南
- 动手做一个工作之前，请先对它进行任务分解
- 多写单元测试
- 我们应该编写可测的代码
- 将任务拆小，越小越好
- 按照完整实现一个需求的顺序去安排分解出来的人物
- 要想写好测试，就要写简单的测试
- 想要管理好需求，先把需求拆小
- 尽量做最重要的事
- 做好产品开发，最可行的方式是采用MVP
额外收获
- 对不了解的技术的任务，先要去了解技术，然后再做任务分解
- 通过一次技术Spike，学习新技术
- 丢弃掉在Spike过程中开发的原型代码
- 分清目标与现状，用目标作为方向，指导现状的改变
- 多个功能并行开发可以考虑使用Feature Toggle
- 在遗留系统上做改造可以考虑使用Branch By Abstraction
留言精选
- 任务分解的作用：1.事前思考，不会造成遗漏，2.任务实施过程被打断，任务列表可以让你快速继续
知识点/读物推荐
- 《设计模式》- Erich Gamma
- 《User Stories Applied》和《Agile Estimating and Planning》 - Mike Cohn (用户故事类)
- 《高效能人士的七个习惯》 - Stephen Richards Covey
- 原型工具
沟通反馈总结
章节记录
若有收获，就点个赞吧
0 人点赞
