一个程序员的Scrum？[关闭]

在我很小的公司中，我被誉为“ Windows专家”，其中包括我自己，担任销售和培训职位的机械工程师以及担任设计，开发和支持职位的公司总裁。

我的角色与一般情况相同，但主要是我设计和实现产品上需要完成的所有编程，以便我们的产品可以在任何最新版本的Windows上运行。

我刚刚看完了网络广播中对Scrum范例的高级概述。我的问题是：鉴于我的开发工作项目通常是在很高的层次上给出的，例如“产品国际化和本地化”，是否值得我花更多时间来学习这种产品开发方法。

如果是这样，您将如何建议改编Scrum以仅使用一名程序员？有哪些工具（基于云的工具或其他工具）对此有用？

如果不是，您会建议一个程序员每天采用哪种方法来组织他的工作？（也许问题简化为那个简单的问题。）

学习Scrum：是的。如果只是要了解它，则可以添加到您的一般技能中。（但您可能正在寻找“ Scrum-ban”的味道……）

Scrum是一个很好的框架，但核心原则是“迭代（Sprint）应为固定持续时间”，我从未见过在较小的团队中进行此工作，而这些团队更受中断驱动。如果您可以真正报名并承诺在固定的时间范围内工作（1周？），那么Scrum是一个不错的框架。如果您不能...那么Scrum值得学习，因为它具有一些很好的概念，可以很好地转化为其他事物，例如...。

待办事项-是否为Scrum，请保留您需要做的事情的优先列表。我喜欢Excel（或Google Doc Spreadsheet ...）。您可能还喜欢其他东西。如果您是一个非常小的团队，我会保留一个非常小的工具。（电子表格>>文字处理器，因为您可以轻松排序。）

计划与提交的分离-以抽象的符号（点）进行计划并保持一致（8分大约是4分故事的2倍，而4分是2分故事的4倍）。当有时间“做工作”时，请重新考虑问题并勾勒出来在几个小时内。不要改变观点。

承诺-承诺时对他人可见，并兑现承诺

回顾-交付后，思考可以做得更好的事情。

等等等

Scrum很容易理解，可能是一个很好的起点。如果您喜欢，我会考虑使用“ Scrum-ban”变体-http: //en.wikipedia.org/wiki/Scrum-ban#Scrum-ban。在一个相当活跃的社区中为它提供支持的“如此详尽的记录”，这无异于我。

我也想推荐Alistair Cockburn的Crystal方法论（http://alistair.cockburn.us/Crystal+methodologies+main+foyer和http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Small / dp / 0201699478 / ref = ntt_at_ep_dpt_3），但它涉及更多的阅读和挖掘方式。

诸如XP之类的东西提供了有关特定实践的更多详细信息，因此我也要读一本书：http : //www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= books＆ie = UTF8＆qid = 1304359834＆sr = 1-1

最终阅读建议：只要您同意敏捷宣言，并遵守以下原则：http : //agilemanifesto.org/principles.html 您应该处于体面的状态。

个人建议：采用TDD（不可协商，恕我直言）保留待办事项（按照Scrum的方法）始终保持其大小和优先级进行排序分解“在中断之间太大而不能做的事情” int较小的块有其他人设置/查看优先级（无两个项目具有相同的优先级。）使您的构建环境能够在5-10分钟内构建/测试/部署（到实验室环境），向客户（内部和外部）展示故事的结果直到故事完成您的客户同意。当您完成当前故事时，请从堆顶部拉动故事并对其进行处理不要一次打开两个以上的故事。先分散注意力，然后再开始。

希望这可以帮助

您可以使用Scrum中使用的一些做法，例如产品积压，优先级划分，相对估计，增量交付，但是将整个Scrum用作由一组自组织的跨职能成员组成的团队管理产品开发的过程可能不是一个人秀的方式。 。

问题是您是否能够将工作项目分解为可以逐步交付的小块？如果不使用大多数实践，那是没有意义的。Scrum也与产品所有者/客户保持高度合作。它不应该是这样的：“这里有一个作业，完成后立即取回”。

虽然我不会说赞成或反对一人制Srum，但我会说一人制看板拉动系统效果很好。看板与自动化的单元测试相结合，使我的工作效率提高了很多，并获得了“文档化”。尽管两者都不是真正的方法，但是更多的工具（以及当时非常不同的工具），都迫使我将大型个人项目分解为一口大小的片段，并且给了我一种仪式以鼓励我每次都做更多的事情天。没有什么比单击“运行所有测试”并看到每个项目都变为绿色令人满意的了……除了从我看板的“进行中”列中将一张卡片拿到“正在测试”（或完全不在面板上）之外，什么都没有。

我认为单独工作的真正问题在于，您可以从多种方法中进行选择，而这些方法实际上是针对开发人员群体的，并且可以对其进行调整以使其最适合您。 最终目标实际上只是让您负责，高效和开心。谁会比自己更好地做到这一点（从这里拉一点，从那里拉一点）。

当我独自一人工作时，我确实尝试过这种方法。效果良好的是：

1. 将所有工作项目都放在白板上。我很快就能知道那里有什么杰出的工作。依赖和障碍在哪里。另外，很多人都会在我的董事会前停下来阅读它-我们会聊一聊。我认为这有助于他们了解“怪胎”整天在做什么；-)
2. 燃尽图也很棒。我只是用Excel。它使我能够在这种环境下更好地进行估算。它使我对迭代的方向有了一个很好的了解。我的经理（不是技术人员）也喜欢这一点，因为她可以看到功能中涉及的所有不同内容以及它们的位置。
3. 每日站立。尽我所能。每天早晨，我更新了所有工作项目和燃尽图，并记录了所有需要解决的障碍。
4. 自动化测试和持续集成（MSTest / TFS），最好是TDD，将使用任何方法论帮助任何开发团队-但在这里值得一提。
5. 简短的迭代（1周）确实帮助我专注于交付某些东西。
6. 保持积压非常好，因为当我获得新工作时，我能够将其放置在所有其他工作的上下文中，并让产品所有者重新确定优先级。

无效的是：

1. 独自工作，与志同道合的人合作永远不会获得推动。或来自一支拥有非常优秀的士气和文化的团队带来的竞争和专注感。当您被卡住时，没有其他大脑可以选择，因此，每天站起来的Scrum管理员都无法消除这样的障碍。
2. 没有Scrum管理员-因此没有人可以阻止中断。人们经常问其他问题并破坏我的工作流程，这给我带来了很多麻烦。在优秀的Scrum管理员的领导下，类似的东西会被拦截，您可以继续前进。我从不想对别人无礼（也许我很软），所以这是个问题。此外，如果没有Scrum管理员，您可以轻松地离开该过程。

这是一个有趣的练习，但过了一会我就停止了。我认为与传统的瀑布团队相比，Scrum的优势应显而易见。但是，当您独自一人时，两者都是有争议的。没有沟通或协作问题-您只需完成设定的工作，然后完成。

我认为每个人都应该保留待办事项，尽管要做TDD。

我认为在单个开发人员环境中有意义的敏捷/ Scrum /看板元素：

1. 有一个板，可以在看板之类的索引卡上组织用户故事/活动积压项目。

2. 从非开发人员那里获得以下原则的价值：

   • 给我时间工作，而不改变我的工作重点或进行微观管理（冲刺点）。给我些时间，我会尽力准确地弄清楚我能做些什么，而我会尽我所能去做。

   • 如果我需要某些东西（我被挡住了），我来找你，而你却无法为我排序，那么冲刺可能不得不被异常取消。（这只是意味着我们需要一个新的计划。）

   • 在冲刺过程中没有人会改变任何东西。或者，如果这样做，我们只是取消冲刺，然后创建一个新的。如果这种情况经常发生，生产率就会下降。

   • 利益相关者之间的交流可以在定期的每日站立会议上进行，该会议可以传达与常规Scrum大部分相同的信息，包括当天开发人员的成就。本质上，您可以报告花费比您预期更长的时间或进行得很好的事情，以及您对实施计划所做的任何调整。（我发现了四个新错误，并记录了下来，我认为它们比此可选功能更重要，因此，我想我将花点时间修复它们并推出此可选功能。）

作为一个开发人员，我已经做了很多工作，可以肯定地说，单个开发人员与其非开发人员主管/老板之间的信任以及良好的沟通是关键，而不是方法论。但是，如果您遵循良好的原则，您总是可以提高效率。

我已经阅读了一些有关此的博客，我认为它可以帮助您解决问题。

第一部分：http：//www.21apps.com/agile/doing-agile-in-a-team-of-one/

第二部分：http：//www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

您可能会在此博客上找到更多信息。

我丝毫没有联系；只是我最喜欢的东西。希望对您有所帮助。

是。并且请记住，Scrum不必使用精美的工具，它可以是一个简单的15分钟的站立会议，每个人都可以谈论他们在做什么。Scrum的优点是每个人都知道发生了什么事，这使得在出现问题之前更容易解决问题，并可以轻松地预测问题。

这些答案中有很多都缺少重点。

Scrum团队不需要纯粹由程序员组成。

您的一位同事进行“设计” /“开发”，而一位同事进行“销售”。

也许您的“销售”同事可以是产品负责人（代理）。客户的期望是什么？

对我来说，您其他同事的设计和开发听起来像是Scrum团队的纪律。Scrum的开发不是分阶段的，而是垂直的（淘汰需求，设计和实施只需一次冲刺）。

您可以对三个人进行Scrum处理。

完成“这项工作”需要什么？Scrum的sprint计划会议放大了“这是什么”的问题。产品负责人期望将其视为完成什么？

在sprint计划会议中，您可以为其他同事提供有关为何在技术上难以实现“产品国际化和本地化”的背景信息。

使用scrum恕我直言的原因很多。

我建议尝试看板，并从以下基础知识开始：可视化和限制进行中的工作（WIP）。

即使稍后再中止，您在此过程中也将变得更加敏捷。尽管看板适用于“常规”软件开发，但是当您同时具有开发新功能和维护的情况时，看板+基于流程的流程（而不是迭代）会胜过其他流程工具。

我第二次推荐了大卫·安德森（David Anderson）撰写的《看板》一书，您也可以在本地聚会上浏览我的幻灯片，其中介绍了为什么以及如何从简单的看板（或crisp.se/kanban）开始。

对于您的情况，我有几点想法：

• 可见性是关键，因此，如果您不能将其永久显示在（大）屏幕上（如果位于同一地点），则应使用物理白板而不是数字工具。
• 从您当前的过程开始
• 仅从您的势力范围开始，包括上游和下游转移阶段（成为您的队列，例如，已准备好供开发人员使用的设计功能，或从您那里排队，例如已完成的功能，准备销售的队列）
• 如果您的同事有兴趣在上游或下游扩展可视化效果，那就更好了。也许您最终将可视化公司的整个价值流（或网络），即价值从概念到现金的流动方式
• 通过限制在制品最小化多任务（！）。如果您的同事可以看到工作流程，他们应该理解原因，并轻松查看您的菜板上有什么
• 将工作分为3或4种工作类型（服务类别）可能会很有用，这三种工作类型对他们有不同的要求：f.ex。错误，关键问题，有严格期限的工作，没有期限的工作
• 观察您的工作流程，例如，遇到瓶颈，工作受阻或您因某种可预测的模式而“饥饿”。从长远来看，如果您使用数字工具，这会更容易，请参阅我的最后几张幻灯片。
• 逐步改善工作流程

如果您现在想尝试一下，今天，当您做出决定时，我建议像您上周一样，在您旁边的墙壁，窗户或橱柜上尝试个人看板 ...

在阅读完所有其他答案之后，我认为简单的实用答案是：

使用正在使用的过程或技术或方法来学习可以帮助您更好地完成工作的东西。

现在，这可能意味着要认真地每天优先处理任务。

这可能意味着要解决积压问题。

这可能意味着向老板报告进展情况（即使他不在乎……做这件事也是一件好事，从心理上允许您盘点自己的位置）。

您可能会使用各种各样的方法或技术，因为它们最终会使您更好地工作，这意味着晚上睡得更好。

做一些有用的事情（在当前情况下对您有用），丢弃那些无效的事情。

除非您具备以下条件

• 表示对传入需求进行组织和优先级排序的方法。

• 准确估算将要进行的工作，以便您知道可以在迭代中提交的内容

• 迭代和持续改进-不断检查和调整迭代的概念非常宝贵。这种做法鼓励实验，并有助于不断学习。教会中的Scrum，第4页

• 好吧，您不能进行每日Scrum会议，但是至少您可以使自己想起今天要完成的任务。使用每日Scrum会议，以便团队可以彼此同步他们的工作。

• 冲刺后的反思-在Scrum中称为Sprint Retrospective，在每次迭代结束时，您可以反思迭代后发生的情况，并思考出了什么问题以及如何改进它，保持这些问题的最佳实践是什么在做

我建议您采用最低限度的方法，并且通过不断改进，可以拥有一个非常适合您需求的scrum。

如果您无法满足需求并适应当前的情况，Scrum就不是Scrum。