21天敏捷打卡-敏捷估计与规划

通过之前的章节,我们可以清楚的知道,估算交付时间、交付成本、可获得利润,对项目是否可以落地有重要的影响。

敏捷估算的基础:

  1. 为什么要估算:估算可以让团队了解项目规格计算ROI和IRR,形成可执行许可的基础,有了估算,市场也可以提前的为后期产品上市做准备;
  2. 谁执行估算?:产品负责人、敏捷教练;
  3. 会议什么时候进行?自然是越快越好,在整个项目进行之间,同样随着逐步完善更多的信息,估算也要持续进行。敏捷提倡:拥抱改变,那既然拥抱改变,估算也要做调整,该加人手就要加人手。不要一味指望加班来压缩成本,随着90后,00后步入市场,这一代更注重生活品质,毕竟工作是为了生活;也别画饼,别把剥削说的冠冕堂皇;
  4. 估算如何创建?方式有多种:从各个维度,如时间、人工、物料等方面入手;
  5. 相对尺码:主要用于用户故事上;
  6. 价值点:交付价值和成果。也只有交付可用的软件,将客户利益最大化,客户才会把尾款付给我们。

项目规模测量:通过代码量、时间维度、人力维度、功能复杂性几点考虑。

  1. 故事点:是相对测量、相对独立、相互进行对比;
  2. 分配故事点要考虑:复杂性、投入量、风险等因素;
  3. 故事点估算的步骤:故事应拆分为小的,独立的。每个故事应由1跟人不超过两天的时间内完成,否则,就会陷入胶着状态,其代价往往是巨大的。同时团队要达成共识,敏捷是一种思想,需要团队成员转变思想,有一个掉线,就会影响行进速度和稳定向。在过程中需要不断的对话、协调、改进(年假、事假等未知因素,往往会影响团队的进度和故事点的完整性)。

故事点之类比估算:讲一个故事和其他故事相比,如果故事类似,其精确性、完成时间不能相差太大。同时建议研发团队一起评估,避免一言堂。

  1. 理想日:没人任何打扰,所有信息都可用的情况下专注的进行唯一一项工作;很多企业提倡多面手,即一个人可以做A岗位也可以做B岗位,认为这种就是高效?这是错误的,试想一下,编码10分钟开会1小时,开会想着编码,编码想着准备开会的发言。嘿嘿......代价也蛮高的,奇怪的是很多企业高层选择视而不见,没人向CEO提出这种不良现象。
  2. “编程10分钟,吹水1小时”通过这句玩笑,我们可以看出,研发人员不是机械的工作是创作,就要保持一个相对私密的空间,不受外部的打扰。这里多说几句:”很多初次走上管理岗位的研发兄弟们,往往会犯一个错误,亲自上阵;对各项评估会议不屑一顾,认为是瞎搞。这其实是思维没有转变过来,岗位的高度,决定岗位日常所要工作的重点。管理岗位的重点是规划、协调、避免风险、掌控进度,而不是亲自介入进来开发。用一句话总结:进化成人了,别再用猴子的思维了,你要关注的是一片香蕉林,而不是一两个香蕉的好坏“。

故事点和理想日的对比:切着更有助于驱动跨职能行为(协调资源、答疑等等支持行的工作);故事点的估算不会衰败:通过不断的对话确定思想统一;故事点特性,挟制了估算时间的增长。后者:有差异,来自团队成员;理想日的不确定性,会使外界认为是靠谱的,事实上即为不靠谱。

估算规模:敏捷评估建立在合理的预测估算,不应追求100%的精确性。有以下几种方法:

  1. 宽带德尔菲:用来收集项目的准确估算,在会议中只讨论估计是可能会遇到的问题,估计本身和所花的成本不做讨论。会议结束后,团队每个人进行单独的估算,一定要独立,拒绝结对式的估算。组员估算完毕后,收集所有估算,并在画表中画出来,展示差异,进行讨论。需要注意的一点,这是匿名的,即不要展示其姓名,记得有一次,集团做满意度调查,调查卷上还有姓名一栏,结果也如我所料,行政部门收集到的是100%满意。真正的问题反而被遮盖,失去本应起的作用,这是一种浪费。
  2. 步骤:团队选择组建成员、启动会议:讲明游戏规则和进行的程序、个人准备、估算会议、配置任务:收集估算单,汇总、任务评审:找出差异,达成共识。
  3. 计划扑克:由于本人极度反感扑克和麻将,这里不介绍,自己百度;

亲和估算:主要用来进行大规模的估算,优势:快速、简单、决策制定过程透明可见、积极合作而非对抗;

步骤:

  1. 沉默的相对尺码:产品负责人提供产产品待办事项,排列在墙上,由组员考虑每样物品在执行中所花费的时间、付出的努力。不讨论技术。
  2. 编辑墙:根据对尺码达成的一致性,移动尺码。
  3. 分类
  4. 产品负责人所面临的挑战:根据估算出来的尺寸,可能不符合产品经理的理想状态。那就需要根据实际情况重新估算或者其他的措施;
  5. 储备数据:最后一步,上述一切步骤,都是为一个结果:储备数据;

体恤尺码:优点与亲和力的差不多,即团队成员决定每个尺码的基准;L、XL、XXL的基准要统一;

计划扑克:不介绍,自己百度;

确定项目规模:主要看productBacklog中有多少事项,记住一点,ProBacklog动态而非静态的;需要在整个项目的生命周期进行不断的查看、调整;正是动态的,由于我们确定团队的规模,团队的数量、冲刺的持续时间、版本中的冲刺数量和目标上限;

估算是为了辅助我们的工作,而非KPI\KBI的考核,敏捷宣言中”适应变化而非遵循规范“的特性决定了我们估算所花费的时间成本,尽早的投入研发中才是不二的选择,过多花费估算时间来确定其100%精确性,实际上是一种浪费。

原文地址:https://www.cnblogs.com/atun/p/12094162.html

时间: 2024-08-29 05:51:57

21天敏捷打卡-敏捷估计与规划的相关文章

21天敏捷打卡--敏捷方法实现

常用的敏捷实践包含:精益.看板.Scrum.XP极限编程.水晶.DSDM动态系统开发.FDD功能驱动开发.AUP敏捷统一过程.OpenUP. <敏捷实践指南>将敏捷方法和看板方法是为精益方法的子集.因为他们都符合精益思想的具体实例,都反映了“关注价值”.“小批量”.“消除浪费”. 精益软件开发LSD TPS 面对场景 解说 原则 解说 过度 对员工和生产/研发过程施加不必要的额外压力 消除浪费 无法带来价值的事务就是浪费 违规 不切实际的需求导致过生产/研发程中的不均匀 尽快交付 短期迭代或小

敏捷21天打卡-敏捷项目管理(终章)

软件项目管理的两大主流管理模式:传统项目管理(预测型项目管理).敏捷项目管理: 传统项目管理(预测型项目管理):瀑布式.部分迭代开发模式,要求在项目一开始,需求足够明确.文档足够规范.迭代过程需求变更越频繁,其对项目造成的遭难往往越大.相信很多IT团队都尝试过,这里不赘述. 敏捷项目管理作为新兴的项目管理模式,简化了传统项目的流程,从繁琐的流程和详尽的文档中解脱出来.但并不代表敏捷不做计划,有很多人的观念“敏捷不做计划”这是错误,否“probacklog.scrum.看板.燃起图.燃尽图.用户故

21天敏捷打卡-用户故事地图

上图是基于敏捷故事的一个看板或者说敏捷流程中的一种,没有什么比亲身投入的效果更好.用户.组员需求方通过自身的投入.表达以便于让团队成员更加了解其想法和统一组员的想法.用户故事是一种思维,通即故事思维,运用故事的元素进行思考和设计,解决问题.达到某种效果.用户故事设计中核心是通过故事传递信息,引起共鸣,决绝问题. 讲故事不是一个简单工作,需要优秀的组织能力,清晰的表达方式,达到听众清晰明了我们想表达的.这里笔者建议,如果平时和人交流的时间太少,可以通过书写博客等方式,组织自己的中心思想,让听众知道

21天敏捷打卡-看板

看板在我们生活中随处可见,”课程表.餐厅的餐牌.加油站的今日油价等等“,其作用便于所有人了解点前的状态,例如通过课程表,可以让我们知道接下来课程的安排,做出有计划的复习.和课前准备. 在制造业中看板运用的价值更为突出,通过生产看板,可以及时了解到当前的生产状况.物料信息.品质信息,便于整个车间\小组都能理解当前的生产状态,并以一种自发的.有动力的相互协作的方式完成今日的目标.上图是一个我在开发中常用到的看板,通过”待处理.开发中.评审中.集成测试中等“几个状态,组员可以清晰的知道当前的工作进度,

用Leangoo做敏捷需求管理-敏捷团队协作

传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发.在这样的环境下,需求文档是信息传递的主体,也是一份契约. 然而详细的需求说明书有以下5大弊端: 单向的信息传递,容易出现理解偏差. 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断. 有了详细的文档,我们不会反复讨论它,相互确认. 书面文档不利于团队共享责任,它扮演了证据的角色.Scrum强调团队共享责任,不论是需求人

蒋步星:自助报表难自助,敏捷BI欠敏捷

这里有点标题党,为了对仗把题目写成这样.其实自助报表和敏捷BI深究起来是一回事,都是希望业务人员自己能完成数据分析和呈现,叫得通俗些是自助报表,洋气一些就是敏捷BI了. 经营分析软件中大都会提供丰富的固定报表,能够处理较复杂的计算需求,但毕竟死板.业务经营中常常会有临时性的数据分析需求,传统手段一般提交给技术部门去实现,这样显然周期长效率低,有时获得结果时已经失去意义了.如果能让业务人员自己做分析和呈现,那无疑会极大地提高决策效率,这就是敏捷BI产品主打的目标. 问题是,这个目标能达到吗? 如果

1.3敏捷宣言与敏捷过程的特点

01敏捷宣言 敏捷宣言,也叫做敏捷软件开发宣言,正式宣布了对四种核心价值和十二条原则,可以指导迭代的以人为中心的软件开发方法. 敏捷宣言强调的敏捷软件开发的四个核心价值是: 个体和互动高于流程和工具 工作的软件高于详尽的文档 客户合作高于合同谈判 响应变化高于遵循计划[1]  敏捷选择提出的12条原则已经应用于管理大量的业务以及与IT相关项目中,包括商业智能(BI).12原则包括: 1.通过早期和连续型的高价值工作交付满足"客户". 2.大工作分成可以迅速完成的较小组成部门. 3.识别

让敏捷工具在敏捷开发中发挥高效作用

敏捷软件开发绝不再是一个新名词了,但理解还是时时有偏差.敏捷宣言中的第一条“个体和互动高于流程和工具”,有人就误读为“有了沟通,一切都迎刃而解” ,因此花费大量精力整顿团队合作,却轻视了工具(技术).其实宣言中的意思只是想强调个人和沟通更重要而已. 实际上,既然是软件开发,在所难免得面临工具的选择,而且很多优秀软件实践离开强有力的工具支持都玩不转.在如今的软件开发世界中,工具(这里谈的是软件工具)层出不穷,数不胜数,那么到底该怎么去选择适合的工具呢? 本文将根据我十几年的企业级软件开发经验给出一

敏捷价值观之敏捷宣言(转载)

     一.个体和交互胜过过程和工具 人是软件项目获得成功最为重要的因素 合作.沟通能力以及交互能力比单纯的软件编程能力和工具更为重要 方法和工具是死的,人是活的,人要是太“面”或者协作不好,再强大的方法和工具都是白扯:      二.可以工作的软件胜过面面俱到的文档 过多的面面俱到的文档往往比过少的文档更糟 软件开发的主要和中心活动是创建可以工作的软件 直到迫切需要并且意义重大时,才进行文档编制 编制的内部文档应尽量短小并且主题突出      三.客户合作胜过合同谈判 客户不可能做到一次性地