怎么做到真正意义上的敏捷?

北大青鸟大学城校区logo 北大青鸟大学城校区
招生简章校园环境师资力量就业明星招生问答软件工程师北京大学学历学员项目联系我们 报名通道

免费在线咨询通道>>

免费在线报名通道>>

北大青鸟报名电话
当前位置:北大青鸟 > 北大青鸟 > 北大青鸟学员 >

怎么做到真正意义上的敏捷?

标签:   分类:北大青鸟学员

一灯能除千年暗,一智能灭万年愚。

——慧能,中国禅宗第6代祖师

一点智慧,只要有它便足够了。我们希望大家喜欢对这些敏捷实践的描述,而且其中有一到两个可以点燃诸位智慧的火花。

无论经验是否丰富,不管过去有什么样的成功,遇到过什么样的挑战,只要进行一个新的实践,就可以让人头脑清醒,并让你的工作与生活从此发生改变。使用这些实践的子集,能够救濒临失败的项目于水火。也可以使得从此往后的项目变得完全不同。

只要一个新的习惯

举个例子,看看Andy曾经服务过的一个客户的故事。他们的办公室位于一座具有玻璃外墙的、高耸的写字楼中。团队的办公室沿着外墙排列,形成一条优雅的曲线。每个人都能看到窗外的风景,整个团队的分布几乎占用了楼层一半的墙内空间。但是这个团队有不少问题:版本发布总在延期,团队逐渐失去了对不断增多的bug的控制。

按照通常的工作方式,Andy和注重实效的程序员们,坐在办公室的一端,开始对团队进行访谈,以了解他们的工作是如何开展的,有哪些进展顺利,哪些构成了障碍。第一位成员解释说.他们在开发一个c/s应用,客户端非常瘦,所有的业务逻辑和数据库访问都放在服务器一端。

然而,随着访谈的不断进行,故事却慢慢发生了变化一每个人对项目的方向和目标的了解都有所偏差。最终,最后一个成员骄傲地宣称:系统的构成包括一个包含全部GUI和业务逻辑的胖客户端,以及仅仅包含一个简单数据库的服务器!

现在问题就很清楚了,团队从来没有坐在一起讨论过项目。实际上,每位成员仅仅与坐在旁边的人有过谈论。就像是学校里的孩子们玩过的“传话”游戏。信息在人与人之间传递时产生了偏差,最终偏离了本意。

需要哪种有实效的建议?马上开始使用立会吧。这种做法很快就收到了令人惊异的效果。不只很快解决了架构上的问题,而且产生了更深远的影响。团趴开始变得更有凝聚力。彼此紧密配合,共同工作。bug产生率降低了,产品变得越来越稳定,截止日期也不再像以前那样令人窒息。

没有花费太多时间,也没有耗费多少精力。只需要一些规矩来保证立会的举行,不过这很快就形成习惯了。只要一个新的习惯,就让团队发生了巨大的变化。

救濒临失败的项目

如果采纳一个习惯可以产生好的效果,那么采纳所有的习惯,就应该产生更好的影响,是吗?最终一定是这样的,但是不能下子全部上马——特别是对一个已经处于困境的项目。突然改变某个项目的全部开发习惯,是让项目突然死亡的最佳方式。

用一个医学上的比喻。假定有一个胸部疼痛的病人。当然.如果病人经常运动而且保持健康饮食的话,他们不会生病。但是不能因此就马上说:“别赖在床上了,爬起来开始在跑步机上运动吧。”这有可能要了病人的命,而且你的渎职保险赔偿率一定会升高。

必须要稳定病人的状况,并使用最小剂量的(但是必要的)药物和治疗过程。只有在病人身体状况恢复且趋于稳定之后。才能让他按照良好的饮食起居制度来安排自己的生活,保证身体的健康。

当项目岌岌可危时,应该先引入一系列习惯来稳定目前的状况。看这个例子:一个潜在的客户曾经以惊恐的声调打电话给Venkat,说他们的项目陷入危机。他们已经耗费了一半的时间,而项目还有90%的成果要交付。管理层对于开发人员不能及时完成任务感到很不高兴。开发人员对于管理层总是逼得这么急也觉得很不爽。剩下的时间,他们是应该用来修补bug,还是开发新功能?不管危机发展到什么程度,团队总是希望获得成功,然而他们不知道该怎么办。所做的每件事情都让他们落后更远。他们感到了威胁并且不愿再做任何决策。

Venkat没有试图一次解决全部的问题,他必须先稳定病人的状况,使用了下面这些促进沟通和协作的敏捷习惯作为开始,这就是紧急救助的模型。如果事态没有那么糟,可以采取更加全面、整齐的方式来引入敏捷习惯。无论你是经理,还是团队带头人.或者只是一个对敏捷感兴趣、试图从组织内部发起敏捷过程的程序员,我们都有一些针对性的建议。

引入敏捷:管理者指南

作为一个管理者或者团队的带头人,有责任先让整个团队知道接下来将要发生什么。要向大家说明敏捷开发是要让开发人员的工作变得更加轻松,这主要是为了他们好(根本上来看,对用户和组织也是有益处的)。如果没有达到这样的效果,那就是有些地方出了问题。

要慢慢来。记得领导所做的每一个小动作,都会随着时间对团队产生巨大的影响。

将这些主意介绍给团队的时候,确保每个人都知道项目将会以此运转——而不只是口头上说说而己。

从立会开始.这可以让团队有机会进行彼此讨论,并对一些重大问题达成共识。把之前相对孤立的架构师带到团队中,并让他们参与到日常开发工作见。开展非正式的代码复查,并做出计划.让客户与用户也参与到项目中来。

接下来要准备好开发的基本环境。也就是说要开始采纳(或改进)基本的入门级别习惯。

版本控制

单元测试

自动构建

版本控制是第一要务。在任何项目中,它都必须是要最先搭建好的基本架构。设置好后.就要为每个开发人员安排好各自要使用的本地构建项目,这些项目要与服务器保持一致,可以通过脚本运行构建操作.还要能够运行任何可用的单元测试。这些都搞定之后,就可以开始为正在开发的新代码创建单元测试,井按需为已有代码创建新的测试了。最后,要准备一台供后台运行持续构建的机器,使之起到棒球比赛中“挡球网”的作用.以捕获任何发生的问题。

如果你对这些领域不熟悉,到最近的书店(或www.PragmatieBookshelfcom)去买一本ShipIL[RG05】,它会告诉你如何设置相关的环境和运行机制。入门工具箱(StarterKit)系列图书可以帮你完成如何在特定环境下配置版本控制、单元测试.以及自动化等具体细节。

基础架构搭建好后,就要考虑如何将项目和团队带入到固定的节奏中了,来了解项目的时间安排和节奏相关的内容。

现在应该已经对基本知识都有所了解了,接下来应该调整习惯,以让它们适用于你的团队。在设定环境时,了解如何以敏捷的方式来解决日常问题。

让团队可以紧密配台.共同工作。但这并不是结束,还有很多其他工作可以开展,很多习惯可以采纳。

要不时——也许是在每个迭代结束后,或每个版本发布完成后——举办项目回顾会议。从团队处得到反馈:哪些做得不错,哪些需要调整,哪些不起作用。如果之前采纳的某个习惯没有达到预期效果.翻回头查阅本书中对应习惯的“切身感受”和“平衡的艺术”两个部分,看看是不是有哪些细节方面出了问题,井且进行修正。

引入敏捷:程序员指南

如果你不负责带领团队,但是希望让大家向敏捷的方向努力,就要面临不少挑战了。不单要完成前一节列出的各种事项,还应该通过实际的例子,而不是行政命令来引领大家。

有句老话说得好:“你可以把马带到水边……但是你不能强迫它使用你最钟爱的代码编辑器。”当然,除非你已经用得非常熟练了。只要好处明显,团队成员肯定会希望尽快着手使用的。

举例来说,从单元测试开始是一个不错的选择。可以先针对自己的代码开始使用。在短时间之内(几周甚至更少),就可以看到代码质量提升了——减少了错误的数目,提高了质量,健壮性也有所提升。你下午5点就可以下班回家,而且所有的任务都可以顺利完成——不必担心半夜被电话叫醒,去修复bug。旁边的开发人员想知道你是如何做到的,而且消息也渐渐传开了。整个团队现在都想尝试这些新奇的习惯,而不需要你努力去说服他们。

如果要将团队带入新的领域,必须首先以身作则。所以不妨从可以马上着手的习惯做起。还可以在自己机器上运行一个持续构建服务器,发生问题时可以马上知道。队友可能会觉得你有“千里眼”呢。

过些时间之后,可以试着开始一些非正式的自备午餐会,与大家一起讨论关于敏捷项目的节奏和其他感兴趣的话题。

更多激励性的文章尽在北大青鸟官网!

若有疑问请拨打北大青鸟咨询热线:010-80146691或点击免费在线咨询!
  • xml地图 网站地图 招生简章 合作企业 学员项目 联系我们
  • 关闭窗口