▶️明确现状
以终为始：
明确目标：正确、边界清晰
#遇到事情，倒着想。第一反应应该是梳理功能细节，而不是美滋滋践行新学的技术。
任何事物都要经过两次创造：
一次是在头脑中的创造，也就是智力上的或者第一次创造（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➜用户文档➜代码 //
需求评审－技术方案评审－测试用例评审－写代码－测试－上线－测试。