碎片粘合:Tasking DD 启发的思考
Posted Phodal
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了碎片粘合:Tasking DD 启发的思考相关的知识,希望对你有一定的参考价值。
标题原来意指 TDD,即 Test Driven Development,用 TDD 来进行碎片化时间的粘合。只是呢,Tasking 才是 TDD 的核心,于是在新的思考之下,我重构了本文的大纲。这篇文章的构成也非常有意思 —— 以致于我都没想清楚,为什么会写成这样。它只是由一个个的思考,所构成的文章,有些杂乱。
引子 0:长长的 To Do
昨天打开我的 To Do 时,发现待写的“文章 idea”有近一百篇,大概率是写不完了。所以需要清理一下 Todo 了,本文也是其中的项。在日常工作中,总会突然领悟到一些东西(aha 时刻),便会简单地写个标题或者一句话记录一下。在周末的时候,寻找相关的资料,编写文章,以深入相关领域的思考。
在这里,我们的第一个关键点便是:随时可记录 idea。其次,便是寻找时间完善它。只要时间不长,就不会像我一样,有一个长长的 todo —— 够我再写一年了。
引子 1:成就感 ox Game
文章的另外一个起源非常有意思。源于如何在非工作时间摸鱼,如早、中、晚过度碎片的时候,如何有效地组织起来,~~以更好地玩游戏~~。我的意思是:写会代码,看点资料,补充技术。
当你的时间被切割得支离破碎,比如参加各种会议时,要再挤出时间来写点代码,并不是一件容易的事。想法被打断了,在刚找到感觉的时候,可能又一个新的会议,又或者是讨论。这大抵就是作为一个技术负责人的生活,能寻找稳定的编码时间非常不易。
接着,离开这个悲伤的故事。回想一下,每天茶余饭后,总会拿起手机,玩会游戏。游戏里有每日任务、每周任务、每月任务,休息的时候拣起来,在领导来的时候关上。
除了游戏会带来一系列的成就感之后,它还有一个明确地任务,让你知道你完成了没有,你可以看到与目标的差距。比如,你有一个 51 级的英雄,而这个游戏的上限是 60,所以很进步一点,就能看到明显地成长。也因此,与花时间成长来说,花时间玩游戏更有成就感。
引子 2:从 Test Driven 向上到 Tasking Driven
多年过去,我一直在努力地保持着早上、中午、下午编写代码。为了保证细粒度(10 ~ 20 分钟内)时间下,能提交一次代码。需要有更细粒度的需求/任务,才能达成这样的目标。
从实践的模式来看,TDD(Test Driven Development)是最适合于业余开源项目的实践 —— “随时”可以中断手头的工作,一旦另外的再优先级的任务完成之后,可以继续找到当前的任务(即测试),完成这部分的工作。尽管,依然会存在一定的状态丢失,但是都能尽量地回到上下文中。
在缺乏“周期性练习” + “刻意训练”的情况下,TDD 便是一件相当难的事情。它的难点不在于,是否先写测试,而在于 Tasking。你并不一定需要 Test First,而是需要 Tasking First(即先进行任务拆解)。依此往下类推,用于支撑我们改善碎片时间的一个关键是:Tasking Driven。
粘合碎片时间:动机 + 举措 + 拆解
从理论上,粘合起碎片时间,并不是一件复杂的事情。诸如于,日常工作时,通常在显示器前、电脑上粘贴各种便利贴,来提醒我们:今天需要做哪些事情?在解决了一个个的问题之后,便会干掉一个个的便利贴。与编码相比,这种粒度会更为相比。不过呢,它没有突然任务拆解的重要性。
所以,对于我们来说,会粘合起碎片化的时间,需要:
动机。强烈的动机,以实现某一愿景。
举措。实现愿景所需要做的举措
拆解。拆解完的任务的子任务
我们可以将它对比到软件开发中的看板与故事卡的故事,又或者是更高维度的精益价值树(LVT)。只是呢,上述的三者都具备一点的难度。
如何有强烈的动机?假设我们想保护改善颈椎、腰椎的情况,那么正确的方式,应该是在工作的时候,多次起身做做动作。但是,什么时候才会让你有强烈的去攺它的欲望呢,当你的腰开始疼的时候……。
怎样的举措才是合适的?再回到程序员健康这个问题,我怎么知道这个举措真的是有效的?我又从哪里获取对应的尝试性方案呢?来自社区网站(如知乎),又或者是朋友的建议?
如何有效地拆解任务?采用 SMART 原则?我怎么验证拆解确实是有效的?
这部分的坑就暂时挖到了这里,等我回头再想想。而粘合起碎片时间,我觉得它的一个核心要素在于:状态回溯。
核心原则:状态回溯的机制
再回过来看,从 TDD 的例子里,我们有一个非常好的原则:IDE + Git 可以为我们提供一个非常好的状态记录。在我们离开 IDE 的时候,它记录下了当时的状态。只要你们的猫不会同时按下 Ctrl/Command + Z,再按一下其它的按钮,那么我们就可以回放到当时的状态。这一点点小的 IDE 功能,是人类的大脑无法提供的,它可以帮我们回溯时间线上记忆的瞬间。
所以,在我继续填碎片化时间的这个坑时,应该思考是否要做的其它事情,都有相应的回溯机制?
一个没有把握的例子,我们在读书的时候,往往是需要由几个连续的时间段组合而成。所以,每当我们再次拿起书本的时候,需要往前看看,以回到当时的状态。而如果我们在今天看完书里,能记录一下书上的内容,就能 GET 到当时的状态,它相当于是我们对于书的一种快照。这种快照的形态是多种多样的,如书的脑图,又或者是书的书评。
其它
我一直在佛性管理时间,从来没有好好计划过,什么时间做什么。只在状态的时候干活,不想干的时候就不干,或者瞎干。
所以,这里这是一点儿思考 —— 为了记录那些高优先级的思考,以及便于未来再拾起来看看。
以上是关于碎片粘合:Tasking DD 启发的思考的主要内容,如果未能解决你的问题,请参考以下文章