2017-06-11 16:26:28 qq_26761587 阅读数 187
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10414 人正在学习 去看看 CSDN讲师

一、什么是敏捷开发

敏捷开发(Agile Development)不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。

怎么理解呢?首先,敏捷并不是一门具体的技术,而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。其次,敏捷开发都具有以下共同的特征:
- 迭代式开发
- 增量交付
- 开发团队和用户反馈推动产品开发
- 持续集成
- 开发团队自我管理

二、具体方式

上面说了敏捷是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而具体的开发方式有哪些呢?

Scrum,极限编程(XP),精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。这些方法还需要结合业务选择并实践,目前还没有深入学习~

三、敏捷开发宣言和准则

《敏捷宣言》

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:

  • 个体与交互 重于 过程和工具
  • 可用的软件 重于 完备的文档
  • 客户协作 重于 合同谈判
  • 响应变化 重于 遵循计划

在每对比对中,后者并非全无价值,但我们更看重前者
敏捷宣言是对敏捷的高度总结和升华,即使现在不理解也没有问题,在实践的过程中我们会逐渐对它有一个深刻的认识。

敏捷开发十二原则

在敏捷开发中,我们遵循以下准则:

  1. 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户
  2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
  3. 要不断交付可用的软件,周期从几周到几个月不等,且越短越好
  4. 项目过程中,业务人员与开发人员必须在一起工作。
  5. 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
  6. 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
  7. 可用的软件是衡量进度的主要指标。
  8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
  9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
  10. 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
  11. 最佳的架构、需求和设计出自于自组织的团队。
  12. 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。
2012-01-29 14:28:00 huanghyw 阅读数 1024
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10414 人正在学习 去看看 CSDN讲师

过年放假这几天读了一些敏捷开发方面的书籍,基于自己对敏捷开发的理解总结出以下几点。本文内容还会进一步整理,暂时先贴出来,权当作是一份备忘吧。也希望对阅读过本文章的挨踢人有些许启发,如果能留言进行进一步的讨论交流就再好不过了。


我认为敏捷开发应该围绕如下几点进行:

1、出了现了一个问题或发现了一个bug,第一重要的事情不应该是想办法确定这个问题是谁造成的,而是应该试图去想办法解决这个问题。因为去争论这个问题是谁造成的没有任何意义,有意义的是如何去解决,让系统能正常的工作起来。

2、发现一个bug,并且时间紧迫,如果不去了解真正的原因就进行快速修复确实能解决它(在最后添加一行代码或者是对结果进行简单的偏移运算)。但是要知道,千里之堤毁于蚁穴,这样的修复日积月累下来就会使项目代码变得凌乱且晦涩难懂。如果在这样的项目之上添加新功能或者进行其他的改动,将会很难下手。所以,未雨绸缪。建议不要孤立的进行编码,要经常阅读团队中别人写的代码(包括单元测试)。自己要对每个功能写好单元测试,写单元测试能帮助代码进行分层,方便别人阅读与理解。这样,不管是你在修改别人的bug还是别人修改你的bug,会相应的顺手一下。这样坚持下去,即可最大限度的保持项目的保持整洁与清晰。

3、在设计或者代码中遇到了奇怪的问题,应该花时间去理解代码为什么会是这样的。如果找到了解决方法,但是代码仍然不好理解,那么就鼓起勇气去重构它,使它变得容易理解。如果没有马上理解那段代码,就不要轻易的否定和重写它。那不是勇气,那是鲁莽。

4、养成立会的习惯。顾名思义,立会即站立着开会,参与者不允许在会议中就坐,这样能保证会议的快速进行。因为一个人坐下之后,会由于感到舒适而使会议持续更长的时间。立会可以在每天十点准时举行,每人发言时间控制在三分钟内,会议内容围绕昨天有哪些收获、今天准备做什么、当前面临着怎样的障碍这三个方面来进行叙述。各项问题不进行深入讨论,防止延长会议时间。如果有深入的必要,可以在会后进行。这样的立会可以让团队成员达成共识,并能保证会议短小精悍不跑题。

5、要寻找深藏不露的程序bug,进行正式的代码复查其效果是任何已知形式测试的两倍,而且是移除80%缺陷的唯一已知的方法。代码复查由项目团队中的成员来完成,可采用交换复查的方式。代码复查在团队中某一个成员即将提交代码时进行。代码复查内容包括代码能否被读懂和理解、是否有明显的错误、代码的改动是否会对项目其他部分造成影响、是否存在重复的代码、是否存在可以改进和重构的部分。

6、和客户讨论问题的时候,准备几种可以让客户选择的方案。从业务角度而不是技术角度向客户介绍每种方案的利弊,以及潜在的成本和利益,以及和他们讨论每个选择需要的时间和预算。如果事后他们又想要其他的东西,可以公正的就时间和成本重新进行讨论。

7、搭建一个演示服务器,每添加一个新的功能或者是对系统进行优化之后,告知客户访问最新的系统。这样系统每一次迭代都能获取客户的反馈意见,这样也基本保证了项目始终是沿着客户的需求进行开发的。保持项目随时可发布很重要。

8、很多项目都是因为程序代码失控而陷入困境。修复一个bug导致更多的bug,从而又导致了更多的bug修复。这时我们需要一个频繁的反馈,虽然可能不会使代码更好。但是也不会使代码变坏,至少还是像昨天那样可以运行。此处,使用单元测试就是一个非常不错的选择。单元测试应该在增删改某个功能的时候来运行,至少应该在提交代码的时候运行。单元测试中用来测试的数据应该包含边缘数据(比如11:59:59,0:00:00都是比较好的边缘测试数据),并不能放过任何一个失败的测试。

9、建议采用先测试再实现的方式进行开发,也就是“测试驱动开发”。总是在有一个失败的单元的测试后才开始编码,测试总是先于代码编写。通常这种测试失败的原因是测试的方法不存在或者是方法的逻辑还不足以让测试通过。先写测试,就会站在用户的角度来思考,而不仅仅是一个单纯的实现者。这样做和先编写后测试有很大的区别,你会发现因为自己要使用它们所以才设计了他们。这种方式能让接口的设计更有效。除此之外,还有助于消除过于复杂的设计,可以专注于真正需要完成的工作。

10、并不意味着单元测试在自己的机器上能运行,就一定能在其他的机器上能运行。不同的环境可能会有不同的结果。这个和操作系统环境有关,甚至可能和硬件环境有关。

11、在系统开发中辛苦的编写单元测试用来获取代码的反馈,却往往容易忽视了最终用户的反馈。不仅需要和真实的用户进行交谈,还需要耐心的倾听。即使他们说的内容是一些让你觉得非常直观,非常简单的问题。因为每一个用户的抱怨背后都隐藏了一个事实,我们要做的是找出真相,修复真正的问题,而不是对用户发出嘲笑。

12、用户在使用系统的过程中如果出现什么错误,不要只是简单的弹出一个错误对话框。应该告知用户发生了什么错误,方便用户进行有效的反馈。如果出于保护代码底层的原因不想让用户知道具体的错误信息,也可以在系统后台给技术支持人员发送一份问题的详尽错误报告。

13、编写能够清晰表达意图的代码,这样的代码清晰易懂,仅凭小聪明写的那些晦涩难懂的程序很难维护。注释虽然能帮助理解,但是有可能会对理解造成干扰。其实,这里也不是说注释不用写,只是不能让别人完全通过注释才能理解所写的代码。最好是采用规范的命名、清晰的流程、简单的编码等方式来达到代码既是注释的效果。

14、在代码编写或项目开发的时候应使用增量式的开发方法,即每完成一个功能或者方法的时候确保其对应的单元测试能正确通过。这样,在编码的过程中也能实时不断地获取来自代码的反馈。提交代码之前需要保证所有的单元测试能完全通过。

15、应具有一个自动化测试环境,每天固定的时间开始从svn检出最新版本的源代码进行单元测试。测试完成之后会生成一份测试报表。这样,每天早上就能获取一份关于最新代码的测试报告。时刻了解项目目前的状况。

16、编写具有内聚的代码,做到一个方法只做一件事情,一个类只包含他自己所应该包含的方法,一个包只包含应有的模块。这样有利于维护。但是内聚的颗粒不能太粗也不能太细,要拿捏的恰到好处。这样有助于对代码的理解,也降低了项目维护的难度。举个例子:当需去储物室寻找一台电脑的时候,打开们一看,里面乱七八糟的什么都有,后来费了很大的气力才把电脑找出来,这就属于颗粒太粗,没有分好类;当需要去储物室寻找一台电脑,打开门一看,里面大大小小的箱子盒子收拾的井井有条,一眼就看见了一个盒子上面写的电脑二字,打开盒子一看,里面是内存、CPU、硬盘、主板……这属于颗粒太细,虽然得到了自己想要的东西,但是不能马上用,还需要自己组装之后才可正常使用。

2018-04-03 21:50:24 weixin_41787887 阅读数 1221
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10414 人正在学习 去看看 CSDN讲师
天天在用着敏捷的思想,但是今天面试的时候让讲敏捷,又不知从何说起,今天记录下 ,部分内容也有参考网上优秀的易理解的说法。

什么是敏捷开发?
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

我理解它仅仅是一种开发方法,更是为了应对激烈竞争和快速需求变化的一种价值观和商业模式。
敏捷提倡以人为核心,敏捷注重的是人与人之前的,面对面的交流。
敏捷的核心假设就是:需求是变化的。
它以一种局部演进,逐步交付,小批串行的方式更快速的进行交付和保证产品质量。


开发测试过程图 借用几张图来说明


测试活动
测试系统图

敏捷的核心假设是:
需求是持续变化的
敏捷12条准则/原则
1.Customer satisfaction by rapid delivery of useful software
 对我们而言,最重要的是通过尽早和不断交付有价值的软件满足客户需要
2. Welcome changing requirements, even late in development 
我们欢迎需求的改变,甚至在开发的最后阶段
3.Working software is delivered frequently (weeks rather than months) 
经常交付可以工作的软件(从几星期到几个月)
4.Working software is the principal measure of progress 
可以工作的软件是进度的主要度量标准
5.Sustainable development, able to maintain a constant pace 
敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏
6.Close, daily co-operation between business people and developers 
业务人员和开发者应该在整个项目过程中始终朝夕在一起工作
7.Face-to-face conversati最好的架构、需求和设计都源自自我组织的团队
12.Regular adaptation to changing circumstances 
每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为
on is the best form of communication (co-location) 
在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈
8.Projects are built around motivated individuals, who should be trusted 
围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务
9.Continuous attention to technical excellence and good design 
对卓越技术与良好设计的不断追求将有助于提高敏捷性
10.Simplicity 
简单。——尽可能减少工作量的艺术至关重要
11.Self-organizing teams 
 
敏捷的价值观:
个体与交互 重于 过程与工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划

敏捷的一些特点和问题
Ø 前期投入变多了
Ø 对人的要求变高了
Ø 常常在项目未完时就显现出的商业价值
Ø 成功项目管理类,互联网类偏多
Ø 项目成功但可维护性不佳
Ø 给人感觉流派比较多
Ø 有一些极端敏捷的思路和主张,无文档等
 
敏捷最佳实践:
XP、SCRUM、水晶体系、动态系统开发方法DSDM、适配性软件开发、FDD等
SCRUM
SCRUM是遵循敏捷方法的一个软件开发框架。在SCRUM框架中,融入敏捷开发的精神和思想。
Scrum方法是一种偏重管理的优秀实践组合:
    它通过组建客户参与的团队,确定客户与开发团队的一致目标;
    分里程碑,按商业价值排序的需求列表;
 Scrum框架核心内容:3-3-3
“3”个角色(Role)
产品主管(Procuct Owner):负责项目的商业价值
Scrum师傅(Scrum Master):他负责团队的运转和生产
自组织的团队:目标一致的团队
“3”个会议
迭代计划会议
每日晨会
迭代回顾会议
“3”个工作组件
待开发任务列表(product backlog)用来排列任务的优先级和跟踪任务
迭代任务列表(the sprint backlog)
进度图(burndown chart)
 
客观的认识敏捷
敏捷是一个新生的、飞速成长的方法论
① 敏捷基于文化和价值观的特点让其实框架宽泛,兼容性好,同时灵活性大导致施难度加大
大家对敏捷的理解各不相同,优秀实践百花齐放;敏捷的优秀实践个异性较强,直接学习风险大
② 敏捷提倡的紧密互补的工作方式,对人的要求高
③ 敏捷强调的价值观理解不到位,容易让人忽略某些东西,其结果会给人带来误解
④ 没有万能、完美的开发方法,适合的才是最重要的


2015-05-31 08:16:30 jiuqiyuliang 阅读数 23287
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10414 人正在学习 去看看 CSDN讲师

随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。

背景

我们公司引入敏捷开发的时间并不长,在实施敏捷的过程还存在一些问题,自己在实施敏捷的过程也存在很多的疑惑(毕竟原来没有学过,和真实的经历,体会),所以最近一直在学习敏捷,看敏捷的视频和阅读相关资料,同时结合自己实施敏捷的经验,通过分享博文进行一下简单的总结,目的有四:
1. 详细的介绍和学习一下敏捷开发
2. 和CSDN的大牛们一起分享交流,学习,提高一下
3. 总结实施敏捷过程中的问题,不断反思,不断提高
4. 最后,希望对不了敏捷的朋友有一定的帮助

什么是敏捷开发

敏捷开发(Agile Development)不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。

怎么理解呢?

  • 首先,敏捷并不是一门具体的技术,而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。

  • 其次,敏捷开发都具有以下共同的特征:

    1. 迭代式开发
    2. 增量交付
    3. 开发团队和用户反馈推动产品开发
    4. 持续集成
    5. 开发团队自我管理
  • 最后,相比于“传统”的瀑布开发模式,敏捷开发是一种“现代”的开发模式。

具体方式

上面说了敏捷是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而具体的开发方式有哪些呢?

Scrum,极限编程(XP)精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。

除了Scrum和XP,对于上面的其他开发方式,我也只是简单了解,大家可以多查查相关的资料。

我们可以简单的对比一下Scrum和XP:
1. 在开发的过程中,你可以采用Scrum方式也可以采用XP方式;
2. Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的。

敏捷开发宣言

《敏捷宣言》

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:

个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划

在每对比对中,后者并非全无价值,但我们更看重前者

敏捷宣言是对敏捷的高度总结和升华,即使现在不理解也没有问题,在实践的过程中我们会逐渐对它有一个深刻的认识。

敏捷开发十二原则

在敏捷开发中,我们遵循以下准则:

  1. 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
  2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
  3. 要不断交付可用的软件,周期从几周到几个月不等,且越短越好
  4. 项目过程中,业务人员与开发人员必须在一起工作。
  5. 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
  6. 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
  7. 可用的软件是衡量进度的主要指标。
  8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
  9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
  10. 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
  11. 最佳的架构、需求和设计出自于自组织的团队。
  12. 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

敏捷开发宣言比较抽象,但是敏捷开发十二原则就非常具体了,相信用过敏捷的人都知道,上面的十二原则都是开发过程的经验总结。看到十二条原则,一一的对比我们公司在实施敏捷的过程,还存在一些问题,这些问题直接导致了低效率的,不顺畅的敏捷,例如:最后一条,团队要定期反省,这点做的就不好,造成团队的积极性降低,开发效率下降,而且很难作出调整,甚至我开始也是拒绝的,有了这些原则作为指导,我们可以更加从容的实施敏捷。

敏捷开发十二原则是我们实践的具体指导方针,它可以指导我们实施更加成功的敏捷。当我看到这些内容时,真有一种如饥似渴的感觉,真想一下子都把他们装进我的脑子里。书到用时,方恨少。及时补充自己永远都不晚。

总结

敏捷的思想今天算是深入人心了,后面的具体方法就是教会我们如何实施敏捷。有了这些思想,整个世界都开始美好了。

下篇博文,进入我们的重点简单介绍Scrum以及Scrum的流程,敬请关注。

2019-08-23 19:38:07 baidu_36943075 阅读数 119
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10414 人正在学习 去看看 CSDN讲师

敏捷开发


  敏捷开发,现在大多数团队都在推崇敏捷开发模式
  笔者最开始理解的时候,也在疑惑到底什么是敏捷开发,带来的好处又是什么?

  笔者也只是一个入行没多久的新手,以下只是笔者自己对于敏捷开发的一些理解,并不全面,如有不同理解/或更深刻的理解可以回复进行互相学习。更深入的理解仍需要长时间实践的沉淀


1. 敏捷开发是什么?


  敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。

2. 怎么理解呢?


  首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发;

3. 敏捷代表Scrum和Devops


其实现在大量推崇的敏捷开发主要以Scrum和Devops为主
  Scrum扫盲篇 https://www.cnblogs.com/taven/archive/2010/10/17/1853386.html (感谢博主的分享)
  Devops扫盲篇 https://www.cnblogs.com/jetzhang/p/6068773.html (感谢博主的分享)

 

3.1 两者在敏捷开发中分别起到什么作用呢?


个人的理解是:
  Scrum是一种开发流程,该流程通过将需求从产生-评审-研发-测试-上线-反馈-产生新的需求闭环的形式,将一个产品分解为一个个互相影响的闭环,就是一个个迭代的版本。
  Devops是一种交付理念,主张通过使用CI/CD工具链方式将一个迭代版本中的每个环节都通过工具自动连接,完成每个环节的交付工作,直至上线交付用户。

两者是一个相辅相成的关系,Scrum提供研发流程,Devops提供CI/CD工具链

 

3.2 对于Scrum理解

             (图片来自网络)

个人对于Scrum的理解是:站在产品/项目的角度,怎么让需求得到更快/更好/更准确的实现。

  对于产品人员,希望设计的产品功能等能够快速得到实现、上线、验证、更新。传统的瀑布式开发往往是一次性完成所有的需求,如果上线后发现无法满足市场再次进行新的调整,再次上线可能已经是半年后了,对于互联网产品简直是一个致命的伤害。对于产品特性的刨析分解,将特性重点提取出来,快速实现开发上线得到市场用户的验证,再不断丰富特性无疑是互联网产品占据市场的最好方法。

  所以在Scrum中对产品人员的要求变得严苛,要求产品人员能够对产品特性进行丰富准确的刨析分解(对产品的定位、用户的画像、数据的分析、特性的分解、市场响应的应对、需求管理都是很大的考验)

  对于研发人员,需求的理解偏差/需求变动/Bug修复应该一直都是一个头疼的问题。如果研发人员对于需求的理解存在偏差,也就只有等到测试阶段才能发现需求实现偏差,此时再次进行返工将导致整个产品的上线延期(如果是瀑布式模式,延期时间更长项目成本更高)。如果研发过程中出现需求的变动(因为产品/市场/政策等等因素造成),研发人员将需要重新理解需求,如果需求变更较大之前的编码将进行重新编写,对于整个产品的上线也是一种延期(如果需求变动为主要业务流,在瀑布式模式中可能导致整个项目停工重新设计)。如果测试人员无法快速准确的识别需求偏差/发现系统Bug,将会导致交付延期甚至带来交付隐患,随时带来不可预想的后果。

  所以Scrum提倡快速的版本迭代而不是瀑布式模式,目的就是为了将项目成本损失最小化;

  同时Scrum也很注重研发人员对于需求的理解,目的就是让研发人员对需求进行详细的理解,根据理解进行需求分解后让产品人员进行评审检查是否偏差遗漏;

  并且需要测试人员全程参与产品/研发环节,通过对产品的详细了解/研发的实现逻辑快速分析定位是否满足要求/是否存在Bug,同时也提倡将传统的手工测试自动化,加快测试环节的效率减少工作成本。

 

3.3 团队融合Scrum

  对于Scrum,它本身的研发流程并不一定适用于所有团队,因为每个团队的产品方向/人员配置/团队氛围都不尽相同。

  个人认为对于Scrum的学习,不是对于Scrum流程的照搬,而是对于快速迭代交付的理解,然后根据自己团队的其他种种因素结合,输出适合自己团队的研发流程

  当然Scrum中有很多环节/方式是可以直接借鉴进来使用的,比如任务看板/每日站会/工作量评估/需求分解会等。任务看板可以帮助大家快速同步任务进度,方便进行下一步的工作准备;每日站会,可以让大家同步进度并且提出问题风险;工作量评估,可以让大家不断对自己的工作量化表现战斗力;回顾会议,探讨发言改进的地方共同进步。

  个人认为团队对于Scrum的融合(1)根据团队现状因素等,拟定一套研发流程(2)对全员进行敏捷概念的普及(3)详细讲解流程各环节作用,试行一个版本迭代后召集全员进行回顾会讨论,集思广益对流程进行近一步优化(4)确定合适的研发流程进行强制推广执行,中间出现的问题于每个版本回顾会讨论记录(5)每版本或月或季,进行一次流程优化并继续推行

  让团队去适应一个新的研发流程是一件很难的事情,了解敏捷思想后制定一个适合的研发流程难度不大,难点在于流程的执行监督需要消耗一定的时间/精力,因为敏捷开发的主要驱动核心是人。团队融合Scrum可能会增多一些环节/会议等,想要完成真正的融合一定要加大力度的监督执行,让大家养成习惯才是真正的融入新的研发流程

 

3.4 对于DevOps理解

            (图片来自网络)

              (图片来自网络)

个人对于DevOps的理解是:站在集成/交付的角度,怎么让研发流程各个环节无缝连接,同时推动工具链减少人员操作(当然DevOps是一种理念,理解起来肯定不仅如此,只是在落实方面CI/CD思想比较着重)

  对于研发流程而言,一个好的研发流程就是一个完整的闭环,每个环节都有其存在的意义并且每个环节的完成都意味着工作交付(产品人员将需求交付给开发人员编码,开发人员将系统交付给测试人员测试,测试人员将系统交付给运维人员上线,运营人员将系统交付给客户使用,客户将使用意见交付产品人员分析)。完整闭环就需要产品/开发/测试/运维/客户等角色共同参与,闭环的形成、多种角色的参与都意味着每个环节、角色的交付都是一个重点。更好的交付将减少下游环节、角色的工作成本;更好的交付将提高研发流程的流畅度(对于研发流程的推进也有帮助);更好的交付将提高产品的市场、乃至提高产品的收益。

  笔者接触到的大多数DevOps的讲解,DevOps是将开发、测试、运维融合起来,但是笔者认为DevOps并不仅仅是这3者的融合,而是整个产品至上线所有环节/角色的融合

  DevOps提倡使用工具链,将所有的交付/监控等等环节操作工具化,并通过工具之间的API互相关联形成一套完整的工具链体系。通过工具减少人员的操作,即减少了人员成本又极大的避免了人为操作失误带来的损失。

  笔者之前看到过一个比较完整的DevOps工具链概览,分享给大家(同时也感谢作者的分享)https://blog.csdn.net/qq_31977125/article/details/82796739

  顺便再分享一个 DevOps BookMarks ,涉及了DevOps方方面面的工具和内容,有兴趣的同学可以去学习下。http://www.devopsbookmarks.com/

  (笔者也有简单分享过一些工具相应的介绍/安装/配置文章,后面笔者也会继续学习继续补充)

3.5 团队融合DevOps

  对于DevOps,它是一个理念。个人认为对于DevOps的学习,首先是真正的理解集成/交付的思想,然后就是工具链的学习使用(硬核技术)。

  团队对于Devops的融合是需要全员参与的,也是对团队整个技术栈的全面提升。首先是组织推广CI/CD的思想,让大家理解交付的意义;然后团队整体寻找适合团队的工具链,进行技术栈的全面提升。

 

4. 团队走向敏捷开发

  个人认为团队想要真正的走向敏捷开发,需要对于Scrum和DevOps进行一个完整的融合。

  通过DevOps闭环的思想、Scrum迭代的思想,结合Scrum可以借鉴的环节/方式,制定一套闭环、适合团队的研发流程。

  通过JIRA等项目管理工具将研发流程工具化管理,再将研发环节交付工具化执行,然后打通项目管理工具、研发各环节交付工具形成一个完整的工具链。

  最最重要的一点还是人,一个团队想要真正的走向敏捷开发,首先也是必须要让团队人员都认同迭代、闭环、集成、交付思想。只有思想上的认同,才会让整个团队共同努力向着敏捷开发的方向不断前进

敏捷开发之Scrum

阅读数 24

没有更多推荐了,返回首页