2010-04-02 80 views
1

当我安装MS-TFS 2008时,我开始准备好使用TFS服务器附带的敏捷过程指导模板。随着一点点的谷歌搜索,我通过迈克科恩材料去:敏捷和Scrum让我失望,请帮我弄清楚道理

  1. 我看着他的YouTube“由谷歌主办的”会议:
    http://www.youtube.com/watch?v=fb9Rzyi8b90
    http://www.youtube.com/watch?v=jeT0pOVg0EI
  2. 阅读他的著作“敏捷估计与规划”
  3. 在他的网站上观看了视频系列:http://www.mountaingoatsoftware.com/presentations-tag/video-recorded

我很高兴,同时吸收和吃技术他与团队一起使用,以及敏捷和Scrum如何是一个伟大的软件过程/方法论,直到我看到Mike回答有关架构师角色和讨论需求文档的问题......在这一点上,一切开始崩溃,由于如下:

  1. 去年我已被分配到对大项目“非常高优先项目”进行全面分析“包括需求收集”。
  2. 在艰苦的工作,奉献和承诺的2个月内,我以完全满意的客户以及我的BOSS和ZERO修正案完成了整个分析。
  3. 后来,项目进入了架构,开发阶段。
  4. 由于这样的事实,该系统包括许多具有竞争力和令人兴奋的功能,我要求申请专利它和它在这个过程中去...

所以,想象一下你是谁用爱面对所有的那种人各种挑战和回报,为利益相关者和你自己带来卓越的经验和成果,公平的敏捷和Scrum流程将如何相信并承认你的才能和激情,而Scrum主/教练则将团队视为完成用户故事并通过试错法?!!!!

随着关于敏捷和Scrum那些黑暗的想法,我发现很多人的“反敏捷”,并在它们上面是“克里斯平·罗杰斯约翰逊”:
http://agile-crispin.blogspot.com/

那家伙由耐声明的一切麦克科恩曾经谈过。

我真的不知道下一步该怎么做!所以任何指导将不胜感激。

感谢,

回答

3

每个项目有一个正确的发展战略。如果美国国家航空航天局使用敏捷或scrum,他们不会有卫星系统需要的100,000行代码缺陷率。你不能释放并重复执行错误。如果你真的认真看着你的系统碰撞火星。这就是说,你不应该在极其详尽的细节中详细说明与好莱坞大亨的狗或粉丝团有关的网站的每一个细微差别。当客户给你提供反馈时,你可以重复并修复这些问题。

每样东西和每一个平衡都有一个平衡点。也许你应该读一本像Rapid Development这样的书。虽然它有点过时,但神话般的男人月,但都具有持久的价值。这些应该教导的是,没有办法做事,但有很多。该项目应该规定你的方法,而不是一些福音派软件大师。免责声明:这绝不意味着非敏捷是为了“真正”的用途,而敏捷应该降级到Scruffy的McPointless项目。

+0

非常周到的答案!你能告诉我,微软对敏捷的过程指导是否设计了某种方式来弥补美国航天局和好莱坞例子之间的差异?我认为TFS敏捷版本已经通过包含不属于敏捷的文档模板进行了定制。如果我错了,请纠正我。 – 2010-04-02 02:51:19

+2

我不认为敏捷说“释放并重复错误”。测试应该在迭代期间完成,而不是一旦代码被发布。 – 2010-04-02 12:26:10

+0

在我对敏捷的描述或如何在那里完成测试的过程中,我没有主张没有测试。然而,我相信敏捷允许更早的更现代的版本,并且将方法学迭代到软件上比瀑布更好。 – wheaties 2010-04-02 13:00:22

3

正如Wheaties所提到的,一种策略并不适合所有情况。敏捷方法通常非常适合那些一开始就不了解要求和/或将要改变的产品。通过迭代地构建系统,并通过与客户的协作,使客户的愿景符合客户的愿景,产品得到完善。现在,与此同时,从我所看到的,安全或真正昂贵且不可恢复的问题,例如卫星,通常不在这些项目的关注列表中。

Scrum和XP分别为处理敏捷和敏捷的管理和工程提供了最佳实践。您应该根据自己的情况自由地采纳/修改这些最佳实践,但同时要根据Agile Manifesto的精神检查您的实践。

最后,这个interview with Linda Rising on InfoQ考察了敏捷是否经过科学验证。基本上,敏捷社区的人们给自己一个“糖丸”?

访谈摘录

科学是关于实验,约持有的想法很短的时间周期和测试,然后检查该测试的结果,找出的假设是否成立起来。这正是Agile所关心的。敏捷是关于小实验。我现在认为,我们所做的一切,不仅仅是软件开发,而且我们的生活应该是一系列小实验。

我们引入每一个可能的利益相关者,我们引入客户,引入用户,测试人员与开发人员一起工作。我们一直在仔细检查那些糖丸。它真的有用吗?你怎么看?你对结果满意吗?这是拯救我们的唯一东西 - 敏捷本身。这一系列的小实验。

+0

是的,灵活性在人类生活中扮演着重要角色,而且我个人总是采取变化,但听起来像软件行业的科学决策太多,使得标准化或工程设计变得更加困难。真的是怎么一个人在第二天进入计算机科学专业,他们称他/她的软件工程师?! – 2010-04-02 03:19:19

+0

您可以添加一个术语/标题..“开发人员”:)我认为这是由于软件的基本可变性以及我们行业相对其他工程学科的相对婴儿期。例如,考虑一下自从我们进行了自动构建,单元测试等多长时间以来,时间不是太长。而这些标题因为与它们不同的内涵而被卡住了。例如,软件工程师意在表示,不仅您对CS部分负责,而且还对您的努力进行量化,执行技术和财务权衡分析。 – 2010-04-02 03:51:30

1

如何相当敏捷和Scrum过程将信贷和承认自己的天赋和激情,而Scrum管理员/教练把球队作为一个单元,实现用户故事和收敛通过试验和错误的做法?? !!!

如果PO是高兴,客户很高兴,你的老板很高兴,你的产品是成功的;那么你应该期望看到自己和团队通过增加薪酬和其他奖励(如假期,股票,免费午餐)来获得公正的回报。

如果你希望阳光每天都会因为你的“英雄”努力而每天都会让你失望,那么scrum将会让你大失所望,因为大自然的敏捷过程会消除英雄的位置。

顺便说一句,你描述了你成功的“2个月分析”,我猜你的项目定义得很好,或者你的利基太慢了,无论你使用什么过程,你都会成功。 Scrum展示其真正的优势当你不能花费2个月,并拿出所有的要求和设计。

+0

说真的,这句话听起来更像是问题在团队中而不是在Scrum本身中工作。 – Nate 2010-04-03 00:34:35

相关问题