科学评估iOS开发工作量

在我团队里我们尽量把每次的开发工作控制在2周左右；我主要从源头上去控制这个开发量，比方反复和产品说，不要太多不要太炫；到现在也能和产品达成了一种默契。如果实在太多，我会将其拆分为2~3次进行。具体开发的时间和节奏，不是由我敲定，而是放手让开发人员自己去制定。实际上他们最后的评估的结果基本也就在我预估的时间左右；如果真碰到特别麻烦的地方，我会主动砍去部分需求，留到下次再做。其实有只用开发自己评估出来的，他们才会自己认可。
多说软件行业的开发周期不可评估，这话要分两方面来看。一个大型软件或复杂软件的开发确实很难评估。对于落实下去的关于一个迭代周期里的时间还是完全可以估计出来，甚至做到非常精准。

物流准备：原型，UI稿，和接口文档

原型不但用最粗糙的方式说明了页面内容，更加隐含了深层的业务逻辑，开始之前必须仔细研读。好的原型不光是简单放几张粗陋的页面，还要阐述业务逻辑，特别是页面无法说明的东西，就要通过语言来说明。
UI稿是我们要实现的目标，我们最后完成的成品应该是对UI稿的像素级拷贝。UI稿同时还承担了说明用户交互的职责。UI稿必须具备的要素，必须有尺寸标注，颜色标志（目前我们使用sketch来标志，确实非常方便；方便了设计师，也方便了开发人员）；还需要有切图。好的UI稿，应该遵循一定的设计规范，比方所有的热区至少是44*44；还应该有一致性，比方所有导航栏颜色，字体应该一致；所有分割线高度颜色，“一致”了才能给用户带来和谐的感觉。
接口文档，就是我们经常说的后端提供的接口文档。好的接口文档，应当是有一致的数据结构。良好的接口切分，尽量做到一张页面对应一个接口请求，而不是要通过好几个请求才能拿到一张页面所需的所有数据。

页面维度进行任务的划分

移动端主要工作在于实现页面，我们可以通过按页面一张张来检查来入手，评估工作。
按照页面，我们需要去看对应这样页面的原型说明，UI稿件以及接口说明。通过原型，了解业务逻辑，思考是否还有模糊或缺少的地方；查看对应接口返回的数据内容，是否可以支持这张页面的展示，页面上的每一行字，每一张图片，或者一个状态都是要通过接口数据中获取，所以要检查是否有数据缺少。UI稿，主要是评估界面中的内容是否会出现干涉，相关会有什么样的交互。

几种典型页面

列表页面
提到列表我们首先要想到的就是，是否需要分页展示；如果分页，每页展示多少数据，又是通过什么样交互来加载更多；列表要注意的另外一个问题就是，数据排序问题，通常这是由后端来完成。其次，列表是通过一个个重复样式的单元格组成，要查看接口中返回的数据接口是否可以完全填充满单元格。复杂一点的列表会有几种样式的单元格组成，相应返回的数据也会复杂一点；我认为，微博的列表是我见过最复杂的列表了，交互多（很多可以点击的地方，很多操作，比方点击展开..），内容多（用户名称，头像，内容，图片）。

用户注册页面
现在App估计都会有的页面，这个页面的特点就是
1，输入内容多，是个典型的表单页面；每个输入多要做检验，都有自己的样式要求。表单业务典型的要求，就是合理处理键盘类型，弹出和收起键盘，避免键盘遮挡输入框。
2，和后端业务交互多：比方请求验证码，登录要求；页面上完成一些限制，不能频繁发送验证码；多次登录异常，需要做特殊处理。
3，登录途径多：各种方法登录要求。
和列表相比，它的后端请求就多了很多。

详情页面
比方说淘宝的商品详情页面，特点是：
1，组成内容非常复杂：商品头图，商品价格，描述；相关评论；是否限购等等信息；各种按钮，收藏，购买，评论…
2，交互非常酷炫：有很多动态交互要求，比方头图可以滚动；往上推，导航栏会逐步变成透明。这个页面，设计师会竭尽所能，让它看起高大上。
因为内容复杂，所有返回的数据接口也会复杂。

制定计划的几个方针

1，自底向上：比方一定是要建立好网络接口请求，后才能进行页面实现。
2，先打框架，在填内容：通过网络请求到的数据，先可以用于呈现页面，而不要去管那些复杂的但局部的交互特效。
3，打通流程：先把所有的业务逻辑跑通，然后在做其他零碎页面。
4，在评估过程过程中，发现难点：比方逻辑复杂，交互复杂，或自己的只是盲点。这些难点会是开发过程中的不可控制因素。
5，将开发任务分解，每个任务不要超过0.5天。

计划制定好后，每天按照分解好的任务按部就班执行；只要每天都踏上了截止，那么一切都在掌握之中。

找一件长长久久的事，长长久久的做下去。