如何实施Scrum？
我们正在尝试改用 Scrum 作为我们的开发流程，但我们不确定如何以最佳方式实现它。
在我们开始使用 Scrum 并取得积极成果之前，我们也不想为昂贵软件工具付费。
我们如何使用白板来实现 Scrum，而不要求人们在白板上写下他们的时间，然后输入到我们自己的时间跟踪软件中？
您使用什么样的方法？
We're trying to switch to Scrum as our development process but we're not sure how to implement it in the best way possible.
We also don't want to pay for expensive software tools until we get scrum working and get positive results.
How can we implement scrum using a whiteboard without asking people to write down their time on the board and then also input into our own time tracking software?
What kind of methodologies do you use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
这是一个很好的资源供您开始使用：用 10 个步骤实施 Scrum
还有一个非常好的网站，提供了许多关于如何开始使用 Scrum 的建议： implementingscrum.com
仅使用白板即可轻松进行跟踪的一种方法是在上面写下您的故事/任务便利贴并在上面写下预计的成本/时间。然后，您可以在白板附近召开日常会议，当开发人员交谈时，他们会写下完成会议的实时时间。
有了这些信息，您就可以构建燃尽图和燃尽图。
Here is a nice resource resource for you to start with: Implementing Scrum in 10 steps
There is also a really good site with many advices about how to begin with scrum: implementingscrum.com
One way you could easily do the tracking with just the whiteboard is to write your stories/tasks on post-its and also write on them the estimated cost/time. Then you can do your daily meeting near the whiteboard and when developers are talking they write down the real time they have done them.
With this information you can build both the burn up and burn down charts.
如果您已经对 Scrum 有一定的了解，那么创建一个产品待办事项列表，找一个产品负责人、一个团队、一个 ScrumMaster 并开始使用 Scrum。然后，检查并适应。
您不需要这样做，实际上，我强烈建议您从白板和便利贴开始，尤其是对于收养而言。您需要学习并掌握该流程，而您最不想要的就是一个规定流程并妨碍流程的工具。
对此没有神奇的解决方案（并且意图完全不同）。在第一种情况下，人们需要这样做，因为软件开发是一个经验过程，需要控制透明度。燃尽图（显示剩余工作的估计，而不是花费的时间）是 Scrum 用于实现这种透明度的工具之一。在第二种情况下，您需要这样做的唯一目的是报告（这是一种浪费），但是，您的管理层需要这样做（这一次，您报告花费的时间，但 Scrum 不关心这一点） ）。
If you have already some understanding of Scrum, then create a product backlog, get a product owner, a team, a ScrumMaster and start using Scrum. Then, inspect and adapt.
You don't need to and, actually, I would strongly recommend to start with a whiteboard and post-it notes, especially for an adoption. You need to learn and to master the process and the last thing you want is a tool that dictates the process and gets in the way.
There is no magical solution for that (and the intend is totally different). In the first case, people need to do it because software development is an empirical process and requires transparency to be controlled. The burndown chart (that shows an estimation of the remaining work, and not the time spent) is one of the tools Scrum uses to achieve this transparency. In the second case, you need to do it for the only purpose of reporting (which is a kind of waste) but, well, your management requires it (and this time, you report the time spent but Scrum doesn't care of that).
以下是关于我们如何使用（以及过去如何使用）Scrum 的简短回答：
我们目前使用连接到我们的缺陷跟踪系统的电子任务板。电子任务板是由我们自己的一些开发人员在 Sprint 之间实现的。在此之前，我们只是将巨大的白色海报挂在一面墙上，并在上面贴上写有任务的便条。
我同意，了解如何实施 Scrum 的最佳方法就是实际操作。您应该首先阅读它，主要是因为无论它听起来多么简单，它确实有一套我绝对建议遵循的规则。 （如果你发现其中一些方法对你的团队来说效果不佳，你仍然可以调整它们，但只有先试用几周你才会发现。）
Scrum 的绝妙之处在于，就工具而言，你几乎可以使用你拥有的任何工具。白板、墙壁、电子工具等等。它非常灵活，允许您开始实施它，而无需先花钱购买新工具或设备。如果您有白板，请使用磁铁或便签即可完成。打印燃尽图并通过标记每天更新它，就完成了。使用 Excel 来处理产品待办事项（或任何您喜欢的其他内容）。如果您觉得有必要，当您更好地了解团队在功能方面的需求时，您仍然可以使用其他工具。 （或者您也可以只使用白板和记事卡。）
Scrum 来自Trenches 是一个很好的介绍，并且有很多关于如何进行 Scrum 的现实生活示例，所以我赞同这个建议。
Here's the short answer as to how we are using (and used to use) Scrum:
We currently use an electronic taskboard which is connected to our defect tracking system. The electronic taskboard was implemented by some of our own developers between Sprints. Before that we simply hung huge white posters on one wall and stuck notes with tasks on it.
I agree that the best way to find out how to do Scrum is to actually do it. You should read up on it first, mostly since however easy it sounds it does have a set of rules that I'd absolutely recommend to follow. (If you find that some of them are not working well for your teams, you can still adjust them, but you won't find out until you try them out for a couple of weeks first.)
The brilliant thing about Scrum is that in terms of tools you can pretty much use whatever you got. Whiteboards, walls, electronic tools, whatever. It's very flexible and allows you to start implementing it without having to spend money on new tools or equipment first. If you have a whiteboard, use magnets or sticky notes and you're set. Print out the burndown chart and update it daily by marker and you're done. Use Excel for the product backlog (or whatever else you like). If you feel the need to you can still use other tools later when you have a better idea of what your team needs in term of functionality. (Or you can just stick with the whiteboard and note cards.)
Scrum from the Trenches is an excellent introduction and has a lot of real life examples of how to do Scrum, so I second that recommendation.
我发现实施 Scrum 的最佳方式就是使用 Scrum。
积压一些需要完成的任务，以便从现有流程迁移到 Scrum，将这些任务分解为多个为期两周的冲刺，并在几个月内逐步实施。这有助于人们掌握每个流程，而无需用新工具轰炸他们。
最初，我会介绍基本的冲刺计划会议、每日站立会议和冲刺回顾，并继续使用旧方法进行工作。然后随着冲刺的继续引入更多的方法。
特别是 Scrum 建议每个用户故事应该是一个垂直切片，实现的所有方面一起完成，以尽快交付业务价值。设计、开发、测试、基础设施、集成……这可能是非常困难的估计，甚至更难实现。只有当您拥有一支坚如磐石、跨学科的团队和非常强大的工程实践时，您才能真正做到这一点。首先将开发和单元测试结合在一起（如果还没有的话），然后将流程的更多部分引入每个任务中。
对于 Scrum，它告诉你如何做事，而不是做什么。如果您需要大量严格且快速的规则，请考虑 XP。建立一个真正高效的团队的大部分工作就是找出适合你的方法。密切关注速度并看看如何改进它。
关于工具，白板很棒。
当心邮寄。这些非常适合放在办公桌上作为提醒和笔记，但有一天，当您走进办公室时，您会看到组织精美的冲刺在地板上变成了一堆五彩纸屑。即使是特别坚固的柱子，在有空调的房间里放置大约两周后也会变干并失去粘性。我通过惨痛的教训学到了这个教训。
使用带有图钉和软木板的索引卡。
Excel 非常适合计算速度和燃尽指标。
我们只使用分布式团队的工具。然后我们使用 Acunote，因为它很简单。它实际上只是一个虚拟的软木板。
在时间跟踪软件中跟踪时间。跟踪任务的故事点。这些不一样。伦敦最近下雪，导致交通混乱，导致我们的速度下降了 35%，因此我们完成任务的能力也下降了，尽管团队与几个关键个人和客户在家工作的时间更长。
I have found the best way to implement Scrum, is using Scrum.
Have a backlog of tasks you need to do to move from your existing processes to Scrum, break these down into a number of 2 week sprints, and implement gradualy over a couple months. this helps people to get tp grips with each process, without bombarding them with new tools.
Initially I would introduce a basic sprint planning meeting, daily standups, and sprint reviews, and keep doing the work using the old methods. Then bring in more methodologies as the sprint continue.
In particular Scrum suggests that each user story should be a vertical slice, with all aspects of the implementation done together to deliver business vale ASAP. Design, development, testing, infrastructure, integration... This can be very difficult estimate, and even harder to achieve. You will only really get this right when you have a rock solid, mixed disciplinery team, and very strong engineering practices. Start by bringing togther dev and unit testing if you haven't already, then bring more parts of the process into each task.
With Scrum, it tells you how to do things, not what to do. Look to XP if you want lots of hard and fast rules. Much of getting a really effective team is working out what works for you. Keep an eye on velocity and see what improves it.
Regarding tools, a white board is great.
BEWARE THE POST IT. These are great for reminders and notes on your desk, but one day you walk into the office and see your beautifully organised sprint as a pile of confetti on the floor. Even the extra strong post it notes dry out and lose their stick after about 2 weeks in a room with A/C. I learnt this lesson the hard way.
Use index cards, with drawing pins and a cork board.
Excel is perfect for working out your velocity and burndown metrics.
We only use tools with distributed teams. Then we use Acunote for it's simplicity. It is really just a virtual cork board.
Track time in your time tracking software. Track story points on your tasks. These are not the same. The recent snow in London and resulting transport chaos, dropped our velocity by 35%, and hence our ability to complete tasks, even though the team was doing more hours with a couple key individuals and clients working from home.
如果您认为这会使采用 Scrum 变得更加困难，那么也许您可以依靠 Scrum Master。人们可以将自己的时间写在黑板上，Scrum Master 可以将其输入到时间跟踪系统中。
除非您面对的是分布式团队，否则不需要太多软件工具。即使当我在一个使用 Mingle 的团队工作时，我们也维护了一个物理 Scrum 板。我认为所有其他开发人员都对此表示赞赏。
If you think that this will make it harder to adopt Scrum, then maybe you can lean on your Scrum Master. People can write their time on the board, and the Scrum Master can enter it into the time tracking system.
Unless you're dealing with a distributed team, there isn't much need for software tools. Even when I worked on a team that used Mingle, we maintained a physical Scrum board. I think all the other developers appreciated it.
Scrum 是关于过程，而不是工具。确保每个参与人员（不仅仅是开发团队！）都了解 Scrum 的含义。这不仅仅是在两周的冲刺中迭代工作。这是管理层对这种工作方式的承诺。这是关于拥有一个非常优秀的产品负责人，可以设定优先级。这是关于团队内彼此开放。等等等等。这需要时间来学习。
阅读Scrum from the Trenches 进行简单介绍。
Scrum is about the process, not the tools. Make very sure that everyone involved (not just the development team!) understands what Scrum is about. It's not just working iteratively in 2 week sprints. It's about commitment from management about this way of working. It's about having a very good product owner that can set priorities. It's about being open to each other within the team. Etc. etc. This will take time to learn.
Read Scrum from the Trenches for an easy introduction.
这是描述的视频< /a> scrum 以及我们如何在 Atalasoft 实现它，例如毛绒动物和玩具。
我们使用 FogBugz 进行跟踪。我们为待办事项创建一个“版本”，并为冲刺创建另一个版本。任务从待办事项列表中输入冲刺，并带有时间估计。每天在燃尽图中跟踪发布中剩余的总时间，燃尽图以前由 Scrum Master 在 excel 中构建（FogBugz 中为 noe）。
Here is a video describing scrum and how we implement it at Atalasoft, as acted out by stuffed animals and toys.
We do tracking with FogBugz. We create a "release" for the backlog and another release for a sprint. Tasks are entered into the sprint from the backlog with time estimates. The total time remaining in the release is tracked daily in a burndown chart, formerly built in excel (noe in FogBugz) by the scrum master.
我们已经使用 Scrum 工具“在房子里转了一圈”，我回过头来认为白板和便利贴是最好的。我尝试过的所有项目管理工具，无论是特定于 Scrum 的还是其他的，都倾向于让您的团队改变他们的流程以适应该工具。白板强制执行您尝试通过 Scrum 采用的良好工作实践，而不会妨碍您。
但请注意，当您想要生成报告或只是跟踪任何历史数据时，您将在某人身上投入更多工作。例如，计算速度必须手动完成，并且必须在人们扰乱白板计划下一个 Sprint 之前完成。即便如此，我还是倾向于认为，这仍然比每个人都必须使用工具花费的时间要少。
以电子方式存储产品待办事项的主副本是一种很好的做法，只需保持简单即可（例如将其放入 Excel 文档中）。
We've been 'around the houses' a bit with Scrum tools and I've come back around to thinking that whiteboards and post-it notes are the best. All the project management tools that I've tried, Scrum-specific or otherwise, tend to make your team change their process to fit the tool. Whiteboards enforce the good working practices you are trying to adopt with Scrum without getting in the way.
Be aware though that you'll be putting more work on somebody when you want to produce reports or just track any historical data. For example, calculating velocities has to be done by hand and as well as prior to people disrupting the whiteboards planning the next Sprint. Even then, I tend to agree that this still eats less time than everyone having to wrestle with a tool.
Having the master copy of your product backlog(s) stored electronically is good practice, just keep it simple (e.g. put it in an Excel doc).
在 scrum 中，任务不应超过 4-16 小时（或者必须细分）。因此，您可以将其编码到您的时间系统中。如果它们花费更多或更少的时间，您可以进行更正。
有关更多详细信息，请参阅我的博客帖子。
In scrum, tasks should take no longer than 4-16h (or must be subdivided). So, you can encode this in your time system. If they take more or less time, you can include corrections.
For more details, see my blog post.