49彩票集团首页-49彩票集团官网|官网首页

49彩票集团让大家拥有最好的账号使用功能,49彩票集团是为大家带来更加方便的使用途径,是因为在49彩票集团娱乐的玩家们越来越多,发展成为最受欢迎的网上体育娱乐公司。

敏捷项目管理同样可以把整个框架分为五个阶段

2020-03-27 作者:计算机网络   |   浏览(83)

作者介绍

一、敏捷的框架

对比PMP项目管理过程的五大阶段:启动、规划、执行、监控、收尾,敏捷项目管理同样可以把整个框架分为五个阶段,分别是:构想、推测、探索、适应和结束阶段。

  • 1、构想:确定产品的构想、项目范围、项目团队以及团队共同的工作方式
  • 2、推测:制定基于功能发布计划、里程碑和迭代计划,确保交付构想的产品
  • 3、探索:在短期内提供经测试的功能,不断致力于减少项目风险和不确定性。
  • 4、适应:审核提交的结果、当前情况以及团队的绩效,必要时做出调整。
  • 5、结束:终止项目,交流主要的学习成果并庆祝。

49彩票集团 1

敏捷项目管理阶段.jpeg

一、敏捷的原则:

除了敏捷宣言之外,宣言的发起者还为敏捷方法提供了12条指导原则

  • 1、我们的最高目标是通过尽早和持续地交付有价值的软件/产品来满足客户。
  • 2、即使在项目开发的后期,仍欢迎对需求提出变更。敏捷过程通过拥抱变化,帮助客户创造竞争优势。
  • 3、要不断交付可用的软件,周期从几周到几个月不等,且越短越好。
  • 4、在项目过程中,业务人员与开发人员要每天在一起工作
  • 5、要善于激励项目人员,给他们所需要的环境和支持,并相信他们能够完成任务
  • 6、团队内部和各个团队之间,最有效的沟通方法是面对面的沟通。
  • 49彩票集团,7、可工作的软件是衡量进度的首要指标
  • 8、敏捷过程提倡可持续的发展。项目方、开发人员和用户应该能够保持恒久、稳定的进展速度。
  • 9、对技术卓越和好的设计的持续关注有助于增强敏捷性。
  • 10、尽量做到简介、尽最大可能减少不必要的工作。这是一门艺术。
  • 11、最佳的架构、需求和设计出自自组织团队。
  • 12、团队要定期回顾和反省如何能够做到更有效,并相应地调整团队的行为

朱志,建设银行厦门开发中心技术管理处负责人,目前主要负责大数据技术平台规划和技术资产管理。在银行IT项目管理、数据分析、数据治理以及架构设计领域工作了十五年,曾领导过建总行人力资源项目、ERP报表项目、分行数据分析平台ODSB项目、管理会计项目以及新一代信息系统数据分析平台的建设。

二、敏捷的常见问题解答

二、敏捷的原则的解读

现在各种大数据会议充满了AI的主题,还好仍有人强调数据敏捷性,要不我今天分享的Data APP敏捷实践话题就落伍了。敏捷诞生也有二十多年了,经历了两次高潮,何时提敏捷都不落伍。

(一)、对于敏捷中文档的度,我们应该如何把握?什么样的文档是需要的,什么样的文档可裁剪?

答:

有价值的文档是需要的。什么样的文档有价值? 一是客户需要的文档,比如在软件行业的随机手册、使用说明书、用户手册等;二是有人维护的文档。例如,在有的项目中,代码频繁变更,但是对应的详细设计就没有变更,导致详细设计没有被维护,也就失去了存在的价值。对于类似的文档,在敏捷中认为都是可以裁剪的,前提是确保输出的可交付成果不变形,满足预期的标准和要求。

(一)、我们的最高目标是通过尽早和持续地交付有价值的软件来满足客户

  • 第一点 是要满足客户需求。如果我们只创造了完美的项目计划和文档来让公司的项目管理办公室(PMO)或者质量保证工程师(QA)满意,那么我们就是失败的。我们关注的焦点应该是客户,客户满意是衡量项目成功的关键因素。
  • 第二点 是要尽早和持续交付。我们必须让我们的项目和项目团队尽早交付及频繁交付,鼓励和支持团队成员认同这个观点。早起发现错误会有足够的时间去修正,修正的成本也是最低的。
  • 第三点 是要交付有价值的软件,而不是未完成的工作产品、工作分解结构(WBS)术语、文档或者项目计划。应该有具有目标驱动,对软件项目而言,目标就是可工作的软件;对于其他类型的项目而言,目标是产出的产品和服务或者成果。

今天介绍的这个Data APP基本目标是支撑100,000+用户、120亿条数据、TB级存储、秒级响应。比起性能,更受用户欢迎的功能在于支持不同机构或业务条线发布数据,支持不同岗位不同角色不同用户按需订阅,而这些丝毫不用技术人员介入。

(二)、敏捷宣言提出"客户合作胜过合同谈判",针对不断变更的需求如何签订敏捷的合同?

答:

敏捷的合同需要签订,但是签订合同的方式与传统的瀑布式合同签订方式稍有不同。根据DSDM的方法,敏捷合同的生效必须是业务人员与开发人员一起工作。

(二) 即使在项目开发的后期,仍欢迎对需求提出变更。敏捷过程通过拥抱变化,帮助客户创造竞争优势。

如果是为了交付更好的成果和更高优先级的产品,那么变更对项目就是好事。对于传统项目管理而言,变通通常被认为是负面的,这意味着项目范围蔓延和偏离了项目的计划,需要引发变更成本。所以传统项目中变更控制流程非常严格,只有最高优先级的更变可以被批准。在传统项目中,项目团队大量的时间和精力都用在记录和管理变更请求上。

在软件项目或者其他类型的有高变更比率的项目而言,严格的变更管理流程会带来很多问题。相比而言,敏捷项目管理允许变更的发生,比如极限变成(XP)提倡"拥抱变化"。敏捷使用轻便、高可视化的方法来处理待办事项的优先级排序的变更。

看这个逻辑架构图,Oracle、GreenPlum、Teradata不同系列的数据库产品计算出来的各种指标,通过ETL技术把各种数据源源不断地汇入公共访问区,接着通过Redis、HBase和Kylin等时下流行的开源技术实现两级缓存以应对海量的移动用数访问。移动端采用了HTML5技术屏蔽设备操作系统差异,同时VUE.js和ECharts等技术实现了数据展现和自动推送。通过参数化设计将业务运营从开发中分离出来,让工程师更加关注如何支持好业务数据和用户自然增长。

(三)、敏捷拥抱变化,是否在任何一个时间点客户端都可以提出变更

敏捷项目聚焦于客户价值,所以只要是可以给客户带来竞争优势的更变,都可以进行,所以在任何一个时间点都应该允许客户提出变更。

高效处理变更可以帮助项目团队把更多的时间投入在产品开发商,而不是处理变更商。敏捷方法就是利用易理解、高可视的方法来处理变更,使项目更加灵活。

这种自我生长的APP模式,就像一颗树苗,依靠树根从土壤源源不断地吸收养分,再通过树干以及树枝生出树叶,通过这种架构的孕育,树苗长成参天大树不过是时间问题。

(四)、团队既要保证迭代的不被干扰,又要响应变更,岂不是矛盾

虽然客户在生命周期的任何一个时间点上都可以提出变更,但是团队并不会立刻响应变更,通常会在迭代计划中梳理每个用户故事的优先级,根据价值排序,将需要增加的需求可以加入产品待办事项;同样,价值相对比较低的可以排到产品代办事项的最低端或者直接删除。变更时,需要考虑敏捷的合同,如果要维持合同的不变,增加一个故事,就要拿走一个等价故事点数的故事。

(三) 要不断交付可用的软件,周期从几周到几个月不等,且越短越好。

虽然我们倡导越早反馈越有价值,但是每个人都会要求完美,把工作长时间抓在受伤反而会适得其反。最好的方式是尽早并且要经常得到对工作产品的反馈,以避免在错误的道路上越走越远。

本条准则重点强调了将工作产品投入到测试环境从而获得反馈。频繁测试和反馈对敏捷项目非常重要,团队需要根据已完成的产品反馈来确定如何继续。当然,反馈中也会存在变更的要求。

短时间的交付有利于团队和业务人员之间的互动。频繁的交付使得项目团队可以得到更多的商业机会和反馈。通常在演示会上,团队会得业务优先级高的变更请求。这都是有价值的。

注:树型架构,出处参见高焕堂 Annpping Kao所著《思考软件,创新设计——A段架构师的思考技术》第5页“1.4软件的复杂时本质性的-架构师从复杂设计出简单”)

(五)、在原则4中提出业务人员与开发人员每天要在一起工作,这在实际中是不可能实现的,业务人员通常都比较忙,不可能参加到乙方的开发中,这样如何确保可以一起工作?

在现实中,业务人员的确不太可能与开发人员每天一起工作,所以通常在团队内部会有一个角色代表客户,可以是PO,也可以是BA,这可以根据每个组织的的不同进行设定。这个人在一整个团队中代表客户,需要频繁跟客户沟通,理解和挖掘客户的真实业务需求

(四) 在项目过程中,业务人员与开发人员要每天在一起工作

频繁的演示是业务代表和开发人员在项目共同工作的一个很好的切入点。在实际工作中,开发人员每日和业务代表采用面对面的沟通往往比较困难,但是值得去推动。面对面的交流可以更好的观察肢体语言,相比而言,文档、电子邮件或者打电话都不能有效地传递信息。

每天和业务代表共同工作,开发团队对业务的学习程度和速度都远超在需求收集会议中对业务的理解。因此,开发团队可以提出多种有价值的解决方案来代替直接的业务申请。业务代表也可以学习到那些类型的解决方案或成本高或者开发速度慢,那些功能成本低,进而通过反馈来调整需求。

如果业务代表和开发团队不能每日在一起工作,那么也应该尽量将两个工作小组安排在一起,没两天或者频繁的互动参与工作。有些团队使用"代理客户"(PO或者BA有时候就会成为代理客户),将"代理客户"作为商业代表的替身。

这个APP从什么时候开始蕴藏着如此巨大的能量?

(五) 要善于激励项目人员,给他们所需要的环境和支持,并相信他们能够完成任务

正如软件估算模型性成本模型(COCOMO)所显示的,好的团队成员和好的流程工具,这两个因素影响之间的比例关系是10:1。这意味着员工对一个项目能否成功会起到更重要的作用,而不是工具和流程。

显示中,我们虽然不能确保每个团队都是被精挑细选出来的理想组合,就像中国跳水团队——梦之队,但是我们可以尝试去激发团队成员,让他们成为一个可以自我驱动的理想团队。自组织团队作为项目的一个重要因素,一旦员工开始自组织和计划工作,其工作会更加高效。敏捷方法主张将团队从微观管理和甘特图中的任务式管理中脱离出来,聚焦工作技巧和团队协作从而提高生产率。

知识性项目也包含有特殊经验和技能的成员。如果开发团队可以更好地做出日常决定以及处理好计划的工作,那么项目团队中每个成员都会是专家,可以为项目的成功予以支持。

1962年9月12日,肯尼迪发表了著名的月球演说之后,NASA硬着头皮开始登月,阿波罗1号竟然在地面就爆炸了,经历多次失败,直到阿波罗8号首次完成了载人环行月球一周并返回地球之后,NASA才确信人类登上月球只是时间问题。很多人知道阿波罗11号登月成功,却不知道在肯尼迪航天中心纪念的是阿波罗8号,因为这个阿波罗8号是工程师所怀念的成功原型。是的,这几个简单的界面就是Data APP的“阿波罗8号”,接下来重点介绍如何通过敏捷开发打造出这个“阿波罗8号”。

(六) 团队内部和各个团队之间,最有效的沟通方法是面对面的沟通。

写文档可以很好地做记录,但是速度缓慢会造成高成本。面对面的沟通可以快速传达大量的信息,包括表情和肢体语言。梅拉宾法则曾经提出:“在信息沟通中,除了语言的表达方式外,信息还可以许多方式表达。说话的内容尽占用7%,语音语调占38%,肢体语言占55%”。

在面对面的会谈中,问题可以立刻得到解决,而不是被暂时搁置或者过一段时间再被反馈。但是面对面会谈不能用于所有的沟通场所,是提倡尽量遵循。随着团队规模的扩大,面对面的沟通很难实现,此时我们就需要引入适当的文档要求。

知易行难第一步,按图索骥。

(七) 可工作的软件是衡量进度的首要指标

首先,要将可工作的软件作为项目的关注目标,努力将创建文档等活动作为支持目标的手段而不是首要任务。如果产品不能工作,就不能被认为已完成了。强调"可工作"的软件是为了提醒团队功能特性只有被接受才算完成。项目是以结果为导向的,中间过程的可交付成果(比如文档和部分完成的工作)都不会得到外部的认可,被客户使用的产品才是项目的关注点

大数据这条路上,一定要看每年发布的大数据蓝图。这张图的使用诀窍,在于要透过复杂的表象按照大数据技术的抽象分类来寻找可能的技术方向。

(八) 敏捷过程提倡可持续的发展。项目方、开发人员和用户应该能够保持恒久、稳定的进展速度。

一些快速应用开发技术并非已达到可持续开发的水平,很可能会由于工作时间过长而导致工作人员过度疲劳,从而造成不必要的错误。针对周期长且紧张的开发阶段,敏捷方法认为应保持稳定的进展速度,其价值在于允许团队成员维持工作和生活的平衡。可持续的速度不仅对团队有好处,也会对整个组织带来益处。过程的工作时间会导致员工辞职,组织也会失去很多资源。重新雇佣和整合新的成员会是一个缓慢且高成本的过程。

因此,保持恒定的开发速度可以创造一个更加和谐、高效的团队,较小的压力会提高工作效率、促进团队之间的协作。

这个项目刚开始的时候,我们想法很简单,采用H5技术屏蔽IOS和Android,用ECharts实现移动端数据可视化,沿用数据平台公共访问区已有的GreenPlum。

(九) 对技术卓越和好的设计的持续关注有助于增强敏捷性。

当我们想开发团队可以努力工作并且交付大量有价值的产品时,我们也必须注意保持设计的清晰、高效和变更的灵活性。精益求精的技术和良好的设计会使产品或开发团队更好地理解与更新设计。

在软件世界中,一旦编程的基础紊乱,组织将丧失对变更响应的能力,失去其敏捷性。因此,我们需要给开发团队足够的时间进行重构,重构使编程更加稳定从而维持更长的时间。

第二步,按部就班。

(十) 尽量做到简洁、尽最大可能减少不必要的工作。这是一门艺术。

在软件行业,多达60%的功能很少被使用或者从来没有被使用过。因为很多功能并没有被使用,而且复杂的系统会隐匿很多不确定性,所以敏捷方法专注于简洁,只完成必要的元素。
复杂的项目耗时长,暴露的风险相对比较多,从而带来更多潜在的失败风险。因此,敏捷方法寻求"允许工作的最简介产品",并将其推荐为首先的解决方案。这种方法在减轻风险的同时也帮助团队建立信息。

一项技术要成为企业的选择,必须经历一系列的测试,从功能到非功能,根据预先设定的指标进行匹配,找到最合适的。入选企业级技术产品目录后,再逐步推广,产生规模效应。选好的技术不涉及商业产品,时间紧任务重,赶快出活才是硬道理。

(十一) 最佳的架构、需求和设计出自自组织团队。

人们喜欢自我组织,因为他们通过自己的方法最佳地完成工作、协调关系以及适应环境,同时他们也非常理解和支持这种方式。

为什么最佳架构、需求和设计来自项目团队,而不是来自项目团队外部的组织中的最佳架构师、商业分析师和设计师?因为外部的建议可能存在很多优点,但是如果技术团队对其难以实施也是一个问题。

自组织团队由更高的所有权以及对架构、需求和设计的荣誉感,团队所创建的观点如果已经通过审查,就不要再去验证。相反,如果一些观点来自团队外部,那么需要团队来验证是否可以成功使用,这又将是一个富有挑战的任务。

此外,自组织团队更加贴近项目的技术细节,因此最适合去识别实施中的问题。虽然可以尝试采纳外部的建议,但是敏捷依然采用团队的能力去打造最好的架构、需求和设计。团队成员是最了解项目的人,所以最应该去授权参与项目。

本文由49彩票集团发布于计算机网络,转载请注明出处:敏捷项目管理同样可以把整个框架分为五个阶段

关键词: