Changing Anytime
F.E. 2013 你的任务已经完成，去面对最终的命运吧，我将成为你，将你的意志全部革新…
今天听了一档节目，讲抑郁症的…
最近这段时间的修炼有点没找到门道，拖延之势很嚣张。拖延可以完全摧毁GTD，让每天做事没有效率，不知道从什么时候起你已经是这个模样了。最近在看《狼图腾》，有点共鸣，如果生活太安逸，就变的像羊，生活在危机中，就会变像狼。羊总是被狼吃掉，而狼总是比羊少的。至少在个人的极限领域里不应该看起来像一只羊吧。回溯到出现问题的地方，然后斩断这段历史，从这里继续上路，直到下个阶段，或许叫归零更正确。正是这个问题让一些人变成了羊，在以后的岁月里被吃掉，当然为平衡作出了自己的努力。
你需要把钥匙，但不是每个人都能清楚的发现所拥有的钥匙。在建立GTD模型时，好像忘记了一些东西，这些内容是我的弱点，所以有意识的被我忽略了，现在需要清理出来并给出的解决方案。
明天小路考，应该能过吧，哈哈。
MIUI每周更新一个版本，按雷军的说法：“用互联网模式开发手机操作系统”。传统软件的开发周期非常长，而操作系统就更长了，而互联网模式的特点就是快速迭代，及时响应用户需求及修复问题，这很符合敏捷开发的原则。对于新生、竞争激烈的移动互联网行业来说，快速进行版本迭代非常有必要。
在这2年的iOS开发工作中，迭代了许多版本，迭代流程也发生过变化，在这些迭代版本之间碰到了许多问题，这些问题可能是特有的，但也有些团队开发通常碰到的问题。而这些问题会影响版本周期的稳定性，常常导致无法按时发布，扰乱开发节奏，如：出现同时开发3个版本的情况。以下列出我碰到过影响迭代周期的因素：
App Store审核
iOS的App Store渠道是需要审核的，而这个时间基本有一定的不可预测性，Apple会以某些理由拒绝你。一般等待审核至少要1周，这个时间MIUI都更新一个版本了。这个时间是不可能停止开发，而等审核通过的。这就造成了一个版本的周期还没有结束，已经开始了下一个迭代版本的开发周期。
版本的开发周期
这个版本的定义还是类似于传统软件的定义，只不过周期更短，功能更少。我觉得这跟敏捷开发中快速迭代版本相差甚远。由于还是预先定义好版本的功能，因此给临时插入需求提供了机会。
需求
在稍微大一点的公司，需求可能分为2类：功能需求和非功能需求。功能需求我认为是App本身应该具备的功能，能够解决用户的实际问题。非功能需求基本大多来自于运营或合作。在版本的开发周期中，总会碰到紧急的需求，要求必需在当前迭代的版本完成。
质量
代码质量也是影响发布的重要因素，《人件》有说，“质量是免费的”，只需要花费点时间。如果团队够小够精干这个问题不大。但如果团队不小，并非所有成员都是精干，而需求也各种各样，这就可能造成许多代码质量不高。这就对团队中的软件工程化提出了更高的要求。如何管理迭代分枝的代码？是否采用特性分枝的开发模式？QA的工作如何快速的展开？持续集成如何展开？是否有单元测试？如何更好的进行跨部门合作？
针对这些问题，如何制定适合公司环境的流程，来保证迭代周期的稳定性变成了一个有意思挑战。
胖子说人的动力源来自：爱与创造。这是暗示我今年动力源不够么。。。今年一定要沉住气。
貌似这段时间胃又有点问题啦，看来酸奶不能断啊，或者多吃点泡菜？
最近发现在某个问题上相当的矛盾，一方面不认同通过条件来定位，另一方面自己也有明确的需求。而在这个问题的结果方面，又有哪些你现在不敢拥有？
体力也有点下降，跑步次数没有之前多了。而且感觉像要跑断腿一样，内心深处的眼睛在不断的摇晃。有种虚空的感觉，只剩下深处有一些东西，外在的都不怎么存在。择木。
今年的旅游计划算是提前完成了，年底还有时间再去一个地方，哈哈。
这一站是目的地是韩国济州岛，对于我这种没怎么看过海的人来说，找个海岛来欣赏才能体会广阔的意义。
上几张照片
人还真是有意思的东西，在没有跨越屏障之前，认为这就是边际。但如何能跨越屏障，将会获得更广阔的空间，如此循环着。寻找人生的至高点，然后一览众山小。
哎，出去之后才深切的感受到兲朝是多么水深火热。国内洗脑太严重，一时半会还缓不过来。中国人购买力果然强劲，各种扫货大妈，其实还是因为外边便宜。
