【分享】敏捷开发之道之——做事
魔鬼告诉你：“出了问题，第一重要的是确定元凶。找到那个白痴！一旦证实了是他的错误，可以保证这样的错误永远不会再发生了。”。
有时候，这个老魔头的话听起来似乎很有道理。毫无疑问，你想把寻找罪魁祸首设为最高优先级，难道不是吗？肯定的答案是：不。最高优先级因该是解决问题。
也许你不相信，但确实有些人常常不把解决问题放在最高优先级上。也许你也没有。先自我反省一下，当问题出现时，“第一”反应究竟是什么。
如果你说的话只是让事态更复杂，或者只是一味地抱怨，或者伤害了他人的感情，那么你无意中在给问题火上浇油。相反，你因该另辟蹊径，问问“为了解决或缓解这个问题，我能做些什么？”在敏捷的团队中，大家的重点是做事。你应该把重点放到解决问题上，而不是在指责犯错者上面纠缠。
指责不能修复bug。 Blame doesn’t fix bugs.
世界上最糟糕的工作，除了在马戏团跟着大象后面打扫卫生，就是和一群爱搬弄是非的人共事。他们对解决问题没有兴趣，相反，他们爱在别人别后议论是非。他们挖空心思指手画脚，议论谁该受到指责。这样的一个团队的生产力是极其低下的。如果你发现自己是在这样的团队中工作，不要从团队中走开——应该跑开。至少要把对话从负面的指责游戏中引到中性的话题。比如谈论体育运动或者天气。
在敏捷的团队中，情形截然不同。如果你向敏捷团队中的同事抱怨，他们会说：“好，我能帮你做些什么？”他们把精力直接放到解决问题上，而不是抱怨。他们动机很明确，重点就是做事，不是为了自己的面子，也不是为了指责，也无意进行个人智力角斗。
你可以从自己先做起。如果一个开发者带着抱怨或问题来找你，你要了解具体的问题，询问能提供什么样的帮助。这样简单的一个行为就清晰地表明你的目的是解决问题，而不是追究责任，这样就会消除他的顾虑。你是给他们帮忙的。这样，他们就会每次走近你的时候，你会真心帮助他们解决问题。他们可以来找你把问题解决了，当然还可以继续去别处求助。
符合标准不是结果
许多标准化工作强调遵从一个过程，按符合的程度做评判，其理由是：如果过程可行，那么只要严格按这个过程行事，就不会有问题。
但是现实世界并不是如此运行的。你可以去获得ISO-9001认证，并生产出一件漂亮的铅线织就的救生衣。你完全遵循了文档中约定的过程，糟糕的是到最后所有的用户都淹死了。
过程符合标准并不意味着结果是正确的。敏捷团队重结果胜于重过程。
如果你找人帮忙，却没有人积极响应，那么你应该主动引导对话。解释清楚你想要什么，并清晰地表明你的目的是解决问题，而不是指责他人或者进行争辩。
指责不会修复bug。把矛头对准问题的解决办法，而不是人。这是真正有用处的正面效应。
切身感受
用于承认自己不知道答案，这会让你感觉放心。一个重大的错误应该被当做是一次学习而不是指责他人的机会。团队成员们在一起工作，应互相帮助，而不是互相指责。
平衡的艺术
“这不是我的错”，这句话不对。“这都是你的错”，这句话更不对。
如果你没有犯过任何错误，说明你可能没有努力去工作。
开发者和质量工程师争论某个问题是系统本身的缺陷还是系统增强功能导致的，通常没有多大意义。与其如此，不如赶紧去修复它。
如果一个团队成员误解了一个需求，一个API调用，或者最近一次会议的决策，那么，也就意味着团队的其他成员也有相同的误解。要保证整个团队尽快消除误解。
如果一个团队成员的行为一再伤害团队，则他表现的很不职业。那么，他就不能帮助团队向解决问题的方向前进。这种情况下，我们必须要求他离开这个团队。
如果大部分团队成员（特别是开发领导者）的行为都很不职业，并且他们对团队目标都不感兴趣，你就应该主动从这个团队中离开，寻找更适合自己发展的团队（这是一个有远见的想法，没必要眼睁睁地看着自己陷入一个“死亡之旅”的项目中）。
