一个版本, 到一个需求的开发都应该有节奏, 有规划, 有时间.
在日常的开发中如何评估自己的能力, 同事的能力, 协作能力. 需要在工作中慢慢的来感悟, 但是自己必须要有这个意识. 所以导致了该规范的出现
目前团队的需求管理工具为 tapd
评审会
按时参加, 认真听每一个需求, 尽量完全的理解每一个需求, 如果需求在需求会上不能完全理解, 请即时在会下找产品做详细的沟通.
每一个需求需要注意的点
-
该需求是 bug 类需求还是 feature 类需求.
-
该需求要解决什么问题? 或者是该需求想要做什么, 想要得到什么样的效果.
-
如果是 bug 类的需求, 需要明确如何 reproduce 该 bug.
-
该需求涉及到几方面, Front End engineer, Back End engineer, User Interface designer, User Experience designer, Operation engineer.
-
该需求是否和目前已有的功能有交集.
-
该需求是否需要拆分来分配给多人实现.
-
如果需要和后端交互, 在评审阶段就需要将有几个接口, 接口大概的复杂度给出.
-
如果需要和设计交互, 需要明确设计的要求, 以及实现上的难度.
-
每一个需求的时间必须清晰, 需求的完成时间是由以下几方面加起来的
- 开发时间
- 联调时间
- 测试时间
- 测试的反馈修复时间
Note: 以上的评审包括 产品的需求评审, 技术的技术评审
每一个版本需要注意的点
- 深刻理解该版本中的所有需求, 并将时间确定下来, 分配需求的时候需要和开发者深入沟通需求的所有细节
- 整个版本的时间都需要明确构成的每一个阶段, 每一个时间点都是被确定下来的, 不要做模糊的事情
- 每一个需求在做完之后都可以即时提测, 而不用等待整个版本的完成. 所以最终的测试时间不需要留的太多
记录工具
- 便利贴
每一个版本的时间规范以及每个时间的提测节点可以写在便利贴中, 贴在副屏幕上面
接下来需要做的事情也可以写在便利贴上, 贴在副屏幕上面