背景 在某开发团队辅导的回顾会议上,团队成员对于优化估计具体方法上达成了一致意见.询问是否有什么具体的估计方法来做估算. 问题分析 回顾意见上大家对本次Sprint的效果做回顾,其中80%的成员对于本次Sprint的估算效果不满意,最终团队希望在下一个Sprint中,估算活动能有所改善. 经了解,团队目前的估算方法很简单,基本上是架构师和团队中有丰富开发经验的成员一言堂.估算的速度也很快.对于有些有疑问的需求,开发成员也是保持沉默,草草认领了任务. 团队迫切希望学习新的估算方法来优化目前的估算活

在新公司里,不懂软件工程的产品经理经常逼迫研发人员作出很不靠谱的时间估算.常见场景有下面这些: 需求未细化的情况下要求给出时间估算:比如,就一句话描述需要做一个什么样的功能,但是具体页面长什么样,交互是什么都没有定下来的时候,就要求给时间估算: 根据产品发布时间否定研发人员的时间估算:比如,我亲眼见过的,有个功能,五天之后要上线,研发估了7天:产品说,不行,重新估,五天后要发布:研发说,那这个功能七天做不完啊,加班也做不完啊.产品说,不行,那你想办法.于是研发妥协,好吧,估5天.产品很happy

转:http://www.open-open.com/lib/view/open1330413325514.html 最近把之前学习 Scrum 的资料整理为一篇文档,在接下来的团队和项目开发中,根据项目的情况引入 Scrum 的一些实践,提高团队成员之间的协作能力和项目的交付质量. 参考资料: <轻松Scrum之旅—敏捷开发故事>.<敏捷无敌> 硝烟中的Scrum 和 XP 火星人敏捷开发手册 Scrum-Checklists 维基百科:http://zh.wikipedia.o

近期研究前 Scrum 数据编译的文件,在接下来的团队和项目开发.项目根据该引入 Scrum 一些练习,提高团队成员和项目之间的交付质量的合作. 参考资料: <轻松Scrum之旅-敏捷开发故事>.<敏捷无敌> 硝烟中的Scrum 和 XP 火星人敏捷开发手冊 Scrum-Checklists 维基百科:http://zh.wikipedia.org/wiki/Scrum Scrum 工具 禅道 JIRA+GreenHopper Scrum 中的角色 Scrum Master--项目

[原文链接] 2016-05-03 Sting 敏捷开发作为目前流行的开发方法,为快速迭代提供了足够的理论支持,但敏捷开发方式不应该成为忽略文档和需求分析的过程,注意每个sprint的引入,任务燃烧,输出和回顾才是正确的敏捷过程. 最近把敏捷的资料整理为一篇文档,各位在接下来的团队和项目开发中,根据项目的情况引入 Scrum 的一些实践,提高团队成员之间的协作能力和项目的交付质量. Scrum中的角色 Scrum Master--项目负责人.项目经理 保护团队不受外界干扰,是团队的领导和推进者,

Scrum中的角色 Scrum Master——项目负责人.项目经理 保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程.与 Product Owner 一起将投资产出最大化,他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念. Team——开发人员.测试人员.美工设计.DBA等全职能性团队 团队负责交付产品并对其质量负责,团队与所有提出产品需求的人一起工作,包括客户和最终用户,并共同创建 Product Backlo

雪鸟会议 雪鸟会议前夕,James Grenning 在 Object Mentor 与 Robert C. Martin 一同工作,彼时组织雪鸟会议的 Bob 大叔盛情邀请 James,告知他会议的地点.James 听到地点后毫不犹豫地答应,并在脑海中踊跃欢呼"我要去滑雪!"毕竟,"雪鸟是世界上最好的滑雪场之一",没有人会拒绝雪鸟的诱惑.当然,除了滑雪这个最直观的念头,James 也曾与 Kent Beck.Ron Jeffries.Martin Fowler.W

计算机科学的诞生,是世人为了用数字手段解决实际生活中的问题.随着时代的发展,技术的进步,人们对于现实世界中的问题理解越来越深刻,描述也越来越抽象,于是对计算机软件的需求也越来越高,越来越复杂,变化也越来越频繁. 而软件技术的发展也是随着人们认知水平和抽象能力的不断提高,从面向过程编程,进化到了面向对象编程,再到日渐红火的面向服务的编程.伴随着思维的不断进步,实现软件的技术手段也随之变迁,从最古老的瀑布流程,到RUP统一过程,到敏捷软件开发,它们的出现无一不体现了需求,变化,效率,时间与质量的多方

现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...      为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解:所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助. 什么是敏捷开发?敏捷开发(Agile Development)是一种以人为核心.迭代.

一.    敏捷开发模式简介 敏捷是近年来软件研发领域很火的一个词,采用敏捷开发模式的研发团队是越来越多了,尤其是敏捷模式中的Scrum更是佼佼者大行其道,这表明敏捷模式确有其好处,能给企业带来效率的提升和成本的降低. 让我们看看大名鼎鼎的敏捷宣言,如下图所示: 大家对这段敏捷宣言都有自己的理解,我理解的其核心观点就是敏捷:能够快速,灵活的对变化做出响应,能够去掉繁文缛节,做到身轻如燕,专注于目标并在短期内产出成果物. 其实敏捷开发模式的提出和壮大也是被现实所迫.近年来软件需求变化越来越迅速,如

一晃眼,有两年没有写博客了,回顾前两年,各种奔波,各种忙碌,也有不少的收获.从今天开始,我要把这些收获都分享在这里. 其实这两年,对我影响最大的是开发流程.总所周知,一个好的开发流程,对于项目的进行,更新和维护都起着至关重要的作用.Scrum适用于一些开发周期长,需求不明确,或者随时间渐进明确,频繁更新的项目.然而,现在国内的一些公司,甚至一些大公司,都对这块不太重视,或者做得不够透彻.从而程序猿们天天加班,苦不堪言. 我们先来看张我通过实际经验画的图流程图,红色圈圈出来的是我认为比较容易忽略的

俗话说,自己写的代码,6个月后也是别人的代码……复习!复习!复习!涉及的知识点如下: 软件工程概念 敏捷开发过程scrum 一.什么是软件工程?请用一句话描述. 软件工程是一门研究性的学科:它用工程化的方法(联系建筑工程……),构建和维护有效的.实用的,和高质量的软件.简单来说,软件工程有三要素:过程+方法+工具,而软件工程是目标,软件过程是步骤,方法和工具是辅助. 二.那么,软件过程又是什么? 软件过程:首先它是一个框架或者说步骤,它是一个为建造高质量软件而所需要完成的任务的框架,即形成软件产

现在公司在使用敏捷开发模式进行日常的开发和管理工作,所以我看了下Ken Schwaber的<Scrum Guide>这本小册子,原本是英文的,这里提供中文的,以供日后复习和参考. Scrum简介 自从上世纪90年代初期,Scrum方法就已经应用于开发复杂的产品.本指南介绍了如何应用Scrum构建产品.Scrum不是一种过程,也不是一项构建产品的技术,而是一个框架,在这个框架里可以应用各种过程和技术.Scrum的作用就是让开发实践方法的相对功效显现出来以便随时改进,同时也为开发复杂产品提供了框架

现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP... 为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解:所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助.  什么是敏捷开发? 敏捷开发(Agile Development)是一种以人为核心.迭代.循序渐

看板的朴素思想:在制品(work-in-progress, WIP)必须被限制 WIP上限和拉动式生产 1. Scrum与看板简述 Scrum:组织拆分,工作拆分,开发时间拆分,优化发布计划,过程优化 看板:流程可视化,限制WIP,度量生产周期 2. Scrum和看板的关系 Scrum和看板都是过程工具 Scrum和看板只是给了一些明确的约束和指导,比如,Scrum的约束是固定时长的迭代和跨功能团队,看板的约束是要有可见的看板,队列大小要有约束 敏捷方法也被称作轻量级方法 3. Scrum规定了

为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解:所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助.  什么是敏捷开发? 敏捷开发(Agile Development)是一种以人为核心.迭代.循序渐进的开发方法. 怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,

我们组的PM是白杰,团队SCRUM 报告如下: 一.第一次spring会议内容: 1.确定所做项目的方向: 2.将调查问卷的结果进行统计,做了需求分析,大致了解了用户的想法: 3.确定了团队计划backlog: 4.将任务进行了认领分配: 5.每个人做出任了务项目估算: 二.每人认领的工作任务 崔鹏勃:  进入界面模块和设计期间各模块工作进度的采集   项目估算:48小时 白杰:     闹钟模块         项目估算:36小时 王炳午:  音频录制模块        项目估算:48小时 孔

根据Forrester Research今年第二季度的一份研究报告,在超过1000名专业开发人员中,采用敏捷模式进行软件开发的已经有10.9%采用了Scrum模式,在所有的敏捷开发模式中名列首位,而在所有的软件项目管理模式中,敏捷模式更是被35%的开发人员所采用.当然,研究报告为我们呈现的仅仅是一个统计学的观点,到底你的开发团队应该采用什么样的开发模式,这还是要根据各自不同的开发环境,人员构成,公司架构以及文化背景来决定.图1:Forrester 关于敏捷模式的调查报告 Visual Studi

以下的22个问题基本上涵盖了Scrum所涉及的内容,如果你能够正确回答出所有问题,那么你已经具备了作为一名Scrum Master的基本素质:当然,作为一名合格的Scrum Master,更重要的是你的经验,因为Scrum Master更多的需要和人打交道,很多实际问题的处理方式是必须在实践中才能体会的,有些还很微妙. 也许你对这些问题的答案不尽相同,这没有关系:这些答案是我根据自己的经验给出的,你所使用的方法和理解不一定一样,这也正是Scrum的特色之一,它帮助你找到最适合你的方式,它并不是你

本书作者是开发团队Leader,本书记录了他带领团队实施Scurm过程中的经验教训.全书短小精悍,言简意赅. 以下是书中一些观点信息的摘抄: 1:Nokia总结出的迭代开发的基本要求:1.1:迭代要有固定时长,不能超过六个星期:1.2:在每一次迭代的结尾,代码都必须经过QA的测试,能够正常工作: 2:Nokia的Scurm标准:2.1:Scurm团队必须要有产品负责人,而且团队都清楚这个人是谁:2.2:产品负责人必须要有产品backlog,其中包括团队对它进行的估算:2.3:团队必须要有燃尽图,

SCRUM 流程的步骤2: Spring 计划 1. 确保product backlog井然有序.(参考示例图1) 2. Sprint周期,一个冲刺周期,长度定为两周,本学期还有三个冲刺周期. 3. 确定Sprint目标. 3.1 产品负责人概括产品backlog,对sprint目标进行总体介绍,讲清他认为最重要的故事. 3.2 团队从最重要的故事开始逐一讨论每个故事,估算时间,理清每个条目的含义,在必要的情况下拆分backlog条目.所有重要性高的backlog条目都要填写“如何演示”. 3.