门户网站开发语言,五合一自助建站网站,wordpress添加所有文章页面,wordpress 安装主题57/103 高绩效敏捷团队的特征
参与式指导有效的决策开放和清晰的沟通价值多样性相互信任管理冲突清楚目标明确定义角色 和 职责协调关系积极的氛围
58/103 创建授权团队
敏捷强调 具备授权和积极性 的自我管理团队#xff0c;他们需要对项目成果充分负责#xff0c;授权是…57/103 高绩效敏捷团队的特征
参与式指导有效的决策开放和清晰的沟通价值多样性相互信任管理冲突清楚目标明确定义角色 和 职责协调关系积极的氛围
58/103 创建授权团队
敏捷强调 具备授权和积极性 的自我管理团队他们需要对项目成果充分负责授权是
责任 和 所有权朝着共同的目标工作理解为什么要做决策衡量决策对于所有干系人的影响创造更多权衡
59/103 自组织团队
敏捷团队领导应该在组织接受基本原则的情况下描述高层级的迭代目标让团队确定如何最好的完成工作而不是提供详细的任务清单
目标确立团队的目标与价值授权团队要自我抉择如何最好地完成工作沟通团队成员之间需要互相了解互相尊重可视化工作任务的可视化辅导团队可能需要的培训技术援助奖励针对好的团队要有经济上或象征性的奖励
60/103 服务型领导
也叫 仆人型领导。以服务员工为第一要务。更多的是以指导、培养、授权、委派、支持、帮助、称赞、倾听 等对待员工
仆人式领导的要求
倾听倾听团队成员的内在声音定期反思说服不用职务上的权威在组织内推动决策而是努力让团队信服感同身受每个人都需要别人接纳自己并且认知自己心灵的独特性省察高屋建瓴瓴房屋上的瓦从一个统一的角度来看到问题和形势帮助理解有关道德和价值观的问题致力于员工成长帮助团队里的每个人成长不仅仅是职业成长还包括 个人成长、心灵成长预见力吸取过去的经验教训了解当前的现实明白决策可能带来的结果抽象化仆人式领导应努力培养自己“宏伟梦想”的能力能够从抽象化的角度来透视问题考虑长期目标
61/103 敏捷服务式领导
敏捷 坚信自我管理的团队他们不需要任务驱动而是自我驱动需要帮助去凝聚、组建敏捷管理者用他们的行为去满足团队需要同时愿意去帮助团队实现目标在敏捷团队中价值应该被珍视包括信任、同理心、协作 等超级团结的团队
62/103 领导 VS 管理
领导关注管理关注人员任务授权控制做最正确的事把事情做对方向速度原则实践
63/103 教练 和 辅导
在敏捷中指导团队涉及 教练和辅导方法每部分有它不同的关注和技能去帮助团队交付成果
敏捷教练一定会要有积极的心态 跟不同团队共事时具备平衡视角不要比较、不要抱怨、环境决定一切每个团队具备不同的进展节奏可能会面临制约需要帮助去克服忠于团队成员价值认识社会心理 及 团队复杂性运用有效方法解决团队面临的问题开发方法进行非侵入型干预而改变团队动力干预的时候让团队和团队成员感到舒服、认可敏捷教练技能 积极倾听提问语言和沟通给予反馈冲突处理
64/103 情商技能评估框架
【感知】共情但不要过于共情能够准确地认识、承认、参与和理解“情感、归属感”的能力【管理】该说的一定要合适的表达出来不要冷战不要等别人猜有效地管理、控制、表达情感的能力【决策】能够适当运用情感管理变化和解决问题的能力【实现】能够生产必要的情绪自我激励追求目标实现的能力【影响】自己一定要非常自律知道自己要什么自己先影响自己潜移默化中也会影响别人。向积极的人、成功的人、正能量的人去学习能够识别和唤起对自我及他人情感变化的能力
65/103 分布式团队
分布式团队难以实现集中办公的面对面沟通、渗透式沟通、及 隐性知识 分享所带来的好处
对于分布式团队建设要先想办法改善团队成员之间的关系借助一些工具改善分布式团队的沟通例如视频会议、即时通讯工具、基于展现的应用、交互式的白板 等
分布式团队特征如下
作为一个团队成员在不同城市工作每个地区的成员具备不同技能具有成本效益的均衡分布式团队
66/103 集中式团队
把 部分或全部 项目团队成员安排在同一公共区域集中办公来合作和分享信息。以增强团队工作能力。项目团队可以在办公区域张贴标语和项目进展图表以增进沟通和集体归属感
67/103 集中式团队 vs 分布式团队
集中式 团队分布式 团队团队成员全部在一个空间里团队物理分布问题得到非正式的及时解决正式记录产生的知识偶尔的互动会激发生产力确保过程的结构化运用团队基于冲刺目标来确定角色通过任务明确 定义角色集中办公使用视频直播、群聊天 等 及时信息共享区域作为团队渗透式沟通的地方有 论坛 或 企业信息中心
68/103 渗透式沟通
同处一室耳可听、目可视周遭的信息会潜意识的渗透到人脑达到沟通的效果
属于水晶方法cystal的一项敏捷原则
69/103 信息发射源
信息发射源在任何人都可见的地方显示信息。有了信息发射源大家不需要问任何问题kanban、燃尽图 / 燃气图、可视化图表 等 都属于 信息发射源
70/103 浪费的表现
浪费浪费的表现举例工作中途被打断工作开始后没有完成被打断代码写完没有测试额外的处理额外的工作却没有带来更多的价值 不需要的文档 不需要的认证 多余的功能不需要的特征 镀金 技术特征 任务切换 在几个不同的项目中进行多任务切换 多个不同的项目导致思绪总是要重新切换 同时在多个项目中等待为了等待审核和批准而延迟等待文档审批传递在组织之间沟通、信息交流 或 交接的过程中产生影响 工作交接 搬运 缺陷有缺陷的文档或程序需要纠正软件bug 71/103 适应性计划 与 瀑布型计划 的主要区别
通过实验和示范的方法来发现真正的需求适应性计划不断探索不断反馈不断纠正直到发现真正需求计划会在整个项目中贯彻始终适应性计划时刻随机应变计划在中间不断调整是经常的事情 72/103 敏捷计划洋葱图
敏捷项目管理简化了繁琐的流程和文档管理主张团队内部面对面沟通和交流。
敏捷项目中项目管理计划分不同的等级可以用洋葱图表示
愿景战略目标-路线图产品路线-发布发布计划-迭代迭代计划-日常每日计划
73/103 渐进明细
使计划的严肃性和应变性都得到保证 因为执行计划与编制计划的时间接近内、外条件不会发生很大变化可以基本保证完成第一期实施的结果出现偏差以后各期计划如不作出调整就会流于形式提高了计划的连续性 渐进明细就是规划时的一种接近值在项目的前期会进行概要的估算之后当开发团队有了新的需求后再进行更详细的估算
74/103 发布计划
发布计划可以在前期帮助所有干系人了解发布一个产品需要花费的整体时间。
发布计划可以作为项目小组前进的路标
根据产品愿景确定优先级先做最有价值的部分选择sprint冲刺一般建议14周一旦固定了sprint长度就避免在项目实施期间随意更改
Relese1
Product Backlog Iteration 1 feature 1 User Story 1 task 1task 2feature 2feature 3Iteration 2 feature 1feature 2feature 3Iteration n 75/103 迭代计划
一般在迭代开始之前制定迭代计划。
目的是为了制定当前迭代的开发目标以及 需要完成的工作目标 具体工作
迭代计划在迭代计划会后产生流程过程如下
讨论用户故事从Story分解“任务”团队进行任务估算团队成员对任务进行认领
76/103 时间盒
时间盒是一个 较短 而且 固定长度 的时间段。
在持续不断的变动中有一个稳定的点。不让整个交付团队因为无休止的变更造成混乱而失去控制。让交付团队可以集中精力解决最关键或最优先的问题。
应坚持的原则是
固定时间长度一般几天最高6周结束的日期不可变更时间盒内的资源保持稳定时间盒不应作为绩效考核手段考核指标应该是最终交付的产品要有明确的目标和稳定的范围减少范围的的变动比例 如果时间盒内需要追加需求需要置换某些用户故事如果不置换的话在当前时间盒内可能发生交付延期的情况可能既交付不了原用户故事又交付不了新用户故事并且敏捷教练要进行实践分析。如果有重大变化应取消当前时间盒重新计划并执行新的时间盒
77/103 番茄工作法
选择一个待完成的任务工作25分钟专注工作中途不允许做任何与该任务无关的事当番茄时钟响起休息5分钟
每4个番茄时间4*25100min1h30min后休息时间增加为15分钟以此循环合适的工作周期
78/103 过程裁剪
选团队可以决定是增加过程还是裁剪过程基于组织的业务需求而定
视组织的具体情况对过程进行有效的裁剪只有这样才能增加组织的敏捷性团队每个人都应该是对项目有实际价值的
“守”最初阶段须遵从老师教诲认真练习基础达到熟练的境界“破”基础熟练后试着突破原有规范让自己得到更高层次的进化“离”在更高层次得到新的认识并总结自创新招数另辟出新境界
79/103 宽带德尔菲基于群体的估算方法
宽带德尔菲 Wide band Delphi是由PERT和德尔菲法香结合得到的方法别名”PERT和德尔菲相结合得到的方法“。其主要思路是德尔菲法中参与估计的群体需要进行估计的是三种时间最乐观时间、最保守时间、最可能时间
基于群体的估算方法要求一组专家匿名提交估算。将“从众效应”和“光圈效应”的影响降到最低 80/103 计划扑克
宽带德尔菲法技术通常采用“计划扑克”来实施用卡片中的数字实现估算
参加游戏的人每人各拿一叠扑克牌牌上有不同的数字客户或者产品责任人为大家挑选一个Story并简单解释其功能以供大家讨论每个游戏参加者按自己的理解来估计完成这个Story所需的时间从自己手里的牌中选一张合适数字的牌并展示给大家看游戏参加者各自解释自己选择这个数字的原因尤其是数字最大和最小的人
牌解释0任务已经完成1 / 2任务很小123这些用于小任务5813这些用于中型任务2040这些用于大型任务100这些用于非常大的任务无穷任务是巨大的?不知道完成这项任务需要多长时间一杯咖啡我饿了
81/103 斐波那契数列费布纳西序列
斐波那契数列费布纳西序列指的是这样一个数列0、1、1、2、3、5、8、13、21、34、55···
数列从第3项开始每一项都等于前两项之和
敏捷中使用的是改良的斐波那契数列费布纳西序列01/212358132040···
82/103 故事点
故事点数描述“一个用户故事及其相关努力”总体规模的测量单元
故事点 是相对测量用户故事的故事点互相进行对比故事点是团队对运用计划扑克宽带德尔菲、斐波那契数列(费布纳西序列)等估算技术确定的故事点对一个项目来说是独特的不能同其他项目相比较分配故事点需要考虑的内容 【任务规模】故事规则取决于以下因素复杂性、投入量、风险大小【相对价值】故事点数规模的相对测量绝对值不是很重要【估算】估算运用基准来完成相对值被运用选取最小故事估算价值为一个故事点
敏捷如何高效估算故事点
敏捷开发与故事点介绍
敏捷开发的核心理念敏捷开发不仅仅是一种软件开发方法更是一种思维方式。敏捷开发鼓励团队快速响应变化持续交付有价值的软件并始终将客户的需求放在首位
敏捷开发的核心理念包括
个体和互动敏捷开发强调团队成员之间的互动和沟通认为它们比流程和工具更为重要可工作的软件敏捷开发的目标是持续交付可工作的软件而不是完美的文档或计划客户合作敏捷开发鼓励与客户紧密合作确保软件满足客户的真正需求响应变化在敏捷开发中变化是一种机会而不是威胁。团队应该灵活地应对变化确保项目始终与市场和客户的需求保持一致
什么是故事点
故事点是一种量化任务复杂性的方法。与传统的工作量估算不同故事点更加注重任务的相对复杂性和不确定性
故事点的估算通常基于以下几个因素
任务的复杂性这涉及到任务的技术难度、涉及的系统组件数量、需要的技能和专业知识 等。一个涉及多个系统 或 需要特定技能的任务可能会有更高的故事点任务的不确定性这与完成任务所面临的未知因素和风险有关。例如如果一个任务涉及到新技术或者团队之前没有经验的领域那么这个任务不确定性就会增加相应地它的故事点也会更高任务的工作量尽管故事点主要是衡量复杂性和不确定性但完成任务所需的时间和资源仍然是一个重要的考虑因素。一个需要大量时间和人力资源的任务可能会有更高的故事点
除了上述因素外故事点估算还可能考虑其他与任务相关的因素如任务的依赖关系、外部约束等
故事点估算的目的不仅是为了提供一个任务大小的度量更重要的是为团队提供一个共同的参考框架帮助团队成员之间建立共识确保每个人对任务的理解和期望都是一致的。通过使用故事点团队可以更加系统地进行任务的优先级排序更加合理地分配资源更加有效地跟踪和管理项目的进度
为什么需要故事点估算
故事点 与 工作量 的区别
故事点 与 工作量都是估算任务的方法但它们有本质的区别。
【工作量】 估算注重任务完成所需的时间 工作量估算往往是线性的即任务的大小直接与所需的时间成正比
【故事点】 估算注重任务的复杂性和不确定性 故事点估算则是非线性的故事点估算考虑了任务的各种复杂性和风险可能会导致任务的故事点远高于该任务实际的工作量 故事点可以使能力不同的成员在估算同一个任务时快速达成一致
例如一个任务可能很简单但由于某些未知因素该任务的不确定性很高因此该任务的故事点可能会比实际工作量更高。
故事点估算的价值
可以帮助团队更好地规划迭代和发布团队可以更加客观地评估任务的大小优化资源分配团队可以更加合理的跟配资源提高项目的成功率确保项目始终与市场和客户的需求保持一致帮助团队更好地理解和掌握项目的进展和风险帮助团队建立一种共同的语言和理解促进团队成员之间的沟通和合作
与传统的工作量估算相比故事点估算更加灵活和适应性强可以更好地应对项目中的变化和不确定性。
故事点估算的常见方法
【斐波那契数列】斐波那契数列是一种常见的故事点估算方法它使用斐波那契数列如1,2,3,5,8···来表示任务的复杂性。斐波那契数列的优点是可以提供一个相对稳定的任务大小度量避免过度估算或低估任务的复杂性【T恤尺寸法】T恤尺寸法使用T恤的尺寸如XS、S、M、L、XL来表示任务的复杂性。T恤尺寸法直观简单容易被团队接受。但T恤尺寸法有一些局限性例如T恤尺寸法不适用于非常大或非常小的任务【估算会议 与 规则扑克】估算会议是团队成员共同参与的活动通过讨论和投票来确定任务的故事点。规划扑克是一种常用的估算工具规划扑克可以帮助团队成员更加客观地参与估算。规划扑克的使用方法是团队成员首先独立地为任务估算故事点然后一起讨论并达成共识类似“宽带德尔菲-计划扑克”
如何提高故事点估算的准确性
团队合作与沟通团队合作与沟通是提高故事点估算准确的关键。团队成员应该共同参与估算分享知识和经验确保估算的准确性和一致性。此外团队应该定期回顾估算的准确性根据实际情况调整估算方法和标准定期回顾与调整团队应该定期回顾估算的准确性根据实际情况调整估算方法和标准这可以帮助团队不断学习和改进确保故事点始终与项目的实际需求和目标保持一致使用工具与技术辅助现代的敏捷工具如Jira、Trello提供了许多故事点估算的功能可以帮助团队更加高效地进行估算。这些工具不仅可以自动计算故事点还可以提供历史数据和统计信息帮助团队更好地理解和掌握故事点估算的技巧
面对挑战故事点估算的常见误区与解决策略
故事点估算虽然有许多优点但也存在一些常见的误区。
例如过于注重任务的细节忽视任务的整体复杂性或者过于依赖工具忽视团队的经验和直觉。为了避免这些误区团队应该持续学习与改进确保故事点估算始终与项目的实际需求和目标保持一致
在哪一个会议上进行故事点估算
如果有梳理会就在梳理会上进行如果没有的话就在计划会上进行
估算完成后可以任意亮牌吗
不可以必须一起亮牌并且在估算过程中团队成员之间也不可以互相讨论预估的点数
PO、SM参与估算吗
不参与只有 开发团队 参与估点注意是“开发团队”包括研发和测试人员
超过多少点数用户故事需要重新拆分
每个团队的基准故事点规模不一样所以没法给个确切数字但是建议刚组建的敏捷团队最好不要超过5后期可以根据团队的反馈进行调整 实际开发中发现了估算失误要不要修改点数
不要。估算是为了辅助我们的工作安排而不是用来管理员工的绩效表现。
为了达到精准的估算而耗费过多的时间精力这是本末倒置。
很小的需求也必须要团队集体估算吗
要。估点是团队对需求来理解对齐的过程如果需求真的很小估点的过程也会很快达成一致的不会耽误大家多少时间
83/103 相对大小故事点估算
团队自己定义故事点估算应该是将所有的时间都包括的规模是相对的
84/103 亲和估算快速更容易地估算大量用户故事
团队用于快速和更容易地估算大量用户故事的形式
亲和估算是估算用户故事工作量的方法
亲和估算的优势
快速简单决策制定过程透明可见亲和估算创造了一种积极合作的体验而非对抗性
亲和估算的步骤
团队确定相对尺码将不同规模大小的故事卡片按顺序排列并贴在墙上团队成员对每个故事卡片进行规模定义根据相对尺寸移动团队完成估算后产品经理可以对评估进行质疑和挑战就某个故事卡片重新进行规模估算
亲和估算的步骤详细介绍
【沉默的相对大小】产品负责人向团队提供用户故事敏捷团队悄悄地建立用户故事的相对大小。团队在水平范围内按升序排列故事。也可以通过重新整理笔记或索引来完成直到整个团队都对订单满意为止。这个步骤是“静悄悄地”执行的就像在mute映射中一样以保持过程的快速和非对抗性【编辑墙】团队成员在墙上编辑相对大小。此步骤涉及产品所有者PO和团队之间的讨论后者可以根据他们的相对讨论和决策重新排列第一步中决定的顺序【将项目放入相对大小桶】项目被放置在确定的“桶”中并根据选择的估计规模进行标记。例如木桶可以被标记为“非常小、小、中、非常大··”或者它可以基于一个非线性的刻度来标记例如1,2,3,5,8···【产品所有者的挑战】此步骤中的产品负责人可以与团队讨论大小。如果团队确实决定更改一个故事的大小他们首先将它从墙壁上移除然后根据与产品负责人的讨论将它放置在他们得到的修改大小上【存储数据】在整个团队完成估算之后将存储数据并记录关联估算。在完成这一步之后关联估算的过程就完成了
亲和估算是相对估算的一种形式其中团队成员将产品未完项条目组织到产品未完项条目组中每个产品未完项条目的大小相同或者 团队成员使用类似T恤尺码如小号、中号、大号、特大号作为估算尺度
亲和估算的参与者
项目的产品负责人交付敏捷团队敏捷专家
85/103 T恤尺码的估算
一种流行的敏捷相对估算技术中码、大码、加大码 等
操作简单
介绍团队使用相对估算的好方法亲和估算非常有效在进行用户故事估算前每个T恤尺码的基准需要由团队决定
86/103 理想时间
在不考虑其他因素的情况下完成工作需要的时间
理想时间的估算需要基于这样的假设
所估算的故事是唯一要做的工作没有意外的隐性工作或未了解到的工作所有需要的东西在故事开始前都会准备好故事开发过程中不会被打断
87/103 适应性计划特点
多层级的计划迭代时有迭代计划、发布时有发布计划、日常有日常计划客户参与到团队中通过不断地 反馈进度 和 推进速度 来管理期望值根据项目特征裁剪过程根据优先级更新计划确保估算能够考虑到风险、干扰和团队的可用性估算的精确度是有一定的范围性估算时要考虑外部的工作和精力分散的因素
88/103 周期时间
周期时间实际花费在工作项上的时间综合。当任务进入“工作”栏时周期时间就开始了前置时间从客户发出请求开始到该项工作被完成。即客户等待这项工作被交付的时间 89/103 漏网缺陷
漏网缺陷也叫作“溜走的缺陷”
客户发现的、试用阶段发现的、产品上市以后发现的、以及 应该在迭代阶段发现却没有发现的
不同的项目溜走的缺陷来源不同需要进行详细分析找到缺陷遗漏的原因
90/103 持续集成
持续集成是一种软件开发实践
持续集成即团队开发成员经常集成他们的工作通过每个成员每天至少集成一次也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建包括编译发布自动化测试来验证以尽快发现错误 代码质量保障步骤
统一编码规范静态代码检查单元测试持续集成代码评审 和 重构
需求调研市场需求、用户需求-- user stories 用户故事 -- themes release user story backlog 用户故事待办 -- 分解 -- sprint user case/task backlog 用户故事任务待办
持续集成 的好处
【减少风险】一天中进行多次的集成并做了相应的测试及时了解软件的健康状况【减少重复过程】通过自动化的持续集成可以将这些代码编译、数据库集成、测试、审查、部署 等动作变成自动化的无需太多人共干预【任何时间、任何地点生成可部署的软件】利用持续集成可以经常对源代码进行一些小改动并将这些改动和其他的代码进行集成。如果出现问题项目成员马上就会被通知到问题会第一时间被修复。不采用持续集成的情况下这些问题又可能到交付前的集成测试的时候才发现【增强项目的可见性】有效决策有些持续集成系统可以报告功能完成度和缺陷。趋势呈现如构建成功或失败、总体品质以及其他的项目信息
91/103 探针
探针Spike英[spaɪk]这个术语来自“极限编程XP”
一个探针spike指的是一个用来探索/寻找潜在的解决问题的方法
迭代前工作量不好估计敏捷开发造成技术方案不确定无整体规划迭代中方案变化交付风险大基于风险的探针spike
92/103 测试 驱动 开发TDD test-driven development
敏捷测试聊聊测试驱动开发_测试驱动开发模式-CSDN博客
测试驱动开发TTD是指在编写某个功能的代码之前先编写测试代码。然后编写使测试通过的功能代码采用“测试-编码-测试”的方式积累代码
优点
使开发者从使用者的角度出发深入思考用户需要的功能缩短了决策反馈链降低返工代价生产出内部质量尽可能好的软件自动化的单元测试和组件测试的安全保障使程序员可以频繁的重构
93/103 验收测试 驱动 开发ATDD
ATDD 验收测试 驱动开发不是一种测试方法论而是一种开发方法论
产品、开发、测试都需要参与到 ATDD验收测试驱动开发 中来
在“ATDD验收测试驱动开发”活动中团队需要就需求‘’定义出期望的质量标准和验收细则‘
4 个阶段
讨论收集验收标准问题提炼准备好测试开发直到通过测试演示客户验证
94/103 回顾会
回顾会是敏捷中普遍使用的方法回顾会发生在每个迭代后面可以让团队成员检视和提升自己的工作
优点
改善生产率总结经验教训识别瓶颈减少返工提升能力为知识共享提供了场地提升团队成员能力提高质量发现缺陷去除根本原因
95/103 回顾会步骤
【开场】设置阶段预设基调创造舒适的空间坦诚讨论‘’明确会议的议题和目标‘’【收集数据】回忆发生的场景收集和展示全面性的数据【产生见解】给团队时间评估收集的数据推导出 深层次意义 或 根本原因【决定做什么】考虑下个迭代如何改变识别出最高优先级的行动项设置可度量的目标【总结收尾】为团队成员提供交流和感激的机会总结团队哪些事情需要保留哪些事情需要改变
96/103 ESVP一种非常有意思的收集与会者心态的小活动
【Explorer 探索者】我希望能够引领大家找到我们项目的改进方向
【Shopper 采购者】我希望今天的会议上能够有振奋人心的改进方向
【Vacatiober 度假者】我并不想参加但我觉得来开会比干活有意思
【Prisoner 囚徒】放过我吧我不要参加这个会议
97/103 聚焦、散焦
消除参会者担心受到批判而产生的恐惧心理
聚焦散焦探寻xxx而不是 辩护xxx对话xxx而不是 争论xxx交流xxx而不是 争吵xxx理解xxx而不是 防备xxx
98/103 SMART原则
SMART原则5个原则
【S Specific 具体】目标明确且具体不能模棱两可【M Measyrable 可度量】必须是可以追踪、考核、评估的【A Attrainable 可实现】目标必须务实避免设立过高或过低目标【R Relevant 相关性】目标和完成目标的人要紧密相关【T Time Bound 有时限】目标必须具有明确的截止时限
99/103 价值流图
是基于精益生产概念而产生的由一系列步骤、增值、非增值活动组成是识别和消除过程浪费、提高效率、吞吐量和效果的核心工具
100/103 创建价值流的步骤
识别分析的产品创建目前流程的价值流识别步骤、顺序、延迟找出浪费为未来的流程创建新的价值流移除减少延迟、浪费、约束创建路线图规划流程的再次访问以持续优化
101/103 重构
重构就是在不改变软件系统外部行为的前提下改善它的内部结构
软件重构需要借助工具完成重构工具能够修改代码同时修改所有引用该代码的地方
在极限编程XP的方法学中重构需要单元测试来支持
重构的优势
改进软件的设计重构帮助尽早的发现缺陷提高代码质量更易被理解重构可以提升开发速度
102/103 鱼骨图
鱼骨图是由日本管理大师石川馨先生所发明出来的故又名“石川图”
鱼骨图是一种发现问题“根本原因”的方法 103/103 问法
5问法通过对一个问题点 连续以5个“为什么”来 自问以追究其根本原因
例子
why工厂地板上有漏出的油清除地板上漏油 因为地板上漏油 为什么地板上漏油 修理机器why 因为机器油封磨损 为什么机器油封磨损 更换机器油封因为购买的油封质量不佳更换机器油封规格
