I'm on a team that started Scrum a few months ago and we seem to be getting things done faster and with much less "waste" (projects that are scrapped). Just my observations from our small team (4 devs).
I've found the overall move to Agile/XP practices very positive, in many ways it front loads quality into the project/development process. You'll need buy-in from management and from the team to really see success...a few suggestions:
trial any change with a small project (2-3 people)
understand what areas your current team can most improve (quality? productivity? time-to-market?) and incorporate a few Agile/XP/Scrum (what ever) processes in...don't incorporate them all in at the same time and understand which processes address which issues prior to any change
if possible - track those areas you're looking to change and compare to another project running at the same time (the mere focus of improving something often is enough to improve it ,there's a study/term for this, but I forget what it is)
sometimes you'll see a dip in performance as you begin a new process, this is part of the learning curve
never assume that a good change today will remain a good change tomorrow, always review your project areas and be ready to change any process at any time
no change remains good forever, just like refactoring code, refactor your processes
ensure you get buy in from the team and management, you can't force success
I like some of the things the agile approaches do, but I also value some of the things traditional approaches do.
Both can work, as can a mixture of the two, which is what I find works best for my team now. I have implemented incremental development and it really helps us; iterative development is a little harder and we're still working on that. However, we have a variety of constituents, and many of our stakeholders (and PMs) prefer traditional artifacts and milestones. So we have to keep finding the right balance.
I have also found that even more important than the methodology is the people implementing it. Good people find a way to do good work and get things done regardless of the methodology, although certainly the methodology can have effects on efficiency (and morale :) ). Poorly aligned resources, however, can use the finest methodology and find ways to deliver poor results.
For developers, the great lessons of XP & Co. are shorter release cycles, and a more evolutionary approach - in the sense that change of requirements is accepted as a natural part of any project. Also, Customers suggest solutions, but designers and developers need to understand the problems.
Lessons for managers: Developers are not exchangable spec-to-code-converters, their individual strengths and weaknesses can make a productivity difference of 10 or more for a given topic. Knowledge and experience are the most valuable skills in your team, and developers can teach each oterh. Managers need not understand what developers do in order to enforce desired results.
XP & Co. are usually mixing solutions to these with the problem to make a company change. The heroic XP consultant singlehandledly saving a doomed, delayed and derailed project acts as large part as a buffer between development and management. But if you are looking at what to learn, you have to separate these aspects.
What I learnt in the recent years is that bugs aren't a personality fault, and that the sky doesn't fall when specs change. I've learnt that while design errors are still the most expensive to make, there isn't a single "perfect" design. Instead of getting one thing right we need to implement safeguards that of all the many details none goes wrong - and I've learnt to use the leeway between "right" and "not wrong" to our advantage.
My experience has been that I prefer to use Scrum over traditional approaches as it hasn't happened often that requirements could stay unchanged for the length of a project where usually projects seem to run at least 6 months to my current one that is over a year.
There can also be the case where there isn't any project management and everyone just scrambles to "make it work" so having some formal structure is good over nothing. There is something to the question of how well does the team come together and egos rarely appear as it isn't someone's code but rather the code of the team and there is a kind of group think where while each person has their view, no one tries to make everyone else see things that way.
At times it seems to me that some Scrum and Agile approaches I've used end up being like rapids instead of a big waterfall. What I mean is that the cycle of gather requirements - Analyse and Design - Implement - Test - Deploy and get updated requirements seems to be repeated over and over so that what comes out in the end would be extremely hard to state at the beginning of the project unless the project sponsor could give very detailed requirements that would never change.
我认为传统项目管理的真正问题在于，它往往并不真正存在。 我很惊讶有这么多商店声称使用 RUP 或 Code Complete 甚至 Agile，但实际上没有任何可识别的项目管理。 当然，有会议。 人们称之为项目经理。 但问一个简单的问题，比如“项目 X 已经做了什么”或“项目 Y 还需要做什么”，却没有人能给出答案。 他们必须仔细研究电子邮件或指出一个极其不准确的 MS 项目文件。
如果一个人声称正在节食，但无法回答有关他们吃什么或如何锻炼的问题； 你会接受他们真的在节食吗？
Before I ever heard of XP, I had a really good manager (Mike) at an early job I had. He was used to managing engineers and transitioned to managing software. After a few bad working experiences I looked back at his style versus typical project management I had before and after working with him.
Met with everyone at least once a day but gave us space to work
Used a whiteboard with two columns, people working and what they are working on anyone could look at that board and see if something had been done or was being done
Had everyone cross-train. I learned rcs and then cvs there and how to use make files
Ran productive "post mortum" when a task was completed. He would ask question like "would it have helped if X?" or "next time, can we try to..."
Kept everyone working on short tasks and managed our time so we always working on something but never had a ton of stuff piled up
Mike did everything on paper. He would keep notebooks and index cards with him. He insisted that anything asked of him by management be converted into manageable tasks, often written on note cards. He refused to have anyone work on anything that couldn't be clearly explained or had a clear objective. He would ask the VPs "what do you mean by faster?" "What kinds of metrics are the reports meant to show?" "Why should this be a priority?" He seemed to have near infinite patience in writing out what needed to be done and what was meant by "done"
When I first read the XP book, I was amazed by how much was familiar as "the way Mike worked"
It seems that Agile is just about implementing a set of best practices and evaluating how they work in your environment. When they don't work, change them. When they do work, stick to them.
I think the real problem with traditional project management is that more often than not, it doesn't really exist. I'm amazed by how many shops claim to use RUP or Code Complete or even Agile and don't actually have anything recognizable as project management. Sure, there are meetings. And people called project managers. But ask a simple question like "what has been done on project X" or "what is left to do on project Y" and no one has an answer. They have to dig though emails or point to a comically inaccurate MS project file.
If a person claimed to be on a diet and couldn't answer questions on what they were eating or how they were exercising; would you accept that they were really on a diet?
You take your old baggage with you when you go. Meaning that any project management bad practices you had before will still linger.
However, I will say that things improved greatly when we began to close the loop between us and the customer. Greater and more frequent feedback and prototyping with the customer means far fewer moments of the customer saying, "This is not what I wanted."
I've used (a slightly modified) Scrum before at work and here are my thoughts:
The daily meetings and burn-down provided motivation to make progress on tasks.
Our manager could talk to colleagues across the pond and show them "this is what we're working on this month."
You knew exactly what tasks you needed to get done, and had already estimated the time required to complete.
When priorities changed (new tasks, important bugs added), there was a well-defined process to handle adding them to the sprint or simply pushing them to the backlog.
发布评论
评论（9）
我所在的团队几个月前开始使用 Scrum，我们似乎可以更快地完成工作，并且“浪费”（被废弃的项目）更少。 这只是我的小团队（4 名开发人员）的观察结果。
I'm on a team that started Scrum a few months ago and we seem to be getting things done faster and with much less "waste" (projects that are scrapped). Just my observations from our small team (4 devs).
我发现向敏捷/XP 实践的总体转变非常积极，在很多方面它都将质量前置到了项目/开发过程中。 您需要管理层和团队的支持才能真正看到成功...一些建议：
I've found the overall move to Agile/XP practices very positive, in many ways it front loads quality into the project/development process. You'll need buy-in from management and from the team to really see success...a few suggestions:
我喜欢敏捷方法所做的一些事情，但我也重视传统方法所做的一些事情。
两者都可以，两者的混合也可以，我发现这对我的团队来说是最有效的。 我已经实施了增量开发，这确实对我们有帮助； 迭代开发有点困难，我们仍在努力。 然而，我们有各种各样的成员，而且我们的许多利益相关者（和 PM）更喜欢传统的工件和里程碑。 所以我们必须不断寻找适当的平衡。
我还发现，比方法论更重要的是实施它的人。 优秀的人会找到一种方法来做好工作并把事情做好，而不管方法如何，尽管方法肯定会对效率（和士气:)）产生影响。 然而，如果资源协调不善，即使使用最好的方法，也可能会找到取得不良结果的方法。
I like some of the things the agile approaches do, but I also value some of the things traditional approaches do.
Both can work, as can a mixture of the two, which is what I find works best for my team now. I have implemented incremental development and it really helps us; iterative development is a little harder and we're still working on that. However, we have a variety of constituents, and many of our stakeholders (and PMs) prefer traditional artifacts and milestones. So we have to keep finding the right balance.
I have also found that even more important than the methodology is the people implementing it. Good people find a way to do good work and get things done regardless of the methodology, although certainly the methodology can have effects on efficiency (and morale :) ). Poorly aligned resources, however, can use the finest methodology and find ways to deliver poor results.
对于开发人员来说， XP 和 Windows 的重要教训。 Co. 是更短的发布周期和更具进化性的方法 - 从某种意义上说，需求的变化被接受为任何项目的自然组成部分。 此外，客户提出解决方案，但设计人员和开发人员需要了解问题。
给管理者的教训：开发人员不是可互换的规范到代码转换器，他们的个人优势和劣势可能会导致给定主题的生产力差异达到 10 或更多。 知识和经验是团队中最有价值的技能，开发人员可以互相传授。 管理者无需了解开发人员所做的事情即可实现预期结果。
XP 和 公司通常会将这些问题的解决方案与问题混合起来使公司发生变化。 英勇的 XP 顾问单枪匹马拯救了一个注定失败、延迟和脱轨的项目，在很大程度上充当了开发和管理之间的缓冲作用。 但如果你正在考虑要学什么，你就必须将这些方面分开。
近年来我学到的是，错误并不是性格缺陷，规格改变时天也不会塌下来。 我了解到，虽然设计错误仍然是最昂贵的，但并不存在单一的“完美”设计。 我们需要实施保障措施，确保所有细节都不会出错，而不是把一件事做好。我学会了利用“正确”和“没有错误”之间的余地来为我们带来优势。
For developers, the great lessons of XP & Co. are shorter release cycles, and a more evolutionary approach - in the sense that change of requirements is accepted as a natural part of any project. Also, Customers suggest solutions, but designers and developers need to understand the problems.
Lessons for managers: Developers are not exchangable spec-to-code-converters, their individual strengths and weaknesses can make a productivity difference of 10 or more for a given topic. Knowledge and experience are the most valuable skills in your team, and developers can teach each oterh. Managers need not understand what developers do in order to enforce desired results.
XP & Co. are usually mixing solutions to these with the problem to make a company change. The heroic XP consultant singlehandledly saving a doomed, delayed and derailed project acts as large part as a buffer between development and management. But if you are looking at what to learn, you have to separate these aspects.
What I learnt in the recent years is that bugs aren't a personality fault, and that the sky doesn't fall when specs change. I've learnt that while design errors are still the most expensive to make, there isn't a single "perfect" design. Instead of getting one thing right we need to implement safeguards that of all the many details none goes wrong - and I've learnt to use the leeway between "right" and "not wrong" to our advantage.
我的经验是，与传统方法相比，我更喜欢使用 Scrum，因为在项目期间需求保持不变的情况并不常见，通常项目似乎运行至少 6 个月，而我目前的项目则超过一年。
也可能存在这样的情况：没有任何项目管理，每个人都只是争先恐后地“使其发挥作用”，因此拥有一些正式的结构总比没有好。 问题是团队团结得有多好，自我很少出现，因为这不是某人的代码，而是团队的代码，并且有一种群体思维，虽然每个人都有自己的观点，但没有人试图让其他人都这样看问题。
有时在我看来，我使用的一些 Scrum 和敏捷方法最终就像急流而不是大瀑布。 我的意思是，收集需求 - 分析和设计 - 实施 - 测试 - 部署和获取更新需求的循环似乎一遍又一遍地重复，因此最终的结果将很难在开始时说明。除非项目发起人能够给出非常详细且永远不会改变的要求。
My experience has been that I prefer to use Scrum over traditional approaches as it hasn't happened often that requirements could stay unchanged for the length of a project where usually projects seem to run at least 6 months to my current one that is over a year.
There can also be the case where there isn't any project management and everyone just scrambles to "make it work" so having some formal structure is good over nothing. There is something to the question of how well does the team come together and egos rarely appear as it isn't someone's code but rather the code of the team and there is a kind of group think where while each person has their view, no one tries to make everyone else see things that way.
At times it seems to me that some Scrum and Agile approaches I've used end up being like rapids instead of a big waterfall. What I mean is that the cycle of gather requirements - Analyse and Design - Implement - Test - Deploy and get updated requirements seems to be repeated over and over so that what comes out in the end would be extremely hard to state at the beginning of the project unless the project sponsor could give very detailed requirements that would never change.
在我听说 XP 之前，我早期的工作中有一位非常优秀的经理（Mike）。 他习惯了管理工程师，转而管理软件。 在经历了几次糟糕的工作经历之后，我回顾了他的风格与我在与他合作之前和之后的典型项目管理。
迈克把所有的事情都写在纸上。 他会随身携带笔记本和索引卡。 他坚持将管理层要求他的任何事情转化为可管理的任务，通常写在记事卡上。 他拒绝让任何人从事任何无法清楚解释或没有明确目标的事情。 他会问副总裁“更快是什么意思？” “报告旨在显示哪些类型的指标？” “为什么这应该成为优先事项？” 他似乎有近乎无限的耐心写出需要做什么以及“完成”的含义
当我第一次阅读 XP 书时，我惊讶于“Mike 的工作方式”如此熟悉
似乎敏捷只是实施一组最佳实践并评估它们在您的环境中的工作方式。 当它们不起作用时，就改变它们。 当它们起作用时，坚持下去。
我认为传统项目管理的真正问题在于，它往往并不真正存在。 我很惊讶有这么多商店声称使用 RUP 或 Code Complete 甚至 Agile，但实际上没有任何可识别的项目管理。 当然，有会议。 人们称之为项目经理。 但问一个简单的问题，比如“项目 X 已经做了什么”或“项目 Y 还需要做什么”，却没有人能给出答案。 他们必须仔细研究电子邮件或指出一个极其不准确的 MS 项目文件。
如果一个人声称正在节食，但无法回答有关他们吃什么或如何锻炼的问题； 你会接受他们真的在节食吗？
Before I ever heard of XP, I had a really good manager (Mike) at an early job I had. He was used to managing engineers and transitioned to managing software. After a few bad working experiences I looked back at his style versus typical project management I had before and after working with him.
Mike did everything on paper. He would keep notebooks and index cards with him. He insisted that anything asked of him by management be converted into manageable tasks, often written on note cards. He refused to have anyone work on anything that couldn't be clearly explained or had a clear objective. He would ask the VPs "what do you mean by faster?" "What kinds of metrics are the reports meant to show?" "Why should this be a priority?" He seemed to have near infinite patience in writing out what needed to be done and what was meant by "done"
When I first read the XP book, I was amazed by how much was familiar as "the way Mike worked"
It seems that Agile is just about implementing a set of best practices and evaluating how they work in your environment. When they don't work, change them. When they do work, stick to them.
I think the real problem with traditional project management is that more often than not, it doesn't really exist. I'm amazed by how many shops claim to use RUP or Code Complete or even Agile and don't actually have anything recognizable as project management. Sure, there are meetings. And people called project managers. But ask a simple question like "what has been done on project X" or "what is left to do on project Y" and no one has an answer. They have to dig though emails or point to a comically inaccurate MS project file.
If a person claimed to be on a diet and couldn't answer questions on what they were eating or how they were exercising; would you accept that they were really on a diet?
当你走的时候，你带着你的旧行李。 这意味着您之前的任何项目管理不良做法仍然会持续存在。
然而，我要说的是，当我们开始关闭我们和客户之间的循环时，情况有了很大改善。 与客户进行更多、更频繁的反馈和原型设计意味着客户说“这不是我想要的”的时刻要少得多。
You take your old baggage with you when you go. Meaning that any project management bad practices you had before will still linger.
However, I will say that things improved greatly when we began to close the loop between us and the customer. Greater and more frequent feedback and prototyping with the customer means far fewer moments of the customer saying, "This is not what I wanted."
我之前在工作中使用过（稍作修改的）Scrum，以下是我的想法：
I've used (a slightly modified) Scrum before at work and here are my thoughts:
这些都是可爱的答案，但我认为每个人都将项目管理与开发/设计方法混淆了。
These are lovely answers, but I think everyone's confusing project management with development/design methodologies.