当我安装MS-TFS 2008时，我开始准备使用随TFS服务器一起提供的Agile Process Guidance模板。通过一点谷歌搜索，我浏览了迈克科恩的材料：
我非常高兴吸收和使用他与团队一起使用的技术，以及敏捷和Scrum是如此优秀的软件过程/方法，直到我看到Mike回答关于架构师角色的问题并谈论需求文档......在这一点上，由于以下原因，一切都开始分崩离析：
想象一下，你是那种曾经喜欢面对各种挑战的人，并且为利益相关者和你自己带来了出色的经验和成果，如此公平敏捷和scrum流程将如何信任和承认你的才能和激情而scrum master / coach将团队视为一个完成用户故事并通过试错法融合的单位?? !!!!
对于那些关于敏捷和Scrum的黑暗想法，我发现许多人“反敏捷”，而且他们之上是“Crispin Rogers Johnson”：
http://agile-crispin.blogspot.com/
那家伙对迈克·科恩过去谈论的所有内容做了反陈述。
我真的不知道下一步该做什么！所以任何指导都将受到赞赏。
谢谢，
答案 0 :(得分：3)
对于每个项目都有正确的发展战略。如果NASA使用敏捷或scrum，他们将不会有卫星系统所需的100,000行代码缺陷率。你不能释放和迭代这些错误。如果你这样做，你最终会看到你的系统崩溃进入火星。
那就是说，你不应该在一个与一些好莱坞大亨的狗或粉丝有关的网站的每一个细微差别中详细说明。当客户给你反馈意见时，你会迭代并修复这个问题。
一切都平衡，每一个平衡。也许你应该读一本像Rapid Development这样的书。虽然它有点过时，但是神话般的人月，但两者都有持久的价值。这些应该教导的是除了很多之外没有办法做任何事情。该项目应该决定你的方法而不是一些福音派软件大师。
免责声明：这绝不意味着非敏捷用于“真正”用途，而敏捷应该降级为Scruffy McPointless项目。
答案 1 :(得分：3)
正如Wheaties所提到的，一种策略并不适合所有情况。敏捷方法通常非常适用于那些要求在开始时不是很清楚和/或将会发生变化的产品。随着系统的迭代构建，产品得到改进，并通过与客户的协作实现客户的愿景。与此同时，从我所看到的，安全或某些非常昂贵且不可恢复的东西，例如卫星，通常不属于这些项目的关注列表。
Scrum和XP分别提供了处理敏捷管理和工程工作的最佳实践。您应该根据自己的情况自由采用/修改这些最佳做法，同时继续检查您对Agile Manifesto精神的启示。
最后，这个interview with Linda Rising on InfoQ调查了敏捷是否经过科学证明。基本上，敏捷社区的人是否给自己一个“糖丸”？
采访摘录
科学是关于实验，关于在短时间内持有一个想法并对其进行测试，然后检查该测试的结果以确定该假设是否成立。这就是敏捷的真正含义。敏捷是关于小实验的。我现在相信我们所做的一切，不仅仅是软件开发，而是我们的生活应该是一系列小实验。
我们引进所有可能的利益相关者，我们引入客户，引入用户，测试人员与开发人员合作。我们一直在仔细检查那些糖丸。它真的有效吗？你怎么看？你对结果满意吗？这是拯救我们的唯一因素 - 敏捷本身。这一系列的小实验。
答案 2 :(得分：1)
如果scrum主人/教练将团队视为一个完成用户故事并通过试错法融合的单位，那么相当敏捷和scrum流程将如何归功并承认您的才能和热情？!!!
如果你的PO很开心，客户很高兴，你的BOSS很开心，你的产品也很成功;那么你应该期待看到自己和团队通过增加工资和/或其他奖励（如度假，股票，免费午餐）获得公正的奖励。
如果你想让Sunshine每天都因为你的“英雄”努力再次摧毁你的屁股，那么scrum会让你大为失望，因为敏捷过程本质上会消除英雄的位置。
顺便说一句，你描述了你成功的“2个月分析”，我猜你的项目定义得很好，或者你的利基很慢，无论你使用什么过程，你都会成功。当您不能花费2个月并提出所有要求和设计时，Scrum会显示其真正的优势。