Situational Leadship

clipped from www.infoq.com 理想情况下，团队在其中进步到“能够，愿意”。我们从Tuckman的团队建设模型（"-orming model"）中已经知道，事件或状况可能导致团队被打回之前的状态（比如：新的团队成员或经济状况不稳）。同样需要注意的是，基于某些定义，团队至少要达到“愿意”，否则不能真正被看作是一个团队。 Hershey和Blanchard为每一种追随者取向分别指出了一种有用的领导风格。这表示对某个团队非常有效的东西，对另一个团队或其部分成员可能没那么有帮助。看起来一个敏捷领导者可能需要一套不同方法的集合。  在这一模型中，领导者的态度由轴线代表：“面向关系”表示对领导者与追随者之间关系的强调，而“面向任务”表示领导者需要做出的努力，使准备好的追随者完成实际任务。 这些领导风格也可以有其他命名： Telling告知 Directing指导 Selling推销 Coaching教练 Participating参与 Joining, Supporting参加，支持 Delegating授权 Trusting托付

Agile isn’t about the work. It’s about you.

clipped from blog.criticalresults.com Dilbert: "We need three new programmers." Boss: "Use agile programming methods." I really do hear it a lot: “We tried agile but it didn’t work.” Even the way one says this is passive. Something was out there, we tried it, it failed. Let’s rephrase that: “We picked some specific Agile practices and didn’t get the results we wanted or expected.” “We brought in an Agile consultant, but it just cost a lot of money and nothing really improved.” “The guy who’s always talking about pair programming, we let him do it, but nobody else is interested.” The difference is not just the informality, it’s the mental and emotional ability to connect with what needs to get done as opposed to what you’ve been told to do. That’s part of the principle of self-organizing teams. But you have to ask yourself, is your corporate culture one that rewards following orders? Or rewards the solving of difficult problems?

Modest Manager+Humility Culture

对于如何推进敏捷，如果只是从实践来着手，往往走向形式主义；如果从文化价值观的角度来着手，似乎是不可完成的革命。

How to promote Agile/Scrum is big topic. If only drive the practice, then the formalism is the unavoidable result; If try to change from culture and value, it seems a impossible revolution.

clipped from www.infoq.com 关于一个敏捷程序员需要什么技能，或者一个公司想要成功地实施敏捷必须采用哪些实践，还是有很多争论的。但是虽然其重要性不可否认，这真的就是敏捷成功的核心所在吗？Mark Schumann建议敏捷的“一个基本要素”并不是基础级的敏捷技巧，而是管理层的敏捷定见。  Schumman通过强调结对、TDD和站立会议这些敏捷实践背后的本质来介绍他的观点： 结对很重要，但是你能开心于每天被纠正几十次更重要。测试驱动开发很有用，但是去设想一百多种让测试通不过的场景更有用。站立会议可能很有效，但是同事的信任解放了你去做自己的事情，才让会议真正有效。 随后他把“纠正、设想和信任”联系起来，提升到了一个新的层次，并且解释了这真正的基本组成部分如何不仅在团队中、也在管理层中发生： 抛开陈词滥调，敏捷真的是一种态度或者一种定见。而且我觉得它应该自上而下展开。 我不知道是不是有一个单独的词汇来命名它，但中高级管理层中必须具备这样一种态度，承认他们不是什么都懂、有些事情无法控制、意外情况总会出现。你必须信任你的团队，甚至在他们没有交付你所期望的结果之时。你必须设想不止一种可能的结果。你必须得体而容易地接受对你第一印象的修正。 Schummann事实上找到了这个一开始没想到的名词，从而以此完善了他的思想：“成功敏捷开发起源于谦恭（humility）的文化”。  信任意味着你不得不放弃控制，放弃很多。 设想意味着你将少了很多确定性。 改正意味着你不得不承认从来就没有完美这回事。 ...成功运用敏捷软件开发——或者任何其他种类的敏捷——的公司，都是那些能处理好失去控制、确定性以及完美保证的公司。

敏捷-好的开发人员-培养他们-留住他们

clipped from www.infoq.com InfoQ中文站：有人说要成功应用敏捷开发，需要很好的开发人员才可以，你觉得如何呢？ Dave：我实在很爱这论点！虽然我完全不明白这是什么逻辑，但十分有趣。 “如果我想应用敏捷开发方式，那我就需要好的开发人员”，那是不是如果我采用其他方法就可以用差的开发人员呢？我从来都不认为在什么情况下可以接受低劣的开发人员。 当我去做顾问服务的时候，看到他们公司开发人员，我希望我可以跟他们说：“炒掉30%的开发人员”（但我从来未说过），因为这样其实可以提升效率，我不认为你可以期望在没有好开发员工下能做到什么好东西。 但不要误会，好员工跟巨星是有分别的，一班大师级的开发人员只会花时间在争吵，你需要的是良好的配合，一些好的，一些大师，也需要初级员工以作培训。 任何好的开发过程的核心都是好的员工，在其他行业也不例外，试想想你去到医院，里面有不好的医生那可不可以呢？无论什么行业，你都需要好的员工。 更重要的问题是，我们如何找到好的开发人员？ 我们这个行业，从来都没有一个好的方法去培养好的开发人员。我们有大学教授理论，不过学校不知道什么是真正的软件开发，而入了行再重新开始学习编程，我认 为这是不当的方法，你需要一些大师，好的开发人员，和初级开发人员，而我们的责任是使初级的开发人员成为良好的开发人员。这是开发优秀软件的重要因素。 2009年10月22日 上午9时23分 发表人 Tarzan Wang Tarzan Wang 当我去做顾问服务的时候，看到他们公司开发人员，我希望我可以跟他们说：“炒掉30%的开发人员” 哈哈，老大说的好呀，关键是如何招到好的开发人员，如何培养好的设计师，如何留住他们 Re: 关键是如何招到好的开发人员，如何培养好的设计师，如何留住他们 2009年10月22日 下午7时56分 发表人 egmkang wang 好的开发人员要看天赋的,还有就是上进心的. 我觉得好的开发人员都有洁癖,心理上的洁癖. 留住,是一个很大的问题.如果说,一个公司的流动性过大,就因该考虑这个公司的福利是不是出了问题.......人才有时候看重的不是福利....