话说,几个月前有个朋友是这么和我说的。
但是呢,大家也知道,人很多时候往往是有心无力。所以呢,他刚好找到了我。我当时突然灵机一动,决定用敏捷开发的方式对其进行培养。
敏捷最大的特色是迭代式开发,将一个复杂且周期很长的开发任务,分解为很多小周期可完成的任务,然后每个小周期开发出一个可以交付的产品,每个周期都需要进行总结讨论可改进点。
我们的这个复杂且周期很长的开发任务是啥?
就是进入BAT
我们的这个很多小周期可完成的任务是啥?
就是各个知识点,例如
(1)消息队列
(2)redis
(3)省略…
另外,将这些知识点再细分为不同的用户故事,供其学习。
但是,大家要知道敏捷开发有一个很坑的地方,因为敏捷开发要求在每个迭代周期制定好本周期迭代的需求。然而有些需求真的是一天一个样,根本无法准确评估出时间。
幸运的是,JAVA可以复习的知识点也就那些,每块需要复习多少时间,我都心中有数,因此大体上可以按照我的计划进行。
OK,开始我们的正文
OK,我和他首先要在学习时间方面达成一个共识。首先,可以明确一点,我是提倡每天学一点,积少成多。
考虑到他是一个开发,经常性加班,我们将工作日的学习时间定为一小时。这个是完全可以落地的,他甚至在吃饭的时候,还不忘学习。
至于周末,我定的时间为每日三小时。统计下来,一周的学习时间为十一小时。如此坚持半年时间,效果惊人!
在敏捷开发中,站立会议的目的是让所有人了解其他人在做什么,当前项目计划进展如何。
在真正实践中,不必拘泥于形式。由于我们的上班时间是一样的,决定在工作日的早上8点15分,大家都在地铁上刷手机的时候,利用微信汇报昨日进展。
若为休息日,鉴于大家都有睡懒觉的习惯,我们则选择在晚上7点左右进行汇报。汇报完毕,各自开始学习。
要求每日汇报回答出下面的问题
昨天学了啥?
遇到了啥问题?
今天打算学啥?
OK,这样就够了。我能做的就是及时给他排除阻碍,顺利复习。
在敏捷开发中,非常强调稳定的迭代节奏,一次迭代的时间为2~4周。
在真正实践中,我会根据具体的知识点给不同的迭代周期。例如,关于 Docker
和 jenkins
这些属于持续集成的知识点,我只给一周。因为这些知识点纯粹是会用就行,不需要给太长的迭代周期。
然而,关于 j.u.c
这类知识,迭代周期就需要给一个月,毕竟这种原理性的知识,还是很困难的。
就算我们制定了迭代周期,告诉他,我们这个周期要学 spring
啊。
但是,他不懂要具体学 spring
的哪些知识。比如,你让他看源码?一年时间都不一定能领悟到精髓。
因此,对于每个知识点,要列出待办列表,例如
(1)掌握spring事务原理
(2)懂spring的bean的生命周期
(3)省略…
然后每周从中选几个点进行学习!
在敏捷开发中,看板目的是可视化你的工作流程。所有的任务的进度会全部显示看板上,每一个人都可以一目了然了解进度和流程。比如下面这样的
然而实际落地中,我们一致认为最鸡肋的就是这个。毕竟我们就两个人,还需要弄一个看板?太画蛇添足了。我们只弄了一个Excel表格,记录每周的待办列表有哪些。
在敏捷开发中,每个迭代周期要开一次回顾会,也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方。
但是在真正落地中,我们不是以一个迭代周期为单位。而是一周一次,我们通常会在每个周日晚上11点进行一次10分钟的沟通,讲一下学习整体情况,看看有没有什么整体的不足,需要改进事项!
在敏捷开发中,迭代计划会在每个迭代的第一天召开,目的是选择和估算本次迭代的工作项。
我们一般把回顾会和计划会放在一起开。在每周日开展回顾会的时候,若本周恰好迭代结束。我们会直接开始计划会,告诉他下个迭代周期的时间,以及任务的内容。
当然,我会经常听到他说
这种时候,我只能鼓励他努力试试。如果有问题,第二天站会帮他扫清障碍!
有时候发现他有点懈怠了,而恰巧这个知识点,我突然想复习一下。我就会提出结对编程的方式,共同学习,当然,最后结果是下面这样的
毕竟虐人的感觉,还是很爽的…
目前大部分公司敏捷开发的落地只是一种形式。因为很多人只会生搬硬套敏捷开发的定义,而不加以思考这种方式是否满足现状。
相反,我们应该善于思考,灵活运用在生活中的其他方面,对我们还是有一定帮助的。