For simple projects (where both the requirements and the technologies are well known), the predictability is high so a predictive methodology (waterfall) works well.
For complicated and complex projects (and the vast majority of IT projects are), predictability is low and a predictive methodology won't work, an adaptive approach should be preferred. This is where Agile works well.
When both the requirements and the technologies are unknown, you're close to the chaos and the odds of failure are very high, regardless of the methodology.
My team was unsuccessful at making agile work. IMO, it was because:
The very first time the dev team would hear about a project, it was in the form of a requirements document and a deadline.
Stakeholders were often reluctant to take time to look at the result of a sprint's work, thus they would not take action between sprints if they thought the project was headed in the wrong direction.
When we showed stakeholders our work, they generally just OK'd it. They would talk about what they would like, to which we would reply "That can be done in about X amount of time," to which they would reply, "Well no need to go over the deadline for that."
The deployment process was long and complicated, discouraging frequent deployments. So in practice, we often deployed things when a 2-month project was done, not at the end of a sprint.
Our sprint planning meetings were long and inefficient.
It seems everyone was confused about what scrum is (and about what our process was), except for the scrum evangelists.
So I'm pretty sure we were doing it all wrong. Don't you do it wrong, too.
Some things that have sped us up, which we continue to use:
automated builds that work on everyone's machine (HUGE help!)
a formal arrangement for our code repository
learning how to apply apply abstraction mechanisms to UI code
refactoring
unit and integration tests
continuous integration
I guess you could say that our code is more agile, though our methodology is less agile. Whereas before we could not keep pace with demands, now we can.
(I'm not saying agile is bad; I'm just reporting my experience. Also, please understand that I do not choose what methodology we use.)
The discussion is usually agile vs. waterfall, right? I am linking an article, but it is in Portuguese, so I'll try to transmit some of its ideas:
Waterfall is like chess. You think and plan a lot, try to foresee every possible issue as soon as possible. There's a lot of planning, but makes sense only on stable and well-known domains, where change isn't much expected.
Agile is like soccer (or many collective sports): decisions are made in-game and should be done fast. There's no much time to analyze every consequence. It is "ideal" for dynamic and unstable domains, where change is always expected (web applications, for instance, tend to fall in this category). Another point to note is: even if you have the best players, if they don't do well as a team, you won't be the winner.
IMHO, Scrum would be useful, because:
Once every two weeks (or every month, depending on iteration time) you'll be able to see what's working or not. And this is very valuable, specially as an "amateur" team, which is expected to be learning and finding things out much more constantly.
As amateurs, you probably won't be able to foresee everything (and that's something agile embraces)
There's more space for sharing experience (stand-up meeting, retrospective, and even planning meeting). And you share REAL experience (you must write code every week rather than just plan)
It appears your priorities are changing far too frequently for either methodology Agile or Waterfall. With priorities changing frequently, you are likely churning in and out of projects leaving a lot of them partly done. The Agile alway be ready to release may help. It has been my experience that getting a methodology in place will improve productivity.
Your situation reminds me of a project I worked on. The developer on the project asked one question at the start, "Do you want me to be do it right or be responsive?" I was on the project when it was two years into a six month project. One week the same functionality was implemented Monday, Wednesday, and Friday. Tuesday and Thursday were spent removing the functionality.
I would suggest you start adopting practices from Agile. Scheduling a short sprint period could help with changing priorites. It may be easier to maintain priorities for a period of a week or two and may make it easier to stabilize priorities. You will also need a backlog (sounds like you have a large one already).
Management may be more willing to hold off new priorities if you can slot them into a sprint in a week or two. You will also be able to identify the priority tradeoffs. If you add something to the next sprint, what will be removed.
Consider having part of the team working Agile while the others maintain the status quo. Rotate one team member each sprint as you are gaining experience. Consider having the whole team participate in a daily stand up status meeting, and the post sprint review. Once you have demonstrated increased productivity and returns to the company you should be able to increase the amount of work being done using your methodology.
Agile is a adaptive methology. Expect to be making major changes to your methodoly for the new year or two. Eventually, you should reach a stage where you are fine tuning.
In my experience, you absolutely need the following for agile (XP or Scrum at least) to work. Without these prerequisites you are likely to fail. Hard.
Team must be stable and 100% dedicated to this.
Team must be colocated in one workspace.
Customer/product owner must be available on site at all times.
Support from management. This means providing funds and courage to ensure the points above.
Give these points, you can probably tackle anything as long as you keep to the values.
发布评论
评论（5）
Ralph Stacey 的复杂性矩阵通常用于说明敏捷的最佳点：
（来源：typepad.com）
对于简单项目（要求和技术都众所周知），可预测性很高，因此预测方法（瀑布）效果很好。
对于复杂且复杂的项目（绝大多数 IT 项目都是如此），可预测性较低且预测方法不起作用，应首选自适应方法。这就是敏捷发挥作用的地方。
当需求和技术都未知时，无论采用何种方法，您都接近混乱，失败的可能性非常高。
Ralph Stacey's complexity matrix is commonly used to illustrate the sweet spot for Agile:
(source: typepad.com)
For simple projects (where both the requirements and the technologies are well known), the predictability is high so a predictive methodology (waterfall) works well.
For complicated and complex projects (and the vast majority of IT projects are), predictability is low and a predictive methodology won't work, an adaptive approach should be preferred. This is where Agile works well.
When both the requirements and the technologies are unknown, you're close to the chaos and the odds of failure are very high, regardless of the methodology.
我只是根据经验说的； YMMV。
我的团队未能成功实现敏捷工作。 IMO，这是因为：
会听说一个项目，它在
需求文件的形式
和最后期限。
花时间看看结果
冲刺的工作，因此，如果他们认为项目朝着错误的方向发展，他们就不会在冲刺之间采取行动。
他们一般都同意。他们
会谈论他们会做什么
就像，我们会回答“那
大约可以完成 X 量
时间，”他们会回答，
“好吧，没必要超过最后期限
为此。”
复杂，令人沮丧的频繁
部署。所以在实践中我们
经常部署2个月的东西
项目已经完成，而不是在某个项目结束时
短跑。
时间长且效率低。
所以我很确定我们都做错了。你也不要做错事啊。
我们继续使用的一些东西已经加快了我们的速度：
每个人的机器（巨大的帮助！）
知识库
UI 代码
我想你可能会说我们的代码更敏捷，尽管我们的方法不太敏捷。以前我们无法满足需求，但现在我们可以了。
（我并不是说敏捷不好；我只是报告我的经验。另外，请理解我不选择我们使用什么方法。）
I'm speaking only from experience; YMMV.
My team was unsuccessful at making agile work. IMO, it was because:
would hear about a project, it was in
the form of a requirements document
and a deadline.
to take time to look at the result
of a sprint's work, thus they would not take action between sprints if they thought the project was headed in the wrong direction.
they generally just OK'd it. They
would talk about what they would
like, to which we would reply "That
can be done in about X amount of
time," to which they would reply,
"Well no need to go over the deadline
for that."
complicated, discouraging frequent
deployments. So in practice, we
often deployed things when a 2-month
project was done, not at the end of a
sprint.
long and inefficient.
So I'm pretty sure we were doing it all wrong. Don't you do it wrong, too.
Some things that have sped us up, which we continue to use:
everyone's machine (HUGE help!)
repository
abstraction mechanisms to UI code
I guess you could say that our code is more agile, though our methodology is less agile. Whereas before we could not keep pace with demands, now we can.
(I'm not saying agile is bad; I'm just reporting my experience. Also, please understand that I do not choose what methodology we use.)
重新发布 我的相关回答：
讨论通常是敏捷与瀑布，对吧？我正在链接一篇文章，但它是葡萄牙语的，所以我会尝试传达它的一些想法：
瀑布就像国际象棋。你思考和计划很多，尝试尽快预见每一个可能出现的问题。有很多计划，但只有在稳定和众所周知的领域才有意义，这些领域预计不会有太多变化。
敏捷就像足球（或许多集体运动）：决策是在游戏中做出的，应该快速完成。没有太多时间来分析每一个后果。对于总是期望发生变化的动态和不稳定领域来说，它是“理想的”（例如，Web 应用程序往往属于此类）。还有一点需要注意的是：即使你有最好的球员，如果他们团队表现不佳，你也不会成为胜利者。
恕我直言，Scrum 会很有用，因为：
Reposting a related answer of mine:
The discussion is usually agile vs. waterfall, right? I am linking an article, but it is in Portuguese, so I'll try to transmit some of its ideas:
Waterfall is like chess. You think and plan a lot, try to foresee every possible issue as soon as possible. There's a lot of planning, but makes sense only on stable and well-known domains, where change isn't much expected.
Agile is like soccer (or many collective sports): decisions are made in-game and should be done fast. There's no much time to analyze every consequence. It is "ideal" for dynamic and unstable domains, where change is always expected (web applications, for instance, tend to fall in this category). Another point to note is: even if you have the best players, if they don't do well as a team, you won't be the winner.
IMHO, Scrum would be useful, because:
对于敏捷方法或瀑布方法，您的优先级似乎变化得太频繁。由于优先级频繁变化，您可能会不断地投入和退出项目，而其中很多项目都已部分完成。敏捷总是准备好发布可能会有所帮助。根据我的经验，制定适当的方法可以提高生产力。
你的情况让我想起了我做过的一个项目。该项目的开发人员在一开始就问了一个问题：“你希望我正确行事还是做出回应？”我参与这个项目时，六个月的项目已进行了两年。一周内，周一、周三和周五实施了相同的功能。周二和周四的时间是删除该功能。
我建议您开始采用敏捷实践。安排一个短的冲刺期可以帮助改变优先事项。将优先事项维持一两周可能会更容易，并且可能更容易稳定优先事项。您还需要一份待办事项（听起来您已经有一大堆了）。
如果你能在一两周内将新的优先事项安排到冲刺中，管理层可能更愿意推迟它们。您还能够确定优先权衡。如果您在下一个冲刺中添加某些内容，则会删除哪些内容。
考虑让团队的一部分进行敏捷工作，而其他人维持现状。随着经验的积累，每个冲刺轮换一名团队成员。考虑让整个团队参加每日站立状态会议和冲刺后审查。一旦您证明了生产力的提高并为公司带来了回报，您应该能够增加使用您的方法完成的工作量。
敏捷是一种适应性方法。预计在新的一两年里你的方法会发生重大改变。最终，您应该达到微调的阶段。
It appears your priorities are changing far too frequently for either methodology Agile or Waterfall. With priorities changing frequently, you are likely churning in and out of projects leaving a lot of them partly done. The Agile alway be ready to release may help. It has been my experience that getting a methodology in place will improve productivity.
Your situation reminds me of a project I worked on. The developer on the project asked one question at the start, "Do you want me to be do it right or be responsive?" I was on the project when it was two years into a six month project. One week the same functionality was implemented Monday, Wednesday, and Friday. Tuesday and Thursday were spent removing the functionality.
I would suggest you start adopting practices from Agile. Scheduling a short sprint period could help with changing priorites. It may be easier to maintain priorities for a period of a week or two and may make it easier to stabilize priorities. You will also need a backlog (sounds like you have a large one already).
Management may be more willing to hold off new priorities if you can slot them into a sprint in a week or two. You will also be able to identify the priority tradeoffs. If you add something to the next sprint, what will be removed.
Consider having part of the team working Agile while the others maintain the status quo. Rotate one team member each sprint as you are gaining experience. Consider having the whole team participate in a daily stand up status meeting, and the post sprint review. Once you have demonstrated increased productivity and returns to the company you should be able to increase the amount of work being done using your methodology.
Agile is a adaptive methology. Expect to be making major changes to your methodoly for the new year or two. Eventually, you should reach a stage where you are fine tuning.
根据我的经验，要使敏捷（至少是 XP 或 Scrum）发挥作用，您绝对需要满足以下条件。如果没有这些先决条件，您很可能会失败。难的。
考虑到这些要点，只要坚持价值观，您就可以解决任何问题。
In my experience, you absolutely need the following for agile (XP or Scrum at least) to work. Without these prerequisites you are likely to fail. Hard.
Give these points, you can probably tackle anything as long as you keep to the values.