需求制定
版本开发之前会提前制定需求，也会定义一下版本号，例如 v3.7。每次迭代会把值得迭代点作为需求，有些小修改就直接就改掉了。当然要跟 boss 过一下需求，明确一下我要干这些事儿了。
虽然我也不喜欢中途改需求，但这避免不了，只能在前期沟通时候尽量约定好，每一个需求的制作和衡量标准。
方案制作并核对
需求定好之后，就要出相应的原型了，其实出方案之前都是有草图的，甚至都是与 boss、设计 大概沟通过的，只是把方案绘制出来罢了，并且写清楚一些逻辑关系和页面关系。
8-10 个 feature 我大概需要 1 天时间绘制
与执行人进行需求沟通
绘制完原型后，会与 boss 进行 double check，确保没什么问题，会召集全部兄弟（有前端、后端、设计）一起开个「需求沟通会」，坐在会议室里大约 1 小时，沟通一下需求，大家看看方案，基本确定实现方案。
需求沟通会有几个目的：
1、 让兄弟们清楚，我们要干的事情和目标；
2、 兄弟们之间可以约定好方案，例如 A 给 B 的 api 形式如何等等…
我也会出现需求沟通会上发现，有些方案不太靠谱，之前没有预料到一些情况，这时候我会把当前需求停掉，继续往下说，会后会马上找到 boss 寻找解决方案，再次与直接执行人沟通。
这部分大约需要 1-2 小时，其实 2015 开始我很想把用研也带着一起开会，应该尽力争取吧~
开发排期
需求沟通会之后，要进行相应的开发排期（如附件），可以按照需求进行排期，每个需求的执行人需要执行几天，例如：设计 2 天，前端 1 天，API 3 天。
这是我至今为止的做法，其实不好。
以后的做法：
排期只排大概时间点和顺序，不排具体执行天数。例如 api 需要 3 天，前端 1 天，设计 1 天。那设计能不能在看到我的草稿后就开始设计起来了？我的原型只写逻辑就好了。api 能不能先约定个接口形式出个假接口，之后再慢慢写真接口好了。
那这样前端可以最早的拿到设计稿，开始还原界面，假接口 1 小时就可以给出来，效率是不是提高了。
但仍然是有个 deadline 的，大概估算时间拿到后，就可以算出合理完成时间，可以向 boss 汇报时间。如果是团队比较 nice 的情况，bugfix 时间大概留出开发时间的 1/3 则合理。
这样做的好处就先不写了，反正能提高效率，兄弟们也开心。
验收、测试等…
开发完成=自测通过，这是个死标准，必须要自测，自测通过后再提交正式测试！
为什么呢？
因为我太懒，不想反复测试，哈哈~
开玩笑啦，其实这是对开发的要求，做出来的东西应该是「作品」而不仅仅是「产物」。
我会测试中，用 worktile 进行 bug 管理和协同，其实之后准备用 worktile 做项目任务管理，而不仅仅是 bug。
completed
测试通过，大功告成了。要干嘛呢？当然是要汇报 boss 我们他妈的这么快就干完了~~~
如果 delay 了怎么办？
当然是要挨骂，但 delay 之前应更早的发出 delay 预警，提前告知这个版本由于 XX 问题，要 delay XX 天。但 delay 不全是坏处，例如 XX 功能，如果按 A 方式完成则需要 1 天，但工程性不好。如果按 B 方式完成则需要 3 天，但工程性、兼容性和扩展性都好，那么就应该选择 B 方法去做，并且汇报称「为了更好，而 delay」，如果 boss 坚决要求速度，那么就应该按照 A 方式去执行。
忘说了，其实开发排期完成之后，就已经进入下一个版本迭代的工作中了…