我从Mile High敏捷2011中学到了什么


这是一篇比平时略长,漫无边际有点异想天开的帖子。真对不起。不过最后还是有一些好东西。反正我是这么想的。

上周四我参加了就职典礼Mile High Agile conference装上,装上Agile Denver。一天的开始时间很早,我飞奔下山到戈尔登,然后在70号州际公路和25号州际公路上奋战。也许是由于出行时间较早,交通比我想象中的噩梦要轻,与我日常的通勤(从卧室经过厨房到地下室)相比,这一天的收获是值得的。

以下是我从会议中得到的想法,并不是所有的想法都与敏捷直接相关。

今年早些时候,当我第一次听说Mile High敏捷时,我自愿帮助做了几件事--与另一位志愿者一起建立网站,建立相应的注册和支付系统。我已经有一段时间没有做过任何类型的web内容创建了,但是我们选择通过使用WordPress有一个合适的主题。虽然这显然意味着有相当多的限制(特别是因为我们自己并没有主持WordPress博客),但这确实意味着我们可以轻松快速地进行。如果有机会再做一次,考虑到我们的简单需求,我几乎肯定会坚持使用WordPress,但我们自己主持它将是非常值得的。这可能会让我们避免使用插件所面临的问题,而当托管在wordpress.com

用于注册和支付方面的东西EventBrite。这是一个我以前从未使用过的服务(至少在会议组织者的角色中没有使用过),我不得不说这是一个令人印象深刻的服务。虽然我们的需求很简单(几种票证类型,几十个折扣代码,简单的报告等等),EventBrite似乎可以毫不费力地工作。我们曾经想做的每件事(除了一件事)似乎都已经预料到了,而且做得很好。此外,我有机会两次使用他们的支援服务,这些服务非常好,而且反应非常迅速。

在上周召开会议之前的几个月里,我非常喜欢与促成会议的人们一起工作。与其他人相比,我的贡献很小,但成为其中的一份子并与真正有热情的人一起工作是很有趣的(激情被过度使用了,不是吗?)让这一切发生。这是一个真正的喜悦,看到人们投球,无论是他们的角色,提供有用的想法和评论,随着事情的发展。我希望我能和更多像那样的人一起工作。

在开始的时候,我们还不清楚我们能获得多少赞助商,也不清楚我们能卖出多少张门票。由于几个人真正出色的努力,我们超出了所有的期望。只是check the number of sponsor logos我们卖了将近500张票。对于这样一个非常紧迫的时间框架和有史以来第一个高度敏捷会议来说,还算不错!如果你建造它,它们来吧。只要你把这个词传出去,并且努力推销它。

会议结束后,有几件事引起了我的注意,它们与敏捷无关,但对我来说却是有趣的见解。我在家工作已经有一段时间了。虽然我认为我已经通过电话,电子邮件和IM等方式与团队中的人进行了相当丰富的互动,但能突然置身于众多技术人员的纷争中并与他们交谈还是很不错的。我是站在登记台后面的一群人中的一员,500人中最多的一个到了登记台,登记台忙得不可开交,忙了一个小时左右。这让我想起了我十几岁时的一份兼职工作,星期六在一家家用电脑商店工作,那时候总是忙得不可开交。我爱死它了。绝对让我渴望更多本地的,面对面的互动。

另一件奇怪的事是,开车到丹佛似乎并不太糟糕。过去我总是觉得它不那么理想,但在过去一年里一系列的城市旅行之后,也许我终于有了一个像样的感觉,这一切是如何在我的头脑中联系起来的,并感到更自在了。不知什么原因,我越来越想去丹佛看看。

最后一个奇怪的小发现是,被那些对敏捷软件开发的各个方面充满热情的人包围是多么美好。尽管你可能在细节上与其他人有不同的观点和经历,但有一个共同的思路,那就是“获得它”(“它”是敏捷的)和想要“获得更多它”。也许遇到那些观点强化了你自己许多信念的人只不过是一种自我打击,但这让我想到与更多这样的人一起工作是多么的酷。

谈到我能够参加的三次会议,所有这些会议都是技术方面的。我真的很喜欢。我希望能有更多--如果明年能有一个为期多天的会议,那就更好了:-)这也让我觉得它会很好地呈现出来。我不完全确定是什么,但我觉得在过去的几年里我学到了很多,除了在博客上写一些之外,分享其中的一些会很有趣。也许明年吧。

我参加的第一次会议是Agile the Pivotal Way给出者Mike GehardPivotal Labs。我承认我没有真正意识到Pivotal Labs除了制造Pivotal Tracker。事实证明,他们的业务实际上是为人们(通常是初创公司)开发软件,而且他们对待工作的方式对我来说很有意义。

迈克提到他们对所有的事情都进行配对编程。这提醒了我是多么怀念结对编程。我在过去有过两次严重的配对过程,我很确定这是很多软件开发工作的最佳方法。第一次我们不把它叫做结对编程,因为那只是我12岁的自己和我的朋友在一个Commodore Vic 20用BASIC写游戏,PEEKing and POKEing屏幕上制作的游戏可以与吃豆人相媲美。差不多了。但很棒。另一次是最近的一次。这是我学习Java的方法,感谢一位同事与我广泛结对。这也是我们产品套件三分之一的第一个版本是如何以难以置信的速度建立起来的,只有我和另外一个人。如果我将来要编程,我希望是结对编程。

Mike还提到了他们的“团队”是如何小,除非他们的客户坚持没有独立的QA或测试人员角色,也没有PMS。他们(这对开发人员)自己做这些东西。回想起来,我写过的最好的软件是当我完全沉浸在客户中并直接与他们交谈时,我必须确保它按其应有的方式工作。没有中间人(或女人)来解释客户的需求,也没有其他人来寻找错误,而且由于我不喜欢我的东西失败,所以我肯定测试了我的工作。

总之,我希望我能更多地了解Ruby和Rails,因为它们听起来是一个非常酷的工作场所。我不确定Mike的谈话是否是一次秘密招募演习,但它肯定能起作用。

我参加的第二场演讲来自Chris PowersObtiva。他是talking about test driving front end code他所说的前端代码是指JavaScript。我已经有几年没有涉足JS了,可能在不久的将来也没有涉足过,但它仍然很有趣,而且对于现场演示和编码活动来说,这绝对是功劳当之无愧的。克里斯展示的工具是Jasmine,虽然我没有其他东西可以与之相比,但它看起来非常整洁,而且我非常喜欢BDD风格的感觉以及表达特性和单元测试的能力。如果我将来要做任何JS,我想我会检查它。

我参加的第三次也是最后一次会议的主讲人是Paul Rayner并有权Strategic Design using DDD。这里面有一些激怒的东西。首先是Purpose Alignment Model作者:尼尔·尼古拉森。这是一个简单的想法,你可以把功映射到一个有四个象限的图上,如下所示:



这里特别有趣的是,那些属于右上角象限的东西,是你想要付出最大努力的东西--你想让最好的人来做这件事,你想要真正关注这些东西的设计。相比之下,那些落在左下象限的项目不值得这样的努力。

如果我对Paul的理解正确的话,他是在提倡使用上面的内容来思考您在系统的各个组件的设计中投入了多少精力。这似乎是个好主意。但是,从敏捷和scrum的角度来看,这样简单的东西如何被用来促进产品开发中的特性优先级划分。我以前见过这样的想法:把故事(或主题或特征)贴在白板上,让人们把它们放在最优先的一端,最低优先的另一端。但这将覆盖一个稍微更严格的评估事物。如果在使用开放白板技术时,有人把一个项目放在高优先级的一边,我不知道为什么。如果白板被分成四个象限,就像上面一样,我马上就会知道他们认为它是关键任务,还是市场差异化,或者两者兼而有之。我觉得那很有力量。

我从这节课中得到的第二件事(实际上是在不久之后,在Paul
blogged on the topic),如果你能做好“应急设计”这个流行的想法是很棒的。但有多少团队真正具备设计和重构技能来完成这一任务?有多少团队能发现好的和坏的方向。如果有一个框架,首先识别出系统中哪些组件比其他组件更值得精心设计,再加上一套好的设计技能可以应用,这确实有助于我的思考。

保罗谈到的第三件事让我记忆犹新,那就是他的“广告牌测试”。这里的想法是,如果你拿着你正在努力工作的东西,把它想象在一个广告牌上,它真的是你想要传达的信息吗?考虑他的例子:“我们的日志框架踢屁股!”坦率地说,除非您的公司实际销售日志框架,否则,意识到您在日志方面投入了这么多精力,应该会让您停下来思考一下。比如说,“我们的测试自动化框架踢了屁股”。或者随便什么。(内幕笑话)

就这样了。回家的路比我想象的还要快。准备好把高速公路变成停车场了,但事情进展顺利。