优质“码农”是怎样造就的——读《快速软件开发》by Minghui Tan
当初刚接过沉甸甸的《快速软件开发》的时候，心头不由一紧，软件开发？还快速的？不会是一本代码吧，要不就是一本流程图，反正内容一定足够“专业”足够“厚重”，万万没想到居然是一本“有图有真相”的非纯技术书籍！读过了自己感兴趣的章节，有些自己的理解，也有些尚存的疑问。
1，激励机制。《快速软件开发》中提到软件开发的人员大多是理性内向，而正因为如此，激励他们最重要的方式就是成就感。内向的人或许不善交流，但是他们认准的事儿，大多会执着地坚持下去，即使遇到困难，如果他们认为值得，也会咬着牙挺着。对于那些怀揣梦想但是或许不善言谈的程序员来说，实现他们自己设定的有意义的目标会让他们发挥出更大的潜能，真正实现小宇宙大爆发。这让我想起微软的一个小惯例，每当有员工申请专利的时候，公司总会发给员工一块小的专利石。这块小小的专利石，与其说是表彰，倒不如说是纪念，与其说是嘉奖，倒不如说是鼓励。这一小块石头，让员工们得到了满满的成就感啊！
2，自愿加班。这部分虽然在本书的最后，但我却确实挺感兴趣的。相传有的公司老板，每天晚上下班后一个多小时会在公司楼下溜达，并记录下那些天天挑灯夜战的人员的名单，而这些人等来的不是表扬和鼓励，却是批评和教育。到底该不该鼓励加班，大家众说纷纭。书里提到，适当的自愿加班可以适用于任何环境，但是由于自愿加班和过度的强迫加班被广泛使用，实际上使其应用受到了一定的限制。书中还有一副让我印象很深刻的折线图，如果进度加力超过了平均值一段水平，就出现了很明显的拐点，如果再加力，就是标准的事倍功半，费力不讨好了。这点也很符合在公司的生活，从来没有人要求我们要加班，但是大多数人都选择十点之后再走，主要原因就是每位mentor在背后默默地push着我们，另外就是来自我们内心的想要做出点儿啥的想法了，这点也是和成就感一致的。
3，团队合作。个人感觉这部分和我们的关系挺紧密的，现在正在进行team project，之前刚刚完成了pair project，都属于团队合作，只不过规模不同。我仔细浏览了书中讲团队合作的部分，没有看都有明确写分工原则的部分，只有比较大的类似于业务团队，主程序团队之类的划分，我比较疑惑，因为我认为分工很大程度上影响着工作效率，甚至影响着成败。在结对编程中，两个人面对同一台显示器，一起编程，但在团队中，总不可能一群人注视着一台电脑，但是究竟该怎样给每个人分工呢。是按软件实现的不同功能，还是按照工程的结构，亦或是按照程序实现的流程。在rosting的team project中，我和haifeng同学的工作始终处于你中有我，我中有你的状态，很多人笑谈我们可以在team中实现结对编程了。我认为这也未必不可以，但我一直困惑是我们的任务分配不合理还是在团队合作中这本身就是不可避免的？
4，估算能力。书中特意开辟出一章主要讲估算，可见估算对软件开发的重要性。还记得软件工程课上，邹老师让我估计黄河入海口每年的流量，我当时目瞪口呆，实在是哑口无言。回家问我爸，老爸答曰：黄河是不是有时候都断流了。同样，在软件开发中我们也设身处地的感受到了估算的重要性，分配任务的时候总不能信口开河大包大揽，也不能推三阻四混吃混喝，只有合理地估算工作量，才能合理地做出计划，并完成计划。在team project中，我们要在原始代码的基础上添加功能，但是真正熟悉原代码已是在小组分工结束之后，我当时给自己计划连续两天的任务是一天画圆，一天连线，拿到了代码才发现，圆都画出来了，线早就不是什么难事儿了，这两天若想按期完成，必是前紧后松。书中在估算技巧中提到，避免无准备的估算，同时留出估算时间，并做好计划，我想，黄河流量和小组计划对我来说就是无准备估算，所以要么说不出，要么说不准。所以我很同意书中所说的“把估算本身当作一个小项目做”。但是我很疑惑的是，究竟估算要做到什么程度才算是完成了，我觉得估算的越精细，日后实现就越顺理成章，其实是很节省时间的，但绝对的理想是不可能的，对于初学者，我认为最好能给出一个模型，或是规律，尺度的把握究竟是怎样的？
5，小型里程碑。读了书中的有关小型里程碑的段落，个人感觉很像是daily scrum，每一两天进行一次。文中提到了里程碑的二分性，指出里程碑分为完成和未完成两种，我比较困惑为何不能像书中反例那样说完成了多少。在task中 有remaining time和estimated time，他们之间的比例不就是完成的多少吗？如果单纯完成和未完成两种选择，如果遇到很多个里程碑都完成了一些基础构建，而差最后一步，比如把几个里程碑连起来这样不能马上完成的工作，这样完成与否还能很好的衡量工作量吗?
以上的这些问题，恐怕要在完成了team project之后又会别有一番理解吧！