一个人的敏捷开发

Posted 世纪卓越PMP

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一个人的敏捷开发相关的知识,希望对你有一定的参考价值。

武汉PMP  汉阳PMP  光谷PMP  武汉PMP培训认证 武汉PMP考试中心 武汉项目管理培训 PMP考试中心 武汉ACP培训认证 武汉ACP考试中心 武汉PMP认证考试

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

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 的的细节。

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

  • 主动改变

  • 效率优先

  • 不断的总结

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

一个人的敏捷开发

↑↑↑长按二维码一键咨询



以上是关于一个人的敏捷开发的主要内容,如果未能解决你的问题,请参考以下文章

敏捷开发XP

敏捷开发

聊聊敏捷开发

敏捷软件开发---闲话敏捷

关于敏捷开发的含义、原则、目标和机制

对敏捷开发的五个误解,你中了几个?