IT牛人博客聚合

自从我发布了“Scrum为什么不行”，并被CSDN推成首页头条后，我在我的新浪微博上就经常被敏粉们@去讨论他们的一些话题。他们似乎想要从我这里听到一些不同的声音，我很喜欢他们的这种态度，在这里先赞他们一个。既然，让我来评论他们的东西，我就不客气了，板砖自然是少不了的。 我觉得我在微博上的观点比较散，所以在这里做一个汇总。我在所有批评敏捷的文章里都重复说过我的立场，这里还要再说一遍，因为那群人很敏感——“我承认敏捷中有一些东西我是认可的，但对敏捷社区的推广和思维方式我持否定态度”。

敏捷词汇表

我被@吴穹adam邀请进入了一个敏捷词汇表的微群，这个群就是想明确的定义一下敏捷的各种词汇，比如，他们想把TDD定义成就是UT。呵呵。我对

查看全文: http://www.udpwork.com/item/5636.html

这篇文章的原文在这里（原文链接）（下文不是全译，也不是部分译，我只是把其总结，有我自己的发挥，但是原意大致不变），这篇文章完全是在调侃Scrum的，作者第一段就是一个免费声明，其说他是Scrum和其它敏捷方法的big fan， 他也认为Scrum 100% 对 软件开发可行。作者使用Scrum 5年了，也公开作过几次敏捷的分享会。他觉得写这篇文章只是为了好玩，因为他们戴上Edward de Bono 的 black hat （黑礼帽 – 是6个思考之帽中的一种——负面思考，思考事物的负面因素，这样才知道：它会起作用吗？缺点是什么？它有什么问题？为什么不能做。）

因为本人经常站在Agile的风口浪尖，所以我有必要也来一个

查看全文: http://www.udpwork.com/item/5505.html

    第三章：三思而后行：前期准备

    3.1：计划的重要性是不言而喻的，需要明确的是：软件不仅仅是开发代码。创建高质量的架构活动需要一定的技能，这些技能不是轻而易举能够获得的，某些准备工作也需要特定的人来做。优秀的程序员永远是紧缺的，当更好的机会摆到面前的时候，在一个蛮荒的软件企业中工作是不明智的（欢迎来阿里云，简历发到longtask@gmail.com,呵呵）。软件错误的积累就如同食物链一样，越到食物链顶端，累积的有害物质越多，软件开发过程中，发现错误的时间要尽可能的接近引入该错误的时间。例如：修复一个架构缺陷大概需要￥1000，在系统测试修复这个缺陷就可能花

查看全文: http://www.udpwork.com/item/4347.html

Scrum是一种敏捷开发过程，最基础的介绍推荐看这个：An Overview of Scrum

关于Scrum运行当中常见问题及解决方法，我曾写过一个slides，在公司内部分享，现在重新整理了以后共享在这里：近距离接触Scrum

近距离接触Scrum
View more presentations from huandu.

关于Scrum，最常见的误解是Scrum master == team lead，这是不对的。Scrum master可以是任何人，不需要担当任何管理职责，在Scrum中只是一个推动者。

除了Scrum过程本身，还需要整个team共同遵守一些游戏规则。这些规则可以根据实际情况来制定，不过尽量不要超过3项

查看全文: http://www.udpwork.com/item/732.html

不少公司都在考虑采用敏捷开发，或者在项目开发过程中融入敏捷的思想，在这里，我列出几个常见的误区，希望能对大家有所帮助。

欢迎发表不同意见。

误区：敏捷开发 == 极限编程/Scrum/…

敏捷开发是一种方法论，只是一些基本原则的集合，并非具体流程。

极限编程、Scrum等流程是具体的实施方法，它们都声称符合敏捷开发的思想，但执行起来是否真的“敏捷”，还得看参与者究竟思想上是否真的接受敏捷开发的原理。

如果把结对编程、daily scrum当做是敏捷开发的表现，那更是本末倒置，可悲的是，不少人还真是这么认为的。

误区：敏捷开发 == 简化流程

敏捷开发不一定能简化工作流程，而且简化流程也并非提出敏捷开发的初衷

查看全文: http://www.udpwork.com/item/737.html