从管理学看敏捷开发Scrum

2010-12-21 14:13 宗子城

每次我们看敏捷开发Scrum都是从技术角度,今天我们尝试从管理角度来看这个问题。

Scrum

Scrum近几年已经成为最有影响的软件开发过程,从Forrester 关于敏捷模式的调查报告我们可以看出一些倪端,而且微软也推出了更Scrum的模板,相信.Net平台下越来越多的团队会采用这一过程。


 

图1: Forrester 关于敏捷模式的调查报表

Scrum的在软件日趋复杂的环境下,其成功不是偶然的,其指导思想符合我们现代管理学的一般规律。

管理学

经过近百年的管理理论的演进,管理一般被认为是一个协调工作活动的过程,以便能够有效率和有效果地同别人一起或通过别人实现组织的目标,其协调工作活动一般分为计划,组织,人员,领导,控制五个方面,这五个方面并没有严格的时间断点,而是一个相对独立的问题域,周而复始的贯穿整个管理过程。

计划:计划涉及使命、目标选择、决策完成使命的行动方案。

计划是管理的首要职能。它是在预见未来的基础上对组织活动的目标和实现目标的途径作出筹划和安排,以保证组织活动有条不紊地进行,计划内容包括“5W1H”.制定计划首先要确定目标,在制定目标时候要参照SMART法则.

组织:维护群体的工作方式,旨在建立一个合适的角色体系,创造一个促进员工完成任务的环境。

组织意指一个正式的、刻意设计的角色或职位结构以满足组织目标实现,明确所需要的活动并加以分类,对那些为实现目标所需要的活动进行分组,每个小组安排有监督职权的管理人员来领导,为组织结构中的横向协调和纵向协调制定有关的规定。 在组织设计的时候要注意统一指挥原则 ,控制幅度原则,权责对等原则,柔性经济原则,同时注意强调组织有效性和组织文化。

人员:组织角色的填充,涉及人员的配置和保持人员的稳定。

人力资源管理工作直接影响整个企业的经营状况,现代管理学人为人力资源部门为企业利润中心,在人力资源管理方面,企业总的目标是尽可能拥有高素质的员工,以使企业得以保持竞争优势;而人力资源管理部门则主要侧重与这一总目标有关的更为具体的目标即生产力以及质量和服务,通常人力资源的变革涉及企业在文化、领导方式和人力资源政策与实践惯例等方面作出相应的改变。

领导:对团队人员施加影响,促进其对组织和群体目标做工作。

领导是影响人们心甘情愿和满怀热情地为实现群体的目标而努力的艺术或过程。越是了解那些激励下属的因素以及如何使这些因素发挥作用,并体现于管理的实际行为之中,那么领导就越有效,在领导过程中可以从分发挥采用委员会和小组的优点。

控制:确保事情的发展方向符合计划,评定和纠正人员和组织的绩效手段。

控制是对绩效进行衡量和矫正,确保企业目标以及为实现目标所制定的计划能够顺利完成,控制基本过程为确定标准,衡量绩效,纠正偏差,在控制点上我们可以选择实物标准、成本标准、资本标准、收益标准、计划标准、无形标准、以系统目标为标准、以战略计划作为控制点。

解析Scrum

Scrum框架图如下:

 

图2: Scrum框图

1.产品列表和迭代计划

产品任务列表(Product Backlog Item/PBI) 是可以预知的所有仸务,包括功能性的和非功能性的仸务,PBI属于计划阶段,指出了我们目标,PBI表述的时候建议的原则

Independent 独立性,避免与其他Story的依赖性。

Negotiable 可谈判性,Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细,开发人员可以给出适当的建议。

Valueable 有价值性, Story需要体现出对于用户的价值。

Estimable 可估计性,Story应可以估计出Task的开发时间。

Sized Right 合理的尺寸, Stories应该尽量小,并且使得团队尽量在1个sprint(2 weeks)中完成。

Testable 可测试性, User Story应该是可以测试的,最好有界面可以测试和自动化测试。每个任务都应有Junit Test。

这个虽然加入了一些软件技术性描述,但是总体上和我们说Smart原则上是一致的。

迭代计划(Sprint Planning ),综合考虑项目环境,在下一个迭代周期的目标,其中的Sprint Backlog来自PBI,这个就是我们所讨论的计划工作中对目标实现的途径作出安排。

 

图3:迭代计划

当然这涉及到决策问题,比如迭代的周期?先实现那些PBI?比如迭代周期的选择,这个就是个非程序化决策,需要我们自己的经验判断,PBI的优先性我们可以从PBI的字段描述中进行程序化决策。

2.Scrum中的角色与团队

Scrum定义了许多角色,关于猪和鸡的笑话很形象,对于猪的角色来说又分三种:产品负责人(Product Ower),Scrum主管(Scrum Master),开发团队(Scrum Team)

产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写 用户故事,排出优先级,并放入产品订单。

Scrum主管Scrum主管促进 Scrum过程,他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导(由于他们是自我组织的),而是负责屏蔽外界对开发团队的干扰。

Scrum主管确保Scrum过程按照初衷使用。Scrum主管是规则的执行者。开发团队负责交付产品的团队。由5至9名具有跨职能技能的人(设计者,开发者等)组成的小团队完成实际的开发工作。

Scrum中这三种角色是精心设计的,符合我们管理理论组织的理论,一个产品只能有一个Product ower符合我们的统一指挥原则,Scrum Master的主要工作是去除那些影响团队交付冲刺目标的障碍,也是为了项目实现创造环境等等。 在实施Scrum的时候,所做的第一件事情就是打乱特定于组件的团队,创建竖井式的团队。它减少了诸如“我们没法完成这个条目,因为我们在等server那帮家伙完成他们的工作“之类的情况发生.

3.Scrum中的会议

敏捷的宣言中包括个体与交互胜过过程和工具,Scrum中对于会议分为:计划会 (Sprint Planning Meeting), 每日立会 (Daily Standup Meeting),评审会(Review Meeting),回归会(Retrospective Meeting)。

 计划会 Sprint Planning Meeting:在每个冲刺之初,由产品负责人讲解需求,并由开发团队进行估算的计划会议。

 每日立会 Daily Standup Meeting:团队每天进行沟通的内部短会,一般包括完成了什么?是否遇到了障碍?即将要做什么?因一般只有15分钟且站立进行而得名。

 评审会 Review Meeting:在冲刺结束前给产品负责人演示并接受评价的会议,在这个会议上产品负责人确定完成了哪些工作和剩余哪些工作。

 回顾会 Retrospective Meeting:在冲刺结束后召开的关于自我持续改进的回忆。

这个和我们管理中控制息息相关,其中计划会指明了控制的方向,每日立会作为前馈控制,评审会可以作为现场控制,回顾会可以作为后馈控制,为我们下一步计划做参考,在会议中各个Sprint Backlog完成情况可以作为员工绩效考核的一个因素。

4.燃尽图

是一个公开展示的图表,显示当前冲刺中未完成的任务数目,或在冲刺订单上未完成的订单项的数目,通常燃尽图可以在每日立会展示,作为我们控制的一个辅助手段。

 

图3:燃尽图

Scrum文化建设

让团队坐在一起,从分共享信息,这些都切合我们管理学领导中激励的概念,满足员工工作个人成就的需要。

原文链接:http://www.cnblogs.com/Roping/archive/2010/12/21/1912525.html

时间: 2024-09-12 23:28:20

从管理学看敏捷开发Scrum的相关文章

敏捷开发的Scrum晨会实践

hursing所在的公司推行敏捷开发有两年多了,其中最让人直接感受到的就是scrum晨会.从生搬硬套到过程创新,令大家由抵触变成积极响应,这个过程真的很花费心思. 11年12月,hursing开始在自己的团队推行晨会.当时团队是刚成立的,很小,包括hursing自己在内的2个老人+2个新人,基本上hursing得指导所有的事情.事实上,团队小到不开晨会hursing也知道他们在做什么,所以晨会的内容更多是反馈他们遇到的还未解决的问题以及提出对编码过程的改善意见,然后hursing做一些指导和纠正

敏捷开发(XP, SCRUM)

敏捷方法的核心思想 敏捷方法是适应型(Adaptive),而非可预测型(Predictive).与传统方法不同,敏捷方法拥抱变化,利用变化来发展,甚至改变自己,最后完善自己.也就是要用重构(Refactoring)  敏捷方法是以人为本(people-oriented),而非过程为本(process-oriented).传统方法把开发者看作一个生产要素(分析员,测试员,程序员),拥有大量的中间产品(需求规约,设计模型等),而忽视了作为决定因素的人的特殊性.敏捷开发它只写有必要的文档,或尽量少写文

SCRUM敏捷开发规则一栏

敏捷.敏捷开发这类词最近很火!敏捷开发,就是指能够在需求迅速变化的情况下快速开发软件.我们接触最多的和敏捷相关的名词是:极限编程(XP).结对编程.测试驱动开发(TDD)等. 敏捷建模(Agile Modeling,AM),的价值观包括了XP的四个价值观:沟通.简单.反馈.勇气.此外,还扩展了第五个价值观:谦逊. 敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力.除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发. SC

[免费讲座] 成都软件技术沙龙 - 开启基于Scrum的敏捷开发全新征程讲座

成都软件技术沙龙4月28日活动议程 开启基于Scrum的敏捷开发全新征程 沙龙介绍: 成都软件技术沙龙成立于2008年,致力于发展成都地区软件事业,结交志同道合的软件界朋友,先后与微软.NET俱乐部,微软社区精英计划,天府软件园以及Scrum成都等机构合作,希望能团结成都地区软件同仁共同交流. 4月28日活动 – 开启基于Scrum的敏捷开发全新征程 时间:4月28日下午1点 – 5点 地点:成都天府软件园A区3号楼大会议室 讲座一:自下而上的敏捷实践 大纲: l 持续集成 l TDD l 自动

敏捷开发 PK 瀑布模型

   在去年12月底开始接触高校平台项目,到现在也快有小半年了.这次的开发不同以往.是以敏捷开发作为开发方式.以前都是遵循传统的瀑布模型,而新方式的开发思路直接与传统的开发思路来了个正面碰撞,擦出了阵阵"火花".     在一开始接触敏捷开发时,有些兴奋,有些期许,但是在真正用来做项目时,由于瀑布模式已经根深蒂固,再加上对需求不熟悉,对开发环境不熟悉,新方式的开发反而让人感到别扭,麻烦,甚至抵触.     由于对敏捷开发的不理解,大家也爆发了很多争论,不过也正是这些争论,引导我们逐步走

独立软件测试团队在敏捷开发中的几个特别实践

最近读了<测试人与敏捷团队的五个约定>,很是赞同.但发现其并没有紧扣敏捷开发测试的特点,这五个约定在传统开发中已经早有实践,也有相关论述.哪么在敏捷开发的测试方面有没有不一样于传统开发测试的并且是有效的实践? 从敏捷团队的组建上来说,敏捷团队并没有要求安排专门的测试人员,甚至于在某些的方法中不建议清楚的区分开发人员角色和测试人员角色. 本文讨论的是已经存在独立测试团队的情况,如何在敏捷开发中进行高效的测试. 实践1:测试保护开发 通过快速的自动化测试跟进开发,保证新增和修改不破坏已经获得的成果

为什么敏捷开发难于成功?

我大概是在2003年接触敏捷软件开发这个概念,之前无论是在学校的小打小闹项目,还是工作后的项目都是典型的瀑布式开发模式, 设计上自顶向下逐层分解, 设计.实现.测试.上线有条不紊.这不是一篇介绍敏捷开发的入门文章, 而是我学习.实施敏捷的一些感想, 如果你没有实践过敏捷软件开发, 不妨到文末看看书籍推荐. 我大概是在2003年接触敏捷软件开发这个概念,之前无论是在学校的小打小闹项目,还是工作后的项目都是典型的瀑布式开发模式, 设计上自顶向下逐层分解, 设计.实现.测试.上线有条不紊. 除了大学时

Leangoo:打造敏捷开发团队协作Saas平台

Leangoo是Scrum中文网旗下敏捷研发团队开发的一款敏捷团队协作工具.Leangoo创始人廖靖斌同时又是Scrum中文网的创始人兼CEO,是中国Scrum和敏捷开发的先行者.实践者,曾帮助大型跨国金融软件开发组织eBaoTech的研发中心导入了Scrum和敏捷方法,在大型软件项目研发领域经验丰富.2008年,廖靖斌创办了Scrum中文网,建立了线上学习社区和线下培训顾问平台,2014年,他带领团队做出了Leangoo看板协作软件.廖靖斌介绍,团队协作工具的市场规模达到千亿级,Leangoo

读《大规模敏捷开发实践》

初识敏捷开发是在2006年,那时愉快的加入了毕业后第二家公司,一家打算在中国开展外包业务的美国公司.其业务形式就是让在美国的总部接当地的IT单子,然后拿到中国来做. 中国分支的名字也很高大上,Global Development Center,其实当时在全球就这么一个分支机构,不知当初的美国老板怎么选上杭州,而不是上海的. 我那时对软件开发的流程认识基本停留在软件工程课本里描述的所谓瀑布式开发,在项目开始前拼命的收集需求,根据可怜的尚不明确的信息进行分析,争取设计出一套合理的逻辑抽象,并祈祷在开