上海译文出版社出的一堆村上的随笔系列，都是小小的一本，刚好可以放在短裤的口袋里，出门的时候揣上一本，等车或者无聊的时候都可以拿出来看一会儿，相当不错。村上25岁开始开酒吧，七年后把酒吧转让给别人，开始在家里写书养活自己。我也刚刚告别了七年的外企打工生涯，坐在家里，暂时还不清楚是否能养活自己。
在家办公的生活再简单不过，早上一睁眼就坐在电脑前，晚上一关机就上床睡觉，虽然没有免费可乐，但可以把Led Zeppelin的Whole lotta love放得震天响。有时候猫睡醒了就跑来趴在我腿上，做个鼠标托，做为同一屋顶下的同事，猫真可算是工程师的好朋友。
村上早晚写作，午后则出门逛游，曾被别人当作闲散人士投以狐疑的眼光。因为再没有时间限制，我准备培养一下下午四点钟锻炼的好习惯，来到楼下浩沙，居然次次暴满。不是说朝九晚五么？难道大家都是闲散人士？
什么叫天天Deadline？早上一来办公室，布置任务，明天交活。这就是我这几天的工作状态。说实话，这是一种很高效的工作方式。高中的时候，每周要交两篇周记，很痛苦，往往都要拖到周日一下写两篇。天天deadline就象老师每天布置的作业，明天一定要交，没有procrastinate的可能性。
对于一个项目的管理，除了长期计划，更需要把工作细化，使之在短时间段内可以监控。细化的粒度越小，可控性越强，效率越高。同时，阶段性的成就感也能抵消一部分工作压力。
细化工作存在风险，预期时间的单位量越小，和实际完成时间产生误差的机会和偏差量就越大。以周计算的工作，一周内的各项工作之间有所调整，可以缓冲由某部分工作超过预期带来的偏差。如果以天来划分工作，一天内工作量估计的不足往往没有回旋余地。
如何在提高效率和降低风险之间找到结合点，可能就是项目管理的艺术了。
一般来说我不太会专门去看软件开发方法类的书籍。我个人的偏见是：如果不可以亲自实践，只看这些书基本上没用。
近来项目开发，和美国同事合作，语言和距离的关系，遇到一些问题，美国同事提出使用scrum来管理开发过程，一次很好的实践敏捷开发的机会，我们都表示同意。
昨天老美花了一天作好了Scrum Sprint的表格，大家在每个属于自己的工作项目中添入估计时间，以小时为单位。今天早上我们开了第一次scrum meeting，15分钟，汇报每人具体在哪个条目上花了多少小时，并对估计时间做出调整。
我没有读更多scrum的介绍材料，但也有一些体会。
首先，以小时而不是传统的天、甚至人月来做预期以及跟踪进度，的确可以促使人换一个角度来看待工作时间分配。就好像用惯了变焦头，让你改用定焦头，思路不得不有所改变。时间段短了，步调不同了，当考虑到需要将这个小时划给某个工作时，进度很容易把握，分心以及用于焦虑的时间明显减少，符合getting things done的原则。以前也看过(10+2)*5的gtd方法，将时间片划得更小，要达到的效果是类似的。
再有，对项目进度的监督不再是交给每周数小时的例会，换之以每天15分钟，同时项目管理的方法更简单和直观，问题的发现和进度的调整都更容易更及时，效率得到提高。
今天是第一天，我没什么更多可说，时间长了，或许会发现更多好处或者缺陷，不管怎样，现在感觉还不错。
