哈Ha！ 我叫振亚。 我是NORBIT的系统分析员，也是初学者。 我一直在研究Scrum，以便在我们的分析师团队中研究，尝试和评估其功能。 现在，在与RP
进行鼓舞人心的对话后，我意识到：停止思考，是时候这样做了。
在本文中，我将介绍我们准备代表Scrum管理员使用有限Scrum的经验：我们做了什么。 在撰写本文时，第15冲刺完成。 飞行正常！
我经常听说在成员不是开发人员的团队中使用Scrum框架。 各种专业知识的团队正在积极加入敏捷。 我以为Scrum最初是为全周期开发团队创建的，因此，如果团队与创建者想到的参考对象不同，则应注意许多困难或有趣的方面。 我在产品开发周期的专业知识和参与程度方面区分团队。 我认为，专业知识的方向并不限制使用Scrum。 但是参与产品开发的程度可能会受到限制。 他们中的一些人可以执行产品的整个工作周期，负责提供给客户的最终结果-在我看来，在这样的团队中，您可以使用成熟的Scrum。 其他人只是整个周期的一部分，是工作链的一部分。 在这种情况下，成熟的Scrum可能会有问题和困难。 这样的设计情况可能需要折衷。
本文将重点介绍负责产品开发周期的一部分的团队以及在其中启动ScrumBut的准备工作。
我们的启动行动计划如下：
- 研究和评估目前的状况以及期望的
- 建立一个现存的并在Scrum中成为模型的术语，
- 介绍并激励团队
我如何学习ScrumBut是什么
首先我用谷歌搜索并得到：
ScrumBut具有特定的语法：（ScrumBut）（原因）（解决方法）。 ScrumBut例子：“（我们使用Scrum，但是）（每天有一个Scrum，每天的开销太大了，（所以我们每周只有一个）。””（我们使用Scrum，但是）（回顾是浪费时间。 ，）（所以我们不这样做。）”
即 Scrum但是是有限的Scrum。 框架的这种变化使您可以从Scrum中获得所需的一切，而无需接受我们认为不需要的一切。 当然，这是一条湿滑的道路，因为 要了解什么是必需的，什么不是必需的，了解经典的Scrum非常重要，对于我来说，理解为什么它包含在完整版中很重要。
对我来说，有用的是：
- 文献研究： 软件开发的敏捷清单 ，“ SCRUM革命性项目管理方法”（约瑟夫·萨瑟兰德），“敏捷团队指导”（李萨·阿德金斯）；
- 与活跃的认证经典Scrum大师进行了一系列漫长而有趣的协商。
我如何评估当前情况
首先，我利用自己的远见，提出了几点供管理者评估。
收集团队成员的意见并记录下来。
我们有两个列表：输入中包含的内容和想要获取的内容。
在这里，我将列出合并列表和广义列表。
他们在入口处有什么
- 大型系统开发的大型项目。
- 单独的开发人员，支持和分析师团队。
- 一支很酷的分析师团队（约14人）。
- 仅在分析师团队的框架内采取行动的能力。
- 发布系统版本。
- Waterfall软件生命周期管理模型。
- 由于客户的任务随时出现，因此很难进行计划。
- 分析师的工作量不均。
- 分析师检查区的功能分布。
我们想得到什么
- 能够快速响应业务变化。
- 考虑并优先处理工作中的任务
- 有可行的产品增长预测。
- 短距离冲刺可以使您跟踪，记录和完成任务，并更准确地预测任务何时发布。
- 为分析师创建任务积压。
- 在任何给定时间，分析师都知道该怎么做。
- 交流解决复杂问题的经验。
- 以共享知识的方式建立团队合作是愉快，舒适且互惠互利的。
- 使用Black Jack等来组织您的Scrum。 :)
- 尝试新事物，提高团队合作精神。 帅哥 为什么不呢
造型
在建模阶段，我们分配了团队角色：我们确定了产品所有者，团队成员和我本人是Scrum管理员，冲刺的持续时间，填写待办事项和确定待办事项的优先级。
确定了强制性任务属性，用于跟踪的工作流，跟踪工具，为每种任务分配的人工时数估算值以及每个分析师的每周总工作时间数，并考虑了冲刺团队计划的完成情况，每日集会和回顾的时间和规律性。
产品的所有者和积压的人员是一组分析师的负责人。 决定组成2至7人的团队，以满足7±2的数量要求。 这是两个团队，根据要解决的任务的功能属性有条件地进行划分，该团队更接近原始模型，但与预期目标相距甚远。
为了进行跟踪，我们决定使用现有的TFS，在该状态下可以方便地将任务的状态设置为``新''，``正在工作''，``已完成''，并且可以在冲刺结束时的回顾性会议上收集有关结果的少量统计信息以供讨论。 TFS板模仿了物理Scrum板，但是我们也有一个物理的Scrum板。
简报
在计划阶段结束时，向演示团队演示了“一起开始”建模，讨论和纠正结果的演示结果，这些发现并没有得到他们的回应。
Scrum和Scrum但尤其是团队合作，连贯性，透明度和普遍接受度。 这是我们从灵感开始的重要时刻。
来源发射准备的结论
当您从事大型项目时，您将无所适从，因此您必须进行计划。 重要的是要了解它会是什么样子以及它将带来什么结果，但是我们满足了为该计划在某些方面仍将保留该计划这一事实做好准备的需要。 在计划时，我们大笔画画，并且已经在实施阶段添加了团队和设计状况带来的细节。
我们的团队仅负责软件开发周期的一部分，因此在调用什么产品以及增加产品时会遇到困难。 我们知道它应该是整体的和完整的。 我们同意，我们的分析师团队正在准备几种类型的文档以与客户进行交互，并为开发人员创建任务以积压这些文档。 因此，任务属于开发人员的冲刺。 我认为，这种折衷的途径既适用于由分析师，开发人员，测试人员，支持人员组成的团队的项目，也适用于需要将人员数量分成几个团队的项目。 这个决定还有一个缺点：我们的团队成员不能影响产品功能可用性的时机，我们只能影响他们部分工作的绩效。 优点是-开发人员的分析任务具有连续性。 这种解决方案使我们避免尝试成为一个跨职能团队（分析师=开发人员=测试人员等），而在我们这个阶段，这是不可能的，同时通过团队互动的折衷方式维持产品开发周期。
在演示阶段，我们来自
NORBIT的团队反应非常
热烈 ，并引起了人们的兴趣。 但是我认为，团队的积极情绪反应是制定目标以及将目标与紧迫而明显的问题联系起来的优点。
上面描述的步骤（理论研究，建模和演示）成功了：我们成功地开始了。
但是启动只是第一步。 在下一篇文章中，我将向您介绍发布后发生的情况以及取得的结果。