石锅拌饭

两周前我的ipod出故障，跳歌不放歌，用disk utility发现硬盘分区问题，修复后重新格式化再用iPod update恢复出厂设置，上传两张专辑，听了几天没问题，继续上传，结果在上传过程中和iTunes一起吊死。
我的4代iPod早已经过保修期，坚决拒绝天价返修，又不想赶五代的尾巴，从我的del.icio.us里翻出了这篇文章，仔细研读了文章和下面的几百条回复后，总结出，如果你的ipod出现貌似硬盘故障，除了给apple再送一笔钱就无计可施的时候，可以尝试以下方法：

1. 按照苹果的官方建议重启ipod并恢复
2. 自己打开ipod，将硬盘下拔下再插上，以此解决因接触不良带来的问题
3. 左手拿住ipod，然后用右手猛击ipod，以此解决因硬盘磁头偏离带来的问题
4. 自己更换硬盘

我采取了方法2，刚刚上传完近1G的歌，暂时没有发现任何问题，现在正在听:)。

打开iPod非常容易。把iPod面朝上，用平头改椎从上向下插入面板和金属外壳之间，然后延着边滑动慢慢撬开。改椎越尖越容易，我使用的是修眼镜的小平头改椎。动作要非常小心，不然很容易留下划痕，我留下了三条。如果有硬塑料头改椎最好，划痕也不用担心了，据说吉他拨片不错。如果十年前你修过打口带，这不比那个更难。
这里给出的是没办法的办法，由此产生的任何后果，本人概不负责。

五一放假结束后的第一周，在一位经验丰富的美国同事带领下进行了一周的敏捷开发实践。在此之前的半年时间里也试过scrum，并且体会到了一些好处，但那一周不仅让我们体会到了好处，可以看到了敏捷开发的力量。很多书本上早读过的观点和方法在他的帮助下确确实实为我们解决了实际问题，很让人兴奋。
此后将近一个月的时间里，我们尝试延续第一周的方法，必须承认我们还不是实施敏捷开发的专家，但还是取得了以前无法想象的成果。下面是一些体会：
1。短而递进的开发周期。我在以前也提过，现在能比以前更好的采用分而治之的方法。对于一个需求，如果需要十二天来完成，那么两天我们能完成到一个什么程度，或者是一个简化的需求，或者是这个需求的一部分，只要实现的完成度可以拿出来衡量，我们就制定一个两天的计划，两天后验收，然后一步一步做下去而不是“这是需求，十二天后见！”。
2。更准确的估计工作量。估计工作量对我来说一直是一个难题。当这次我又对一个work item给出不很确定的估计时，我被反问“哪些不确定因素造成了这些不确定地工作量”，我回答那里那里可能有潜在的问题可能会导致工作量的增加，“那么如果目前不去考虑这些潜在的问题，你对工作量的估计是多少？”，我的答案马上变的确定了。对于不确定的问题，我们只需要把它记下来，在问题浮现或者变得确定后再解决，而不是把它变成包袱背在身上。能绕过这个槛是我这次最大的收获。
3。分清什么是需求，什么是实现。工程师在讨论问题的时候很容易陷入细节，以至于忘记了事情的根源，即需求。我不止一次的被提醒“你现在讨论的是需求还是具体实现”，在回答了这个问题后，很多诸如“做什么”“怎么做”的问题自然就得到了答案。
4。unit test。没有UT就不是敏捷开发，不光是为了测试，有时候只有UT才能确定你工作是否完成，才能使短而递进的开发成为可能。在这一点上我还欠缺不少。
教训也是有的，最大的教训就是我们把计划定得太激进以至于经过这三个星期我们越来越不敏捷了。40小时每周是敏捷开发的核心，此话一点不假。
最后是同事发给我们的一副图片，最真实地再现了我们的工作：