10x程序员工作法——以终为始

▶️明确现状

以终为始:

明确目标:正确、边界清晰

#遇到事情,倒着想。第一反应应该是梳理功能细节,而不是美滋滋践行新学的技术。

任何事物都要经过两次创造:

一次是在头脑中的创造,也就是智力上的或者第一次创造(Mental/First Creation),

然后才是付诸实践,也就是实际的构建或第二次创造(Physical/Second Creation)。

对于做软件,‘终’是“对用户有价值的软件”,可以通过以下方法降低实际开发的成本:

if 要给用户看产品样子➜先做原型(Prototype/Demo/POCProof Of Conception 概念证明)

if 呈现服务接口➜用模拟服务器搭建 moco

if 让程序员知道开发细节➜描述场景、行为

❗️提前准备,做好第一次创造:

准备迭代0 根据优先级确定迭代1要做的需求,然后细化


需求:

明确要做什么:

对于业务场景明确的需求:使用用户故事清晰界定

【用户故事(User Story)】 细化出有价值的需求

标题,简要地说明这个用户故事的主要内容,比如:注册用户使用用户名密码登录。

概述,简要地介绍这个用户故事的主要内容,一般会用这样的格式:

As a (Role), I want to (Activity), so that (Business Value).

没有这个功能时,用户是怎样完成这个事情的,有没有其他方式可以达到目的。

举个概述的例子:作为一个注册用户,我想要通过用户密码登录,以便我可以使用注册用户才能够使用的服务。

详述,详细地描述这个用户故事的完整流程,我们会把操作流程、用户界面等信息都放到这里。

比如:用户使用正确用户名和密码登录,就可以登录成功;如果密码不正确,则登录页面提示用户“用户名密码不正确”。基本上,看到这个部分,程序员就可以在心中描绘出这个用户故事的样子了。

列出超出范围的部分,比如:第三方登录不在范围内,这个部分主要是限定人们不要进一步发散。

验收标准,这个部分会描述一个正常使用的流程是怎样的,以及各种异常流程系统是如何给出响应的,这是程序员常常会欠缺的思考。它会把详述中很多叙述的部分变成一个具体的测试用例。

//依照BDD行为驱动开发。Java的BDD框架: JBehave, JDave, beanSpec, Instinct

比如,下面我给出的两个验收用例:

正常场景:给定一个注册用户张三,其用户名是 zhangsan,密码是 foobar,当张三使用 zhangsan 和 foobar 登录系统时,可以成功登录,登录成功后,跳转到用户中心。

异常场景:给定一个注册用户张三,其用户名是 zhangsan,密码是 foobar,当张三使用 zhangsan 和 wrong 登录系统时,登录失败,在登录页面上提示“用户名密码不正确”。

假如你没有这个条件,就扮演产品经理的角色,在开发前先厘清需求。最重要的是明确验收标准‼️

面向不确定性问题:试 减少对不确定性产品的过度开发

反馈循环:开发(build)->测量(measure)->‼️经过验证的认知(Validated Learning) 

➜idea->code产品投入市场->收集data,验证想法。

➜通过制作最小可行产品(Minimum Viable Product)以最低成本尝试

工具:精益画布

确认是否要做该产品特性:#默认所有需求都不做,直到弄清楚为什么要做这件事。仔细想每个需求的正真解决目标问题,紧急度、优先级、验收标准…

你要检证的东西是什么呢?他要验证的目标是否有数据可以度量呢?

要解决的这个问题是不是当前最重要的事情,是否还有其他更重要的问题呢?

验证这个目标是否有更简单的解决方案,是不是一定要通过开发一个产品特性来实现呢?

通过DoD清晰定义完成 同步团队间对完成的定义[]把DoD放入奇妙清单

先推演,然后拿出详细的实施方案:

先从结果的角度入手,看看最终上线要考虑哪些因素

推演出一个可以一步一步执行的上线方案,用前面考虑到的因素作为衡量指标。

根据推演出来的上线方案,总结要做的任务

技术:

构建脚本:编译打包,测试,构建 IDE 工程、代码风格检查、常见的 bug 模式检查、测试覆盖率…

CI Monitor :把持续集成的状态展示 Cucumber

管理数据库变更:数据库迁移…… flyway

把部署/发布自动化 by Docker/shell

风险准备:如何快速恢复服务,如何回滚版本、回滚数据库

用数字衡量工作 测试覆盖率,API调用时间、次数

工作

向上管理:

发挥上级的长处,以其能接受的方式向其提出建议

❗️敢于对不合理要求说“不”

管理上级的预期 把你看到的问题暴露给上级

帮助上级丰富知识

说出你的想法

拓宽工作的上下文:

找到你和你的下一步职业目标的差异

很多时候跳出程序员角色,技术不再是问题

多了解别人的工作逻辑,认识软件开发的全生命周期

多了解一些上下文,你才有能力判断自己是否想多了。

实际操作

倒排时间表:调整需求范围和资源配置

测试驱动开发TDD

Amazon开发顺序:新闻稿➜FAQ➜用户文档➜代码 //

需求评审-技术方案评审-测试用例评审-写代码-测试-上线-测试。

你可能感兴趣的:(10x程序员工作法——以终为始)