说说Scrum敏捷开发
本文由发表于3年前 | 软件开发与管理 | 暂无评论 |  被围观 3,844 views+
Scrum敏捷开发基本角色和任务敏捷开发中的测试不能流于形式书籍
Scrum敏捷开发

第一次听到敏捷开发是在刚毕业后的工作中的,而公司使用的是这种开发方式。

随着敏捷开发的不断发展,一些企业公司,多多少少的不知不觉的融入了一种敏捷的思维。

很多初创的互联网公司,更多的是一种功能的叠加开发和业务的扩展,这种模式也很适合于敏捷的开发模式,而在开发过程中也多多少少看到了这种影子。

基本角色和任务

Product Owner需要确定产品的功能和完成时间,并对产品的收益负责,要根据市场需求确定产品功能的优先级。

Scrum Master的职责是:负责监督整个 Scrum 项目进程,调整项目计划;确保开发团队成员的能力能够胜任产品的开发;促进团队中不同角色的成员间充分交流和沟通,并负责为项目的进行扫除障碍;保证开发团队不受外力的干扰和阻挠;掌握产品开发进度,参与每日 Scrum 会议、Sprint 计划会议和 Sprint 评审会议。

首先是根据需求讨论得出Backlog,Scrum团队根据功能模块把每一个Backlog又继续划分为UserStory,注意User Story由是由市场和客户驱动的,这样可以确保是由项目相关领域专家们来写User Story的,格式如下:

作为<某个角色>,我可以<做什么>,以完成<什么目的>。

为了高效的完成每个Story,由Scrum团队把每个Story分解为若干个Task,每个Task规定明确的完成时间(以小时为计量单位,一般不超过8小时)。

Scrum会议是一个很好的团队交流并把握整个项目进度的良好方式,这个会议的主体和受益者是团队的开发人员。

敏捷开发中的测试

考虑到敏捷开发团队,拥有属于自己的测试是很重要的,因为这种开发方式是迭代式的,开发和测试的分开,更多的会让软件变成流程式的,而敏捷开发强调的是以人为本。价值为本,要时时刻刻想着客户,想 办法创造真正对客户有价值的软件。当做到了能更快速地提供价值的时候,就是敏捷了。

测试开发分开为两个隔离的部门有好的也有不好的,好的是即使项目再多,测试人员也不用太多,这种情况下测试的成本是会缩小,但是测试那边的工作也会比较繁琐,很多时候并不能真正的体会到作为共同创造一个产品的乐趣,而这种的考核项目的方式也比较传统,有时候并不能把测试和开发作为同一个产品的研发队伍去考虑。

特别是引入了自动化测试后,测试人员应该是和一个产品相关联的,而不恩能够把测试仅仅是当做一种技能,这样也更能提升在产品中的影响力和作用。

不能流于形式

当然,敏捷开发也是一种管理哲学,而不能流于形式,有些人说敏捷开发不适合于做产品类的project,也有些人说敏捷开发室为了测试而搞出来的,除了提高可测试性没有别的好处。根据自己的项目的实际情况进行调整,或者多多少少会受到一点启发,或者这种方式就确确实实是你需要的。

书籍

看了《轻松Scrum之旅:敏捷开发故事》,简单的做了个图,毕竟是别人描述的经验,并不以一定适合每一个团队,但是也可以从中受到一些启发:

scrum敏捷开发

点击查看大图

下面是从《轻松Scrum之旅:敏捷开发故事》书中节选的一些片段:

在每个 Sprint 开始之前,需要召开 Sprint 计划会议,会议时间一般为 4~8 小时,参加人员有产品责任人、Scrum Master、Scrum 团队和其他感兴趣的人,比如管理层人员和客户代表。Product Owner 从产品 Backlog 中挑选高优先级的任务,并与 Scrum团队一起决定在这个 Sprint 中需要完成多少功能。Scrum 团队将这些任务分解成小的功能模块。Scrum 团队成员详细讨论如何能按需求完成这些功能模块,并估计完成每个功能模块所需的大概时间。

在混乱中建立秩序是 Sprint 开始阶段的目标。

敏捷和 Scrum 倡导团队自我管理,在任务分配上提倡每个人按兴趣和能力自主选择任务。

JSUnit 是为 JavaScript 而设计的,JUnit 是为 Java 程序设计的,都是自动单元测试的框架。我以前一直以为单元测试是测试员该干的工作,今天才明白原来得开发来做。

会议由 Scrum Master 主持,Scrum 团队的所有成员轮流回答以下 3 个问题。(1)昨天我完成了什么工作?(2)今天我打算做什么?(3)我遇到了什么障碍?

最重要的体会是每日 Scrum 会议很容易使团队产生凝聚力,不再是过去那种“你干你的,我干我的”的状况了。

你一定要记得不能在会上对这样的问题做过多的讨论,这是在浪费所有人的时间,你要做的是会后联系其他的资源来解决这个问题。

做 Sprint 计划的时候不能光图完成得快,还应该把方方面面的问题都考虑到。这句话说起来容易,要做到完美还真是很难。好在现在是一个 Sprint 结束后就可以暴露问题,而过去要很晚才能发现。

发现问题不是坏事。Sprint 评审可以帮助团队尽早地发现问题,尽早地得到使用反馈。

不要隐瞒团队的技术实力,否则很难做切合实际的计划和评估。

善于寻求帮助是个好习惯,不仅仅是针对敏捷开发项目。

在 Scrum 中,产品要完成的功能清单叫做产品 Backlog。每一个 Backlog项通常也叫 Story,因为它是由 User Story 来描述的,一个 Story 是由一个完整的 UserStory 来描述的。有时候,一个比较复杂的 Story 也可以分解若干个成更小的 Story。Task 是任务,在具体实现每个 Story 的时候都要将其分解成具体的任务,比如编码、测试、调研、Code Review 等,这些都是 Task,而不能称为 Story。

Sprint Goal 是个鼓舞士气的好工具。

在 Scrum 中,实际上要求 Scrum 团队是跨职能的。一个 Scrum 团队应该包含开发人员、测试人员、美工及文档人员。敏捷的开发流程迫切需要一个跨职能的团队。

ECF 的全称是 Eclipse Communication Framework,是一个基于 Eclipse 的协同工作框架,它让开发人员在开发产品时,相互间可以及时地沟通和交流。

将投资和回报最大化,快速反映市场的风云变换,敏捷开发是应对危机的最好武器。

敏捷开发是最注重人与人之间的沟通的,而现在在沟通上出了问题,该怎么办?想来想去,最好的方式莫过于面对面的沟通了,让双方都多了解一下对方的产品,先把以前存在分歧的地方达成一致,以后再通过邮件

和电话沟通,应该就会好多了。

Scrum 的可视性能够保证及时发现问题。不要隐瞒风险。要用非技术语言给客户提供足够的信息以便他们提前做出决策。

还有自动化 Unit Test,要是每次做完 Build 都能自动跑一遍 Unit Test 就好了,现在的问题一个是覆盖率太低,另一个是没有自动化。

按照产品整合部门可以大大提高执行效率,开发和测试在行政上属于一个部门有利于使他们结合成一个真正的 Scrum 团队。

IBM Rational 推出的 Jazz 是一个创新的团队协作平台,它将成为下一代 Rational软件开发平台的基本框架。

在测试新功能的时候必须先对原来的老功能做回归测试,以保证新加进来的功能不会破坏系统原有的功能和完整性。还有,咱们应该尽量实现自动化测试,这也是事半功倍的。

在生活中,敏捷可以无处不在,Scrum 其实蕴含着先进的管理思想。

持续集成是敏捷开发中核心的工程实践,它是敏捷产出“可以工作的软件”(Working Software)的有利保障。

敏捷也不仅仅是一堆软件开发方法和开发流程,它的本质是一种哲学思想,是一种做事情的方法论。我的体会,敏捷之道就在两点,以价值为本,以人为本。价值为本,要时时刻刻想着客户,想办法创造真正对客户有价值的软件。当做到了能更快速地提供价值的时候,就是敏捷了。帮助客户成功,你也就赢了。以人为本,说到底,价值还是由人来创造。一家新公司或者一个新团队的关键是人才,有了人一切都好办,对人才要好好珍惜。当人的能动性超越了一切死的流程,就是敏捷了。记得有一句话是这么说的,‘Youdon’t do Agile, You are Agile !’”

除了文章中有特别说明,均为IT宅原创文章,转载请以链接形式注明出处。
本文链接:http://www.itzhai.com/about-scrum-agile-development.html
关键字: ,
arthinking Java技术交流群:280755654,入门群:428693174 more
分享到:
 
文章评论
    没有评论
给我留言

有人回复时邮件通知我
软件开发与管理的相关文章
随机文章 本月热门 热评
1 Android的广播机制实现 BroadcastReceiver 2011/7/12
2 Java Web笔记 – JavaBean的使用 JavaBean的范围 与Java代码的交互 2011/11/10
3 ExtJS拖放技术DragSource拖动到指定区域DDTarget 2011/4/13
4 J2EE分层架构中的参数和异常处理 2012/9/15
5 数据结构笔记 – 排序算法 简单选择排序算法 2011/9/20
6 Struts2笔记 – Struts2相关帮助文档和在线学习资料 2011/6/18
友情推荐 更多
破博客 文官洗碗安天下,武将打怪定乾坤。多么美好的年代,思之令人泪落。
Mr.5's Life 白天是一名程序员,晚上就是个有抱负的探索者
行知-追寻技术之美 关注大数据,分布式系统
我爱编程 编程成长轨迹
Cynthia's Blog 学习笔记 知识总结 思考感悟
 
欢迎关注我的公众号 IT宅
关于IT宅 文章归档

IT宅中的文章除了标题注明转载或有特别说明的文章,均为IT宅的技术知识总结,学习笔记或随笔。如果喜欢,请使用文章下面提供的分享组件。转载请注明出处并加入文章的原链接。 感谢大家的支持。

联系我们:admin@itzhai.com

Theme by arthinking. Copyright © 2011-2015 IT宅.com 保留所有权利.