• Comments
  • Comments
  • Comments
  • Comments
  • Comments
  • Comments
  • Comments

个人Scrum敏捷开发转型中的技术实践

个人Scrum敏捷开发转型中的技术实践

Scrum无处不在,说起Scrum敏捷开发框架,也许大家并不陌生,表面理解它其实并不复杂,但是真正用得好的公司并不多,我自己曾经的工作环境也依然没有体验过敏捷开发非常成熟的实践过程,但是我依然推荐这种开发方式,不论是对于企业发展还是生活中的任意角落。不过我今天并不是谈论企业中的敏捷开发,自己近半年的空窗期间,在努力尝试个人的Scrum转型。

如果想深入理解Scrum敏捷软件开发,可以阅读一下Mike Cohn的书籍,也可以关注他的推特等社交账号,都会有很多意外的收获。我们先来简单看一看敏捷开发的整个框架是个什么样的(下图出自网络)。

这篇文章首先需要了解Scrum软件敏捷开发的整个过程,这个框架是什么样的,否则可能不能理解接下去我写的那些文字:)

那么为什么要转型,因为曾经我在工作中都是以瀑布式开发为基准的,当然也有少量公司项目比较庞大, 尝试使用敏捷开发方式增量迭代,效果有好有不好,也是一个积累吧。对于自己的一些项目来说,也有涉及少量敏捷方式的,比如一些在国外平台销售的插件或者一些工具包,都多多少少用了一点敏捷开发的思维。因为我没有预期结果,甚至作为一枚新人来说,没有什么完美的方案,只能放手去做,一点点收获效果,不断改进和迭代。

但是光是这些还远远不顾的,我还需要从一些开发方式上(比如测试驱动开发),技术选型上(比如框架、跨平台、WebGL中的数学原理、算法等),书籍选择上(比如工具类、大学科班教材类、传记类等),思想逻辑上(比如变化和实践、优先权、技术集合、团队与导师、教练与研究员等),扩展更多的空间。

(一)个人面对敏捷转型的一些难点

如果从表面去理解,Scrum敏捷开发框架在企业中也许正在做这些事情:需求管理,迭代规划,迭代开发,站立会议,进度跟踪,持续交付,评审与回顾。虽然这个链有不同的角色,但是往往角色在执行的过程中,会对运营、销售、人力资源、财务甚至客户产生影响,这就是所谓的变化会来的很快,结束状态不可预知。难,代表敏捷模式不单纯只是一种工作流,一种理念,它甚至还是一种策略,一种训练习惯养成的方式方法,一种实时可变的角色扮演。

其实很多时候企业面对的敏捷转型困难,可以从大方向上映射到个人身上,我从几个方面分析自己这段时间面对的一些困难。这些困难其实也是按照序号逐层排序和由浅入深的。

1.意识上

首先对于一个人来说,不论是在职期间还是空窗期间(灵活就业或者自由职业),都有无数天在和自己的心理做斗阵。挣钱,学习,考试,看书,运动,调节生活,娱乐等等,这时候,又来一个敏捷转型?岂不是火上浇油。对的,因为任何的”转型“,势必会有陌生和持久性学习,这个过程是非常非常艰苦甚至是乏味的,再严重一点可能是迷茫的。

主观意识上,人都会排斥一些新事物,新技术,可能会觉得需要花费太多时间,去得到一个不能预期的结果。特别是一种软件开发方式从瀑布式开发(需求分析、设计、编码、测试、维护)到敏捷开发,将面临各种坑,第一战线绝对是自己的主观意识。

抵触、纠结、效果不明显、无意义、理想化、理论化、悲观、害怕...也许可以用一千个词来概括自己的内心所想。这些都是意识上会面临的困难。

继续往下说,我对这种工作方式,学习方式,想达到什么样的预期结果,渴望做些什么?一连串的思绪将如雪崩一样袭来。

2.时间上

如果你是在职期间,那么根据公司的一些计划和安排,也许会督促你进行一些敏捷开发的实践工作,当然,也许公司策略也会各种调整,也许不会采用这种方式,因为可能不适合。曾经雅虎、salesforce等等都是敏捷转型的大型实践者,并且也经历了失败和成功,当然他们目标是全面转型而不是试点行为,最后也有很好的ScrumMaster参与,最终完成了转型。

对于个人而言,时间是一个头等大事。离职空窗期,你会有大把的闲暇时间去做自己的事情,这些事情如何安排,需要不需要参与到敏捷转型中来?会不会耽误学习,找下一份工作,或者面试准备,考研,职业规划等等。这些是我要面对的时间管理问题。

3.引进新技术实践

这个话题对于开发和设计界来说就非常明显了,设计方面,你要学习PS,AI,C4D等等,还有各种云平台协作工具,各种交互研究,用户体验研究,不断地练习,熟悉软件,不断扎实美术绘画、视觉理论基础,太多太多的迭代学习。

对于开发而言,比如前端开发,由最初的掌握一定的HTML,CSS,jQuery,到现在的Webpack工程化,自动化,单元测试,TTD,Node,Vue,React,Threejs,D3等等,每一年技术更新,框架革新,工程化工具演变速度之快,大家有目共睹。再如一些扩展性试验,比如小程序,Taro,uni-app,Electron等跨端需求越来越多,要求前端开发者的技术也在不断变化,学习计划也在不断更新。

虽然底层的基本功(计算机科学、数据结构与算法、高数、离散数学、WebGL等)不变,也需要个人花大量时间去学习各种流行的框架,特别是思想和逻辑的学习。开发中涉及太多的逻辑演化。你看,一下子这么多的新技术实践,你不头疼?你不卷?自然也有人卷。

如何使用引进的新技术,如何规划学习时间,他们是否符合敏捷开发中的需求迭代,是否符合我未来预期的工作计划和职业规划?哇哇哇~~ 真的,这也是一个难点。

4.试点项目和ScrumMaster

好了,说完了意识、时间和技术,接下去要如何尝试转型呢?选择一个合适的项目,那么这个项目是作为自己的业余练习还是做外包商业项目呢?不论是哪一种,都需要投入一定的学习和时间成本,还有金钱成本。

项目实践用敏捷的方式去实践,如果是公司可能会有导师,有管理者,有CEO,作为个人来说,没有教练团队,也许我的ScrumMaster可能是书籍,也可能是客户,也可能是自己的思想。

选择“通常也是一个非常非常头疼的过程。就拿职业、兴趣来说,选择人生追求,足以让你在迷惘和前行的路途中走个五年十年几十年。我算幸运的,虽然没有什么惊天动地的成绩,也算是跟着自己的初心走了那么多年,设计和开发,都是我的产品依托,都是我的技术路线,这是一个持久连续的路线,要遇到无数的未知和不好的结果。这不正好?敏捷的方式,可以让自己避免太大的损失,逐渐让自己的目标浮出水面,逐渐让自己擅长的东西浮出水面。

(二)作为个体的实施模式

实施之前,我们会根据ADAPT模型分析自己具备哪些条件。

ADAPT模型构成:意识(Awareness),渴望(Desire),能力(Ability),推广(Promotion),传递(Transfer)

对于我个人而言,有几个很明显的瓶颈和自身条件,综合归纳如下:

  • 科班的基本功(我的专业是旅游管理,只不过不太喜欢做实体服务行业,曾经和现在,多次自修了原版译本大学科班教材:计算机科学、数据结构与算法、设计模式、离散数学、美术专业基础、透视学等)
  • 目前具备的能力(UI设计和用户体验研究、前端开发相关、流行框架偏React、后端比如PHP、健康管理等)
  • 时间(离职空窗期半年以上,这段时间会合理分配,当然我的自律能力也不算很强,但是也不差)
  • 生活成本(没有工作期间,势必要保证足量的超过1年的生活成本,否则也许一个小小的实验,也会导致生活困难而乱了脚步)
  • 实战空间(自己的居住地,学习地,办公地,需要在自己的老家和其它城市之间做一个良好的调剂)
  • 目标规划(整体我自己都是跟着初心走,也许是兴趣做成了职业,也许是职业做成了兴趣,都无妨,我有那个意识和自信去尝试新事物)

总体衡量了自己的情况,我觉得尝试一次更加全面的敏捷转型,从自身做起,是没有大问题的。经过以上分析,我觉得我自己应该全面转型,而不是临时的针对某一个小方面试点。

其实一定程度,我已经公开实施了一些敏捷转型,自己尝试使用一些没有使用的技术,学习一些有趣的东西,加以实验,比如制作一些跨平台的软件,使用一些新技术和框架尝试提高性能和用户友好程度。因为我花了很多时间和成本,去做这些东西,面对渐进式的转型过程,肯定会遇到一些困难,但是这已经是我长期的研究方向。

另外,我也不断地提升自己的基础能力,自学感兴趣的大学教材(包括英文原版翻译版教材),因为这有不断训练自己的思维,产生肌肉记忆,才能对未来的风险做更好的评估,才能减少一些试错成本。

(三)组织预期结果

做任何事都需要一个结果,当然一次比较困难的敏捷转型也是一样的,需要有一个度量方式去衡量自己的成果。但是这个度量方式并不是标准,也不会有一个所谓严格的标准。因为本身敏捷过程就是持续化的,是长期的。

我把我的结果主要归于一些软件组织的审查,比如提交一个软件,完成一个商业项目提交到市场售卖,按照国外的标准来说,我会从失败多次到成功一次,然后成功两次。因为只有这样,我才能知道我自己是否能在某个时间段内有能力去做到它。做不到怎么办呢?没关系,我可以学习,经历着无数年的探索,摸索到了适合自己的学习方式,这是我的一个很重要的信心来源。

也许你会非常看重最终结果,但是本身敏捷开发就不存在最终结果。它将是一个一直迭代的循环。是的,我也许是在推广自己的一些学习和工作方式,虽然它并不成熟,但是我确实自己去做了,花了至少半年去训练成一个“习惯”。

有些方面我达不到标准,没关系,我通过不断地渐进式学习方法,弥补一些缺陷,慢慢去适应这种改变。

愿意改变是一种优势,即使这意味着某段时间会使公司的某个部分陷入混乱。

——杰克 • 韦尔奇

这种改变对于个体而言,其实也可以映射出来。这对我而言可能要牺牲大量的时间和金钱成本,牺牲大量的就业机会,我必须面对这种风险,它对于我未来长期的研究方向和发展方向是至关重要的,它很值得

在不同的阶段,要审阅自己给自己的交付,也可以说,其实每次commit都算作是对自己的一次交付,同时它也提高了自己在整个项目环节的维护热情,开发热情。同时,敏捷开发的观念,要求很多环节都是“我的事情”,而并不是大家隔开闷头自己做自己的事情,做完再交互,实际上可能项目的每一个方面,都是我的任务。面对Sprint,还需要考虑环境因素对自己的影响,如何审阅自己,评估自己的成果,如何改良,我想这些才是最重要的敏捷提现。一个运用敏捷开发很好地企业,加班其实是很少的,对员工的体验也是很好的,质量和效率也许还会大大高于非敏捷手段。

结语

虽然我并没有参与过一个非常成熟的敏捷开发团队,但是我觉得大家都有在尝试,沟通,寻找问题,解决问题,而且这个过程不断改良方法,改良标准,这是一个进步,持续的进步,我相信未来会慢慢熟悉它。

经过这一些思考,我将会再下一次Scrum探索中,写出某一个阶段某一个试点空间的方法论。也由此训练自己的逻辑思维和提升学习的把控力,资料的查阅能力。我相信,每一次探索,都是值得的,每一篇文字,都是值得花时间去整理去分享的。我是ChuckieChang,我为自己带盐:)

本文出自没位道 - Chuckie Chang个人网站,转载请保留出处,谢谢!
文章采用 CC-BY-4.0 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。


返回列表  分享

分享给朋友!

微信
微博
文章评论