在读完无痛功能规格 – Part 4：提示之后，ㄚ琪要继续读无痛软体时程，但是ㄚ琪先跑到约耳的网站去看时，发现他有一个重要的更新告知：“This article is obsolete.
Over the years, I’ve learned a lot more about schedules and estimates. A newer, far better method for producing accurate software schedules painlessly is Evidence-Based Scheduling. Read that instead.
This article remains here for archival purposes, but please don’t read it!”
他说这篇文章已经过时，并且教我们不要去读，可是我中文版的已经读完了啦！而且也是对ㄚ琪的工作很有影响，但是我也想看看，新的这篇Evidence-Based Scheduling会有时馍更新，所以我会两篇合起看，并检讨一下自己的工作！
“睾丸素过剩的自大狂游戏公司”有够夸张吧，看是约耳要骗我们来看的！
记取莲花的Lotus 123 3.0版、让Jamie Zawinski有世界闻名之怒的Netscape的5.0版web浏览器及曾称霸一时的资料库软体dBase的安信达(Ashton-Tate)的教训，这三个古老的软体ㄚ琪也都有碰过，不过都玩得没有很多，想来也是设计不良吧，或跟台湾水土不服，还好没有继续用是对的，不然一定会哭说，怎么会倒？
既然软体界的魏征约耳说，“所以说你一定得定时程。”身为唐太宗的你一定为听这个劝的。
“那么为什么没人要订时程呢？主要原因有二。首先是执行起来很痛苦。其次是没人认为值得做。”执行很痛苦，这个ㄚ琪深有体验，特别是针对自己没写过的程式，真像是如履薄冰啊！一不小心就会身败名裂，至于值不值得做就ㄚ琪来看是非常有必要的！
约耳就提供了一个简单无痛的方法，可以订出确实无误的时程。
1)使用微软Excel。不要用要花大量时间处理相关连性(dependency)的微软Project，那是设计给建筑办公大楼用的，喔！原来如此，难怪我非常地讨厌微软这个东西，而且在ㄚ琪前任公司时代，资讯经理竟要导微软Project 2007进入公司，哇！难怪就这样倒了，当然这不是主因，但事出必有因。我觉得聪明的还是ㄚ琪前任处长的睿智，他想用专案管理，就叫ㄚ琪开发了一个比Excel好用，但又比微软Project简单的Web介面的专案管理，这一套程式弄到现在的公司一样的得心应手地用。另外所谓相关连性是指有两件工作，第一件工作必须在第二件工作开始前完成。
2)简单就好。
（引用自无痛软体时程)
只要七个栏位：Feature、Task、Priority、Orig Est、Curr Est、Elapsed、Remain，当然我想每个人可以视需要改变这个表格！
3)每个功能应该包含多项工作。
4)只有实际要写该程式的程式员才能排出该项的时程。那是一定的，如果找不会写程式的老板定时程，等着铁达尼号沉吧！
5)把工作分得很细。“当你必须订出细项工作时，就得强迫自己实际地找出确实要进行的步骤。细分工作还有另一个理由，就是能逼你设计那些要命的功能。”这个ㄚ琪有很多话可以说的，我看过很多菜鸟对专案管理不懂，所以在用我的专案管理程式时，会变成只有一个工作项目，这意味着你不了解专案不懂细节，因此我很有理由地就可以知道你真是菜！另外不像一些小白脸似的业务个性能说会道，可以讲得天花乱坠，相信我，我还是有能力去分辨业务的真假的！有些黝黑的大老粗，说是技术职嘛，也不像，只要我去看看，就可以看出是空心的还是实心的了，在福音的学习上也是如此，有些人常自栩福音生活化，但是当他上台分享的时候，他无法说出详细的见证时，这就可以让我们知道，这是空心的了，如果你真是福音生活化，你必定会有实务经验，这个我们称之为灵性的见证，你有去想有去做，才是福音生活化，也因为你有这样的技术，你在分享见证时才不会空洞！
6)记录最初和目前的估计。 “当你把某件工作第一次排进时程时，先估计所需时数并填入Orig[inal] Est[imate]以及Curr[ent] Est[imate]栏位中。”这是经验的累积，别无他法，ㄚ琪也是这样过来的！如何作到精准，做财务预算也是一样的道理！
7)每天更新耗时(elapsed)栏。
8)加上国定假日，休假等等项目。记得将安息日算上，免得离弃了神，这样程式会越写越好！
9)把除错时间排入时程！
10)把整合时间排入时程中。
11)在时程中加上缓冲时间。“考虑两种重要的缓冲。第一种：预防工作耗时超过预期的缓冲。第二种：针对未预期但必要的工作的缓冲(这通常是因为管理阶层决定某功能超级重要，绝对不能等到下一版)。”
12)绝对不要让经理叫程式员缩减估计时间。‘很多菜鸟软体经理认为能用精细“紧密(短得不切实际)”的时程，“激励”程式人员做得更快。我认为这种激励根本是头壳坏掉。’‘不过你绝对绝对不可能由n变成3n，如果你自认有这种本事，请写信告知贵公司的股票代码好让我放空。’其实我很想这么做，不过继然会让公司倒，还是不干得好！
13)时程就像积木。“如果你有一堆积木，积木太多塞不进箱子里。这时候你只有两个选择：找个大点的箱子或拿掉一些积木。”这个比喻懂吧，我就不多说了！
另外你如果要用Excel做专案管理的话，你需要懂一些功能：
共用活页簿
自动筛选
枢钮分析表
WORKDAY函数
如果你还有问题，就看约耳的Q&A吧：Juggling Tasks in Excel
说到Evidence-Based Scheduling, or EBS（循证式软体时程），当然前面骗人的屁话，如果你没有看无痛软体时程，你当然要看，如果看过了，就可以跳过！
你收集证据，当然主要是从历史的时间表资料中来，然后回馈到你的时程中，你会因此会画出像下图类似的分布曲线图，曲线越陡，就越有证据显示出货的日期越真确！
（引用自Evidence-Based Scheduling）
以下是几个要做的事：
1) Break ‘er down
把工作细分，工作时间不要超过16小时！内容有点跟前述的相似！
2) Track elapsed time
追踪过去的时间，收集资料，做个统计图表，像下图：
因此你可以看看你的斜率是多少，斜率1表示精准，过与不及都不好，所以这个我想是要由经验来累积的！
3) Simulate the future
这一节介绍Monte Carlo method（蒙地卡罗方法，也称统计模拟方法，是二十世纪四十年代中期由于科学技术的发展和电子计算机的发明，而被提出的一种以机率统计理论为指导的一类非常重要的数值计算方法。），看起来这需要会点数学，更精准的说要会统计学，我不知道是不是很多人会，我自己有瞄过这个方法，但是我没有用过跟做过这类的统计题目，所以可能有点难吧！但是本中大概是假设100种可能性，每一种就有1%的机率，你可以用前面的表，然后配上下表：
| Estimate: | 4 | 8 | 2 | 8 | 16 | |
| Random Velocity: | 0.6 | 0.5 | 0.6 | 0.6 | 0.5 | Total: |
| E/V: | 6.7 | 16 | 3.3 | 13.3 | 32 | 71.3 |
你可以依据这个表大概估出这个软体出货的时期！
这个计算可能是很累人的，所以相信电脑的使用是很需要的！
强迫症的毛病不需要，这里在推荐EBS是多棒的方法，嗯！看起来是！
4) Manage your projects actively
这个工作的轻重缓急看来细分的很多，比我自己在用的还多！
从甘特图里找出哪些人的工作有问题一目了然！
Scope creep
这里提到的就是ㄚ琪担心的事，如果有些专案是新的点子，你没碰过该怎么办？
- New feature ideas
- Responding to the competition
- Integration (getting everyone’s code to work together when it’s merged)
- Debugging time
- Usability testing (and incorporating the results of those tests into the product).
- Beta tests
你还是可以做出类似上图来做规划。
这里有一些约耳学习关于时程表的经验：
1) Only the programmer doing the work can create the estimate.只有程式设计师可以作估计的工作
2) Fix bugs as you find them, and charge the time back to the original task.当你发现错误时修正这些错误，把这些时间计到原来的工作上
3) Don’t let managers badger developers into shorter estimates.不要让经理纠缠开发人员更短的估计时间，这跟前述类似，但是我发现3n的时间已经变成4n了，哇！
4) A schedule is a box of wood blocks.时程表是一个积木
感觉新旧文没有差异很大，但是要更精准的估计时程，用新文的EBS会较妥，用一些简单的数学工具来计算，算是很大的进步，但是如果你觉得数学差，那用前文的介绍，我是觉得没什么不好，那ㄚ琪算是个科技人嘛！是应该好好用新文去做的时候了！