敏捷文化

在过去的十年里，教育经历了数字革命，而Itslearning CCI（中心竞争与创新）正处于这一变革的核心。这是一个完整的教育平台，旨在满足学校和教师的需求，提供各种工具和资源，以改进学习和教育。 在本文中，我们将深入探讨Itslearning CCI是什么，它是如何运作的，以及它如何有助于学校的成功。 什么是Itslearning CCI？ Itslearning CCI是一个在线学习平台，专为学校从小学到高等教育的机构设计。它提供了一个数字学习环境，汇集了对教师、学生、家长和学校管理人员至关重要的功能。该平台促进了沟通、协作、内容管理、评估以及学生进展的跟踪。 Itslearning CCI如何运作？ 对于教师： 课程管理 教师可以在线创建、自定义和管理他们的课程。他们可以访问工具，上传教育资源，创建学习活动并设定目标。 沟通 Itslearning CCI通过消息、讨论论坛或通知等方式，便于教师与学生进行沟通。教师还可以安排在线会议。 评估 教师可以创建在线评估，跟踪学生的进展并生成评估报告。结果将自动记录在平台上。 对于学生： 课程访问 学生可以轻松访问他们的在线课程、教育资源和作业。他们还可以跟踪自己的进度，并接收来自教师的反馈。 协作学习 Itslearning CCI通过小组活动、共同项目和讨论论坛，鼓励学生之间的合作学习。 自主学习 学生可以按自己的节奏学习，从而促进了自主学习和自我负责。 对于家长： 进度跟踪 家长可以跟踪孩子的学习进度，查看即将到来的作业并了解学校活动。 与学校的沟通 该平台使家长可以轻松与教师和学校管理人员进行沟通。 Itslearning CCI如何促进学校的成功？ 资源集中化 Itslearning […]

尽管这种敏捷方法在当今不如以前那么流行，但极限编程仍然影响着现代Scrum以及倡导技术卓越的不同敏捷运动，例如软件工艺和DevOps。 我在不同的文章中多次提到它，但我从未写过一篇关于这种在21世纪初期非常流行的敏捷方法的具体文章。很多人听说过它的名字，但很少有人真正了解它的具体内容。 极限编程的起源 肯特·贝克（Kent Beck）、沃德·坎宁安（Ward Cunningham）和朗·杰弗里斯（Ron Jeffries）于1996年在克莱斯勒（Chrysler）的C3项目上进行了一种新的项目管理方法的实验，这一方法后来演化成了极限编程。它于1999年正式发布在《极限编程解释》（Extreme Programming Explained）中。 极限编程的五个价值观 极限编程基于五个关键价值观，我将在这里简要介绍它们。 沟通 极限编程要求团队内部进行卓越的沟通。沟通是一切正常运作的基础。 简化 重要的是要遵循“保持简单，傻瓜”（Keep It Simple, Stupid，KISS）的原则，只开发必要的部分。开发人员不应试图预测事物，即使这可能需要以后进行重构。 反馈 极限编程（XP）强调尽快进行交付以获取反馈，最好是尽可能频繁地获取。这也是XP提出短开发周期的原因之一。XP还鼓励使用测试驱动开发（TDD）和自动化的功能测试（例如BDD）来快速获得关于产品技术方面的反馈。及时获取这些反馈可以防止在生产环境中出现未发现的错误。 勇气 有时候，改变事物需要勇气。不应坚持不适合的做法或架构，而应有勇气选择新的做法。 尊重 虽然这个价值观在1999年并未明确提出，但肯特·贝克后来将其迅速加入极限编程，以强调尊重与我们一同工作的人是非常重要的，无论是团队内部还是外部。 极限编程中的迭代 与许多敏捷方法一样，极限编程强调进行短期迭代。每个迭代都应以迭代计划开始，在此期间，团队将共同定义在该迭代期间要完成的工作。 XP（极限编程）要求在每个迭代计划中从用户故事中选择对客户最有价值的故事。考虑到XP建议保持可持续的节奏，关键用户（或其代表）应根据先前的速度来规划迭代。需要注意的是，Scrum中现在使用的用户故事以及速度/可预测性的概念基本上源自XP。实际上，在Scrum中，开发团队选择他们认为能够完成的工作。 这些迭代的内容包括用户故事（功能要求）和技术任务。 XP中的迭代应该持续1到3周。但是，这种方法的项目还应该进行迭代发布（这个概念有些被Scrum采纳）。 每天都要进行一个Daily会议，除了迭代计划的日子，整个团队都要参加，以进行同步，就像Scrum中的所有团队一样。 当这个方法不再百分之百适用并需要改进时，团队也可以不时进行回顾。 这是XP的简化版本： XP（极限编程）的一些建 这是XP（极限编程）强制执行的一些建规则，奇怪的是，在许多成熟的Scrum团队中也可以找到它们。 今天，这已经非常普遍，但XP（极限编程）非常强调团队必须共同办公，工作在开放式办公空间，并且团队必须保持可持续的节奏。 […]

“海星回顾”是Scrum领域中一种非常经典的回顾方法。鉴于关于这种回顾的需求很多，我决定为您提供一篇关于它的文章。 这种“海星回顾”旨在寻找改进的方向，同时提出当前冲刺中的不足之处。虽然是一种经典方法，但非常有效。 请随时查看我们专门页面上的其他回顾方法： 我们的回顾方法 进行“海星回顾”需要以下准备材料： 便签纸 白板或大型便签纸（白板） 可擦除标记 总共需要30分钟来完成“海星回顾”。 进行“海星回顾”的步骤如下： 第1步：Scrum大师会在白板上或墙上的牛皮纸上绘制5个分隔区域。他会在每个区域上写一个标题：更多、更少、开始、停止、保持： 第2步：他会让与会者花5分钟的时间，使用便签纸指出他们认为： 在团队内仍然是负面的（更少） 在团队内是积极的（更多） 应该在团队内停止（停止） 应该尝试由团队开始（开始） 不需要改变（保持） 第3步：他将花10分钟的时间阅读所有成员在白板上张贴的便签纸；如果有疑问，贴出便签纸的人可以用几句话分享他们的想法。此时，他还将整理出涉及相同想法的便签纸，以提高团队提出的不同想法的可读性。 第4步：然后，Scrum大师将建议与会者花5分钟时间，用便签纸记录改进方向，但每张便签纸只能写一个想法。 第5步：接下来，他将建议进行投票，选出最重要的3个改进方向，这些方向将在下一个冲刺开始时立即实施。 海星回顾的结论 这种海星回顾非常受欢迎，是一种经典方法，已经证明其有效性。请不要犹豫，在您的团队中使用它。

燃尽图表（有时被称为燃尽图）通常在Scrum团队中使用，它作为一个跟踪工具，用于监控Scrum团队工作的进展。保持最新的燃尽图表可以为潜在障碍提供宝贵的见解，并帮助迅速解决它们。 虽然Scrum团队非常熟悉使用燃尽图的做法，但本文旨在面向对广泛采用的Scrum实践感兴趣的新手。让我们深入探讨如何设置燃尽图。 创建基本的燃尽图表模板 要启动燃尽图表，首先要建立一个垂直轴，表示故事点的数量。总结当前冲刺计划的所有用户故事的故事点（放在上方）。 提示：我强烈建议在您的燃尽图上放置贡献到冲刺目标的冲刺项目的总故事点。并非所有项目都与目标相一致。 接下来，将冲刺的工作日分配到水平轴上。您可以使用数字或字母来表示每一天，后者通常更容易阅读。 有了这个基础，绘制理想轨迹以达到冲刺目标。重要的是要注意，垂直轴代表“剩余的故事点”，而不是“已完成的故事点”。在冲刺开始时从35开始，然后在冲刺结束时逐渐减少到0。 然后，可以绘制一条红色的线性线，代表冲刺的理想进展轨迹，如下所示： 重要的是要承认，目标不是严格遵循这条线。目标是为跟踪冲刺进度提供一个参考点。如果出现问题，Scrum Master可以分析情况并找到解决方案。 一旦模板准备好，每次冲刺都需要在冲刺开始时调整轴值（使用Excel或Google表格等工具）。这样可以避免每次都需要重新创建整个图表。 保持最新的燃尽图表 要保持燃尽图表的最新状态，我建议将其可视化显示（例如，放在墙上）并每天更新一次。 例如，考虑我们的模板：如果一个具有2个故事点的用户故事在星期二完成，更新图表时，绘制一个表示减少2个故事点的蓝色曲线，如下所示： 事实上，这是一个简单的过程。 通过每天重复这个实践，您可以保持对冲刺进展的清晰视图。 然而，即使蓝线出现在红线上方，也要在引发警报之前谨慎行事。如前所述，严格遵循理想轨迹是不可行的。上下文和项目具体情况可能导致各种结果。 当燃尽图表的蓝线上升时 偶尔，您可能会注意到燃尽图表上的线（在一天内）上升。其解释很简单：产品负责人在冲刺中引入了一个新的用户故事。 如果这个新的添加与冲刺目标一致并得到开发团队的认可，线可能会上升。 然而，如果额外的用户故事与目标无关，避免调整曲线。在燃尽图表中简单地忽略这个用户故事。考虑将其标记为“障碍”，以表示其对流程的干扰。 作为Scrum Master，我建议遵循这一准则，特别是在观察到延迟时，蓝色跟踪线不应无故上升。燃尽图应该只反映在冲刺开始时承诺的用户故事（或直接为冲刺目标做出贡献的故事）。 结论：燃尽图 对于Scrum团队来说，燃尽图不是秘密。为什么不考虑在您的团队内使用燃尽图呢？

我非常喜欢敏捷金字塔的这种简化表现方式，它提醒我们在推动企业敏捷化过程中绝不能跳过任何步骤。我采用了由Nicolas Delahaye和其他敏捷教练制作的图示。 敏捷金字塔 敏捷金字塔的表现方式提醒我们，要从顶部开始，逐步向下发展，才能真正实现敏捷化，无论是在敏捷转型还是培训的情况下。 这就是敏捷金字塔的外观： 我们永远不能说得太多，但在实施敏捷实践甚至敏捷框架之前，首先要理解敏捷思维方式。正是这种敏捷思维方式将帮助您理解执行这些实践的重要性，或者为您提供指导，使您能够进行“敏捷”的Scrum。 从敏捷思维方式到敏捷宣言 当正确理解敏捷思维方式时，重要的是要充分理解敏捷宣言的四个价值观，这是由17位计算机项目管理专家创建的宣言。这四个价值观还提供了12个基本原则，以更好地理解从中产生的各种敏捷方法的预期结果。 正是这些价值观将使团队更好地理解Scrum、Scumban等框架的存在原因。要正确应用它们，需要理解其背后的理念。 有时候我们看到团队提前六个月准备了详细的待办事项清单…有时候我们看到他们将大型需求拆分为多个用户故事（成功与否不一），这通常是因为这些团队没有理解敏捷思维方式和敏捷宣言的价值观。 您可以随时查看我们的完整文章，以更好地理解这四个价值观。 从敏捷宣言到框架（然后到实践） 当敏捷宣言被充分消化后，团队可以选择他们认为最适合其情境的框架；实际上，对于更成熟的团队，完全有可能自行创建框架。 只有在完全理解敏捷思维方式和敏捷宣言的情况下，团队才能真正从实施敏捷方法中获得各种好处。 然后，团队可以选择适当的实践，以补充已制定的框架。这时，团队才真正变得敏捷。 正确遵循这个敏捷金字塔有助于避免只是进行一场大型瀑布模型内的实施阶段，这就是所谓的“水瀑布敏捷”。 敏捷金字塔总结 尽管有些人可能认为这种表现方式过于简单，但它的好处在于提醒我们不要在不理解其用途和基础的情况下实施所谓的敏捷方法。 请随时使用这种表现方式，以便身边的所有参与者都明白，投资于采用敏捷思维方式是实现成功的前提。

RACI矩阵（Responsible, Accountable, Consulted, Informed）是项目和流程责任管理的有力工具。它提供了每个涉及个人或组的角色的清晰概览，从而澄清了治理结构。 以下是一个简单的RACI矩阵示例（仅作参考）。您可以查阅我们更详细解释这一概念的文章：RACI概念。 然而，为了真正有效，定期对其进行优化是至关重要的。 在本文中，我们将探讨优化RACI矩阵的方法，将其转化为项目和流程管理中的战略资产。 RACI矩阵的建议 澄清角色和责任 优化RACI矩阵的第一步是确保每个角色都有明确定义。通过明确定义每个人或组的责任，避免模糊不清，这将有助于建立团队的信任和理解。 吸引利益相关者 有效的RACI矩阵需要所有利益相关者的积极参与。与他们密切合作，以确定适当的角色，并确保每个人都理解他们被分配的期望。利益相关者的参与增强了承诺和责任。 考虑技能和专业知识 每个个人或组都应分配适合其技能和专业知识的任务。确保分配到特定角色的人具备成功所需的技能。必要时，提供培训或额外资源。 对工作负载保持现实 避免让一个人承担过多责任。平衡分配的责任有助于防止超负荷工作，并保持团队内的健康工作平衡。确保每个人能够有效地专注于自己的任务。 定期更新 RACI矩阵不是静态的。它必须随项目或流程的发展而演变。计划定期审查以确保它与不断变化的需求保持一致；这可以通过回顾等方式来实现。新的利益相关者或范围调整应纳入考虑。 促进沟通 将RACI矩阵用作沟通工具。确保所有利益相关者理解它的运作方式以及对项目或流程成功的重要性。开放的沟通加强了理解和承诺。 避免过于复杂 过于复杂的RACI矩阵可能适得其反。保持简单易懂。集中精力于要点，以避免不必要的混淆。 使用项目管理工具 使用项目管理软件，如Microsoft Project（用于传统项目管理）或Jira（用于敏捷项目管理），可以将RACI矩阵的创建和管理集成到项目工作流中，从而简化工作。这些工具有助于实时协作和更新。 正式化协议 确保每个人或组都理解并接受他们在RACI矩阵中的角色。通过会议、签名或文件来正式化协议，以加强承诺和责任。 保持灵活 根据项目或流程的发展，准备调整RACI矩阵中的角色和责任，以反映实际情况。灵活性是效率的关键。 结论 – RACI矩阵的建议 一个构建良好的RACI矩阵是项目和流程管理的重要资产。对治理的明确定义将有助于减少项目生命周期中的冲突和时间浪费。 通过遵循这些建议，您可以改进RACI矩阵，使其成为一种战略工具，促进沟通、透明度和团队在责任管理中的成功。

项目管理是一个复杂的过程，需要平衡各种因素，以确保成功完成项目。在这些因素中，“三重约束”通常被认为是项目管理领域的一个关键概念。这些约束通常被描述为必须平衡以实现项目目标的三个关键元素。在本文中，我们将探讨项目管理中的三重约束及其重要性。 三重约束 范围 范围指的是必须完成的具体目标、可交付成果、任务和特性，以使项目成功。项目的范围提供了一个详细的描述，说明了必须实现的内容，并作为项目团队的参考点。对范围的任何更改或添加都可能直接影响项目的时间和成本。 时间 时间是项目管理中的一个关键约束。它涉及设定一个特定的时间框架，必须在其中完成项目。项目的时间表确定了里程碑、期限和任务的持续时间。项目时间表的任何延迟都可能影响项目的范围和成本，因此有效的时间管理对项目成功至关重要。 成本 成本是指分配给项目的预算。它涵盖了与项目相关的所有费用，包括劳动力、材料、设备和一般开支。项目经理必须确保项目保持在预算内，因为任何超支都可能影响项目的范围和时间。有效的成本管理对实现项目目标至关重要。 三重约束之间的关系 通常使用项目管理三角形来表示三重约束之间的相互关系。在这个三角形中，每个约束被表示为一个角，显示改变一个约束将不可避免地影响其他两个约束。例如： 如果范围增加（增加了更多的工作），时间和成本可能会增加。 如果项目的时间缩短（时间紧迫），成本可能会增加，范围可能会减少。 如果降低成本（削减预算），可能需要调整范围，并可能需要更长的时间来完成项目。 平衡三重约束 项目经理负责在三重约束之间找到微妙的平衡。实现这种平衡对于实现项目目标以及确保各方满意至关重要。以下是一些有效实现这种平衡的策略： 优先考虑范围：清晰地定义项目的范围，并确保与项目目标一致。在批准范围的任何更改时要小心，并评估其对时间和成本的潜在影响。 有效的时间管理：制定详细的项目时间表，考虑任务依赖关系、关键路径和潜在风险。及时监测进展，并立即解决任何延误，以保持项目按计划进行。 严格的成本控制：实施强大的成本管理体系。跟踪开支，保持准确的记录，并寻找降低成本的机会，同时确保不影响质量。 沟通与利益相关者管理：确保将所有利益相关者及时告知有关三重约束的任何更改或问题。管理他们的期望，并让他们参与决策过程。 结论 理解项目管理的三重约束，即范围、时间和成本，对于成功交付项目至关重要。这些约束之间的微妙平衡确保项目达到其目标，同时保持质量和利益相关者的满意度。项目经理在有效管理这些约束方面起着至关重要的作用，使他们成为项目管理领域的关键人物。

SAFe，即Scaled Agile Framework，是一种敏捷方法，旨在有效协调和管理大型项目。在这一框架中，有许多关键角色，用于确保敏捷开发的成功。其中一个重要的角色是团队教练。 团队教练是一位经验丰富的专业人士，他在指导敏捷团队和实施SAFe实践方面发挥着至关重要的作用。他的主要目标是支持团队采纳敏捷原则和价值观，以便他们能够高效、自主和高产地工作。 团队教练的职责 促进敏捷仪式 团队教练组织和引导敏捷仪式，如冲刺审查、冲刺计划、回顾等。他确保这些会议高效进行，确保所有团队成员积极参与。 教授敏捷原则 团队教练扮演了关键的教育角色。他向团队教授敏捷原则、软件开发最佳实践和SAFe的价值观。他帮助团队成员理解如何将这些原则应用到他们的日常工作中。 促进协作 团队教练促进团队内部和与其他团队之间的协作。他确保团队成员和谐合作，并能够有效地进行沟通。 消除障碍 当团队面临障碍时，团队教练会介入并解决问题。这些障碍可以是技术问题、团队内的冲突或任何妨碍工作进展的因素。 监控绩效 团队教练使用敏捷指标，如速度，来监控团队的绩效。这有助于衡量团队的进展并识别需要改进的领域。他必须关注整个程序递增（PI）的绩效，而不仅仅是单个团队的层面。 导师 团队教练作为团队成员的导师。他指导他们的职业发展，鼓励他们获得新技能并不断提高自己。 支持敏捷过渡 当组织决定过渡到敏捷方法时，团队教练通过与团队合作，以确保他们充分采纳敏捷实践和价值观，帮助促进这一过渡。 协助PI计划 他协助解救火车工程师（RTE）在PI计划方面的工作，这需要高效的协助。 团队教练所需的技能 出色的沟通和协调能力。 对敏捷原则的深刻理解。 能够与团队中的不同成员一起工作，包括开发人员、测试人员和产品负责人。 高度的同理心和解决冲突的能力。 熟悉SAFe框架和相关的敏捷方法。 总之，团队教练的角色是引导团队成功采纳敏捷实践，确保他们以协作、透明和高效的方式工作。团队教练在实施SAFe框架的组织成功中扮演着关键的角色。

在不断发展的网络开发领域中，全栈开发人员已成为至关重要的人物。这些专业人员是技术的工匠，能够处理前端（用户可见的部分）和后端（确保 Web 应用程序正常运行的不可见部分）。在本文中，我们将深入探讨全栈开发人员的角色和技能。 什么是全栈开发人员？ 全栈开发人员是具有深刻理解创建应用程序和网站的两个主要方面的 Web 开发专家：前端和后端。这意味着他们可以管理整个开发过程，从最初的设计到部署和持续维护。 前端 前端是用户直接与之交互的 Web 应用程序的可见部分。全栈开发人员精通创建用户友好界面所需的语言和技术，包括 HTML、CSS 和 JavaScript。他们负责设计、可用性和整体用户体验。 后端 后端处理 Web 应用程序的幕后操作，处理数据、管理数据库、确保安全性并处理业务逻辑。全栈开发人员擅长创建服务器、数据库开发、服务器端脚本和性能管理。他们确保应用程序平稳安全运行。 全栈开发人员的关键技能 全栈开发人员需要多才多艺，具备广泛的技术技能，包括： HTML/CSS/JavaScript：前端开发的基础，这些语言允许创建吸引人的用户界面。 前端框架：流行的框架，如 React、Angular 或 Vue.js，使构建交互式应用程序更容易。 后端语言：用于服务器端逻辑的语言，如 Python、Ruby、Node.js 或 Java。 数据库：数据管理至关重要，全栈开发人员使用 SQL 和 NoSQL 数据库。 版本控制系统：与其他开发人员有效协作。 […]

在飞速发展的软件开发和项目管理领域，敏捷方法已经成为提高效率和灵活性的重要支柱。Kanban和Scrum是两种常用的敏捷框架，通常用于提高生产力和管理复杂项目。尽管这两种方法有共同的目标，但它们具有独特的特点，并更适合不同的情境。在本文中，我们将探讨Kanban和Scrum之间的区别，并讨论何时使用每种框架。 Kanban与Scrum Kanban：可视化工作流 Kanban是一种灵活的敏捷框架，强调持续交付和工作流可视化。它使用Kanban板，通常由表示不同工作阶段的列和表示任务或用户故事的卡片组成。随着工作的进展，工作项在这些列之间前进，从“待办”到“已完成”。 Kanban的优势： 灵活性：Kanban非常适应进行中的工作和不可预测的情况。 减少浪费：通过专注于当前所需的工作，最小化了过度生产。 视觉清晰：团队清晰地看到正在进行的工作，有助于识别瓶颈并快速解决。 何时使用Kanban： 对于处理多个传入请求的支持团队。 在优先级经常更改的情况下。 用于维护任务和持续改进项目。 Scrum：迭代和固定时间 Scrum是另一个流行的敏捷框架，以其结构化和迭代的方法而闻名。Scrum项目被分为持续时间固定的迭代，称为“冲刺”，通常持续2至4周。每个冲刺都有其计划、每日会议、回顾和总结。产品待办列表包含了一系列按优先级排列的功能或用户故事。 Scrum的优势： 可预测性：冲刺提供了交付可交付成果的结构化时间表。 合作：每日会议和团队角色促进密切合作。 迭代改进：每个冲刺结束后都有回顾和总结，以学习和适应。 何时使用Scrum： 对于具有明确定义需求和目标的项目。 当团队可以承诺一致的冲刺持续时间时。 在开发工作具有明确目标的情况下。 选择合适的框架 选择Kanban和Scrum取决于您的团队需求和项目的性质。考虑以下因素： 项目类型：对于进行中或支持性质的工作，Kanban的灵活性非常有益。Scrum更适合具有明确目标的项目。 工作可预测性：如果您的团队更喜欢可预测的工作时间表，Scrum的冲刺可能是更好的选择。对于不可预测的工作负载，Kanban的持续工作流更为适合。 团队动态：您的项目要求团队协作和密切互动的程度可能影响您的选择。Scrum强调每日会议，而Kanban允许更多的自主性。 过程成熟度：考虑您的团队对敏捷方法的熟悉程度。如果是敏捷新手，Kanban的简单性可能是更容易上手的起点。 结论 Kanban和Scrum是旨在提高生产力和项目管理的强大敏捷框架。选择合适的框架取决于您的团队需求和项目的性质。通过了解每种框架的不同和优势，您可以明智地决定是使用Kanban来可视化工作流还是通过Scrum的冲刺和仪式来构建结构。最终，正确的框架将有助于您的团队高效有效地实现目标。