不论是在一些大型的开发团队，还是作为独立开发者。我们经常会被预算、技术迭代，以及时间限制。找到合适的工作方式去适应这些限制, 是所有团队都需要去考虑的问题。

Alex Andrews 在成立 Ten Kettles 的时候花了很多了精力去考虑这个问题。直到有一天上帝把敏捷开发砸到了他的头上，很快他就找到了适合他的敏捷开发之道。他认为敏捷开发极大的解放了他的生产力。

这篇文章就会聊到他是怎么进行敏捷开发的。

远古时代

2014年 3月 1 日，是 Ten Kettles 成立的第一天。那时候整个公司只有我一个人，没有流程来遵循。什么时候开始工作，做什么软件，怎么安排任务....... 都由我自己决定。

那时候，我喜欢 free style，虽然有时候会让我不大舒服。早些时候，我在其他公司做搜索工程师, 预估工期是我最自豪的能力: 你给我一个需求，我告诉你什么时候完成，到那个时候，我把代码拿出来。现在做 app 跟那时候是一样的，只不过设计产品的人换了而已，但是知道 2014 年年底，我都还没意识到这点。

后来，我慢慢发现独立开发者这个称呼不是特别准确。因为写代码甚至都不是我现在最主要的工作内容，影响我工作效率的事情不是写代码，而是设计产品。

“再加一个功能... “

”不，这样设计不对... “

”加载的时候等服务器返回了在进入主界面....”

这些想法简直无处不在, 我几乎随时都在考虑这些问题！

这让我的工作效率严重低下。我的音乐类app，远远的超出了计划。虽然最后做出了满意的产品，但是现在回过头去看，总想问自己，为什么那么长的时间却只做了这么点事情？

结果是很好的，但是过程并不完美。我需要一个更好的工作方式。需要一个能让我更高效，更赚钱，更幸福的工作方式！

哇，敏捷开发

一直都在重复那些无聊且进展缓慢的工作。我决定给自己一个改变，所以我把精力放在了一些外包工作上面......

知道接触到了一家中等规模的公司, 他们正好在使用敏捷开发来进行项目管理。我开始去了解敏捷开发的, 期望她能够让我更高效的编程。看了很多相关的书或者文章之后，我惊喜的发现敏捷开发触及到了的三个痛点：

• 高产出
• 高效率
• 更happy

于是，我开始思考在我自己的产品中运用这套理论。

这家公司的项目做完，我去了蒙特利尔, 打算给自己放个假，也仔细的想想怎么让这套理论给我带来效益。我重新看之前的笔记，重新读了两本很好的书，思考了实际情况下的一些问题，最后总结出了改革我的公司的一些办法。

敏捷开发的基本原则

什么是敏捷开发呢？这里有一段我第一本读到的书中的摘录:

敏捷团队通常由7个左右的人组成，每个任务阶段叫做一个 sprint，包括了回顾和总结的时间。敏捷开发有一个咒语"检察和调整"。敏捷团队具有一个很明显的特征：工作流程和产品在不断的进步。

独立开发跟 5-9 人的团队开发还是有很多不一样的地方的。这段话讲到的内容跟我使用的敏捷开发还是有一些区别。 我更多的是去定义整个工作流程的一些基本原则.

敏捷开发核心原则:

• 主动变化。经常把产品给别人体验，无论是最终的用户，测试用户，甚至是一些懂行的朋友。这样可以避免把资源投入到没有必要的功能上。让测试用去去使用 beta 版本的产品，及时根据反馈来调整方向，这样能节约很多的时间。
• 效率优先，并量化它。短期内最大的量化指标就是产出，并不是销售或者发版数量。要知道每周完成了多少有效任务, 就需要去量化它。这样才能跟踪进度，并优化它。
• 自我总结。定期去回顾总结。

如何进行敏捷开发

知道了敏捷开发的核心原则，那么应该怎么样去实践呢？

Sprint

就是在固定周期的时间里面完成特定的需求，相当于迭代。在这个 sprint 中你应该把全部的尽力用在完成这些需求上面。

一个 sprint 通常有一到四周，这个由你自己的风格和产品决定。我自己的标准是两周一个 sprint。我觉得这样有足够的时间来完成真正有意义的任务。下面是我的 sprint计划图：

可以看出来，每个 sprint 中都有很多时间用来做核心的任务，还有一些其他的东西:

• 每日站会 Daily Stand-up Meeting
• 每周畅想 Weekly Story Time
• 发布 Sprint Release
• 敏捷迭代回顾 Sprint Retrospective
• 敏捷迭代计划 Sprint Plan

每日站会（5 min）

敏捷开发有一个很基础的部分就是自我审查和迭代，尤其是在生产上面。当我们原计划在某一天完成某项任务，但是最后没有完成，这时候就需要总结到底发生了什么，然后在去优化你的工作流。

每日站会是敏捷开发的主要特点。在传统的敏捷开发中，每日站会让每个团队的成员都聊一下昨天的进度，今天的计划和存在的风险。

• 为了简化会议, 避免会议时间太长所以要求大家都站着开这个会。
• 让所有成员都能跟上节奏，及时暴露出风险和挑战。

那一个人怎么搞呢？

我汲取了敏捷开发中的优点。自己总结了一套适合独立开发的每日站会: 拍短片(45 秒) 。

主要是这些内容：

• 回顾：首先看一下昨天的短片，看看昨天定下的任务是什么。

• 总结：没有完成昨天的目标？想想为什么没有完成，还有什么地方没有做到更好。是中午开了一个会，耽误了写代码的时间。还是准备 App Store 的截图花的时间超预算了。

• 准备：在不到两分钟的时间里，思考一下今天的短片说什么，回答下面的问题：昨天做了什么？今天准备做什么？什么影响了进度。比如这样。

  我昨天我做了 A 的 App Store截图。今天我要写更新日志，然后下午跟一个供应商讨论一下合作。总结：在做截图的时候花了太多的水岸，所以没有完成本来计划的更新日志。下次尝试使用自动化工具。

• 拍摄：拍下这个短片，然后就好了。这些片子在最后的sprint 回顾中还会用到。

每周畅想 （30-45 min）

在每个 sprint 中，都会花很多的时间去做程序员。很少花时间去考虑公司发展这类东西，要不要做一个新的 App 、大改现在的 app 等灯。Story Time 这段时间就是我用来做 CEO 的时间。我建议尽量到其他环境去做这件事情，咖啡店什么的。

在 Story Time ，我会去整理一下从用户那里收到的反馈，考虑今后加什么功能，考虑怎么运营 app 和公司。然后把一些实际的想法加到一个列表里面我叫它需求池。

需求池里面都是一些比较大的任务。它帮助我计划下一个 sprint。所以在 Store Time 中也需要去修改和整理需求池。比如:

在统计中看到了更多巴西方面的东西，这就是说，你可能需要加入葡萄牙语，而不是原计划的西班牙语。或者可能看到了一些用户希望的小功能。这时候也需要考虑是不是把这个需求加入这个列表。

发布

敏捷开发还有个原则就是要让你做的工作能够产出成品。这就是在 Sprint Release 中需要做的事情。不一定需要是一个完整的 app，但是把这段时间的工作拿给其他人试一下也是很重要的。让测试用户体验，从他们那儿得到一些反馈。

在敏捷开发的过程中，发布的范围会逐渐的扩大。比如说，最开始你可能只需要发布一个只有一两个新功能的 beta 版。这时候可以优先的去考虑最重要的功能，这样能够尽快的拿到测试反馈。如果你的测试用户根本都没有提到过某个功能，这就是说这没那么重要。这也能帮你决定下个 sprint 中任务的优先级。

Last Day of the Sprint

已经花了9天来完成这个 sprint 的目标，终于到了最后一天了。这一天可能是最轻松的一天，因为今天可能不需要做开发工作。今天是用来回顾这个 sprint，计划下一个 sprint 的一天，然后还可以休息休息。

这可能会让人觉得奇怪，在截止日期做这样的事情？上学的时候，我经常会在回家的路上看书。但是这样我会走偏方向，然后摔倒。敏捷开发也一样，如果不经常抬头看看方向，可能方向就错了。

确保方向正确，这就是 sprint 最后一天做的事情。这是一整天，或者是在是时间紧迫，半天也可以。这一天，抬头看看周围，确保做的事最重要的事情。因为即便你非常的高产出，在不重要的事情上花时间也是不值得的。

现在来看看这天要做什么吧！

Retrospective(回顾) （小于2h）

打开一个新的文档，或者是在笔记本上翻开新的一页，写下你对刚刚过去的两个星期的总结。这是你发现是什么阻碍你的效率的好机会。

这写是一些简单的问题：

• 我完成了什么？
• 我达成了我 sprint 的目标了吗？
• 这个 sprint 最的好的是什么？还有什么地方可以做到更好？
• 有什么影响效率的因素？回顾每天的短片来找到这个问题的答案。
• 有什么没什么必要的事情让你焦虑了，或者让你觉得很爽？

如果你发现出去走走比在桌子边上回顾，那就出去走走吧！然后回来迅速的写下你的总结。我发现这样确实更有效果。

Sprint 计划 （小于2h）

在回顾两次 Story Time 和需求池之间，你应该好好想想下一个 sprint 要做什么。把需求池整理一下，然后挑几个最重要的！

下面是一个简单的例子。说你现在有个快完成了的 app ，你计划下个 sprint 加入最后一个功能，然后做一些自测工作，最后把 Beta 版发布出去。在你的计划文档中，就是下面的内容：

在两个星期的 sprint 中，可能还会有更多的任务需要完成。这只是简单的举个例子。

看每个任务后面的数字，这些都是任务评分。比如说，一个 1 分的任务，需要花 2 分任务一半的时间去完成。这个标准需要你自己来定。就我来说，我还是喜欢用1，2，3，5，8这样的数字，这样可以纠正我们低估大任务的倾向。没有4，所以我必须得用5这个数字。

当你完成所有任务的时候，去想想每一个任务相对于其他的任务需要花费的时间。冷静下来，去预测每一项任务需要花费的时间。

如果某一项任务很复杂，但是你已经做过很多次了，那就可以少估计一点时间，也就是说可以减少这个分值。如果某个任务很简单，但是你还不熟悉。就可以多估计一点时间，也就是加点这个分值。

当你完成任务的时候，只需要把所有分值都加起来，然后跟上个 sprint 做一个比较。如果你经常得到 80-100分的总分，那么下个 sprint 的总分应该就差不多是80的样子了。

这可以说是敏捷开发中最有效的事情了，也是我任务最难做的一部分了，我经常发现，我总是减少我想做的事情的评分，给重要的任务更多的评分。有了 sprint 计划，就擦掉你上个 sprint 的任务板，然后为下个 sprint 做准备！

什么是任务板(Task Board)呢？

译者: 在之前的敏捷开发实践中，都会有一个白板，清晰的写上这些东西。下个部分会讲到。

任务板

现在我们就来说说任务板。即使我在我的笔记本或者其他地方已经了我这个 sprint 的计划，我每天的任务还是会在任务板上组织。我把这个任务板放在办公室的墙上。上面会写一些东西，主要是：TODO、DOING、DONE。

每天下班的之前，我都把第二天的任务写在一个便签上，然后把它们贴在TODO这一块。假如我上个 sprint 平均每天拿到了10分，我就会给下一天贴上10分的任务。

第二天早上，我就会把 TODO 上的第一个便签拿到 DOING 这边。这样做能够让我更容易集中精力。

任务完成的时候，把这个便签拿到 DONE 这边。看到 DONE 越来越多，是一件很有成就感的事情。

Rest and Explore

回到 sprint 中间来。现在你到了 sprint 的最后一个下午了。这个下午就好好的放松一下吧！我经常都是坐在沙发上，看看 Raywenderlich.com 上的教程，或者学点新的知识。

不要把这件事情当作例行工作那样做。只需要做一些跟工作有关，由能让你放松的工作。喝一杯饮料，听听音乐，庆祝庆祝这个 sprint 你完成的工作，多好！

一些建议

对独立开发者来说选择正确的工作方式是很个人的事情。这跟你的精力相关。同时也需要要激励你，让你成长。以这个为核心原则，就能够找到适合你自己的敏捷开发之道了。

额外的建议：

• 在刚刚开始的时候，不要因为实际完成的任务比计划完成的任务差很多而感到不好。在下个 sprint 中调整就好了。不断的调整正是敏捷开发的意义。
• 每隔一两天就调整一下这个 sprint 的计划。review 每一个任务，调整他的分值。如果分值变得很高，就需要把一些低优先级的任务移除掉了。
• 计划细节是一件很麻烦的事情。如果你跟我一样也是两周一个 sprint。第二个星期的计划没有那么详细也是可以的。每天的调整能够慢慢的丰富它。
• 对公司来说，有一个长期计划是必要的，但是不要死咬住这个计划不放。保持一个流动的需求池来适应改变。
• 即便这是我在做 Ten Kettles 的 app 的时候总结的东西。他们在做外包的时候也是很好用的这只需要做一些很小的改动。比如说任务板，可能就需要做成虚拟的了，这样才能让甲方知道你现在是什么情况。
• 别样了买马克笔还有标签纸。

我第一次意识到作为独立开发者，我需要更好的工作方式的时候，我想到了三个需求。更高效的产出，从 app 中获得更多的收入，更多的幸福感。我也很高兴这样的改变确实带来了这些东西。app 的迭代频率大大的上升，每个月的平均收入增长了 18%，用户也更满意(在 App Store中平均分 4.75)，而且工作和生活找到了更好的平衡点。有了周末，一切都更好了。

结束语

这是一篇最近的采访，关于我最近在 Ten Kettles 的的细节。

记住下面三个敏捷开发的基本原则

• 主动改变
• 效率优先
• 不断的总结

看起来很简单，但是有很好工作流程，这几点能够明显的影响你的工作。

如果你想要学习更多关于敏捷开发，尤其是在团队中的敏捷开发的话，这有一些资料。

我最开始看的两本书是：

• Scrum: The Art of Doing Twice the Work in Half the Time (Sutherland, Sutherland)
• Scrum: a Breathtakingly Brief and Agile Introduction (Sims, Johnson)

这篇文章翻译自Ray wenderlich Scrum Of One: How to Bring Scrum into your One-Person Operation