作者：Oliver Teckert

当项目即将或者已经面临重大问题时，通常会出现如下三个危险信号：

1、待办事项的无故增长

无故增长可以是项目范围大大超出估计、新的和不完整的条目的无尽增加。待办事项旨在体现项目的范围，通常以用户故事的形式，专注于能定义项目的核心特征的目标。待办事项也为了让开发者对特征和开发工作的范围和完成它们必须的能力有一个清楚的估计。一旦项目开始，待办事项的目标就是追踪开发工作，以及寻找必须添加到待办事项中的意外工作。通常来说，开发者已经在待办事项中谨慎地估计了完成项目原始规模面临的范围和能力限制。如果在待办事项中，项目的范围不断扩大，却没有定期审查，那么你就遇到范围潜变问题了。

如果没有划掉待办事项中的某些条目，那么你就无法利用待办事项对项目进行有意义的跟进。待办事项也无法匹配半完成的特征、新想法和未完成工作。无法在待办事项中追踪进度，你就会遇到下面的极端报告问题。

Bobs(from gamasutra)

2、极端报告

作报告是经理和团队成员之间反馈循环的重要部分。它的作用在于，帮助监控和追踪进度，帮助你深入了解项目的不同方面，特别是当你必须确定是否需要采取纠正措施时。当你不能预先跟进待办事项时，你通常会求助于被动的报告。项目的进度越滞后、优先级和相关性越混乱，报告就越多。报告可以显示进程中的结构性缺陷，进而帮助你调整待办事项中的优先级，重新评估你的冲刺计划或考虑团队的技术构成。

这里的大问题是，你使用报告来运作你的项目，相当于带着漏洞进行alpha/beta测试。不是着眼于大局和从战略上计划你的开发过程，你现在是专注于非常直接的短期紧急任务，企图让项目回到正轨。但短期计划和“分级验伤”似的工作流程只会使问题越积越多。在这里，你要记住，使用报告来定位生产管理过程中的结构性和程序性问题，然后使它们成为当务之急。考察一下项目的基本执行情况，对没有完成的部分给予更多支持。你必须知道你为什么要评估、评估什么以及根据你追踪到的问题你要做出什么决定。事实上，任何与收集指标有关的人都应该很清楚这一点，这样人们才会：

*有动力提供指标

*报告正确的事情，且不会误解

记住，报告可能会严重阻碍项目，如果你只是不断地评估指标而不解决核心开发问题的话。

Overloaded(from gamasutra)

3、冲刺目标总是失败

听起来很正常？如果你总是遇到冲刺失败，那么你的项目很可能进展得不好。这之所以成为一个大问题是因为，许多开发团队都不把总是冲刺失败当作一回事。他们对这种失败如此不在意，认为对冲刺目标做出重大调整也是可以接受的，甚至完全背离了冲刺目标，使冲刺计划因不断的调整而变得多余。

这里，应该关注的危险信号是：

*大大改变估计和重新定义冲刺目标的范围

*在待办事项中移除多个条目和添加多个条目

*修改冲刺目标的完成时间，使速度变得毫无意义

冲刺目标会议的目的是明确冲刺目标、指派任务和在工作开始以前详细评估冲刺计划。这个过程也是为了引导团队进入下一个冲刺迭代，因为它让团队了解正在制作的特征。当出现以下情况时，可能导致重大失败：

*要求不恰当，必须重新评估

*因为最紧急的工作，新的优先条目必须迅速执行

*因为会议、生病或其他意外的干扰事件影响了速度

一发现根本问题就立即解决它们，不要等到冲刺计划展开才处理。预先主动处理一个冲刺计划到另一个冲刺计划的变化，并明确要求。周转速度是团队进度的衡量标准之一。如果使用得当，可以让你对团队的能力有非常准确的把握。如果使用不当，可能徒劳地增加团队的负担，直到敏捷开发失去敏捷性，这样冲刺目标失败也不可避免了。

当然，尽管还有很多信号预示着你的项目可能遇到麻烦了，但本文所介绍的三个是最重要的。如果你的项目遇到这些问题中的任何一个，你就要坐下来重新评估你的项目的目标和制定达成目标的计划了。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Agile Development Hell: 3 warning signs

by Oliver Teckert

Let’s let a look at some specific warning signs that tell us when a project is heading for significant problems…or is already there.

1.  Unchecked growth in the Backlog

Unchecked growth can refer to estimates wildly outside of the scope project, endless new and incomplete additions in the backlog or just sheer volume of entries. The backlog is intended to be the vision of the project, generally in user story format with a focus on goals that relate back to the key features that define the project. The backlog is also where initial estimates appear to start sizing out features and development work which help bring clarity to the scope and capacity necessary to complete a given feature. Once the project begins the purpose of the backlog is to track development work and to flush out unexpected work that must be added to the backlog to complete the project successfully. Typically there are scope and capacity limits that have been carefully determined for the project in relation to its original scope. If the scope of the project grows in the backlog without regular grooming you have a traditional scope creep problem.

Without intervention in the form of direct action to redlining your backlog you will lose the ability to meaningfully track your project in the backlog. It will become a mismatched listing of half-finished features, new ideas and work that will never be complete. Without the ability to track progress in your backlog, you will turn to extreme reporting.

After going over the reports the Bob’s would like a word…

2.  Extreme reporting

Reporting is an important part of the feedback loop for the managers and team members. It serves to help monitor and track progress in a number of ways and can help you gain valuable insight into different aspects of your project, especially when you need to determine if corrective actions are required when things start to derail. When you can’t track your backlog proactively, you often turn to reactive reporting. And the worse things get, the more the project gets behind and confusion mounts on priorities and dependencies, the more reports you begin to run. Reports can help show you where structural deficiencies are in your process, which can help you prioritize getting your backlog back in order, re-evaluating your sprint commitments or looking at the skillset composition of your teams.

The big danger here is that you use reports to start running your project through a triage workflow that resembles the way you work with bugs during an alpha/beta process. Instead of looking at the big picture and planning your development strategically, you are now concentrating on the very immediate short-term priorities in an effort to get the project back on track. But with short term planning and triage-like workflows the problems will keep piling up. The thing to remember here is to use the reports to target structural and procedural problems in your production management process and to make them your highest priority to resolve. Take a look at the basic execution of your project and reinforce the areas that are failing to get the job done. You need to know exactly why you measure what you measure and what decisions you are going to make based on the issues you track. In fact, everyone involved in the metrics-gathering should be very clear of this so that people are:

Motivated to provide the metrics

Report the right thing without misunderstanding

Remember that reporting can be a huge hindrance to a project if you are constantly measuring metrics that do not address your core development problems.

Of course you will fit. What could possibly go wrong!

3.  Consistent sprint failures

Sounds fairly obvious right? If you are encountering consistent sprint failures, you are most likely not progressing well with your project. The issue here is that many development teams do not recognize sprint failure as problem. They define failure so completely and utterly that significant alterations to the sprint are considered acceptable, even when they completely move the goalposts for the sprint or make the sprint planning session redundant due to constant change.

Warning signs for concern include:

Changing estimates significantly and redefining scope within the sprint (Moving goalposts)

Removing items and adding items aggressively from the backlog (Sprint thrashing)

Shaping the burndown signature into a nice 45 degree downward slope (Renders velocity meaningless)

The purpose of the sprint planning meeting is to recognize sprint goals, commit stories and do some more detailed estimates within the sprint before work begins. This process is as much to guide the team through the next sprint iteration as it is to gain insight into the features you are building out. Significant failures can result when:

Requirements are inadequate and must be reviewed

New priority items must be expedited for immediate work

Interruptions from meetings, illness or other unexpected distractions affect your velocity

Recognize the root issues and address them directly, do not wait to clean up the sprint once it’s started. Proactively address the changes sprint to sprint and get the requirements nailed down. Accept that velocity is designed as a measure of organic team progress that is invaluable. If used properly it gives you a realistic understanding of your team’s capacity based on actual effort. If abused it can be used against the team to ungratefully load them with more and more work, until agility is lost and sprint failure is inevitable.

Though there are certainly many signs your project could be headed for trouble, these are three of the top issues encountered working with developers.  If any of these issues describe your project or sound very familiar, you should probably sit down and re-evaluate what you are trying to accomplish on your project and how to plan to get there.(source:gamasutra)