敏捷项目管理

敏捷软件开发揭秘

人走茶凉 提交于 2020-04-03 10:27:22
前言 本篇文章将对敏捷软件开发的方法论及其应用做基本介绍,将描述团队是如何通过协作来完成共同目标的。本篇文章不仅仅适合软件开发人员阅读,同时也适合于团队负责人、项目经理、产品经理、开发经理、测试人员、QA经理、QA工程师、技术文档专员、用户体验设计师等任何涉及软件交付的人员。文章重点介绍技术团队是如何通力协作来计划、构建和交付软件的。但文中没有具体代码的编写,也没有对特定技术的介绍,并且也不会介绍任何微软技术。希望这篇文章可以帮助你改善专业性和团队的效率。 背景 Winston Royce 瀑布模型 引自 1970 年的 IEEE 论文 "Managing the Development of Large Software Systems" 该论文中阐述了,在计算机程序设计开发过程中,无论软件的规模和复杂度如何,都会经过两个必不可少的阶段:软件分析和编码。而许多其他额外的开发步骤,虽然也是需要的,但却都没有像软件分析与编码一样对最终产品作出最直接的贡献,反而增加的开发过程的支出。 然后,Royce 介绍了需要额外的将 5 个重要的步骤添加到整个开发流程中,用于最大化地消除软件开发中的风险: 步骤1:程序设计优先 一个软件程序的初步设计阶段,将被插入到软件需求和软件分析阶段之间。程序设计人员将在此阶段开始进行软件整体的初步设计,包括设计、定义和指定数据处理模型,定义系统间的接口

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

与世无争的帅哥 提交于 2020-03-13 15:05:43
成都软件技术沙龙 4 月 28 日活动议程 开启基于 Scrum 的敏捷开发全新征程 沙龙介绍: 成都软件技术沙龙成立于2008年,致力于发展成都地区软件事业,结交志同道合的软件界朋友,先后与微软.NET俱乐部,微软社区精英计划,天府软件园以及Scrum成都等机构合作,希望能团结成都地区软件同仁共同交流。 4 月 28 日活动 – 开启基于 Scrum 的敏捷开发全新征程 时间: 4 月 28 日下午 1 点 – 5 点 地点:成都天府软件园 A 区 3 号楼大会议室 讲座一:自下而上的敏捷实践 大纲: l 持续集成 l TDD l 自动化测试 l 结对编程 l 重构 l Scrum 讲师介绍:殷钧钧 Joey Yin任职于Active Network,担任企业架构师。业余白帽子。专注的领域主要有:分布式系统架构;敏捷开发实践;应用开发安全。个人博客:http://www.unclejoey.com, 微薄:http://weibo.com/joeyyin 。业余时间主要在OWASP, Wooyun, Agile Group等开源社区和公益组织出没。 讲座二:Scrum 软件研发过程经验分享 这不是咨询公司的Scrum,缺乏生气的抽象,也不是书本上的Scurm,过于笼统到无味,这是某成都公司7个月来,从尝试到全部项目都迁移过来的一个落地的过程,作为操刀人,讲师将会讲述推动中的选择

敏捷软件开发与传统软件工程概述比较

╄→尐↘猪︶ㄣ 提交于 2020-03-08 06:13:35
敏捷软件开发与传统软件工程概述比较 翁松秀 北京航空航天大学计算机学院   摘要: 软件工程的开发过程中有两种截然不同的管理和开发体系,一种是基于 “瀑布模型”的预设性传统软件工程,另一种是轻量级的适应性敏捷软件开发,本文简单阐述传统软件工程的开发方法与敏捷软件开发的异同,并通过“瀑布模型”和 SCRUM 方法的比较来探析传统软件工程与敏捷软件开发的异同。最后得出结论,把传统软件工程和敏捷软件开发相结合,将软件架构“颗粒化”,在简单可快速交付的敏捷软件开发中嵌套系统的传统软件开发方法,实现预见性和适应性折中。 关键词 :敏捷软件开发;传统软件工程;瀑布模型; SCRUM 方法;嵌套;颗粒化   0 前言   随着计算机的发展,对软件的需求越来越大,软件的规模也变得越来越大,结构越来越复杂,软件开发管理困难而复杂,在这个 “软件危机”背景下产生的传统软件工程,用工程化的方法构建和维护有效和高质量的软件。暂时解决了软件的兵荒马乱时代,但随着社会和科技的发展,对软件的需求变化越来越快,传统的软件工程很难再适应瞬息万变的客户需求,敏捷软件开发应运而生,其轻量级、简单、可快速交付、适应性强收到开发团队的青睐,与传统软件工程并肩,形成软件工程中的两大开发体系。   1 传统软件工程 1.1 传统软件工程概述   基于 “瀑布模型”的传统软件开发方法中,以软件架构 (software

Scrum 学习笔记

我怕爱的太早我们不能终老 提交于 2020-03-06 18:53:58
Scrum 学习笔记 敏捷火了非常长一段时间了,可是一直没有机会实践,如今開始组队实践了,哈哈,先好好研习下规则~~ 什么是 scrum Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发周期包含若干个小的跌代周期,每一个小的的跌代周期称为一个 Sprint,每一个 Sprint 的建议长度2到4周。在 Scrum 中,使用产品 Backlog 来管理产品或项目的需求,产品 backlog 是一个依照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum 的开发团队总是先开发的是对客户具有较高价值的需求。在每一个 Sprint 中,Scrum 开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint 中挑选的需求经过 Sprint 计划会议上的分析、讨论和估算得到一个 Sprint 的任务列表,我们称它为 Sprint backlog。在每一个迭代结束时,Scrum 团队将交付潜在可交付的产品增量。 敏捷价值观之 敏捷四宣言 • 个体与交互重于过程和工具 • 可用的软件重于完备的文档 • 客户协作重于合同谈判 • 响应变化重于遵循计划 敏捷价值观之 敏捷十二原则 • 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。 • 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。 •

Scrum和项目流程总结

走远了吗. 提交于 2020-03-06 18:50:59
最近所在的两个项目组都用到了敏捷开发Scrum,之前对它的理解更多的停留在自己工作涉及到的一些具体形式,比如Daily Scrum,工作量的评估等。对于Scrum是什么,为什么要用Scrum,一直没有去思考过这些问题,更没有做过深入的学习。前几天看到园子里的一篇关于scrum的博文( http://www.cnblogs.com/speeding/archive/2012/10/30/2746532.html ),收获颇多,加深了对Scrum的理解。 Scrum的出现,我的理解是为了适应软件需求的频繁变化,以及满足客户尽快看到软件产品的需求。从网上搜索了一下对Scrum的定义,摘录了一个觉得解释最好的关于Scrum的定义如下: Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint

0502团队项目 SCRUM团队成立

被刻印的时光 ゝ 提交于 2020-03-06 18:47:46
Scrum团队成立 团队名称:对不对?队 团队目标:短期目标,完成O2O模式的第一个平台 团队口号:我们都不是神的孩子 团队照: 角色分配 产品负责人: 许佳仪。决定开发内容和优先级排序,最大化产品以及开发团队工作的价值。 Scrum Master: 卓宇靖。负责确保团队遵循 Scrum 的理论、实践和规则。Scrum Master是团队中的服务式领导。 PM项目经理:赖文亮。团队的领导, 带领、平衡、推动、激励、目标达成、交涉,平等工作之外管事也管人。 用户:柯晓君。从最终使用者的角度把握所开发软件的用户体验,团队工作必须响应并满足用户需求。 团队项目选题 约拍:O2O模式 uber模式,美团外卖,百度外卖......做成一个平台,服务提供者和服务需要者通过我们的平台达成服务交易。流行的获得巨大风险投资的可能。 《构建之法》之第6、7章读后感 第六章: 第六章主要介绍了敏捷流程,它是一系列价值观和方法论的集合。 敏捷的步骤如下: 第一步:找出完成产品需要做的事情——Product Backlog; 第二步:决定当前的冲刺(Sprint)需要解决的事情——Sprint Backlog; 第三步:冲刺(Sprint); 第四步:得到软件的一个增量版本,发布给用户。 第七章: 第七章主要介绍了MSF, MSF是一套大型系统开发指南,它描述了如何用组队模型

第三次作业

半城伤御伤魂 提交于 2020-03-06 18:42:07
Scrum敏捷开发笔记 一、什么是敏捷开发? 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 1.什么是敏捷? 软件开发过程是指设计软件开发过程中涉及的一系列活动,指导开发组一步一步的进行软件开发。 包括传统的瀑布过程、螺旋过程、原型过程、敏捷过程等。敏捷则是一类过程的统称。 之所以把他们都称之为敏捷,是因为它们有共同的特点。敏捷过程讲究快速迭代快速试错,将一个大的项目分解成一个一个独立的小项目,每个项目实现一定的功能,每个项目的成果物都是可以运行的软件。经过多次迭代之后完成整个项目。 2.关于敏捷方法 敏捷方法是试图通过小型的、自我管理的团队用短小的合作发布周期来鼓励迭代式软件开发方法。软件的质量贯穿敏捷软件开发每一个阶段,且非常重要,并提出很多关键的规则来保证能在每一个迭代周期内及早是的发现并及时相应消灭开发过程中出现错误。 在敏捷方法提出理念下,衍生出了很多不同敏捷软件开发方法。 如Scrum、极限编程[EXtreme Programning XP],测试驱动开发[Test Driver Development],重构和持续集成。Scrum是敏捷过程中比较著名的一个过程框架,被很多团队采用。 二、Scrum模型 3个角色 Product Owner: 产品负责人,主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容

第三次作业

匆匆过客 提交于 2020-03-06 18:18:53
第三次实验 以下是我对Scrum的心得体会: (一):什么是Scrum 个人也看了好多关于介绍什么是Scrum,其实我总结下来就是一个团队协作的敏捷开发,注意团队是一个重要词汇,它讲究每个人去完成每个人的任务,从而达到共同的目标。用标准的语言来说,Scrum 是一种团队管理工作的方式,其将工作分解为较小的工作单元,并在周期性固定的时间段内持续地交付工作单元。 (二):Scrum的特点 首先,Scrum它有3 种角色(Roles) 开发团队(Development Team):一个自组织的跨技能的小团队,承担实际开发工作,负责在周期性的迭代中不断的交付有价值的工作。开发团队通过集体共同交付价值,而不是通过个体。 产品负责人(Product Owner):产品负责人是产品最终用户的代表,负责确定产品的方向和愿景,定义产品发布的计划、内容和优先级。Product Owner 要不断的与开发团队沟通,保证团队在做从业务角度来说最正确的事情。 Scrum 教练(Scrum Master):Scrum 定义了一个全新的全职工作角色 Scrum Master。Scrum Master 负责确保团队合理的运作 Scrum,帮助团队移除实施中的障碍。 Scrum特点 适于在不确定性高的环境中开发复杂产品; 简洁但有效; – 易于学习和掌握; – 能够在开发进程中不断检查,并作出相应调整;

Scrum模拟微信看一看“疫情专区”的敏捷开发过程

喜夏-厌秋 提交于 2020-03-03 15:44:54
无论作为产品用户还是管理咨询顾问,都非常非常喜欢微信。自认感情比较克制属于“高冷”挂,但从很多方面都太佩服太崇拜张小龙了(新书里微信也会是最喜欢的案例之一,真的不只是一个产品而已,很多方面都太牛了)。不知道大家是否有注意到,在疫情爆发后,微信的响应大概最快速也相对最到位的了,看一看立马有了“疫情专区”(不知道官方名称是什么,以下暂以此代称),对于了解疫情整体数据和最新动态都很有帮助,真是觉得太棒了。 之前了解到微信也是使用敏捷开发,最近也在筹备ASM实战课程和Scrum咨询服务产品,奇葩开个脑洞用Scrum YY一下看一看“疫情专区”开发过程,也通过这种方式简单科普一下敏捷开发基本理念与价值以及Scrum的流程实践吧。 本文包括4部分: 敏捷开发基本理念与价值 敏捷开发实践方法 Scrum的3个角色与5个活动 如何通过Scrum实现微信看一看“疫情专区” 敏捷开发基本理念与价值 敏捷开发根源于适应性项目管理和精益开发,相较于传统基于“预测+规划+控制”的瀑布式开发方式,能够适应需求变化的风险,及时理解与响应客户需求,通过周期迭代交付可工作的增量产品的方式,增强项目管理灵活性与可预测性,并基于团队责任制的工作理念运行,借鉴精益管理理念与优秀实践,流程效能高,能够显著优化开发成本,提升产品质量与竞争力、客户满意度、团队及干系人满意度。 就像微信看一看的“疫情专区”

敏捷项目管理-用户画像

邮差的信 提交于 2020-03-01 20:46:22
用户故事:卡片、对话和确定;基于三个步骤进行开展。 举例:项目:A公司是一家检测设备公司下的子公司,主要服务对象是制造业,由于早起软件系统陈旧,导致客户满意度很低。公司决定,面向制造业的痛点,重新开发一款迎合当下市场的软件,应包含:企业基础架构、生产作业管理、生产质量管理、生产过程监控、能耗管理等等,需要在3个月内上线。幸运的是,客户愿意指派对接人员与研发人员一起规划系统。 在某周的早上,客户、产品负责人、研发小组、Scrum教练在一个单独的环境中,展开对系统需求的研讨和系统功能的确定。 识别客户: 每人面前摆放一堆空白卡片,接下来,所有成员开始绞尽脑汁在卡片上书写用户角色卡片: BOSS 厂长 线长 qc 一线员工 巡检员 品质负责人 组装工 ..... 直到所有人无法再想起其他角色,下一步将所有用户角色卡片进行汇总,去除相同的角色,过程略...... 又过了许久....... 角色确定为: BOSS 厂长 线长 qc 一线员工 ...... 角色建模:接下来,团队考虑为每个角色卡上添加详细描述。详细描述将根据领域和软件类型的不同而有所不同,需要考虑一下因素: 用户使用软件的频率; 用户在这个专业领域的专业水平; 用户对电脑和软件熟悉程度; 用户对正在开发的软件的熟练程度; 用户使用软件的真正目的。 ........ 基于上面的团队对每个角色卡片讨论