敏捷转型
说到做到
阅读：
说到做到
今天早上我一觉醒来，就发现很多博客和推特都有相同的主题:评估很糟糕，成熟度模型很糟糕，工具很糟糕，参数很糟糕，度量很糟糕，我们应该把这些都删掉。消除这些问题需要客户和团队之间以及管理层和团队之间的信任。在您要求您的客户或您的管理层消除评估、成熟度模型、工具、指标和度量之前，请您自己和您的团队确认您是否值得信赖。当你打算做的时候，你会做你说过要做的事吗?你能快速冲刺并每次都成功吗?
如果可以的话，你有一个有信任的案例。如果你不能......你和你的团队应该先向自己展示自己。向任何组织提出连续的金钱和时间流动，这是不合理的，而不会给他们一些合理的想法，他们将获得他们的金钱和时间。
评论（8）
德里克Huether
当人们说一些“东西”是坏的时，我总是发现很有趣。事情没有动机，人们所做的。我被告知吃红肉是坏的，把盐放在我的食物上是坏的，喝咖啡很糟糕，而且名单继续下去。我列出了与食物相关的物品，因为取决于你吃或喝的东西，它“可以”实际上杀了你。但是，每个物品都不错。它只在一个特定的情况下的特定情况，它可以“潜在”是有害的。
我可以争辩说，估计是好的，成熟的模型是好的，工具很好，测量很好。但是，我不会和他们一起去除它，它扼杀了我的项目的生活。太多的东西可能是不健康的。
是人性的是如此极地吗？为什么有些人看到黑色或白色的一切？
我觉得一点温和走了很长的路，一切都只是灰色的阴影。
苏格兰人
我只是觉得估计不好，还不错，只是适得其反。我更喜欢度量和收集指标，而不是根据时间/复杂性等任意大小来评估故事。我最近发现故事可以很好地预测项目的规模。我们可以一次迭代做X个故事;假设这个数是10。如果在一组提议的功能中有30个故事(例如最小的可发布功能)，那么“估计”(预测)就是3次迭代。尝试用每一个故事去遍历每一个可能的未知排列——对于整个团队来说，这只是一个耗费精力的半天会议。我不认为它比我们已经告诉客户的内容(3次迭代)增加了价值。
其余的......良好的指标和测量对于了解您作为一个组织的作品至关重要。我看不到那种甚至是渴望消除我的甚至是令人沮丧的，我并不是对CMM样式的东西真正了解它来评论它。
Vin D中保
我同意德里克。“事情”不好或坏。这是我们如何使用它们的差异。适用于一个Dev团队的工具或技术可能会因另一个人而失败。为什么？文化，培训，经验，优先事项，目标等的差异。
团队所做的一切都应该增加价值。如果没有，改变它或消除它。努力说你能做的，做你能说的。
敏捷侦察员
同意。+1到德里克。看，事情不好也不糟糕。这就是你的执行方式。如果执行价值，那么问题是什么？关于“这个或这是坏”的毯子陈述没有帮助。
这很有趣......当我写这个时，我没有考虑那些做法的绝对价值，无论是好的还是坏的。在你值得信赖之前，我正在考虑要求被信任的想法。我听到很多人谈论信任团队，消除估计和日期是关于信任的。坦率地说，大多数球队都不知道如何可靠地提供软件。如果我在软件开发团队中，我会努力成为良好的，制作和会议承诺，然后曾经被认为是值得信赖的。如果你想受信任......值得信赖。
你们解读我写的东西的方式很有趣，这很酷，但这不是我写的时候脑子里想的。
苏格兰苏格兰州......当我们通过Twitter谈论时，我想说的是......对我来说，如果你的故事均相对相同的大小，故事只有你的故事。如果您在1到3之间有一个统计分布的故事组......或者所有小......或所有需要大约一天或两个......故事数量有意义。如果故事的复杂程度在1和13 ......或一个小而额外的大...或者在一天和一个月之间需要的东西......故事数量毫无意义。
以下是我的背景……我在很多大公司工作，产品复杂，有大量的技术债务和大量的依赖。这些人可以从敏捷中受益……如果我帮助他们的时间足够长，他们就会慢慢变得敏捷……但笼统地说评估总是不好的，应该总是避免，对我来说是不可能的。这就是为什么我一直说“很高兴对你有用”。如果这在你的环境中行得通，那么我真的认为这很好，你应该使用它。
对我来说......我不能说估计是废话。我最多的团队开始估计是故事点，并打破任务，以及估算任务......直到我可以让他们将事情打破到小型，类似的用户故事中，我们可以删除任务。如果我们可以让一切都足够小，我会同意你的看法并将所有人估算在一起......不幸的是，大多数团队都没有，需要估计任何类似的可预测性......如果别的什么，估算过程迫使他们一起工作并思考问题。
无论如何......只是我的观点。我当然尊重你的评论，在这里和推特上欣赏你的评论。
Sridhar.
我认为，为了做某事而做某事，而不是因为它提供了价值，是产生“糟糕”感觉的主要原因之一。我认识的一个项目团队有一个复杂的业务项目，其中业务用户提供了大约700个详细的用例。亚博vip9通道由于团队遵循“敏捷”，他们尝试将用例转换成相同大小的故事，然后估计/预测时间线。你可以想象在这一过程中浪费了多少精力(虽然将其转化为同等大小的故事已经足够困难了，但在没有很好的领域概念的情况下试图确定最简单的故事更是困难)。
我见过的团队犯的一个基本错误是选择一种方法并尝试100%地坚持它。这就是过程成熟度很重要的地方(尝试我们所讨论的其他事情之一)。团队需要有一个工具箱，可以根据情况从工具箱中选择合适的方法。
在这里和其他人和他人交谈，这将是很好的。
我对客户的第一件事之一是告诉他们，我们将以正确的原因打破任何敏捷的规则。您必须了解原则并选择正确的实践。在您提到的情景中，我可能有一些人们专注于用户故事，以商业价值，风险秩序。亚博vip9通道有一些团队建立故事以了解系统。然后让两个曲目通知下一步。我相信有1000种方法可以攻击这一点...在编写任何代码之前创建整个积压不是我选择的。