前言

利用前几天的篇幅，简单的讨论敏捷与 Scrum，也传达了我觉得团队需要注意的地方。今天再让我们回到团队的日常，一个每人都在苦思，难度直逼午餐要吃什麽的问题－－「没有时间」。

时间不够吗

还记得第一次看到 Joey Chen 前辈的一段话 (91 敏捷开发之路的贴文)：

我认同，『没有时间』是个问题。
问题是，『你做了什麽』来解决这问题？

至今仍然可以记起当时的震撼，这个段话精准点出了问题，同时带有积极的推力。是时候问问自己，究竟做了些什麽来回应时间不够的问题呢？

挤出时间的选择：Side project

来分享我的个人经验，我时常利用时间做一些不在工作范围内的事，以 Side project 的方式开发提高工作效率的工具，也将这个想法推荐给夥伴们，至今我们有量身打造的自动化释出工具、多语系管理工具、程序码资源统整工具、开发平台与看板资料分析工具等，每个工具都大幅减化工作复杂度，持续性地节省团队时间，释放珍贵的创造力，相当感谢团队成员的努力。

但回头看看，每个工具也是投入不少工作量，无论是利用工作之外的时间，或利用工作内零碎的时间完成，若在一开始就先思索一番，那很可能被一个「没时间」给回绝了，於是团队继续做着「粗重」的软件开发工作。

这是一种自动化的体现，我们愿意做吗？

工作态度、能力与时间

若一份工对自己来说没有任何意义，它单纯只是标准工时 8 小时的一种体现 (不同公司算法可能不同，这边以劳动部标准为例)，那会有很高的机率你觉得时间不够用，而且你时时都觉得自己在追赶期限。特别在软件开发这种脑力产业当中，任何工作上的不顺利、制度 / 环境 / 需求上的变化，都会带给你很大的冲击，这可能来自对工作热忱的缺乏，也可能是能力尚不能负荷。

一下子就严肃起来了，谈到能力，经验与技能累积在软件开发当中是重要的，特别是在 Scrum 这种快步调，多方协作的情境下，成员有多少的专业能力足以支持？我们可以思考，正在困扰着我们，让我们觉得时间不够用的工作任务，与自己的能力是否存在关联？这不是批评，而是提醒，如果是因为能力关系，那麽加强它可能是符合自己的价值观上最简单做法了。

你我应该都同意，在学期间或是各方的专业训练课程，都是一个开端，往後仍然需要靠自己延续，才能够迎合这快速进步的时代。若您是位初学者，保有自己对特定领域的热爱是个起点，把课程作为基石，在上面叠加自己大量的学习与尝试，这会使得您在业界能更顺畅的发挥。学习不会停止，任何工作项目都可能是下一阶段的学习大门。当然，如果您已经很认真在学习，能力足够与否只是个短暂的表象，总有一天会到位的。

我们是否对工作有热忱，是否爱着努力的目标(如工作、产品、专案)，会很大幅度影响你对时间的感受。总是觉得时间不够用的读者，不妨以这个方向思考一下，不要急着落入受害者情节。或许理性的读者可能会想反驳，这不就是拐个弯要我们加班吗？从「时间」数字上来看，它可能会是加班，但在钻研这个问题之前，不如想想：「我是为了谁在工作？」。

倘若你真的需要加班，那希望你是为了消灭加班而加班。

没时间测试

谈「没时间」怎麽能缺了这个总是没时间做的事情呢？

敏捷团队必须重视专业技能的卓越度，但这方面的议题在 Scrum 没有明确提及，有些团队可能就遗忘了，殊不知这些都是专业的软件开发团队的必要素养，而测试正是其中一环。

话说回来，一提起要做测试 (我们先以自动化单元测试为对象)，显少有人是笑跟你说好，更多是近乎反射思考的回应「没时间」，这点除了在工作上很容易观察，在多数谈「测试」的研讨会议程中也相当常见，总之，测试这回事就是这麽理所当然的与没时间绑在一起。

会有这种反应，在我的观察，其一可能是对测试这门艺术的熟悉度还不高，尚不足以顺畅地融入实作。也因此，看到 TDD 像看到鬼、穿插於实作中的测试打乱原有的节奏、实作写完还得「补」上测试，辛苦得很。

那麽，该怎麽让团队接受测试，并开始写测试？有许多前辈分享了自己经验，而我也不自称是测试专家，这边分享我浅薄的看法：

1. 先说明测试好在哪、为什麽我们要做测试。
2. 安排教练训练，确保成员掌握基本的测试原则，以及知道如何运用团队选定的测试框架进行撰写。
3. 如果团队有 CI，测试必须在 CI 任务上被触发上，这是非常重要且必要的。如果没有 CI，那先去生个 CI，再把测试接上 (喂！)
4. Code coverage 不一定要马上要求，重点是有「开始」写测试的行为，看到 Coverage 成长是一个过程，暂时不用要求一定要成长到多少。
5. 承担时程延误的可能性，这个过程难免跌跌撞撞，有好的指导者可以缩短阵痛期，如果是自行摸索作必须做好延期的预估。

Scrum 与时间

那麽在 Scrum 的情境下，有什麽与时间相关的议题吗？

Scrum 这种迭代式的开发模式，每次冲刺不仅是产出价值增量，更要让它带起团队成长的正向循环。冲刺内可以运用的时间并不长，团队必须善用它，为此必须尽可能抑制意外的发生，这也可以接到刚才谈到的自动化测试，如果团队缺少这种保护机制，那快速运转的冲刺只是把团队带向更危险的境界，我们可能冲很快，但一点防护都没有。

一旦团队时常在补洞，大量的间就这样消耗掉了，团队总是无法预测这次的改动、增加新功能会导致什麽副作用，久了也无法放心的交付，持续陷入了没时间的循环。

借这个小主题仅提出测试与时间的关系，单就这一点足够团队好好思索。

急病投债

即便再怎麽努力，多少会有迫在眉睫的问题需要团队立即处理，在没有足够的反应时间、无法透过正常手段完成的情况下，团队自然会应用各种绕道的技术，以欠下技术债为代价来实现短期目标。这很有效，但治标不治本，可以带来「看起来」还不错的效果，但千万记得这只是短期的，能早早还债就还，免得它成为未来时间不够用的原因，这也属於团队应该「挤」一下的范畴。

艾森豪矩阵

谈时间、谈工作效率，读者可能多少看过艾森豪矩阵，以四个象限划分出：「紧急且重要」、「重要但不紧急」、「紧急但不重要」与「不紧急也不重要」。

在时间不够的情况下，要删掉哪一类的工作、要优先做什麽工作相信不需要说明，这个分析工具可以帮助你判断工作项目的先後续序，但还是相对被动了一些，所以现在才提起，希望我们能以更极积的方式来面对时间不足。

小结

时间放着不会自己冒出来的，我们可以选择多做点什麽(开发工具、调整流程、排除障碍)；也可以少做点什麽，或… 不特别做什麽，但请停止抱怨。