A project is defined in the PMBOK as being something of fixed scope, duration and budget. Failure of the project is defined as breaking outside one of the three sides of this "iron triangle". Scrum is a set of principles, and a few concrete practices, for dealing with all sorts of knowledge work, based on Agile values, and is specifically designed for development efforts that may not be projects, or may have flexible scope, duration or budget.
You are right that Scrum only deals with a few aspects of the software development process, such as planning. It only defines a few roles, meetings and artifacts, this is to keep it as flexible as possible. Scrum can, and should, address parts of the value stream outside of the software development itself. However, as you mentioned, it does not deal with lots of things, such as software engineering practices, and analysing the business case.
Often the standard Scrum solution is to "let the team decide" on matters that are not directly specified by Scrum. Often the guidelines for dealing with such matters come from other cultures and value or principle-systems within the Agile world, such as XP, or lean software development. Other cultures providing useful stuff for Scrum teams include Real Options, the Incremental Funding Method, Evo.
Some of the PMBOK stuff can be useful to a "project manager" or PO on a Scrum team, however one has to be cautious as the PMBOK stuff implies a rather different value-system than that which Scrum is based on. It is usually best to look for solutions within the Agile culture. Some of the PMBOK stuff still applies in an agile context though.
If you look for mailing lists related to "agile project management" you will find many thriving communities discussing such topics.
然而,在我看来,SCRUM 并不能涵盖项目管理所需的全部内容。它有点缺乏可遵循的总体策略。一种可能性是将 SCRUM 与 EVO 项目/价值管理或其他价值管理方法相结合。然而,它需要与客户签订不同类型的法律合同。项目更像是一个连续的过程,有时间限制,受到预算的限制,或者当客户觉得他的收益低于他的投资时结束(使用业务案例和目标衡量标准)。另一个好处是,客户会将您更多地视为长期合作伙伴,而不是短期供应商。
Agile development and PMBOK should not be mixed. IF you do, you're likely to end up with Scrummerfall. I've seen this happen with traditional project managers who convert to agile. They just don't get it and seem to fall back to old patterns.
However, in my opinion SCRUM doesn't cover all you need for project management. It sort of lacks an overall strategy to rule by. One possibility is combining SCRUM with EVO project/value management or other value management methods. It will however require a different type of legal contract with the customer. Projects are then more like a continuous process that is time boxed, restrained by a budget or ends when the customer feels he gains less than his investment (using business cases and goal measures). An added benefit is that the customer will see you more as a long term partner than a short term supplier.
We have expanded scrum to other departments in the company, modeling, texture and animation artist. We had to adapt the method a little, but it does work nicely. We had problems that were solved by using agile methodology. Some smaller departments (audio, special effects) were already working fine so we didn't tried to fix what wasn't broken. Agile would have added an unnecessary overhead for them.
It is not necessary for all departments in a company to use the same methodology, the best is to be adapted for everyones' needs. But scrum can be the solution for people other than programmers, but may need a bit of adaptation. Daily stand-up, sprints, backlog, those can be a good thing for many types of jobs.
If your software development effort is just one facet of a larger project--for example, rolling out a new financial product--then sure, you will have to employ some kind of project management methodology to orchestrate all of the work involved. Fitting a Scrum-based software development effort into a project managed according to PMBOK principles can be challenging, however, since PMBOK prescribes a linear, phased approach to project execution whereas Scrum, like other Agile methodologies, promotes incremental improvement through iteration. That's not to say that the two can't coexist. Like everything else, it comes down to implementation. Just remember to be pragmatic and adapt the methodologies to your needs, not the other way around.
Scrum is NOT a software development method but a project management method.
Besides Scrum is often introduced with Lego, or other artefacts (search for "59 minutes Scrum"). Therefore it can be used to handle all of the tasks of a project, whatever their natures.
发布评论
评论(6)
项目在 PMBOK 中被定义为具有固定范围、持续时间和预算的项目。该项目的失败被定义为超出这个“铁三角”三边之一。 Scrum 是基于敏捷价值观的一组原则和一些具体实践,用于处理各种知识工作,并且专门为可能不是项目或可能具有灵活范围、持续时间或预算的开发工作而设计。
你说得对,Scrum 只处理软件开发过程的几个方面,例如规划。它只定义了一些角色、会议和工件,这是为了尽可能保持灵活性。 Scrum 可以而且应该解决软件开发本身之外的部分价值流。然而,正如您所提到的,它不涉及很多事情,例如软件工程实践和分析业务案例。
通常,标准的 Scrum 解决方案是“让团队决定”Scrum 未直接指定的事项。处理此类问题的指导方针通常来自敏捷世界中的其他文化和价值或原则系统,例如 XP 或精益软件开发。其他为 Scrum 团队提供有用东西的文化包括实物期权、增量资金方法、Evo。
有些 PMBOK 内容对于 Scrum 团队中的“项目经理”或 PO 可能很有用,但是必须谨慎,因为 PMBOK 内容意味着一种与 Scrum 所基于的价值体系截然不同的价值体系。通常最好在敏捷文化中寻找解决方案。不过,一些 PMBOK 内容仍然适用于敏捷环境。
如果您查找与“敏捷项目管理”相关的邮件列表,您会发现许多蓬勃发展的社区正在讨论此类主题。
A project is defined in the PMBOK as being something of fixed scope, duration and budget. Failure of the project is defined as breaking outside one of the three sides of this "iron triangle". Scrum is a set of principles, and a few concrete practices, for dealing with all sorts of knowledge work, based on Agile values, and is specifically designed for development efforts that may not be projects, or may have flexible scope, duration or budget.
You are right that Scrum only deals with a few aspects of the software development process, such as planning. It only defines a few roles, meetings and artifacts, this is to keep it as flexible as possible. Scrum can, and should, address parts of the value stream outside of the software development itself. However, as you mentioned, it does not deal with lots of things, such as software engineering practices, and analysing the business case.
Often the standard Scrum solution is to "let the team decide" on matters that are not directly specified by Scrum. Often the guidelines for dealing with such matters come from other cultures and value or principle-systems within the Agile world, such as XP, or lean software development. Other cultures providing useful stuff for Scrum teams include Real Options, the Incremental Funding Method, Evo.
Some of the PMBOK stuff can be useful to a "project manager" or PO on a Scrum team, however one has to be cautious as the PMBOK stuff implies a rather different value-system than that which Scrum is based on. It is usually best to look for solutions within the Agile culture. Some of the PMBOK stuff still applies in an agile context though.
If you look for mailing lists related to "agile project management" you will find many thriving communities discussing such topics.
敏捷开发和PMBOK不应该混为一谈。如果这样做,您可能会遇到 Scrummerfall< /a>.我在转向敏捷的传统项目经理身上看到过这种情况。他们只是不明白这一点,似乎又回到了旧的模式。
然而,在我看来,SCRUM 并不能涵盖项目管理所需的全部内容。它有点缺乏可遵循的总体策略。一种可能性是将 SCRUM 与 EVO 项目/价值管理或其他价值管理方法相结合。然而,它需要与客户签订不同类型的法律合同。项目更像是一个连续的过程,有时间限制,受到预算的限制,或者当客户觉得他的收益低于他的投资时结束(使用业务案例和目标衡量标准)。另一个好处是,客户会将您更多地视为长期合作伙伴,而不是短期供应商。
Agile development and PMBOK should not be mixed. IF you do, you're likely to end up with Scrummerfall. I've seen this happen with traditional project managers who convert to agile. They just don't get it and seem to fall back to old patterns.
However, in my opinion SCRUM doesn't cover all you need for project management. It sort of lacks an overall strategy to rule by. One possibility is combining SCRUM with EVO project/value management or other value management methods. It will however require a different type of legal contract with the customer. Projects are then more like a continuous process that is time boxed, restrained by a budget or ends when the customer feels he gains less than his investment (using business cases and goal measures). An added benefit is that the customer will see you more as a long term partner than a short term supplier.
我们已经将 scrum 扩展到公司的其他部门,建模、纹理和动画艺术家。我们必须稍微调整一下方法,但它确实运作良好。我们遇到的问题可以通过使用敏捷方法来解决。一些较小的部门(音频、特效)已经工作得很好,所以我们没有尝试修复没有损坏的部分。敏捷会给他们增加不必要的开销。
公司的所有部门不必使用相同的方法,最好是适合每个人的需求。但 Scrum 可以成为程序员以外的人的解决方案,但可能需要一些适应。每日站会、冲刺、积压工作,这些对于许多类型的工作来说都是一件好事。
We have expanded scrum to other departments in the company, modeling, texture and animation artist. We had to adapt the method a little, but it does work nicely. We had problems that were solved by using agile methodology. Some smaller departments (audio, special effects) were already working fine so we didn't tried to fix what wasn't broken. Agile would have added an unnecessary overhead for them.
It is not necessary for all departments in a company to use the same methodology, the best is to be adapted for everyones' needs. But scrum can be the solution for people other than programmers, but may need a bit of adaptation. Daily stand-up, sprints, backlog, those can be a good thing for many types of jobs.
如果您的软件开发工作只是大型项目的一个方面(例如,推出新的金融产品),那么当然,您将必须采用某种项目管理方法来协调所有涉及的工作。然而,将基于 Scrum 的软件开发工作融入到根据 PMBOK 原则管理的项目中可能具有挑战性,因为 PMBOK 规定了一种线性、分阶段的项目执行方法,而 Scrum 与其他敏捷方法一样,通过迭代促进增量改进。这并不是说两者不能共存。与其他所有事情一样,这都取决于实施。请记住要务实并根据您的需求调整方法,而不是相反。
If your software development effort is just one facet of a larger project--for example, rolling out a new financial product--then sure, you will have to employ some kind of project management methodology to orchestrate all of the work involved. Fitting a Scrum-based software development effort into a project managed according to PMBOK principles can be challenging, however, since PMBOK prescribes a linear, phased approach to project execution whereas Scrum, like other Agile methodologies, promotes incremental improvement through iteration. That's not to say that the two can't coexist. Like everything else, it comes down to implementation. Just remember to be pragmatic and adapt the methodologies to your needs, not the other way around.
Scrum 不是一种软件开发方法,而是一种项目管理方法。
此外,Scrum 经常与 乐高 或其他人工制品一起引入(搜索“59 分钟”) Scrum”)。
因此,它可用于处理项目的所有任务,无论其性质如何。
Scrum is NOT a software development method but a project management method.
Besides Scrum is often introduced with Lego, or other artefacts (search for "59 minutes Scrum").
Therefore it can be used to handle all of the tasks of a project, whatever their natures.
虽然学习这些技术很棒,但我可以建议您的主要重点实际上是运行项目并完成工作吗?
编辑:顺便说一下,这是一个严肃的观点,而不是一次性的俏皮话。
While learning about these techniques is great, can I suggest your main focus is actually on running the project and getting stuff done?
EDIT: that's a serious point by the way, not a throwaway quip.