敏捷管理

敏捷思维的4个高效特征

1、纪律性: 纪律性是敏捷研发和交付团队的基础,千万不要因为我们敏捷起来以及团队自组织,就不需要纪律。敏捷团队的纪律性可以说比任何其他研发模式的团队更为甚之。敏捷团队的纪律性无处不在,例如:频密的检视和作出必要的调整,不论是产品本身还是微观工作方式和过程;频繁交付可用产品;严谨的DoD条款;对时间盒的尊重;对团队合作规则的尊重和遵守;节奏;信息可视化;频密提交、持续集成和自动化测试,等等。 2、主动性: 没有主动性,何来竞争力?对比其他的模式,包括其他敏捷方法,Scrum是特别强调团队主动性的工作方式。我们期望通过多种举措和引导技能带来和培养团队主动性。例如,PO想办法让我们做的产品更有意义和意思,懂得从为什么开始来进行思考和沟通;重视Sprint的目标,特别是业务目标;有一个优秀的ScrumMaster或者敏捷教练来打造团队;

3 min read
敏捷管理

敏捷迭代和版本发布的关系

Scrum是敏捷管理中常用的工具,核心是快速为用户创造价值,及时进行迭代和可持续性版本发布交付。 最近也收到很多朋友的一个纠结问题,说敏捷迭代和版本发布有没有关系?基于这个关系可理解如下: 1、首先没有强关系,存在弱关系。共同点就是迭代和发布的对象一样,都是围绕用户故事或者需求进行开发和交付。 2、敏捷迭代Sprint 对内,版本对外。一个快速开发,一个基于成果对外交付。Sprint持续规划持续迭代,版本按需发布。 3、在工具的角度,迭代管理和版本管理是分开的、独立的。在版本维护的角度,可以按需选择迭代或者迭代的任务,进行选择性的发布和跟踪和追溯管理。

1 min read
敏捷管理

敏捷管理做好版本规划

敏捷管理中Scrum是最常用的敏捷开发工具之一,围绕为用户创造价值展开迭代的规划和迭代执行,并不断可持续进行迭代集成和发布。 为了更好的管理版本,需要进行很好的版本规划,例如在项目加的版本管理模块,可进行版本的相关管理,更好的管理产品版本,还可以把本版本预期要发布的范围做个预期目标规划,方便实时跟踪任务范围的状态。 1、每个迭代版本执行后就需要及时发布版本,每个迭代要求也是在质量上需要达到可用的状态,及时变向用户,不断基于市场反馈进行完善。 2、也可根据迭代的完成情况,规划版本范围,可选择多个迭代进行规划版本。当规划范围内的迭代没有完全完成时可再根据实际情况进行版本发布范围的调整。

1 min read
敏捷管理

产品开发中MVP是什么意思

MVP(Minimum Viable Product)的意思最小化可用产品,是让开发团队用最小的代价实现一个产品,以此最大程度上了解和验证对用户问题的解决程度。 MVP概念是由硅谷创业家Eric Rise在其著作《精益创业》 一书中提出的“Lean Startup精益创业”的一个理念,其核心思想是:开发产品时先做出一个简单的原型——最小化可行产品,然后通过测试并收集用户的反馈,快速迭代,不断修正产品,最终适应市场的需求,我们可以在几个方面简单的看下MVP所关注的维度。 1、最小化,速度大于完美:有时我们做产品或项目时,我们自己或者客户会有很多美好的憧憬和想法,需求很多,但到底哪些需求是用户最痛的点,有时我们基于分析或者客户也不明白。但项目又不能处于等待或者投入大量的调研阶段,否则也会浪费很多市场先入机会,所以只能梳理出最优先的需求去做,

2 min read
敏捷管理

敏捷Scrum每日站立式会议实践

敏捷Scrum站立式会议是有敏捷团队Scrum Team每日举行的站立式会议,是一种简短有效交流的正式例行沟通方式。 1、常规式实践:时间限制,每个成员按次序简短发言。 2、问题解决原则:2分钟能解决的问题当面解决,解决不了的会后问题当事人当面再沟通解决。也可以提出当前迭代遇到的技术和意料之外的情况和问题,原则是当前沟通引起的,常规性的需要日常去沟通。 3、会议前每个成员需要事先了解到整个迭代的进度情况,及时了解燃尽图Burndown chart和迭代任务进展情况。 4、看板方式实践:推荐电子看板,通过任务看板方便团队及时对看当前任务情况,可参考项目加的任务看板。没有电子看板的也可以用实物看板。 5、执行情况实践:站立式会议是对Sprint迭代管理的执行的每日考察和跟踪,一般当前迭代不能变更已经定下的需求或任务。如要变更,须要product owner和team一致同意,但是要非常慎重。如果经常这样做,

2 min read
敏捷管理

XP极限编程的特点

什么是XP极限编程,他与其他敏捷开发工具有什么区别?XP是一种轻量敏捷、高效、低风险、可预测、科学又充满乐趣的敏捷开发方式。与其他敏捷方法论相比,最大的不同特点如下: 1、在更短的周期,更早地提供具体、持续的反馈信息。 2、在迭代的计划内,可迅速定义一个开发计划,然后在开发过程中不断的完善它。 3、依赖于自动化测试进行监控开发进度和质量,并及早地捕获缺陷。 4、依赖于口头交流、测试和源程序进行当面沟通。 5、提倡和鼓励最简单化的设计和持续化演进式设计。 6、需要开发团队内部的紧密和当面协作。 7、尽可能达到程序员短期利益和项目长期利益的平衡。 8、更加注重代码规范化和代码重构文化以及结对式编程,对代码质量更加要求标准化和质量化,每个人都拥有了代码修改的权利和责任。

1 min read
敏捷管理

Scrum是什么?

Scrum字面意思是橄榄球运动员并列在一起相互快速争球,是橄榄球运动的一个专业术语,表示“快速争球”的动作。 橄榄球是一项目标集中,为了全力获得进攻权利,整个团队会自主自发的通过配合一步步向目标进攻的活动。类似团队一起进行开发项目时,通过团队合作把项目一步步推进,和打橄榄球一样迅速,充满激情,把这样的开发方式称为Scrum敏捷开发,并可及时看到开发成果。 Scrum目的是为了提高软件开发效率,小步快跑,快速的把已知的需求进行迭代产出,为客户创造最优先可见的价值。 如今Scrum已不仅应用在软件开发、互联网领域,在零售、投资、教育等等行业都进行了更多创新的方法和落地。Scrum框架也促进团队成员之间的有效沟通和信心的提升,同时也能最快的被客户认可。大概内容包括如下,可点击相关链接进入参考了解。 1、Scrum敏捷开发的基本概念 2、Scrum Team的敏捷状态 3、

1 min read
敏捷管理

Scrum迭代回顾会议Sprint Retrospective Meeting

敏捷开发管理原则之一就是坚持不断完善,持续改进。无论Scrum团队再优秀,也有改进的机会和空间,Scrum团队每次迭代结束后一起留点时间集体思考本次迭代中哪些方面做的好、哪些方面需要改进,这就是迭代回顾会议。 1、迭代回顾会议由Scrum Master主持,没有Master角色的团队就有PO主持。 2、整个Scrum Team和相关干系人参与,原则上是参与Scrum Plan会议的成员都要参与,并建议Team之外的团队在局外的角度给予更多建议。 3、Scrum Team整个团队成员每个成员都要进行总结和思考并提出改进建议和具体方案。 4、Scrum Master会对本次总结进行详细的纪要,并会对改进建议和方案进行详细梳理。 5、所有的改进方案会作为后面迭代需要注意的一些项,并进行执行和实践。 具体迭代管理方式,可参考项目加的 Sprint迭代管理模块。

1 min read
敏捷管理

Scrum迭代评审会议Sprint Review Meeting

Scrum每个Sprint迭代交付结束后,会发起迭代评审会议Sprint Review Meeting,目的是检查评审所交付完成的迭代成果是不是符合迭代预期。 1、迭代评审会议由Scrum Master主持,没有Master角色的团队就有PO主持。 2、整个Scrum Team和相关干系人参与,原则上是参与Scrum Plan会议的成员都要参与。 3、本次迭代的每个任务负责人来演示和讲解自己的成果,整个团队基于成果一起检查此任务是否符合预期。 4、对于不符合交付预期的任务会再创建一个新的需求故事放在需求库中重新按照优先级进行迭代规划,对于符合的预期的任务才算真正的结束。 5、如果在演示评审中发现一些缺陷,也会提交到缺陷列表中。 6、演示和评审讨论结束后,Scrum Master会对本次评审做出总结,也会作为迭代回顾的参考信息。 具体迭代管理方式,可参考项目加的 Sprint迭代管理模块。

1 min read
敏捷管理

Scrum之迭代规划会议Sprint Plan Meeting

Scrum每个Sprint迭代,原则上会最优先实现给用户带来价值的用户故事,为了保证每个迭代以最快的速度产出可行性的成果,需要进行迭代规划会议Sprint Plan Meeting进行整体的评估和达成一致。 1、评审会议Scrum Master主持,没有Master角色的团队就有PO主持。 2、整个Scrum Team和相关干系人参与,可基于自身团队的特点来判断需要参与的干系人,例如有的产品的用户故事需求来自市场,那就需要市场人员参与,来讲述他提出相关需求的思考。 3、决定本次迭代的时间周期,一般建议为两周,可根据项目或团队自身情况而定。 4、决定当前迭代最需要解决哪些用户故事,同时进行优先级的再次排序,用户故事的工作量大概是多少并做出评估。 5、决定当前迭代有没有需要解决或者完善的已知缺陷问题。 6、Scrum Team团队需要主动挑战本次迭代的相关需求或分解的任务,并指定负责人。 7、最后整个Scrum敏捷开发团队一起做出承诺,

1 min read
敏捷管理

拥抱需求变化是敏捷开发管理原则之一

敏捷开发管理有一个原则就是拥抱需求变化。 这是它和传统性项目管理的一个最大的区别,传统的项目管理为了防止需求变更,才开始从需求调研和分析开始并把它文档话,在这块做了大量的工作,但问题是需求变更时避免不了的,只能通过这些方式做到相对降低。所以需求和需求变更更管理是瀑布式或者流程式的项目管理最头疼的地方,大家都用很多招来应对。 需求变更在敏捷开发管理里就是新的需求,产品关注的重点是在于“这个需求变更对用户是不是有价值的,有价值的就会作为一个新的用户故事按优先级进行排序去做迭代规划”。 所以不同的项目管理方式,大家关注或者沟通的出发点不一样。当然前提是什么样的项目适合怎样的项目或者产品研发方式,需要开始时沟通清楚,没有谁对谁错,只是看怎样更合适,否则后期大家在这个最根本的基础点上会存在很大偏差。

1 min read
敏捷管理

Scrum之燃尽图Burndown Chart概述

燃尽图Burndown Chart是敏捷开发管理中呈现某个迭代开发进度的一种可视化图表。 由X,Y轴组成。Y轴一般代表剩余的工作量或剩余的User Story数等,习惯做法为代表剩余的工作量。X轴代表当前迭代的时间段,由迭代开始时间开始,结束时间截至,每天为一个时间点。图表中由参考线和实际工作线组成,一条为从Y轴最高的剩余工作量(最初评估的工作量)为起点,到X轴的迭代结束时间点为终点的一条直线为参考线,然后就是每天工作量变化后的实际曲折线。所以燃尽图顾名思义字面的意思为随着时间的演进,每天燃烧掉了多少工作量或者故事卡片,然后当前还剩余多少工作量。 Burndown Chart的实际折现图代表着当前迭代的进展速度,为了统计出此数据,所以Scrum Team在每天都必须填写Worklog,录入每个任务完成或剩余的工作量,有了这个基础数据,它的实际工作线才能画出来。让我们一起看下在实际工作中大概有几种常见的图形形状。 实际折线图在第一天的剩余工作量反增不降,这种情况代表此团队的迭代规划不是那么严格,迭代开始后还可以在此迭代中添加新的有价值的任务,这样剩余工作量会增加。

2 min read
敏捷管理

Scrum之Product Backlog和Sprint Backlog概述

1、产品需求库 - Product Backlog产品总的需求库,用来收集产品所有的用户故事,并按照需求本身对用户价值的优先级进行排序。每个需求按照用户故事User Story的大概写法进行详细的描述。需求梳理人和提交人,一般有Product Owner负责人进行,有的团队每个Scrum Member也可以提交。需求来源:用户,客户,市场,销售,产品团队,研发团队,测试团队等等都可以进行需求的反馈。Product Owner基于对用户价值的判断有权决定接不接受这些需求,这也是PO的职责之一。2、迭代需求库 - Sprint Backlog每个Sprint的需求库,在每个迭代规划时会选择当前迭代需要完成的需求或者大的缺陷。一种做法是PO可以先规划好Sprint Backlog,

1 min read
敏捷管理

Scrum之Epic的概念和使用场景

在敏捷开发工具Scrum中,Epic顾名思义为史诗故事集,一个比较大的User Story,里面可包含很多小的Story。主要应用场景如下: 一个独立的模块:一个模块里会有很多小的Story,放在一个Epic里可保证这些小的用户故事的相关性,方便上下文的理解,这种情况一般可以把一个模块建设成一个Epic。相关故事组合的故事集:在梳理User Story时,如果存在一些先后循序和很强的干系关联性,可以把这些用户故事放在一个Epic里,以便在研发这些故事时不影响正常的依赖关系。第三方集成相关的需求故事:在模块或者功能开发中,会遇到很多和第三方API或者SDK进行集成,这个时候可以把系统本身的需求和第三集成的需求放在一起合成一个Epic。

1 min read
敏捷管理

用户故事UserStory的概念

用户故事顾名思义就是我们做一个产品或者一个项目甚至一个功能时,所使用用户的故事。就是这个用户他面对什么问题,我们通过怎样的方式去解决,他用起来即解决了他的问题并且用起来很爽。 使用用户:这里强调的是最终端的使用用户,所以当一个产品经理在做产品需求梳理时,一定要清楚这是不是用户的需求,能不能给他带来价值。不是领导:这里强调的是:产品不是给领导服务的。因为我们发现在做产品中,很多需求是领导拍脑袋拍出来的,如果这样的领导了解终端用户的需求也是可以的,就怕不了解用户,更不了解产品背景甚至市场。是描述需求的一种敏捷形式:我们经常会说,如果一个功能需求不能用简短的一句话描述出来,那我们就必须再审核下这个需求是不是有问题。 大概格式为:作为一个<什么用户角色>, 处于<什么场景下>,想要<

1 min read
敏捷管理

Scrum Team成员的敏捷状态和做事闭环

敏捷管理之所以能快,除了它的核心的项目管理价值观和出发点外,Scrum Team成员才是这个管理方法论能不能执行起来和落地的核心。很多团队在转型敏捷管理时最大的困惑之一也是如此。类似我的团队有没有这个基础?在执行时会不会出现放羊的现象等等顾虑问题。 其实对团队成员所谓的一些自驱动,自组织,自学习等等,我们可以换个思维理解,可以理解为做事的闭环: 那就是自己交代给别人或别人交代给自己的事,怎样会产生闭环的结果。 能力匹配和挑战 对能力内的任务能迅速解决或者帮助它人解决自己熟悉的问题,并不断去挑战自己感兴趣并且有更高难度的任务。主动反馈 对有依赖性工作的临时反馈,做完事情的及时反馈,就可达到很好的沟通闭环。结果负责 我们需要让自己愿意对结果负责,自己的结果预期和团队的预期或者项目全局的预期是怎样的?中间出现了偏差怎么办?发现了风险,自己会怎样去积极解决?这些如都能很好的处理,就可做到一个很好的“结果闭环”。能做到这个闭环,加上对产品或项目的全局观理解。任何团队或个人都可以敏捷起来。

2 min read
敏捷管理

Product Owner的常规职责和更高要求

PO常规职责,基本也是初级或中级PO都在做的日常性工作。 和产品内外干系人沟通和协调。确定和梳理产品需求。基于需求对客户带来的价值确定优先级。和团队一起规划、评审、回顾迭代。确定版本的发布范围和时间。不断确定产品产出是否符合客户或用户预期,调整迭代规划路径。有自己的MVP原则。PO所需自我更高要求的能力,也是高级PO要具备的。 产品核心方向和具体的路径以及相关要素。产品所带给市场的具体价值。对产品所在行业的理解。产品运营或基于运营结果对产品的调整和方案能力。对产品ROI有很好的管理。Scrum Master角色的重要性

1 min read
敏捷管理

敏捷Scrum开发管理实施中所面临的困惑

最近和一些朋友探讨敏捷管理Scrum的落地实施的话题,发现几个共同的困惑和大家一起探讨分享下。 现在团队用的瀑布式的开发能转型敏捷管理?团队成员对敏捷不了解怎么办?上了敏捷是不是打破了现有的团队结构?敏捷团队对团队成员的要求感觉好高呀?我的建议如下,基本也是大同小异吧 所谓的管理方法或者工具,没有可比性或者对与错,你需要去实践才知道。对于团队,不能束缚在某个定性的认知里,新的方法也需不断去试错。就像有的公司对技术的选型,不敢去尝试新的技术,但还整天纠结在对新技术的垂涎三尺。团队或者公司定义的一些职位或者岗位只不过一个代号而已,大家不要沉醉于头衔,而要关注自己的价值。敏捷团队的要求也是相对的,所谓的自驱动,自组织,自学习等等都是要求成员在自身意志或者态度上的转变要求, 我感觉它跟用什么项目管理方式没多大关系,那怕用的流程式的管理,这种要求也是需要的,只不过敏捷管理很正式的提出了这些观点。有些项目或者产品如果需求很清晰,再加上组织本身很固化的流程,例如需求增加或变更等都需要流程化,其实建议不用上敏捷管理,这种基于强预算强流程强执行的方式也是很好的。

2 min read
敏捷管理

站立式会议重在敏捷状态的保持和习惯养成

敏捷管理中的例行站立式会议,大家的做法基本都类似,每天早上固定时间(一般15分钟左右)整个Scrum  Team成员例行进行站立式会议。 重点过下当前迭代状态和昨天工作中的一些问题,控制在一个固定的时间范围,到时就结束,具体的问题在会议结束后由干系人去针对性的解决。 但大家有没有思考过[敏捷管理]本身为什么设定了这样的规则?他背后的逻辑是什么? 我的理解是:通过这种正式性的形式,让大家保持一种[敏捷心态],从而逐渐养成[敏捷习惯],我们也可以把它理解成一种[刻意性练习],让大家时刻都能感受到产品或项目每天都有新的进展。即可避免所谓的敏捷背后产生的不敏捷问题,也可避免传统项目管理方式中,常出现的信息不同步问题。

1 min read
敏捷管理

Scrum Master在Scrum敏捷开发中的角色重要性

很多公司和团队在进行敏捷管理的实践时,基于自身人力投入的因素会有各自的不同情况,有的把PO和Master这两个角色交给一个人去做,有的会设立独立的PO和Master。在我和多为Master沟通中,发现他们都会面临如下同样的问题: 1、Scrum Master这个角色的尴尬处境,感觉不到自身的价值所在。 2、和PO在执行上的冲突性,感觉务虚太多。 基于以上问题我建议如下: 1、Scrum Master本身拥有类似教练的职责。 2、团队在实践敏捷管理的过程中,敏捷状态是最重要的,Master也需要实时关注团队成员进行辅导。 3、维持团队的敏捷执行,如站立式会议、迭代规划/评审/回顾等组织和执行以及沟通。 我们可以把Scrum Master教师可理解为军队编制中的政委,PO就是产品军团长总指挥,政委负责日常的敏捷的相关执行。在公司或团队预算允许的情况下,我们认为是很重要的一个角色,

1 min read
Scrum敏捷开发常用概念
敏捷管理

Scrum敏捷开发常用概念

Scrum敏捷开发管理是最为常用的敏捷开发工具之一,我们先对Scrum中常用的一些概念和专有名词先有个大概的了解。 1、三大角色 Product Owner - 产品负责人Scrum Master - 敏捷教练或者敏捷实施负责人Team Members - 敏捷团队2、四大会议 Daily Standup - 日常站立式会议Sprint Plan - 迭代规划Sprint Review - 迭代评审Sprint Retrospective - 迭代回顾3、三大物件 Product Backlog - 产品需求库Sprint

技术
支持

项目加技术支持

交流
探讨

【项目加】项目管理交流三群


立即使用