生活中有很多复杂的任务，让人捉摸不透或者觉得无法实现。就像我们遇到软件项目中的用户需求，第一时间我们会思考如何完成这个任务，基于需求本身讨论如何实现？还是会考虑将需求进行分解？
当需求本身比较复杂的时候，会有很多不同的条件、情况，最终结果也会因为他们的不同而不同。当我们将他们拿到一起讨论的时候，往往会很复杂。团队无法达成一致，或者一个条件触发另一个情况，导致需求梳理不停地跳转。例如：当用户需求是想要一个学生课程完成度的统计。你需要同时考虑，完成度是通过率还是分数线的统计？客户端显示是表格还是图表，趋势图还是柱状图等。如果在同一时间考虑这些情况，那么会感觉有些复杂。
一般这种情况我们会将复杂问题进行分解，将一个复杂问题变成若干个在自己能力范围内可以完成的小问题。这样一方面可以降低未知带来的恐慌，另一方面还能够逐步将复杂问题转换成若干个力所能及的小任务来逐步实现，直到最终解决。
举一个生活中的例子，像马戏团的小丑同一时间能够扔6个球，而我们普通人要做到这样的事情，可能一开始第一想法是我做不到。
funny_clown7.jpeg
但是如果我们将这个问题分解，先练习扔3个球，然后4个球，再然后5个球，我们会发现一开始无法做到，但是我们经过练习，专注于迈出一小步，最终我们也可以做到扔6个球。这样的分解问题的方式，可以让我们逐步提高自己的能力，并最终解决复杂问题。
funny_clown3.jpg
这是不是有些似曾相识的感觉？软件研发中的测试驱动开发(TDD)也是这样一个工作方式，不过我们可以将它看成一种思维方式，将它延展到软件研发以外的很多场景。遇到复杂的任务，如果我们要思考如何拆解问题，那么有什么好办法呢？一种方式是可以思考，我要如何验证完成了这个任务，例如上面的小丑扔球的例子，我们可以先考虑，我们能否验证同时扔3个球？之后5个球？一开始完成这些验证，肯定是无法实现的，那就是发生错误，之后我们开始练习直到成功让这个验证通过。接着进行下一个阶段。当然当你发现已经可以扔6个球的时候，你还可以增加难度。例如踩在平衡板上同时扔6个球。而这个时候验收同样是扔6个球，而实际上对完成方式进行了重构。
tdd.png
考虑当你遇到复杂任务的时候，是不停的在脑袋里反复思考？还是尝试通过TDD的思维方式？将任务通过测试进行分解，逐步验证，逐步实现，直到最终解决。
handle_complexity.png
你会发现通过TDD的思维方式来拆分任务，一方面会降低焦虑，因为拆分后的任务会在我们的能力范围内；另一方面，拆分的任务是可以交付的，也就是让用户能够进行验证的。这也会让交付都带有用户价值。还等什么，让我们运用TDD的思维方式来应对越来越复杂的世界吧！
践行敏捷实践，让工作去繁从简。欢迎留言，交流落地经验。
