敏捷管理_敏捷管理的思想是什么 - CSDN
精华内容
参与话题
  • 敏捷项目管理

    千次阅读 2018-07-30 15:36:46
    敏捷的框架来做事:有角色的划分,任务的分解,有各种会议,也有sprint - 但迭代过程是随意、松散的、没有任何约束的,所以失败。 1-明确了短期目标,一个迭代在两周左右,可以明确告诉客户,在一个迭代周期内,...

    敏捷的框架来做事:有角色的划分,任务的分解,有各种会议,也有sprint - 但迭代过程是随意、松散的、没有任何约束的,所以失败。

    1-明确了短期目标,一个迭代在两周左右,可以明确告诉客户,在一个迭代周期内,只能完成200个里面的40个,先做最有价值的前20个。

    2-便于进度控制和风险预测。

    3-检视与调整,逐步完善的过程 , 迭代结束之后,产生可交付的成果,给客户演示,及早获得反馈,小步前进,不停思考,反省和总结。不停地进行自我检视,调整和完善,一步步走向卓越。

    灵活运用敏捷开发

    项目负责人还要懂得“做人”。和客户方负责人、联系人保持良好的关系是非常非常重要的

    敏捷开发中,注重概念和架构设计,而轻详细设计

    概念设计: 可以看出为何要做这个模块,强调的是产品路线规划,市场趋势,客户价值 和技术趋势等

    架构设计,可以看成从整体上看,概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。

    详细设计,则是具体的设计和做法、API接口等。

    SWOT 分析,在敏捷开发中,更加注重客户需求。对产品进行SWOT分析,就能选出最小工作量,但能获得最大价值的模块。

    业务和客户驱动而非技术驱动:敏捷开发强调在整个开发周期内,业务人员和开发人员中必须天天都在一起工作,确保技术人员能够开发出客户需要的产品。

    时刻考虑版本的兼容性, 当设计变动、API接口重构、配置文件变更时,要时刻考虑产品的架构、规划路线图,老版本的兼容性,及迁移平滑性。否则,随着版本的增多,必将面对着大量的维护工作。

    轻文档而非文档, 强调沟通的重要性, 但并不意味着无文档,在敏捷开发过程中,适量的文档还是很有帮助,有助于整体思路,加快沟通和讨论;

    产品敏捷开发中,每个迭代结束,都会有一个产品迭代演示大会,把这个月的开发结果演示给组员、业务人员、售前,甚至客户,并收集反馈。此外,在开发的过程中,产品的业务人员和售前时刻保持与产品开发团队的沟通和工作,保证开发出来的产品是符合业务需求。

    充分利用资源和时间,敏捷开发后,迭代开发、强调沟通、缩减文档,在每个迭代初期就可以充分地利用开发、测试人员的时间,达到效率最大化。

    每日交付

    产品开发过程中,每天都会做自动化Build,并生成可以交付的产品。业务人员、客户都可以试用并提供反馈和新需求。

    充分自动化

    需要自动化去支持变化,在变化的同时保证质量和开发速度,包括编译自动化、单元测试自动化、功能测试自动化、UI测试自动化、集成测试自动化等。

    架构师和Scrum Master的重要性

     1) 产品架构师 架构师是个举足轻重的角色,需要有深厚的行业背景、创新能力、技术洞察力以及架构能力

     成熟的模块;

      发展中的模块;

    研究中的下一代产品方向;

    2)Scrum Master

    其工作内容和开发组长没什么太大的区别:安排任务、协调资源、控制进度和解决难题。Scrum Master会协调解决每天碰到的问题,确保产品进度和质量。

    参考:https://blog.csdn.net/kylinforce/article/details/4554471

     

     

     

     

    展开全文
  • 量化敏捷项目管理案例分享

    千次阅读 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

     

     

     

     

    展开全文
  • 敏捷项目管理到底怎么实施?

    万次阅读 2018-03-30 08:52:52
    去文档,敏捷管理者需要维护更为精细的需求池;去流程,口头沟通成为常态,对团队的耦合度要求更高。1让我们先来了解一下敏捷的一些概念Product Backlog:backlog 即需求池。待办事项列表。Backlog里面写什么:1...

    我们使用各种敏捷软件写feature,流转、跟踪任务,言必谈敏捷,然而我们是否真的走对了敏捷?

    显而易见,敏捷是绝对的结果导向,去文档化,去流程化,高效沟通和合作是究极奥义。

    去文档,敏捷管理者需要维护更为精细的需求池;去流程,口头沟通成为常态,对团队的耦合度要求更高。

    1

    让我们先来了解一下

    敏捷的一些概念


    Product Backlog:

    backlog 即需求池。待办事项列表。

    Backlog里面写什么:

    1.待开发任务。

    2.任务优先级。

    敏捷需要维护一份详尽的需求列表。这份列表常常要求scrum持有人(一般是产品经理)对所有待开发事项有深入了解,并且能够把待开发事项分解成更为细致的任务。

    story board:

    在开发领域,故事版是任务流转的可视化窗口,一般有待开发”“开发中”“待测试”“返工”“待发布几个区块,所有任务由任务操作者负责流转至于下一个步骤,这样任何一个人项目成员都能看到任务的完成情况。

    ▲在开发中,故事板展现所有需求的工作流

    burn down chart(燃尽图

    一个sprint内,人/时是一个比较固定的值。在这个时间框架充分安排开发任务,每天进行时间结算,绘制时间燃尽图。项目成员通过燃尽图获知时间进展,若项目燃尽所用时间与预期时间契合,则需求时间预估和安排合理,若不契合则需要在下一个sprint进行调整。

    这些概念定义了敏捷各个环节的工作,这些流程和节点是敏捷开展的基础和保障。

    2

    离开敏捷工具

    我们怎么敏?


    一个误区:我们用了敏捷管理工具,就敏捷了

    随着敏捷在行业内的不断融入,各种工具产品层出不穷。国外jiraredmineAxosoft ,国内的leangoo、禅道,三大家则都有自研的工具,百度的icafe,阿里的aone,腾讯的tapd

    (▲数据来源:中国开发者白皮书

    我们在敏捷管理工具上建迭代,建需求,研发、测试等着收到需求流转的邮件之后开始干活...任务在测试和研发之间流转,bug提给研发,研发解决bug.....我们宣称:我们敏捷化了!

    我们习惯于敏捷软件的便利,拉群解决一切,然而却丧失了敏捷的初衷,scrum的本意。

    ▲Jira的名字来自于哥斯拉

    假设我们没有任何项目协同软件,敏捷怎么实施?

    设定一个环境,现在没有任何协同工具可用,但是所有人都坐在一起。有人站起来说,既然这样,我们不如敏捷吧!

    ▲敏捷工具消失了

    敏捷路径里必须有一个项目持有者,制定规划并把握项目走向。这位PM汪我看你骨骼惊奇,你就担负起这个责任吧。

    另外还有一个关键人物SMSM全称scrum master,中文称敏捷教练。一般说来,SM需要由对技术开发以及当前项目明晰的技术经理担任。

    虽然缺少线上工具,但至少要准备一些简单材料:一卷双面胶+白纸或一沓便利贴;笔,一面平坦的墙或一块黑板。

    如果还有电脑可用,excel或者word,甚至写字板都可以,没有电脑那就白纸好了,总之你得找个地方写下你的需求池(backlog

    需求池示例(任务名称、平台、详细描述、优先级按照P0-PX逐渐递减)

    确定一个sprint周期的自然天。可以用月//周等时间概念作为周期,我们选择一周(五个工作日)作为一个sprint周期。

    按照优先级,从需求池中拉出你认为应该加入你们一穷二白的第一个sprint里面去的需求,别太贪心,大概觉得差不多一周左右的开发量就够了。拉上SM单独开一次小会。

    ▲当然不是让你俩傻站着,你俩要开会

    你们一起通览需求,SM根据经验对需求先行分解一遍,比如某需求在开发层面需要分解为ABC三部分,这三部分就形成三个开发任务。

    分解完成后,你得到了一个比较详细的待开发列表。

    正式开始一个sprint开始之前,产品、研发、测试需要一同开一次scrum会议,共同讨论本次sprint的功能点。

    会上讨论什么:

    1.需求讨论或技术讨论;

    2.成员预估需求所需开发时间;

    3.需求是否match人力时间,需求排入sprint

    4.交流一下感情。

    ▲每个任务的预估时间在最后由敏捷教练综合判定

     scrum会后你的工作:

    1.整理这个sprint内的需求列表;

    2.整理每个需求的预期开发时间;

    3.撰写故事版上的小纸条;

    4.把小纸条贴到故事版上;

    5.制作一个燃尽图。

    一个改良版的小纸条,写明开发者、任务描述、预估时间和每日燃尽时间

     故事版布局如下:

     一个标准的故事版:最开始所有的小纸条都在待开发一栏

    到此为止,你可以开始run起一个sprint

    以为这就完事了?天真。

    接下来你必须来参加每日举行的项目短会。为了缩减会议时间,我们一般站着开——所以也叫站会,早上上班后或晚上下班前,抽出十到十五分钟时间,完成它。

    ▲每日站会

    站会都有什么人参加:

    1.你(项目持有者)

    2.SM

    3.其他scrum成员

    站会干什么:

    1.昨天大家分别做了什么事,遇到了什么问题,如何解决或寻求解决方案;

    2.昨天任务的完成状态,剩余多少时间,是否需要进行时间修正(增加时间或减少时间),把已完成的任务流转到下一环节(把纸条从一个item内撕下,贴到下一个item里去);

    ▲任务进行中,小纸条的示例

    3.功能测试后是否有返工;

    4.交流一下感情。

    站会之后你的工作:

    绘制燃尽图

    ▲sprint的任务时间随着sprint的进程逐渐减少

    周而复始,完成了一个sprint后,你们开了第二次scrum会。这时议题多了一项:复盘上一个sprint

    任务未能燃尽;研发返工过多;测试需求淤积.....

    针对问题讨论解决方案,根据实际情况进行下一个sprint的任务安排。

    自此,我们在没有任何敏捷工具的帮助下,开始了敏捷的旅程。


    3

    敏捷不需要文档吗?


    敏捷了一段时间之后,产品进入正轨,项目拿到拨款,公司拿到投资,你们要扩大团队规模,新入职的同事想了解下产品和技术细节,你告诉TA

    你要不翻下backlog看看?这个实现你要不看一下代码?这个字段我也不记得有没有了....你抓包看下?

    新同事一脸懵逼,难道咱们没有文档吗?你自豪地指出:

    我们是敏捷团队。

    十几个人八九条枪的阶段之后,产品趋于稳定,团队逐步扩大。无论从内部协调还是外部沟通上对产品流程的正规化和文档化要求与日俱增。

    从短期收益上看,文档对于敏捷开发是非必须品,并且很有可能会拖慢进度。在一个sprint中,口头沟通显然效率更高,每个人都有精确到工时的任务,没人有等待文档更新的时间。强调文档就等于放弃灵活性。

    从长期和宏观上看,文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本,同时降低错误的发生概率。对于一个将要长期实施敏捷的团队来讲,文档让后续的工作效率更高。

    ▲一个以讹传讹的过程

    那么——谁来维护文档,怎么维护?

    我们挑选其中一个重要的文档:产品文档

    产品文档:PM虽然维护backlog、跟SM分解需求、开scrum会、写小纸条、开站会、画燃尽图、还有什么外部沟通啊......但你要认真把这个文档维护好。

    对又是你

    产品文档包括:

    1.需求;

    2.加入日期;

    3.开发版本;

    4.呈现和详细方案。

    长久来看,文档是提高效率的一大利器

    文档的时效性和灵活性远低于口头沟通,但却有它实在的好处。

    1.空间上,文档传播范围更广。规范化和常规化的内容形成文档可以大大减少沟通成本。尤其在多个系统协作的情况下,跨scrum、跨团队甚至跨部门的沟通时有发生,文档的重要性和便捷性不言而喻。

    2.时间上,文档流传性更好。团队不是一成不变的,有人离开有人加入。更新换代中,新人快速了解系统,老兵传承研发理念;在更大的时间跨度上,文档的存在就是对产品历程的完整追溯,你将不用他人帮助就可以了解到产品的大部分面貌甚至全貌。

    4

    大项目怎么引入敏捷?


    看起来敏捷方法特别适合产品常规迭代。有一种可能性是,你的产品需要插入一个巨无霸模块,与其说是模块倒不如说它几乎可以成为一个产品了。你想了想,这么大个项目怎么说产品、设计、研发、测试全情投入也得个一两个月。

    还能走敏捷吗?

    注意你的项目时间。有deadlinescrum是带着镣铐跳迪斯科,时间节点关乎sprint的大小。

    大项目敏捷之前,先得不敏捷几步。

    可能会发生一到多次需求讨论会。

    团队必须不厌其烦地理解需求或修正产品经理天真的幻想,产品经理使用不断完善的原型同团队进。在最后这次评审邀请项目成员和所有协同团队,除了敲定的产品功能,技术上需要得到一些初步结论(比如能不能做”)

    大项目敏捷中:

    1.deadline之前的时间分解为多个sprint。(deadline之前必须留出一定出血时间用以解决时间预估不足的任务、返工任务以及bug)

    2.将所有需求分解成任务,开一次全局scrum会。预估时间之后,分散任务到各个sprint中。在时间较紧的情况下,sprint的容量就要相应增加。

    ▲一个需要加班的sprint

    3.进入敏捷流程,常规scrum会、站会,燃尽图,故事版。未完成任务在scrum会上重新预估时间,滚入新sprint内,以此类推(按时完成sprint内的任务是目标。实在不行我们还有出血时间呢)

    4.别忘了文档。

    虽然被推崇备至,但敏捷并不是完美的开发方法。敏捷的最大的优势是灵活,而造成敏捷问题的根源也正是灵活。

    5

    文末再总结本文重点


    1.敏捷是一种流程、方法、理念,甚至信仰。

    用了敏捷管理软件不一定就是敏捷。敏捷的初衷是团队成员能够更加紧密地配合完成工作,线上的的流转如果削弱了这种配合性,反倒背离了敏捷的本意。实际上只要有白板纸张和笔,你的团队就能开始敏捷。

    4.我们敏捷了,不是不要文档了。在外部交流多、世代跨度长的情况下,文档的必要性显而易见。长期的面对面沟通最终会导致低效,这也是敏捷缺陷的根源。

    5.大项目开发中可以走敏捷,具体问题具体分析,需要根据项目特点制定敏捷计划。


    https://mp.weixin.qq.com/s/cJHijlkysR58l-EhD_Q5aw


    展开全文
  • 敏捷开发必备的管理工具

    千次阅读 2018-12-28 12:57:32
    Leangoo可以帮助我们管理事务,需求管理,迭代管理,缺陷管理,测试管理,排列优先级等,随时随地可以了解到团队以及项目的进展情况。 可以在Leangoo中,定制你和团队的工作流,任务分配,实时同步,每个成员都可以...

    为什么选择 Leangoo

    很简单,因为它够简洁,够轻量,上手够快!

    因为我们的工作中有各种事物要处理,我们需要这样的敏捷开发工具来帮助我们解决问题并清晰的展开工作。Leangoo可以帮助我们管理事务,需求管理,迭代管理,缺陷管理,测试管理,排列优先级等,随时随地可以了解到团队以及项目的进展情况。

    可以在Leangoo中,定制你和团队的工作流,任务分配,实时同步,每个成员都可以最快速度了解到被分配的任务,与团队更好的协作。

    所有的项目进度,需求趋势,缺陷趋势都可以一目了然。

    也可以利用Leangoo的思维导图,可以把卡片通过树形结构组织起来,用来管理创意,知识,需求,测试案例等等。

     

    亮点:

    1. 轻量,操作简单,上手超级快。

    简单不意味着要以牺牲功能作为代价。Leangoo的核心是看板,整个页面设计很友好,可以直观的对任务一目了然。它配置性强,可灵活自定义,大量的操作都以拖拽的形式进行,并支持大量的快捷键!

       2.完美支持Scrum敏捷开发和看板方法

    Leangoo的设计融入了先进的敏捷管理思想,由多位业界知名敏捷管理顾问提供支持,并由专业的敏捷开发团队精心研发,完美支持Scrum敏捷开发和看板方法(如:燃尽图,工作量估算,看板周期等),并且可以轻松对接主流Devops平台,是敏捷研发团队首选的项目管理和协作工具。

       3.管理任何事务

    Leangoo可以管理任务事务,比如:

                 1).管理产品/项目规划和敏捷需求,协作进行需求。

                 2).管理敏捷迭代任务,进行任务协作

                 3).管理缺陷,进行缺陷处理的协作

                 4).管理测试场景和测试案例,进行测试协作

                 5).可视化跟踪项目和迭代的进展

     

       4.思维导图

    一个共享的思维导图,可以把卡片通过树形结构组织起来,用来管理创意,知识,需求,测试案例等等。

    可以多人协作,多人在线编辑,实时同步!

    看板统计:

    Leangoo的每一个看板都设计了看板统计功能,比如:

    1. 燃尽图——项目完成之前,对需要完成的工作的一种可视化表示。
    2. 任务周期——可查看每个任务所花费的时间
    3. 任务分布——可查看每个成员的任务分布情况

    项目跟踪:

    在项目管理的角度,Leangoo也提供了一些统计,比如:

    1. 项目进度 —— 项目进度是根据项目里面所有的需求看板进行统计的,进度值 = 已完成的工作量 / 总的工作量
    2. 团队速度——一个迭代中实际完成的工作量(单位通常是故事点数)
    3. 缺陷分布——展示项目中缺陷的分布情况,(下图所示)

    项目占比的设定以及每个成员参与的项目数量等

     

     

    企业管理:

    在企业管理的角度,Leangoo也提供了一些统计:

           企业仪表盘——整个企业仪表盘上展示了项目状态,需求趋势,缺陷趋势,吞吐量。

    • 项目状态

    项目状态饼图使用了红黄绿三种颜色来代表项目的健康状态。
    绿色表示项目的进度正常,红色表示项目进度有延迟,黄色则是指项目在红绿之间的临界状态。
    通过该饼图能对企业中所有项目的健康状态有大致的了解。
    其中:项目的健康状态是根据项目的需求看板的实际剩余量与燃尽图参考线的偏差进行判定的

    • 需求趋势——需求趋势统计的是每个月需求的变化趋势。
    • 缺陷趋势——缺陷趋势统计的是每个月缺陷的变化趋势。
    • 吞吐量——吞吐量统计的是每个月所有项目完成的需求总和、缺陷总和。

    项目列表:

    项目列表统计的是企业内所有的项目,统计项目进度、需求数量和缺陷数量,资源总数等

    集成

    Jenkins

    API接口

     


     

     

    展开全文
  • 原文地址:https://www.zhihu.com/question/54626462管理工具:1.需求管理工具confluence 是一个基于...2.基于敏捷管理的sprint、backlog、开发task、bug管理工具jira 是一个基于java的issue(问题、事项)管理器,...
  • 互联网敏捷 Scrum 和项目管理

    万次阅读 2018-07-03 02:46:07
    互联网敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多...本场 Chat 着重介绍互联网 Agile 敏捷的模型以及常用项目管理流程等内容。 本场 Cha...
  • 在德鲁克的一本书中,讲述了三...这个故事是讲目标管理的重要性的。 对于第一个人,你能期望他会全身心地投入到工作中去吗?领导怎么说,他就怎么做,只要能拿到工资就可以,教堂与他何干,所以别期望他的主动性和...
  • 它与别的认证不同在于它要求敏捷培训、敏捷项目工作经验以及包含敏捷实践、工具、技巧考试的结合。它结合了SCRUM(敏捷开发)、XP(极限编程)和LeanDevelopment(精益敏捷)。通过获取PMI-ACP认证,从业人士能够:...
  • 敏捷管理认证体系大起底

    千次阅读 2018-03-05 19:06:28
    敏捷管理认证体系大起底本人专注于敏捷开发实践,在IT软件开发和项目管理方面有丰富工作经验。目前获得PMP,下一步致力于敏捷实践与敏捷认证。这段时间不断有小伙伴在问从事敏捷相关的工作都有哪些培训和认证,趁着...
  • PMIACP认证验证了从业人士理解、应用敏捷原则及在项目上实践的能力。 码字不易,有需要可以点赞收藏下~ 我自己也创建了个ACP考试资料分享和纯交流群,点击即可加入 它与别的认证不同在于它要求敏捷培训、敏捷项目...
  • 传统项目管理与敏捷管理的区别

    千次阅读 2017-05-15 14:18:44
    CMM/CMMI 与 Agile 是两种不同的软件研发管理和过程体系,区别在于前者重量,后者轻量;Agile 包含了更多具体、实用的软件工程技术方法,而 CMM/CMMI 提供了更多以数学统计为基础的过程管理和质量控制技术方法。在...
  • Dream big, work smart, deliver fast 使用Atlassian的产品已经有三年多,但是大部分主要以JIRA和Confluence为主,今年年初加入一创业团队负责技术团队的搭建,从零开始通过部署Atlassian产品、制定开发流程,由于...
  • 敏捷管理的利器:故事墙

    千次阅读 2018-06-22 18:01:24
    引言故事墙是敏捷管理的一个高效手段。只要妥善运用,其能够带来的好处远远超出管理理论中提及的。试想如下一些问题:假如一个团队,有一个环节(例如系统测试),人力少,投入低,影响了项目进度,如果让管理者们...
  • 一、背景 近30年来,企业面对的商业环境瞬息万变,...到2000年引入IPD-CMMI,转变为集团军作战模式,到2008年经过敏捷思潮的洗礼,开启了“班长的战争”这一全新模式,形成了 “敏捷+ DevOps”相融合的、独特的华...
  • 传统项目管理 VS 敏捷项目管理

    千次阅读 2019-10-08 19:04:02
    随着软件行业的发展,传统的敏捷项目管理模式,已经不适应于当前互联网行业快速迭代快速开发的需求,从而衍生出了 “敏捷项目管理” 传统项目管理敏捷项目管理有什么不同呢? 传统 VS 敏捷 传统项目管理是计划...
  • 最近微信教父张小龙的一篇 《警惕KPI和流程》再次刷爆朋友圈。这篇文章讲述了小龙对微信在8亿用户量级,1500人团队规模这个阶段的感悟,同时再次... 敏捷性,保持快速迭代;  3. 支持轮岗,提升人才能力,避免舒适区
  • IPD(Integrated Product Development): ...敏捷开发:以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 CMMI(希迈):由来自行业政府和卡内基·梅隆大学的软件工程研究所的一组专家开发。希迈模型...
  • 中秋假期把Jeff Sutherland的著作《敏捷革命》读完了,不得不说这是一本讲Scrum敏捷管理方法论的好书,有种相见恨晚的感觉。 虽然接触敏捷管理有几年的时间了,这本书还是让我受益匪浅。毕竟是Scrum的创始人,作者讲...
  • 上次分享的课程内容是:敏捷项目管理中的几个及职责 本次分享SM 框架及流程 各位群友大家好,本群ACP敏捷项目管理微课今日主题:敏捷项目管理框架及流程 传统的项目管理,有自己的管理过程,比如我们...
  •  当今社会尤其是互联网加速发展的中国,传统的单团队单迭代的项目管理模式已经不能为组织创造多大的价值了,组织或者个人只有使用多团队多迭代的敏捷管理模式,运用敏捷的各种方法,快速应变客户提出的项目需求才能...
1 2 3 4 5 ... 20
收藏数 105,779
精华内容 42,311
关键字:

敏捷管理