精华内容
参与话题
问答
  • 敏捷项目管理流程-Scrum框架最全总结!

    万次阅读 多人点赞 2017-01-20 21:21:01
    Scrum Master——项目负责人、项目经理 保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化,他确保...
    Scrum中的角色
    Scrum Master——项目负责人、项目经理
    保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化,他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。

    Team——开发人员、测试人员、美工设计、DBA等全职能性团队
    团队负责交付产品并对其质量负责,团队与所有提出产品需求的人一起工作,包括客户和最终用户,并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。

    Product Owner——产品负责人、产品经理、运营人员
    从业务角度驱动项目,传播产品的明确愿景,并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目,在 Sprint 中帮助团队完成自己的工作,不干扰团队成员,并迅速提供团队需要的所有信息。

    User——最终用户、运营人员、系统使用人员
    很多人都可能成为最终用户,比如市场部人员、真正的最终用户、最好的领域专家,也可能是因其专业知识而被雇佣的资讯顾问。最终用户会根据自己的业务知识定义产品,并告知团队自己的期望,提出请求。

    Manager——管理层、投资人
    管理层要为 Scrum 团队搭建良好的环境,以确保团队能够出色工作,必要的时候,他们也会与 Scrum Master 一起重新组织结构和指导原则。

    Customer——客户、系统使用人员、运营人员
    客户是为 Scrum 团队提出产品需求的人,她会与组织签订合同,以开发产品。一般来说,这些人是组织中的高级管理人员,负责从外部软件开发公司购买软件开发能力。在为内部产品的公司中,负责批准项目预算的人就是客户。


    Scrum中的产出物
    Product Backlog——Backlog 待开发项,积压的任务。
    产品 Backlog 包括了所有需要交付的内容,其内容根据业务需求的价值顺序排列,每个 Backlog 的优先级是可以调整的,需求是可以增减的,因此产品 Backlog 将根据不断增长来持续驱动维护。

    Sprint Backlog——Sprint 本意为“冲刺”,指迭代周期,长度通常是一至六周。
    在 Sprint 开始前,定义本次 Sprint 要讨论的“Sprint Backlog”,从中产生本次 Sprint 要完成的 “已定 Product Backlog”。
    已定 Product Backlog是 Sprint 计划会议的产物,它定义了团队所接受的工作量,在整个 Sprint 过程中它将保持不变。

    User Story、Task——用户故事、任务
    用 User Story 来描述 Sprint Backlog 里的项目,User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大,可能会导致对它的开发横跨几个 Sprint,此时就应该将这个 User Story 分解。为了能够及时,高效地完成每个 Story,Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时,保证在1个工作日内完成,如果 Task 的时间超过了8个小时,就说明Task的划分有问题,需要特别注意。

    障碍 Backlog——问题列表,积压的待处理事务。
    列举了所有团队内部和团队相关的和阻碍项目的进度的问题,Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。

    通用会议规则
    基本要求
    •每次会议都要准时开始、准时结束。
    •每次会议都采取开放形式,所有人都可以参加。

    会前准备
    •提前邀请所有必须参会的人,让他们有时间准备。
    •发送带有会议目标和意图的会议纲要。
    •预订会议所需的全部资源:房间、投影仪、挂图、主持设备,以及此会议需要的其他东西。
    •会前24小时发送提醒。
    •准备带有会议规则的挂图。

    会议推进
    •展开讨论时,会议的推进人必须在场。他不能参与到具体讨论中,但是他需要注意讨论进程,如果讨论参与者失去重点,他还要将讨论带回正规。
    •推进人展示会议的目标和意图。
    •有必要时,推进人可以商定由某个撰写会议记录。
    •推进人可以记录团队的意见,或是教授团队如何自己记录文档;而且推进人可能会在挂图上进行记录,将对话可视化。
    •推进人会对会议进行收尾,并进行非常简短的回顾。

    会议输出
    •使用手写或挂图说明来记录文档,给白板和挂图上的内容拍照。
    •必须传达会议记录和大家对会议结果的明确共同认知。

    让团队坐在一起!
    •大家都懒的动,尽量让“产品负责人”和“全功能团队”都坐在一起!
    •互相听到:所有人都可以彼此交谈,不必大声喊,不必离开座位。
    •互相看到:所有人都可以看到彼此,都能看到任务板——不用非得近到可以看清楚内容,但至少可以看到个大概。
    •隔离:如果你们整个团队突然站起来,自发形成一个激烈的设计讨论,团队外的任何人都不会被打扰到,反之亦然。

    团队建设
    •Scrum 团队最佳人数控制在“5~9”人。
    •全职能性团队:开发组(后台开发、前端开发、测试人员——3~8人)、Scrum Master(项目经理)、产品负责人
    •兼职团队成员:美工、DBA、运维


    每日立会(Daily Standup Meeting)——建议下班前开始
    会议目的
    •团队在会议中作计划,协调其每日活动,还可以报告和讨论遇到的障碍。
    •任务板能够帮助团队聚焦于每日活动之上,要在这个时候更新任务板和燃尽图。

    构成部分
    •任务板、即时贴、马克笔
    •提示:ScrumMaster 不要站在团队前面或是任务板旁边,不要营造类似于师生教学的气氛。

    基本要求
    •成员:团队、Scrum Master
    •无法出席的团队成员要由同伴代表。
    •持续时间/举办地点:每天15分钟,同样时间,同样地点。
    •提示:团队成员在聆听他人发言时,都应该想这个问题:“我该怎么帮他做得更快?”

    会议输出
    •团队彼此明确知道各自的工作,最新的工作进度图。
    •得到最新的“障碍 Backlog”
    •得到最新的“Sprint Backlog”

    会议过程
    •团队聚在故事板旁边,可以围成环形。
    •从左边第一个开始,向团队伙伴说明他到现在完成的工作。
    •然后该成员将任务板上的任务放到正确的列中。
    •如果可以的话,该成员可以选取新的任务,交将其放入“进行中工作”列。
    •如果该成员遇到问题或障碍,就要将其报告给 Scrum Master。
    •每个团队成员重复步骤2到步骤5。

    每个人三个问题:
    •上次会议时的任务哪些已经完成?:把任务从“正在处理”状态转为“已完成”状态。——今天完成了什么?
    •下次会议之前,你计划完成什么任务?:如果任务状态为“待处理”,转为“正在处理”状态。如果任务不在 Sprint Backlog 上,则添加这个任务。如果任务不能在一天成,把这任务细分成多个任务。如果任务可以在一天内完成,把任务状态设为“正在处理”。如果任务状态已经是“正在 处理”,询问是否存在阻碍任务完成得问题。——明天做什么?
    •有什么问题阻碍了你的开发?:如果有阻碍你的开发进度的问题,把该障碍加入到障碍 Backlog中。——今天遇到了什么问题?

    注意事项
    •不要迟到
    •不要超出限制时间
    •不要讨论技术问题
    •不要转变会议话题
    •不要在没有准备的情况下参加
    •Scrum Master 不要替团队成员移动任务卡片,不要替团队更新燃尽图。
    •Scrum Master 不要提出问题,团队成员不要向 Scrum Master 或管理层人员报告。
    •如果不能出席会议,需要通知团队,并找一名代表参加。


    任务板
    •任务板集合了选择好的 Product Backlog 和 Sprint Backlog,并以可视化方式展示。
    •任务板只能由团队维护,使用不同颜色的“即时贴”来区分开发人员,或者在“即时贴”写上接受任务的姓名。
    •尽量使用大白板,也可以使用软件。

    任务板有4列:
    •选择好的 Product Backlog:按照优先级,将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。

    •待完成的任务:要完成一个故事,你得完成一些任务。在 Sprint 规划会议中,或是在进行当前 Sprint 中,收集所有特定 Backlog 条目需要完成的新任务,并将它们放入该列。

    •进行中的工作:当团队成员开始某个任务后,他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始,没有完成的任务都会放在该列中,并在上面做标记(通常是个红点)。如果某个任务在“待完成任务”列中所处时间超过一天,就尽量将该任务分为更小 的部分,然后把新任务放到那一列,移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成,就会得到一个红点标记,Scrum Master 就会记下一个障碍。

    •完成:当一个任务卡完成后,完成此任务的成员将其放入“完成”列,并开始选取下一张任务卡


    燃尽图
    •跟踪进度要由团队来完成,燃尽图的横轴表示整个Sprint 的总时间,纵轴表示 Sprint 中所有的任务,其单位可以是小时,人天等。一般来说,燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。

    •团队每天更新燃尽图。
    •如果燃尽图一直是上升状态,或当 Sprint 进行一段时间之后,Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几,就说明这个 Sprint 中的 Story 过多,要拿掉一些 Story 以保证这个 Sprint 能顺利完成。 如果Sprint 燃尽图下降得很快,例如 Sprint 刚过半时Y值已经接近0了,则说明这个 Sprint 分配的任务太少,还要多加一些任务进来。在 Sprint 计划会议上,如果团队对即将要做的任务理解和认识不充分,就很可能导致这两种情况的出现。(锻炼团队人员的自我估算时间)
    •燃尽图要便于团队更新,没必要让它看起来很炫,也不要过于复杂,难以维护。

    Release 燃尽图:记录整个Scurm项目的进度,它的横轴表示这个项目的所有Sprint, 纵轴表示各个Sprint开始前,尚未完成的工作,它的单位可以是个(Story 的数量),人天等。


    Sprint规划会议——第一部分(上午)
    会议目的
    •该会议的工作以分析为主,目的是要详细理解最终用户到底要什么,产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束,团队将会决定他们能够交付哪些东西。
    •产品负责人在会前准备:条目化的需求(用户故事),优先级排序,最近1~2个迭代最希望看到的功能。会前准备至关重要,可帮助产品负责人理清头绪,不至于在迭代期内频繁提出变更、增加或删除故事。

    基本要求
    •迭代计划会在每个迭代第一天召开,目的是选择和估算本次迭代的工作项。
    •只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。

    构成部分:
    •经过估算和排序的 Product Backlog。
    •挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔。
    •假期计划表、重要人员的详细联系信息。
    •参会成员:团队成员、Scrum Master、产品负责人

    持续时间:在 Sprint 中,每周该会议占用时间为 60 分钟,在早上召开该会议,这样还有可能在同一天召开 Sprint 规划会议的第二部分。

    会议输出
    •选择好的 Product Backlog 条目。
    •各个 Backlog 条目的需求。
    •各个 Backlog 条目的用户验收测试。

    会议过程
    •从第一个 Product Backlog 条目(故事)开始。
    •讨论该 Product Backlog 条目,以深入理解。
    •分析、明确用户验收测试。
    •找到非功能性需求(性能、稳定性...)
    •找到验收条件。
    •弄清楚需要“完成”到何种水平。
    •获得 Backlog 条目各个方面的清晰了解。
    •绘制出所需交付物的相关图表,包括流程图、UML图、手绘草图、屏幕 UI 设计等。
    •回到步骤1,选取下一个 Backlog 条目。

    流程检查:询问团队能否快速回答下列问题,只需要简要回答即可:“我们能在这个 Sprint 中完成第一个 Backlog 条目吗?”如果能得到肯定的回答,那么继续询问下一个 Backlog 条目,一直到已经分析完的最后一个 Backlog 条目。——接下来,休息一下。在休息后,对下一个 Backlog 条目展开上述流程。

    结束流程:
    •在 Sprint 规划会议第一部分结束前留出 20 分钟。
    •再次提问——这次要更加严肃、正式:“你们能否完成第一个 Backlog 条目,...第二个,...?”
    •如果团队认为他们不能再接受更多的 Backlog 条目,那就停下来。
    •现在是非常重要的一步:送走 Product Owner,除了团队和 Scrum Master 之外的所有人,都得离开。
    •当其他人都离开后,再询问团队:“说真的——你们相信自己可以完成这个列表?”
    •希望团队现在能短暂讨论一下,看看他们到底认为自己能完成多少工作。
    •将结果与 Product Owner 和最终用户沟通。

    注意事项:不要改变 Backlog 条目大小,不要估算任务。


    Sprint规划会议——第二部分(下午)
    会议目的
    •该会议的工作以设计为主,产品开发团队可以为他们要实现的解决方案完成设计工作,在会议结束后,团队知道如何构建他们在当前 Sprint 中要开发的功能。

    基本要求
    •只有产品开发团队才能制定解决方案,架构师或其他团队之外的人只是受邀帮助团队。

    构成部分:
    •能够帮助团队在该 Sprint 中构建解决方案的人,比如厂商或是来自其他团队的人员。
    •选择好的 Product Backlog 条目。
    •挂图......

    注意事项:不要估算任务,不要分配任务。

    会议输出
    •应用设计、架构设计图、相关图表
    •确保团队知道应该如何完成任务!

    会议过程
    •从第一个 Backlog 条目开始。
    •查看挂图,确定对于客户的需求理解正确。
    •围绕该 Backlog 条目进行设计,并基于下列类似问题: •我们需要编写什么样的接口?
    •我们需要创建什么样的架构?
    •我们需要更新哪些表?
    •我们需要更新或是编写哪些组件?
    •......

    当团队明确知道自己应该如何开发该功能后,就可以转向下一个 Backlog 条目了。在会议的最后 10 分钟,团队成员使用即时贴写出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展,将这些任务放在任务板上。

    持续时间:在 Sprint 规划会议第一部分完成后,召开该会议。可以将午餐作为两次会议的一个更长久的休息。但是要在同一天完成 Sprint 规划第一部分,在 Sprint 中,每周该会议占用时间为 60 分钟。


    估算会议——根据项目情况合并到Sprint第二部分会议
    会议目的
    •要做好战略规划,你需要知道 Backlog 中各项的大小,这是版本规划的必要输入;如果想知道团队在一个 Sprint 中能够完成多少工作,这个数据也是必须的。
    •团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。

    基本要求
    •只有团队才能作估算,Product Owner(产品负责人)需要在场,以帮助判定某些用户故事能否拆分为更小的故事。

    构成部分:
    •Product Owner 根据业务价值排定 Product Backlog 各项顺序。
    •需要参加的人员:Team、Product Owner、User、Scrum Master

    注意事项:
    •不要估算工作量大小——只有团队能这么做。
    •Product Owner 不参与估算。

    会议过程
    •Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。
    •团队使用规划扑克来估算 Backlog 条目。
    •如果某个 Backlog 条目过大,需要放到下一个或是后续的 Sprint 中,团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目,并对新的 Backlog 条目使用规划扑克进行估算。
    •重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。

    持续时间:该会议时间限制为不超过90分钟。如果 Sprint 持续时间长于一周,那么每个 Sprint 举行两次估算会议比较合适。

    会议输出
    •经过估算的 Product Backlog。
    •更小的 Backlog 条目。

    扑克牌估算
    具体步骤:
    •每个人各自估算后独立出暗牌,听口令一起开牌。
    •数值最大者与最小者PK,其他人旁听也可参考。
    •讨论结束后重新出牌和开牌。
    •重复上述过程,直到结果比较接近。

    常见问题

    1、为什么任务要分给组而不是个人?
    答:因为怕出错了牌又说不出所以然,这样即使日后他不做这个功能,也对这个功能很了解。

    2、为什么不让最后领任务的人自己估算?
    答:因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。

    3、为什么不让师傅估算大家采纳,他不是最厉害吗?
    答:师傅的想法常常是徒弟们理解不了的,比如为什么不留在女儿国而偏偏去西天取经之类的,共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。


    Sprint评审会议(Review Meeting)
    会议目的
    •Scrum 团队在会议中向最终用户展示工作成果,团队成员希望得到反馈,并以之创建或变更 Backlog 条目。

    基本要求
    •Sprint 复审会议允许所有的参与者尝试由团队展示的新功能。

    构成部分
    •有可能发布的产品增量,由团队展示。

    会议输出
    •来自最终用户的反馈。
    •障碍 Backlog 的输入。
    •团队 Backlog 的输入。
    •来自团队的反馈为 Product Backlog 产生输入。

    持续时间:90分钟,在 Sprint 结束时进行。

    会议过程
    •Product Owner 欢迎大家来参加 Sprint 复审会议。
    •Product Owner 提醒大家关于本次 Sprint 的目的:Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。
    •产品开发团队展示新功能,并让最终用户尝试新功能。
    •Scrum Master 推进会议进程。
    •最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。

    注意事项:
    •不要展示不可能发布的产品增量。
    •Scrum Master 不要负责展示结果。
    •团队不要针对 Product Owner 展示。



    Sprint反思会议(Retrospective Meeting)
    会议目的
    •该会议的对应隐喻:医疗诊断!其目的不是为了找到治愈方案,而是要发现哪些方面需要改进。

    构成部分
    •参与人员:团队成员、Scrum Master

    基本要求
    •从过去中学习,指导将来。
    •改进团队的生产力。

    注意事项
    •不要让管理层人员参与会议。
    •不要在团队之外讨论找到的东西。

    会议输出
    •障碍 Backlog 的输入。
    •团队 Backlog 的输入。

    持续时间:90分钟,在 Sprint 评审会议结束后几分钟开始。

    会议过程
    •准备一个写着“过去哪些做的不错?”的挂图。
    •准备一个写着“哪些应该改进?”的挂图。
    •绘制一条带有开始和结束日期的时间线。
    •给每个团队成员发放一叠即时贴。
    •开始回顾。
    •做一个安全练习。
    •收集事实:发放即时贴,用之构成一条时间线。每个团队成员(包括 Scrum Master)在每张即时贴上写上一个重要的事件。
    •“过去哪些做的不错?”:采取收集事实同样的过程,不过这次要把即时贴放在准备好的挂图上。
    •做一个分隔,以区分“过去哪些做的不错”和接下来要产出的东西。
    •“哪些应该改进?”:像“过去哪些做的不错”那样进行。
    •现在将即时贴分组:
    •我们能做什么》团队 Backlog 的输入。
    •哪些不在我们掌控之内?》障碍 Backlog 的输入。
    •根据团队成员的意见对两个列表排序。
    •将这两个列表作为下个 Sprint 的 Sprint 规划会议第一部分和 Sprint 规划会议第二部分的输入,并决定到时候要如何处理这些发现的信息。

    展开全文
  • 互联网敏捷 Scrum 和项目管理

    万次阅读 2018-07-03 02:46:07
    互联网敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多...本场 Chat 着重介绍互联网 Agile 敏捷的模型以及常用项目管理流程等内容。 本场 Cha...

    互联网敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。本场 Chat 着重介绍互联网 Agile 敏捷的模型以及常用项目管理流程等内容。

    本场 Chat 您将学到如下内容:

    1. 介绍 Agile 敏捷以及项目管理流程;
    2. 互联网常用敏捷工具和平台以及实战;
    3. Agile 敏捷以及项目管理总结。

    互联网敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。本场 Chat 着重介绍互联网 Agile 敏捷的模型以及常用项目管理流程等内容。

    本场 Chat 您将学到如下内容:

    • 介绍 Agile 敏捷以及项目管理流程;
    • 互联网常用敏捷工具和平台以及实战;
    • Agile 敏捷以及项目管理总结。

    介绍 Agile 敏捷以及项目管理流程

    什么是敏捷开发?

    敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

    怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发。

    为什么说是以人为核心?

    我们大部分人都学过瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

    什么是迭代?

    迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

    关于 Scrum 和 XP

    前面说了敏捷它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而 Scrum 和 XP 就是敏捷开发的具体方式了,你可以采用 Scrum 方式也可以采用 XP 方式;Scrum 和 XP 的区别是,Scrum 偏重于过程,XP 则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲 Scrum。

    什么是 Scrum?

    Scrum 的英文意思是橄榄球运动的一个专业术语,表示 “争球” 的动作;把一个开发流程的名字取名为 Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的。

    而 Scrum 就是这样的一个开发流程,运用该流程,你就能看到你团队高效的工作。

    Scrum 开发流程中的三大角色

    • 产品负责人(Product Owner)

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

    • 流程管理员(Scrum Master)

    主要负责整个 Scrum 流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    • 开发团队(Scrum Team)

    主要负责软件产品在 Scrum 规定流程下进行开发工作,人数控制在 5~10 人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到 Sprint 的目标。

    Scrum 流程图:

    enter image description here

    enter image description here

    enter image description here

    互联网常用敏捷工具和平台以及实战

    无论是创业软件团队,还是企业级规模化软件研发,都会遇到提升管理能力、提升研发效率的问题。为了解决这两个问题,许多软件研发工具平台也营运而生:微软、IBM、HP、Atlassian、Rally、Collabornet、Polarion…… 等厂商都推出了各具特色的产品,而近年来新生的 Slack、teambition 等平台也带来了新的理念和产品,受到了许多团队的欢迎。作为软件研发的团队或企业,我们该如何根据自身发展情况,对这些产品和工具进行合理的选择?一个支撑软件高效研发的工具平台应该具备哪些特点?未来又将向什么方向发展呢?

    世界范围内软件研发工具平台产品发展迅速,国内产品仍是空白。

    当我们在学校里用 Visual Studio 编写 hello world 的时候,我们就已经开始使用工具进行软件研发。只是那个时候,工具的作用还很单一,对管理能力、研发效率的整体提升还没有特别关照。

    在 80 年代,国内的计算机、软件行业刚刚萌芽的时候,国外的同行已经开始研究使用工具提升软件研发效率,微软、Rational(后来被 IBM 收购)推出了各自的 IDE,并在不断增强 IDE 功能的同时,向需求管理和质量管理方向拓展。

    90 年代,又有一些厂商加入到了开发软件研发工具产品的行列中,其中国内同行非常熟悉的莫过于 Mercury(后来被 HP 收购)的产品,90 年代末和 2000 年前后,大家经常使用的研发工具组合一般是:需求管理用 Rational Request Pro,开发 IDE 用 Micosoft Visio Studio,代码库用 collabnet subversion 或 Rational Clear Case,测试管理用 Mercury Test Director,软件性能测试用 Mercury LoadRunner。这些工具在软件研发的每个方面都提升了个人和团队的效率,也让越来越多的人看到了工具平台对软件研发效率提升的重要性。

    进入 21 世纪,敏捷思想及敏捷软件研发方法开始逐渐改变人们对软件研发的认识。在软件研发工具平台方面,ALM(Application Lifecycle Management)逐渐成为各工具厂商产品努力的方向。在短短的 10 年内,涌现出一大批优秀的软件研发工具平台厂商,如 Atlassian、Rally、Polarion、Versionone、Serena…… 一些老牌厂商,如微软、IBM、HP 通过收购、合并、开发新的工具产品等方式,更加完善了软件全生命周期管理的工具平台。有了新的软件研发方法,配合众多优秀的软件研发工具平台,软件行业得到了快速的发展。此时国内同行也广泛认识到工具平台对提升研发效率的重要性,有条件的企业或采购,或自主研发,搭建起自己的研发工具平台。

    2010 年前后,随着互联网的蓬勃发展,互联网软件研发逐渐成为新的焦点,DevOps 很快成为大家普遍的共识。很多传统软件研发工具厂商打着 “DevOps” 的旗帜适时地推出了一些产品或升级版本,同时又有一些新的厂商加入竞争的行列。在如何能够更好地管理软件研发活动的问题上,像 Slack 这样的产品向 “传统” 研发工具平台发起了新的挑战,在看到越来越多的软件研发团队更愿意使用 Slack 进行日常研发工作时,我们不禁陷入思索:未来软件研发工具平台将何去何从?

    enter image description here

    enter image description here

    下面我主要介绍市场上最活跃的 2 款产品:JIRA、BugFree 和禅道。

    JIRA 敏捷管理软件

    JIRA 是 Atlassian 公司出品的项目与事务跟踪工具,被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域,其配置灵活、功能全面、部署简单、扩展丰富。

    JIRA 也可定义为 Professional Issue Tracker,即它是一个专业的问题跟踪管理的软件。这里的“问题”对应的英文单词是 Issue,所以含义比较广,包括 Bug、Task、Enhancement、Improvement 等等跟软件开发相关的名词。跟踪管理即对问题的整个生命周期进行记录和管理。一个问题从创建到解决到关闭涉及到很多相关信息,包括是什么问题、谁发现的问题、谁处理了这个问题、如何处理的、相应的代码有什么改变等等,JIRA 可以方便的记录这些信息,并且在问题的不同状态呈现在相应的责任人面前。相似的软件有 Bugzilla、Trac、Mantis、Clear Quest、Streber 等。

    enter image description here

    Bugfree 和禅道

    BugFree 是借鉴微软的研发流程和 Bug 管理理念,使用 PHP+MySQL 独立写出的一个 Bug 管理系统。简单实用、免费并且开放源代码(遵循 GNU GPL)。 命名 BugFree 有两层意思:一是希望软件中的缺陷越来越少直到没有,Free 嘛;二是表示它是免费且开放源代码的,大家可以自由使用传播。

    禅道是第一款国产的优秀开源项目管理软件。它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体,是一款功能完备的项目管理软件,完美地覆盖了项目管理的核心流程。先进的管理思想、合理的软件架构、简洁实效的操作、优雅的代码实现、灵活的扩展机制、强大而易用的 API 调用机制、多语言支持、多风格支持、搜索功能、统计功能。

    Redmine 是用 Ruby 开发的基于 Web 的项目管理软件,是用 ROR 框架开发的一套跨平台项目管理系统,据说是源于 Basecamp 的 ROR 版而来,支持多种数据库,有不少自己独特的功能,例如提供 wiki、新闻台等,还可以集成其他版本管理系统和 BUG 跟踪系统,例如 SVN、CVS、TD 等等。这种 Web 形式的项目管理系统通过“项目(Project)”的形式把成员、任务(问题)、文档、讨论以及各种形式的资源组织在一起,大家参与更新任务、文档等内容来推动项目的进度,同时系统利用时间线索和各种动态的报表形式来自动给成员汇报项目进度。

    禅道项目管理软件的功能列表:

    1. 产品管理:包括产品、需求、计划、发布、路线图等功能。
    2. 项目管理:包括项目、任务、团队、build、燃尽图等功能。
    3. 质量管理:包括bug、测试用例、测试任务、测试结果等功能。
    4. 文档管理:包括产品文档库、项目文档库、自定义文档库等功能。   
    5. 事务管理:包括 todo 管理,我的任务、我的 Bug、我的需求、我的项目等个人事务管理功能。   
    6. 组织管理:包括部门、用户、分组、权限等功能。   
    7. 统计功能:丰富的统计表。   
    8. 搜索功能:强大的搜索,帮助您找到相应的数据。   
    9. 灵活的扩展机制,几乎可以对禅道的任何地方进行扩展。   
    10. 强大的 API 机制,方便与其他系统集成。

    enter image description here

    案例分析:IBM的敏捷转型之路

    enter image description here

    IBM 软件集团是一个庞大而复杂的组织,从 2009 年的软件部规模来看,全球 26065 名员工广泛分布在世界各地,拥有超过 500 个于各个时期收购的小公司以及相互独立的产品线,大量的独立工具和开发平台在公司内被采用。IBM 的五大品牌行事作风迥异,很难用一种流程、一种组织结构来进行统一。

    为了促进发展,各品牌组织均开发了自己的经营策略,以适合其业务所在的市场。然而,IBM 为所有的品牌都定义和秉持了一套共同的技术策略。

    • 开放的计算:为了创新并确保客户体验的自由度,客户端必须保持灵活性,这种持续的发展和推演需要基于技术和产品自身的价值而非自身的局限性。
    • SOA:为了实现产品的灵活性和资产的重用,SOA(Service Oriented Architecture)是一套可以在分布式系统的设计和实现中将系统的业务模式与 IT 实现紧密关联起来的方法。
    • 彻底简化:尽最大可能增强产品的实用性。
    • 产品整合力:从商业价值出发,确保中间件的产品能够易于集成,并提供适于客户环境的完整解决方案。
    • 产品研发的 3C 品质:消费性(Consumablility)、模块化(Componentiza-tion)和社区(Community)三个原则,聚焦于改进开发流程和开发过程本身。

    3C 原则带来的产品的质量提升,还仅仅是在以产品为中心的主流市场获得的成功体验,但是,当市场发生巨大变化时,战略又将产生变化。2006 年的互联网高潮后,软件部受到全球 IT 经济低迷的冲击,股票开始下滑,面对开始失去信心的股东、董事会,为了生存,IBM 不得不将战略导向从稳定业务转向了动态业务,提出“随需应变”的核心战略,软件部由此提出了敏捷研发方法,最大化地提高生产力,将产品更快、更好地推向市场。

    Agile 敏捷以及项目管理总结

    敏捷项目管理架构(Agile Project Management Framework,APMF),估计是普遍大部分公司所需要的、也比较认可的模式,可以很好的实现传统项目管理向敏捷项目管理转型。这本书很值得推荐,从现代项目管理的发展趋势,到对软件项目管理发展史的剖析,到敏捷项目管理架构的推崇,到敏捷项目管理的企业导入,到敏捷创新创业模式讲解,让你在软件项目管理方面有了更加开阔的视野。如果你对敏捷项目管理感兴趣,在拜读本书的过程中会有茅塞顿开的感觉,同样也为你以后的软件项目管理路提供了更好的参考和借鉴。

    通过对许博士这本书的研读,加入个人的理解,对敏捷项目管理架构,做了简单的梳理,希望对敏捷项目管理感兴趣的你带去更多帮助。敏捷项目管理架构(APMF)共包括 5 个阶段,分别为:立项阶段、启动阶段、发布循环阶段、迭代循环阶段、收尾阶段。

    enter image description here

    enter image description here

    enter image description here

    Agile 和 Watefall 开发模式的一些对比

    enter image description here

    enter image description here

    经过敏捷实施后,我们的生产力提高了很多,员工的积极性提高了,业务的参与使整体需求把控也很好,大家沟通多了,30 天的任务提前了 5 天完成。我们多出来的时间,让大家每周有一天或者半天研究自己感兴趣的领域,但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术,最后做完需要写个 ppt 给大家分享下。既能让大家做自己想做的事情,也给大家创造了一个互相学习的氛围。


    本文首发于GitChat,未经授权不得转载,转载需与GitChat联系。

    阅读全文: http://gitbook.cn/gitchat/activity/5b222d37e4f51376b59dad57

    您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ,阅读更多 GitChat 专享技术内容哦。

    FtooAtPSkEJwnW-9xkCLqSTRpBKX

    展开全文
  • Scrum敏捷项目管理

    热门讨论 2016-01-16 14:57:31
    《Scrum敏捷项目管理》探索Scrum的每一方面,包括科学原理、全新的项目角色及责任、ScrumMaster、产品负责人、如何有效管理未知因素和不断变化的产品需求、如何结束混乱、如何计划和报告、及如何扩展项目团队规模等...
  • 量化敏捷项目管理案例分享

    千次阅读 2018-11-09 09:31:38
    “真感谢你这几个月帮助我们试点项目应用这项目管理工具,现在我才理解...让我们一起回顾他们公司如何结合CMMI、敏捷项目管理工具提升管理:   1「背景」   这是杭州一家专门做政府项目的公司,人数接近300...

    “真感谢你这几个月帮助我们试点项目应用这项目管理工具,现在我才理解这个工具确实很适用于我们软件开发项目的管理。下个月我会开始要求所有研发项目都使用这方式与新的项目管理模板。”——进入CMMI评估前的最后准备的第一天,技术总监对我们的顾问这样说。

     

    让我们一起回顾他们公司如何结合CMMI、敏捷、项目管理工具提升管理:

     

    1「背景」

     

    这是杭州一家专门做政府项目的公司,人数接近300。

    技术总监一直深信要想可持续的过程改进,必须有自动化工具的配合。

    以前公司一直使用开源工具来管理项目,也尝试做了些订制软件,但因为都是基于缺陷管理开发的工具,只可以做到基本的任务管理,很难做到整个项目的计划与监控。

     

    2「希望解决的问题」

     

    希望解决的问题——主要是希望管理好项目进度与成本

    开源工具只可以记录基本的任务,更希望有以下功能:

    1. 工作任务分解 WBS 管理

    WBS可以分层组织任务,而且建立活动间的依赖关系:

     

    一般项目WBS都会包含很多活动,但项目经理不可能把每一项活动都计划好,她只可以把项目分成多个子项目,然后由小组组长计划下面的具体活动,例如测试、需求等子计划。

    所以需要各组长协同做计划,而不是由项目经理一个人包办。

    但传统的项目管理工具,很多都不支持,所有活动主要由项目经理一人统一管理。

     

    2.  项目成本管理

    公司的大部分收入是来自软件项目,但单软件项目最大的成本是人力成本,经常需要到项目结束才可以知道总共花了多少人力成本。

    其实管理层对项目管理的要求很简单,正如下面的图,想实时清楚计划和实际相比是否延后?是否超支?

    正如这公司的技术总监说大家学项目管理的时候都学过这张图,但因为缺乏监控工具而无法看到实际与计划的对比。

    希望项目管理工具可以每月甚至每周,即时按实际的人员工时表结算到现在的实际成本,并与预算对比差多少?不要等到最终才知道超过预算。

     

    3.  变更管理

     

    项目变更很常见,中间没有实时记录变更的话,会导致项目看不到进度偏差,但实际上与最初的基线比较延期不少。

     

    4.  收集真正的实际工时

    现在员工填工时表时,都基本按计划填写,没有真正的实际工时,新的工具可以设定每一个活动的产出物,必须通过评审才算任务100% 完成。

     

    5.  统计项目真实工作量,成为公司基线/标杆

    也因缺乏项目进度、工作量的真正历史数据,导致有新项目投标时无法估算成本,使得报价过低,赢了项目却不能盈利。

     

    6.  项目人员分配

    现在只是靠部门主管手工分配,但经常出现重点被关注的项目,临时抽调一些正在做项目的人员,

    导致一些项目延误。

     

    3年前,在评估结束后,公司高层便决定购买项目管理工具,满足以上需求。比较了3家,最终挑选并购买了一套叫EM的项目管理工具。

     

    一年前,当这家公司要准备做新一轮的CMMI评估时,顾问得知公司已采购并使用了这EM系统,但很奇怪,为什么公司买了EM项目管理工具,只用来做采购管理,报销,但没有用来管理研发项目。

     

    在做差距分析和不同岗位层次交流访谈,发现因为开发人员多年都习惯了使用本来的开源工具

    你自己说开发工作不一样,坚持用本来的方法,管理层也没有坚持。

     

    虽然公司内有人熟悉这新工具的功能,但要改变大部分人多年的习惯不容易,高层也犹豫,不希望逼管开发的主管硬推(也理解研发主管自己也花了不少精力,做了一些对本来开源工具的定制)

     

    3「利用CMMI评估催化变更」

     

    利用CMMI评估催化变更——获取管理者的支持

    改变习惯是很难的事情,所以需要从上而下来推行。

    顾问便安排了熟悉新工具的项目经理,给高层与技术总监演示如何实现上述的各种功能。交流后,大家都同意有用,接下来找试点推行。

     

    4「试点」

     

    因项目的交付期越来越短,需求也常常变,听我们去年在杭州成功帮助另一家公司推行敏捷开发试点(不再用传统的瀑布式),敏捷开发很多公司都已经开始用,我们的特点是不仅仅是敏捷的做法,也配合简化功能点估算于每个冲刺的生产率与质量的数据统计,使用XLS表记录与分析。

     

     

    我们给了试点项目经理一个敏捷项目度量模板,开始时,项目经理不太了解功能点规模估算,也觉得较复杂,我们顾问便给他介绍简化功能点法,因敏捷每个迭代只有2-4周,虽然简化版有15-25%的偏差,但还可以接受。

     

    客户项目经理学懂了这量化敏捷开发方法后,决定试点,同时也尝试利用EM工具来计划与监控,如果效果理想,会整个公司推行。

     

    因为这个项目会使用EM项目管理工具,所以顾问便召集项目经理和技术总监。制定敏捷项目WBS模版。

     

    项目计划与监控都很顺利,过了三个月开始要准备CMMI评估了。

     

    项目经理以以往准备CMMI评估的经验,以为对每一个迭代都要为所有过程准备相关的文档,例如需求文档、设计文档、测试计划文档等等。算起来要准备文档的数量比以前用瀑布式的项目的文档还多几倍。

     

    总监觉得不对,便叫项目经理联系顾问。

    顾问听完他问题,说:“您被 ’CMMI ‘ 的毒害太深了,以为CMMI是等同于大批文档。你这个项目使用敏捷,再配系统管理工具,很多瀑布式项目所需要的文档都应该可以省掉。例如: 不需要像以前那种按公司模板编写需求说明书,里程碑时,再使用XLS表格模版填写实际工时与进度,形成报告。 “

     

    顾问便教他如何在计划与监控等过程域配一个敏捷XLS模板,加上用工具,满足CMMI 中项目计划 PP、项目监控 PMC、集成项目管理IPM、风险管理 RSKM 等要求。

     

    CMMI评估促进了项目经理去了解并在实际项目中使用新的项目管理工具,如果没有评估,管理层未必会考虑项目管理的问题,这种变更/试验也不一定能发生。

     

    5「效果」

     

    有了完整的项目模板、测试、研发与实施阶段在工具中串联起来,使每一个问题等都能找到前因后果,对资源的掌控更清晰,不会出现大规模的冲突,也有效的监控了项目预算及成本。

     

    因为敏捷迭代开发,每2-4 周都会有客户产品的展示,都需要有测试,质量明显比以前瀑布性开发好。 

     

    项目管理方面,项目WBS可以按不同活动负责人进行分解,并对活动分配人力资源,同时也会显示活动状态,是否为里程碑等。

     

    每一次项目审批都会形成一次基线,不同的基线可以进行对比,不同的内容用黄色标注出来:

     

    依赖关系设置好后,可以查看关键路径等。

     

     

    当预算与成本有相关数值计算或录入进去,一旦活动开始有进度进行,可自动计算出EV (Earned Value) 、 PV (Planned Value)等来显示进度偏差 、成本偏差。 

     

    当活动申请人力资源时,可以根据技能进行查找,找到技能满足的可用人力资源。

     

    在工作统计量报表中,可以看到每个资源的工作量及完成工作量等,也可以根据项目来看。

    申请资源时,可以看到此资源已被审批通过的资源人时,同时也会计算出与目前所要申请的资源时相加是否超出总资源时。

     

    这用工具的试点项目也满足了 CMMI 中 项目计划 PP、项目监控 PMC,、集成项目管理IPM、 风险管理 RSKM 等的实践,不需要再填写手工模板。

     

    总经理一直都是做市场,以往都是依赖于技术总监汇报项目的实际情况。包括进度、工作量、成本,现在他可以直接在项目管理系统中即时看到实际的项目状况,他很高兴地发现可以识别出每个项目占用公司的资源的多少。

     

    “原来 XX客户的项目都常常超出本来项目报价的预算,我们下次再报项目时,报价一定不能低。“ 他说——有了可靠数据作为指标,管理层便可以判断合适的报价。

     

    他要求接下来 所有项目都要用这新方法,技术总监和主管们也赞同。

     

    6「后记」

     

    常常被问 ,怎样才可以使CMMI可以帮助公司实际提升,并且可以持续?

    这案例便是如何集合模型 + 系统 + 人员 (有度量) 的好例子:

    - 用度量让员工了解现在的不足,制定具体的目标;

    - 用模型+评估促进员工改变习惯,开始改进;

    - 用系统把改进后的过程持续下去。

    必备条件:领导对现状不满,觉得必须要改进试点项目人员有能力,有动力。

     

    联系我们

    电话:18921395967

    QQ:1228021190

    微信:processis2009

    地址:香港/北京/江苏

    官网:www.processis.org

    邮箱:claire@processis.org

     

     

     

     

    展开全文
  • 敏捷项目管理

    千次阅读 2010-03-18 17:50:00
    1 简介现在,即使在IT预算被大幅度地削减的情况下,IT管理人员的压力仍然在不断增大。同时,业务环境正以非常高的速度持续改变,这使IT艰苦奋斗,以便能够跟上这种变化速度。这些变化导致了以“快速发布和灵活而又...

      1    简介

    现在,即使在IT预算被大幅度地削减的情况下,IT管理人员的压力仍然在不断增大。同时,业务环境正以非常高的速度持续改变,这使IT艰苦奋斗,以便能够跟上这种变化速度。这些变化导致了以“快速发布和灵活而又高质量的维护为承诺”的敏捷软件开发方法论产生了很大的兴趣。

    敏捷方法(XP、SCRUM、Feature-Driven Development)努力在软件开发过程当中减少变化带来的成本。例如,XP使用快速迭代计划和开发循环尽早地产生最有价值的特性。另外,XP中的持续的、系统化的测试确保高质量,尽早发现缺陷和相应的解决方案。

    尽管敏捷方法带来了早期的一些成功案例,但还是有很多因素阻碍它们被广泛采纳。敏捷方法的倡导者经常发现:在应用开发中,对动态变更很难得到管理方面的支持。这些方法需要开发者、管理者和用户都改变他们工作和思考的方式。例如,XP实践中的结对编程、TDD、持续集成以及on-site 客户代表等是很难让人接受的。而且,这些方法论更倾向于以开发者为中心,似乎并不太重视管理角色。

    然而,实践证明,加强管理是敏捷方法被成功采纳并应用的关键,而传统项目管理方法学和工具与这些新的敏捷方法缺少关联。而这种低关联性就是深层次问题的症状。这些深层次问题表现在:对于处理变化、控制、命令、组织、人员以及解决方案等方面的基本假设方面的不同。传统管理理论假设:

    l         管理变化是需要严格过程的
    l         分层级的组织结构是建立秩序的途径
    l         加强控制可以得到更好的秩序
    l         在“项目组”这个机器中,人员是可以互换的“零件”
    l         问题主要是通过任务细分来解决
    l         通过事前详细复杂的计划可以对项目和风险进行充分的预言,并被管理

    在这个上下文环境中,新方法论所表现出来的无序性、平等性和解决问题的无方向性就没有什么奇怪的啦。在这种传统管理与敏捷开发方法论之间的不重合性中,敏捷方法会被逐渐采纳。同样,这些假设的变化和敏捷方法过程中新的管理框架也是非常重大的需求。

    在寻找这种新框架的过程中,我们强烈地认识到:出现了基于“复杂性理论”这个新学科的管理原则。“复杂性理论”这个新学科实际上在对现存系统进行研究的过程中产生的,它主要是探寻对人类自治行为的理解。.尤其是,我们已经开始将一种复杂适应系统(CAS)的概念融入到我们的管理假设与最佳实践中。

    “复杂性理论”的科学家已经研究了现存系统中的集体化行为,如鸟群、鱼群、蚁群和蜂群。他们发现,当这些复杂适应系统中的个体拥有局部的战略原则和能力时,它们的集体化行为比个体的总和表现出更完全的秩序化、自组织性和更高的智慧性。这种CAS理论被成功地应用于经济和生命科学,现在也被用于管理方面。

    这种CAS的概念使我们产生一种灵感:在XP团队中,项目经理也需要一系列的简单的指导实践来提供一种框架,并在这种框架下进行管理,而不是一系列的严格的指令。根据这此实践,管理者成为一名适应性领导者--确定方向、建立简单的产生式的系统准则,并鼓励持续反馈、适应性改变和协作。这个管理框架为团队提供一系列的内容来实现敏捷方法论,这些内容包括:

    l         在团队管理中,组员是熟练地有很高价值的stakeholder
    l         自治性团队的集体能力是解决问题的基本机制
    l         在不可预言的假设面前尽可能地使事前计划最小化,而加强适应变化的能力

    2    问题:作为传统的任务分配者所面对的项目管理

    传统软件生命周期开发方法论的产生是因为我们要控制不断增大的开发项目,以及对产生可靠的产品的工作量的评估和管理。这些方法论来源于建筑工程管理中的一些原则。结果,它们是强调可预言性的(在建一座桥时,工程设计师必须设计桥的每一个细节),并且是一个线性开发周期(即需求、分析、设计、开发)。根据这种可预言性,它们沿用了确定性的简化了的方法,这些方法依赖于任务分解,并且是基于稳定性的(即稳定的需求分析和稳定的设计)。作为项目控制的一个手段,这种刚性表现为顺从性。

    在过去,一些公司使用这些方法,并且现在也可能在使用。对于许多来说,这些方法论只是增加成本和复杂性,却给人们一种错误的安全感――管理就是通过详细的计划、度量和控制来做事。巨大的成本被过早的计划浪费了。我们认识到快速的迭代式开发和从用户那里得到不断的反馈是今天项目达到成功的前提。

    下面这个例子被公认为是原有方法论失败的代表案例:“伦敦救护系统”和“但佛航空行李系统”,巨大的成本超支和拖期。让我们来看一下Standish组织关于CHAOS的调查。在第一次调查中,成功项目18%,31%失败,53%挑战。在1998年的调查中有所提高,但也是26%成功,46%挑战,28%失败。研究还表明,在成功的这些项目中,它们的项目大小都控制在使用小团队就可以完成的级别上。这个结果很明显与敏捷方法论的原则一致。而且,我们还发现,很多已经确立的项目管理实践仍可应用于敏捷开发项目,只需要进行一些适应性改变并加强对其进行领导就可以达到。

    当管理者在使用传统方法论努力控制项目时,技术社区开始用敏捷方法来对付传统管理带来的挫败以及对他们的产品品质和士气所带来的影响。例如,那时的XP就几乎完全聚焦于开发过程。当技术社区支持这些实践时,却很少涉及敏捷开发项目的管理方面。这就暗示着:由于XP团队开发并管理他们自已的任务,对于项目经理的需求就很小。这并不奇怪,公司管理一直怀疑敏捷方法,不太接受它们。管理者希望着一种场景出现:满屋子的开发者做着他们各自的事情。。。。而“eXtreme”这个词并没有什么意义。

    抛开具体的方法论,传统的项目经理经常是作为制订并控制主要计划的人,这些计划详细地描述了任务、它们之间的依赖关系以及为完成最终产品而必须的资源。然后,项目经理监控任务的状态,对计划进行必要的调整。这种做法是建立在这样的假设基础上的,即组员是可以互换的个体,就象同一型号的螺丝。

    所以,对于熟悉传统方法论的经理,是很少有勇气在他们的项目中使用敏捷方法的。但这也不是必须的。事实上,敏捷方法的独立性使管理社区和技术社区在项目管理中趋于同一个焦点。

    3    答案:做为愿景领导者的项目经理

    最好的项目经理并不只是组织者(organizers)-他们使业务愿景、沟通能力、软管理技巧和技术头脑与他们的计划能力、协调能力和执行能力相结合。从根本上说,他们应该是领导者(leaders)。敏捷项目管理要求更高的领导技能。

    例如,XP团队在与客户的协作中,创建并监控他们自已的迭代计划。当XP团队工作时,对每一次迭代结果(等时长迭代)进行度量,并根据需要与用户一起调整计划。那么,如果项目不再需要一个详细的项目计划时,为什么还要项目经理呢?

    因为每个项目都需要一个领导者(leader)。敏捷方法把项目经理从工头的位置上解放出来,使项目经理可以专心作一个领导者(leader),把主要精力放在项目愿景上,激发团队勇气,促进团队协作,排除项目过程中的障碍,使项目开发过程顺利进行。项目经理不仅是项目运作的控制者,更应该成为适应性领导者――如果他放弃对旧风格的管理方式的依赖。

    敏捷开发项目的基本阶段与其它项目没有什么不同。项目经理还是必须定义和初始化项目,作项目计划,执行计划,监督并控制结果。但是完成这些步骤的方式却是不同的,需要项目经理去采用新的思考方式进行管理――思考CAS。

    4 指导原则:团队是一个复杂适应系统

    象前面提到过的,传统的命令&控制的管理方式大部分来源于泰勒的“科学管理”原则。泰勒的“科学管理”原则是基于十七世纪牛顿的观点,即世界可以看作是一个巨大而且有序的“时钟结构世界”,由大自然的经典法则所管理。科学管理被认为是20世纪在发达国家中可以把体力劳动(Working masses)提高到新的富足水平的主要动力。

    然而,今天我们在团队中使用C&C管理的过程中遇到了麻烦。因为体力劳动已经被知识工人(Knowledge worker)所取代。例如,在软件业中,对于他们的老板来说,熟练的软件开发人员比他们的经理更有价值。在Taylor那个时代,管理者是来解决知识难题的。 而在我们的时代,解决知识问题的关键是知识工作者,而不是经理。所以,我们如何采用项目管理技术去处理这个关键问题呢?

    科学世界已经变了。牛顿以后的两个世纪中,他的理论在很多其它的学科中也找到了广泛的适应性。科学界后来的发现(从爱因斯坦的相对论到量子论)在很多学科中开始取代牛顿的观点。实际上,新的科学理论“复杂论”现在已经开始改变传统的管理方式。

    过去的二三十年里,科学家已经在很多领域发现了这样的系统,并去探索其共同的属性,去解释复杂现象。他们已经发现,很多自然系统(大脑系统、免疫系统、生态系统、社会系统)和很多人工系统(并行分布式计算系统、人工智能系统、人工神经网络)以复杂行为为特征,这种复杂行为是在它们组织的不同层次上,各组成系统交互的结果。

    在自然界,这些结论被用于解释活的系统(如鱼群、鸟群等)的群体行为,而这些群体中会有某个个体拥有特殊的原则和能力,他们的群体行为就会以这种全序、自组织和集体智慧为特征。另外,这些系统常常表现出不平常的适应复杂的动态环境的能力。

    总而言之,复杂性理论包括一些有生命特征的系统的基础思想:

    l         有生命特征的系统是复杂的,他们由多个个体组成,并以多种方式进行交互
    l         个体的交互以简单性、局部性为原则
    l         系统中的个体之间的丰富交互使系统作为一个整体进行自发性的自组织,并伴随着系统自身产生的复杂有序性,而不是由外界强加于系统。
    l         这些复杂、自组织的系统是适应性的,因为在不同的环境下会有不同的反应。
    l         整个系统表现出那个领导者的个体行为
    l         这些系统会和他们所在的环境一同进化(环境的变化引起他们行为的变化,他们行为的变化反过来会引起环境的变化),并达到一种新的平衡。当达到一定的变化后,又引起新的平衡点。

    如果我们把我们的团队看作一个复杂适应系统,那么CAS的相关知识就可以应用到我们新的管理哲学中。特别是传统项目管理的规则可以被变化后用于新的CAS模型。

    展开全文
  • 这 6 个过程在项目过程中并不一定是顺序进行的,而是穿插在项目管理的整个流程中,遵循渐进明细的规律,其中前 5 个子过程时间上属于项目进度的制定,第六个过程属于项目进度的监控。 定义活动 即识别为完成项目...
  • 敏捷项目管理

    2019-02-22 11:11:38
    敏捷项目管理(APM):由Jim Highsmith所著的一书敏捷项目管理,试图扩大敏捷技术为一个整体。 敏捷项目管理: 引入敏捷项目管理步骤同PMI所采用的项目管理步骤结合; 调整传统铁三角强调价值和质量,创建敏捷...
  • 敏捷项目管理

    2019-05-23 19:50:39
    敏捷开发遵循软件客观规律,不断的进行迭代增量开发,最终交付复合客户价值的产品。 敏捷宣言 个体和交互胜过过程和工具 可以工作的软件胜过面面俱到的文档 客户合作胜过合同谈判 响应变化胜过遵循计划 ...
  • 敏捷项目管理到底怎么实施?

    万次阅读 2018-03-30 08:52:52
    我们使用各种敏捷软件写feature,流转、跟踪任务,言必谈敏捷,然而我们是否真的走对了敏捷?显而易见,敏捷是绝对的结果导向,去文档化,去流程化,高效沟通和合作是究极奥义。去文档,敏捷管理者需要维护更为精细...
  • 原文地址:https://www.zhihu.com/question/54626462管理工具:1.需求管理工具confluence 是一个基于...2.基于敏捷管理的sprint、backlog、开发task、bug管理工具jira 是一个基于java的issue(问题、事项)管理器,...
  • 什么是敏捷项目管理?

    千次阅读 2018-05-21 16:05:15
    敏捷项目管理区别于传统的项目管理,又如何能让项目具备快速应变能力?敏捷方法是一种理念,采用基于人员、协作和共同价值观的组织模型。敏捷方法采用波浪式规划(rolling wave);迭代递增式交付;对变化做出快速而灵活...
  • 敏捷项目管理

    千次阅读 2006-06-19 13:00:00
    1 简介现在,即使在IT预算被大幅度地削减的情况下,IT管理人员的压力仍然在不断增大。同时,业务环境正以非常高的速度持续改变,这使IT艰苦奋斗,以便能够跟上这种变化速度。这些变化导致了以“快速发布和灵活而又...
  • 传统项目管理 VS 敏捷项目管理

    千次阅读 2019-10-08 19:04:02
    随着软件行业的发展,传统的敏捷项目管理模式,已经不适应于当前互联网行业快速迭代快速开发的需求,从而衍生出了 “敏捷项目管理” 传统项目管理和敏捷项目管理有什么不同呢? 传统 VS 敏捷 传统项目管理是计划...
  • 敏捷项目管理模式

    千次阅读 2011-05-17 10:45:00
    from: http://www.tup.tsinghua.edu.cn/Resource/tsyz/035257-01.doc        <br />第      <br />章    <br />敏捷项目管理模式   ...
  • 流程也许不如人那么重要,但它绝非不重要。像其他事物一样,流程必须与企业目标联系...敏捷流程架构需要体现其核心原则,除了支持企业目标外,该架构还需要: 支持构想、探索、适应文化; 支持自我组织、自律的团队;
  • Scrum敏捷项目管理

    千次阅读 2017-04-29 03:56:32
    敏捷的背景与动机软件危机及软件工程的出现 速度是企业竞争致胜的关键因素,软件项目的最大挑战在于 一方面要应付变动中的需求 一方面要在紧缩的时程内完成项目 传统的软件工程难以满足这些要求 所以软件团队...
  • 项目的属性 ...什么是项目管理 将知识,技能,工具和技术应用于项目活动中以满足项目要求 传统项目管理中一些概念 stakeholder 是参与或受项目活动影响的人 包含有: 1、the project sponsor 2、the pr...
  • 敏捷软件开发宣言的宣言中使用后,在其标题中带有“Aglie”一词的书籍开始出现在IT专家和其他行业专业人士的书架上。Agile描述了一种软件开发方法,其特点是生命...你读过的关于敏捷方法或项目管理的最新书是什么...
  • 敏捷项目管理实战之进度管理

    千次阅读 2014-01-06 12:11:26
    本文以笔者的实际敏捷项目管理经验为基础,分享了关于敏捷项目进度管理中缩短项目工期的实践、进度信息的获取与核实、进度信息的展现、传播及其激励作用。并介绍了项目进度管理与风险管理、期望值管理间的关联。希
  • 使用Scrum进行敏捷项目管理

    千次阅读 2018-12-27 13:27:25
    通常被称为“敏捷项目管理框架”,其重点是使用经验过程,使团队能够快速,有效,有效地做出改变。传统的项目管理方法确定了需求,以控制时间和成本; 另一方面,Scrum修复了控制需求的时间和成本。这是使用时间框,...

空空如也

1 2 3 4 5 ... 20
收藏数 79,285
精华内容 31,714
关键字:

敏捷项目管理