Luna说 | 敏捷开发初探
【前言】
我到新公司上班已经两个多月了，正式参与到项目开发也有一段时间了，IT 行业现在都流行采用“敏捷开发”的模式，我们公司也不例外。
短短的两个月，我已经在开发过程中遇到了很多与学校不同的情况，也更加深刻地感受到了商业产品对 IT 开发人员的要求和期望。
今天这篇文章，就从敏捷开发的业界实战方面，稍微讲讲我的个人体会吧。
【校园版敏捷开发】
Monash IT 学院的毕业课程中融入了很多敏捷开发的要素，课程名称也叫作“Industry Experience”。我今年上半年的主要精力就花在这门课上。
学校老师在课程中介绍到了一些工具，比如 Leankit 这样的 Kanban 系统，每两周一个 Sprint，根据 User Story 来做 task breakdown，制定优先级，并且要求每个 Sprint 都有经过测试的可交付功能，包括要找用户去录制视频等。
现在回想起来，虽然当时开发任务比较紧张，没有太多精力去关注 Sprint 的规划以及相关文档的撰写，但 IE 这门课带给我的体验对正式工作还是蛮有帮助的，
那么公司里面是如何实际执行敏捷开发的呢？
【商业版敏捷开发】
以我目前所在的 IT 团队为例，敏捷开发由以下几个部分组成：
每个 Sprint 的周期是两周（和学校一样），就等于是 10 个工作日，每个 Sprint 都会开一个新的 Git 分支，到 Sprint 结束的时候这个分支就是可交付的结果（Release）。
Figure 1: Sprint and Release
我们每个 Sprint 是从周三开始的，比如现在这个 Sprint 是 9 月 18 日到 10 月 1 日。
每个 Sprint 的前一天（也就是周二），我们会完成上一个 Sprint 的 Release，每个人总结一下自己对这个已经完成的 Sprint 有什么看法，然后开始计划新的 Sprint 要做哪些任务。
Figure 2: Sprint details
Sprint Planning 主要包括两个部分，先是确定团队里面每个成员的 available hour（比如是否有安排休假），一般情况下每人每天要完成 6 小时的任务量，但是我刚加入，所以每天的 hours 稍微少一点，只算我 4 个小时。
Figure 3: Sprint Planning
统计完成之后，技术团队的 Leader 会和 BA（商业分析-Business Analyst）、QA（Tester-测试）、Designer（一般就是 UI Leader）开会讨论下个 Sprint 要完成哪些任务，大家讨论后会把这些任务移到 Kanban 系统里面。
Kanban 系统就是把每个任务分为不同阶段（如 Todo, Doing, Done）的一种直观可视的项目管理工具。
Figure 4: Kanban System
确定好要完成的 Task 之后，就要做更进一步的 Task breakdown，确定每个任务包含哪些子任务，每个子任务需要花多少小时完成。
一般每个 Task 都要有 BA 写好 Requirement（配合 UI 的 Mockup），然后 Developer 进行开发，开发完成+初步测试后，正式移交给 QA 团队，QA 团队完成测试（Signoff）才能部署。
根据我目前的观察，每个子任务的时间量都是 1-6 小时不等。
【一些细节】
【每天的进度追踪】
Figure 5: Sprint daily routine
每个工作日，我们早上都会有 15 分钟左右的 Standup（注意！都要站着哦！），每个人轮流讲自己昨天干了什么，今天准备干什么，如果有遇到什么难搞的问题（Impediment）也会在这个会上说出来，也许其他同事能提供一些建议（讨论一般都比较简短）。
然后就开始干活了~~~~
到下午三点多，我们会再开一个会，这个时候 Team Leader 会打开电脑，每个人轮流说自己今天完成了哪个 Task，可以减去多少小时（比如 Task A 的预计工作量是 4 小时，我今天可以 reduce 两小时，这样的形式）。
之前提到每个人每天的 available hours 是提前计划好的，所以一般来说，每天都要在这个会议上 reduce 相应的小时数（不然这个 Sprint 就完不成啦！）。
这样的工作流程对于每个团队成员来说都是非常透明的，每天开会的时候你可以知道别人在干什么，完成了哪些任务。
所有人都说完之后，我们会一起看一下 Burndown chart👇，了解这个 Sprint 目前的进展是否符合预期。
Figure 6: Burndown chart
【任务分配】
敏捷开发一个很重要的细节就是，任务都是大家认领的，而不是传统意义上的【分配】。
比如我今天做完了 Task A，我就需要看一下目前 Sprint 有哪些任务是还没有人开始做的，然后挑选一个作为我明天的任务。
我个人觉得这样的形式有利于开发人员成为“多面手”，因为不同的 Task 可能涉及到产品的不同功能和模块，手头任务做完了就可以选一个自己感兴趣的模块开始做，做的过程也是学习的过程。
【计划之外】
当然，很多时候计划是美好的，但实际操作是有困难的……
比如我最近遇到的问题是，Task 上面写的时间（比如 6 小时）其实远远不够我用的，因为我对系统的代码不熟悉，也缺乏经验，需要花大量的时间去学一些东西。
像这种情况，Leader 就会列为“Unplanned hour”，也就是我花了额外的时间去做计划好的任务（目前不知道是否和绩效挂钩，但内心还是有点慌……）。
也有些时候，在做任务 A 的时候发现一个 Bug，就要花时间去修 Bug，这些也会列为“Unplanned hour”。
【Recycle hour】
与此同时，如果有些 Task 的预估时间比较久，但实际做的时候花的时间没那么多（比如一个预计 4 小时完成的 Task 只花了 1 小时就搞完了），那多出来的 3 小时就成为了 Recycle hour，可以分配给“Unplanned hour”。
【结语】
我认为，企业管理中很重要的一环就是合理的流程设计。想要偷懒摸鱼是人之本性，寄希望于员工的自觉不如优化管理流程。
与传统的 IT 开发流程相比，敏捷开发更注重可交付结果，每个版本的周期较短，所以受到了很多技术公司的青睐。
总体来说，我觉得企业版的敏捷开发节奏还是比较快的，对个人的要求也比较高。
首先，要能够跟上整个 Team 的节奏，完成自己的每日任务；
其次，需要有快速切换不同的 Task 的能力，不能在一个 Task 上花费太多的时间；
第三，团队沟通非常重要（包括跟测试、BA 以及其他开发人员的交流）；
最后，根据业务需求，要能设计出一套符合现有框架的解决方案，并且能实现这套方案。
不知道大家是否也在采用【敏捷开发】的团队中工作呢？你是否赞同【敏捷开发】的理念？
你所在团队的工作流程，又有哪些优点和缺点呢？欢迎留言或私信和 Luna 进行进一步的交流哦~
Talk to Luna
Support Luna
