这次MPD软件工作坊培训，最大的收获就是培训者引导你了解了为什么，而不是直接告诉你该怎么做。其实只要清楚目标在哪，无论怎么走都是可以到的。
随便百度一下，我们可以了解到项目管理的定义是“在有限资源限定条件下，实现或超过设定的需求和期望”。一句话形成了项目管理的铁三角，需求是范围，资源包括时间和成本。
这传承多年的“定义”是对的吗？摩托罗拉的铱星计划，计划发射77颗卫星，最后只发射了66颗卫星就“圆满“完成了目标。可谓成本的项目。电影泰坦尼克号拍摄过程多次拖期，预算超出很多，可谓是个彻底失败的项目。
可是结果呢？好像哪里不对？铱星项目发射的卫星现在全成摆设，而泰坦尼克至今仍然是世界的票房神话。
到底哪里不对呢？
我们的项目管理铁三角里忽略了价值。
就是这里了，我们的目标是创造价值，实现共赢。
好，目标在这里了，到达目标的方法有很多，每个人都会找到方法。敏捷有很多的流派，有很多的实践来帮助人们达到这个目标。了解别人怎么做，最重要的是理解别人为什么这么做。
要创造价值，第一问题就是做什么是有价值的。换句话说怎么样才能获得有价值的需求。
来自客户? 客户永远要更快的马车。
客户往往讲不清楚需求，但这些讲不清楚的需求有些甚至是影响整个结构的关键。
来自产品人员的策划？ 没人能说明下面的设计放在网页上更受用户喜欢。
来自领导，业务顾问，运营团队？
貌似都不太对。
敏捷项目管理说，来自市场的真实反馈。要得到市场的真实反馈我们需要持续不断的及早的交付有价值的软件。通过市场反馈来获取新的价值。
这点做的就好的应该属于各大互联网公司了。每月每周甚至每天的发布新功能到市场上，搜集用户反馈和反应，除了用户的主动反馈，还包括点击率、浏览量、用户停留时间等访问记录。根据反馈迅速移除没有价值的功能，增强有价值的功能以创造更大的价值。（关于移除功能，甚至关闭一个没有价值的项目，这正是敏捷的魅力所在，它不但可以让项目迅速创造价值，也可以让本不能创造价值的项目迅速失败。个人观点：让一定会失败的项目快速失败可以节省大量的资源，给系统带来的价值甚至更高！但这一点却往往被忽略。认为敏捷必须把项目带向成功，想想铱星项目，如果早早发现没有价值，世界可能都会不一样，至少摩托罗拉公司会不一样吧。）
听起来很美，联系我们的实际却很困难。我们不能立即发布新功能到市场上，我们不能随意的移除没有价值的功能，我们甚至很难从市场获得功能的价值信息。听起来很沮丧。但是，幸运的是，我们知道我们的目标是什么，我们可以千方百计地收集用户反馈，我们可以通过我们的声音影响一些决定，让我们做的事情更有价值。这本身就是双赢的事情，应该会被逐渐的接纳。
回到主题，持续交付很好很强大，但它带来了新的问题。如何保证交付质量，如果交付到市场的软件由于质量问题根本不可用或者几乎不可用，是不可能得到正确反馈的。敏捷答，持续集成，测试驱动开发。
持续集成不说了，我们做的很好。测试驱动开发无论何时何地，一提出都是一个争议性话题，因为这看起来太不敏捷了。一连串的问题，写测试脚本会拖慢进度怎么办？测试脚本的质量又如何保证？测试脚本会对变更产生格外的工作量，怎么办？等等。其实，这也是我心中的疑问。通常得到的答案都是，测试驱动开发产生的工作量都是值得的！好吧，还是那句话，目标在那里，为了实现高质量持续交付的目标我们可以选择的方法很多。加强代码审查，对关键功能，关键模块做自动测试覆盖。甚至包括遗留一些bug但是得到用户反馈之后及时修复。虽然理论上没有测试驱动开发有效，但是我们可以根据自己的实际情况，在投入和收益上找到平衡点，步子小一点也行更不容易跌倒。
综上，敏捷项目的“铁三角“： 
更强调了价值和质量。
当然质量是很重要的，但质量并不是越高越好。比如，招聘网站一两个小时不工作，和证券交易系统一两个小时不工作，对用户的影响肯定是不一样的。所以质量的要求要依赖产品和需求的背景。
不可忽视的是，铁三角里没有提到，但是却在敏捷项目管理中至关重要的一环——人。
价值是人创造的，为人服务的，很多敏捷实践是围绕人展开，试图找到一种（一系列）通用的方法来最大限度的发挥人的能量。例如计划游戏，组建自组织团队，信息公开透明化，集体承诺目标。都是调动团队积极性，消除可能影响团队成员贡献的因素。
对于敏捷实践，林林总总，有如十八般兵器，各门武功，都是名家大师的智慧精华。但是如果只知道招式不知道招式的目的，很容易被人一招打倒的。
本文转自 powertoolsteam 51CTO博客，原文链接：http://blog.51cto.com/powertoolsteam/1265976，如需转载请自行联系原作者
