震惊了！关于JAVA复习的最佳敏捷实践！

引言

话说，几个月前有个朋友是这么和我说的。

但是呢，大家也知道，人很多时候往往是有心无力。所以呢，他刚好找到了我。我当时突然灵机一动，决定用敏捷开发的方式对其进行培养。

敏捷最大的特色是迭代式开发，将一个复杂且周期很长的开发任务，分解为很多小周期可完成的任务，然后每个小周期开发出一个可以交付的产品，每个周期都需要进行总结讨论可改进点。

我们的这个复杂且周期很长的开发任务是啥？

就是进入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分钟的沟通，讲一下学习整体情况，看看有没有什么整体的不足，需要改进事项！

计划会

在敏捷开发中，迭代计划会在每个迭代的第一天召开，目的是选择和估算本次迭代的工作项。

我们一般把回顾会和计划会放在一起开。在每周日开展回顾会的时候，若本周恰好迭代结束。我们会直接开始计划会，告诉他下个迭代周期的时间，以及任务的内容。

当然，我会经常听到他说

这种时候，我只能鼓励他努力试试。如果有问题，第二天站会帮他扫清障碍！

结对编程

有时候发现他有点懈怠了，而恰巧这个知识点，我突然想复习一下。我就会提出结对编程的方式，共同学习，当然，最后结果是下面这样的

毕竟虐人的感觉，还是很爽的…

总结

目前大部分公司敏捷开发的落地只是一种形式。因为很多人只会生搬硬套敏捷开发的定义，而不加以思考这种方式是否满足现状。

相反，我们应该善于思考，灵活运用在生活中的其他方面，对我们还是有一定帮助的。