如何非强制性地保持团队工作压力

Sprint在于激发队员的主动性，也是为了发挥团队所有成员的能力，查漏补缺。

Sprint的潜在意思是：所有人都是渴望尊重的，或者说是希望别人看重自己的，当一个人的自我意识得到满足时，就能主动地对事情负责，发挥主观能动性。当人负责任地积极进取时，工作效能能得到极大提高。

Sprint站在传统管理的对立面：不是自上而下地强制管理，而是通过给队员一个平等的、非拖沓沟通环境，激发队员的主动性，达到增加工作效率的目的。

但不是所有人天生都有责任心或者进取心的，遇到这种人Sprint用了责任到人的办法。

责任到人以前是通过至上而下的方式来管理的，一般是Project Manager给队员分派工作，然后用工作日（周）报表来监督工作进展。这是一种非常低效率、并且压抑员工进取心的方法——没有哪个程序员喜欢被人像木偶一样指挥——软件开发行业的脑力密集性产业特性决定了不能像工厂流水线那样管理团队。

Scrum在名义上做得很漂亮，它通过平等的方式，让大家自己“领取”任务，没有逼迫、没有指派，而且这些任务还是团队成员自己添加、认可的，就连完成的时间也是大家共同估算的。这就是Scrum化被动为主动的方式。

每个人的任务（Task）都记录到待办事宜里（Backlog），让大家都能看到自己（和别人）的任务和进度。再通过每天的站立会议通报自己的任务进展，让任务的监督从上级强制管理变为团队自我平等管理。

上面提到PM最头疼遇到没有进取心的人，可能会一直领取技术含量不高，劳动简单的任务，但只要团队的素质不是到一个无法忍受的情况（都不想做技术活，只想做不费脑力的事情），那么一定会有人站出来领取技术攻关的Task（而且我相信乐于做技术攻关的Task的程序员会占大多数，否则是团队出问题了，任何管理办法都不会起作用），并且Backlog里每一项Task都是必须完成的，也必须要有人去完成，所以只要Estimate估值相等，有技术含量的Task和重复劳动的Task都具有相同的重要性。

但要注意，Scrum Master必须关注技术攻关的人，不要让他偏离攻关的意义：许多程序员最后都钻到技术的牛角尖上了（技术至上主义者的通病），研究的东西早就超过了Project应用的范畴，结果不是研究的东西对Project不适用，就是大大超过了Task的估算时间。Master要时刻提醒团队：不能提高生产率、Project用不到的技术没有研究的必要，我们的技术是为应用服务的，不要为了技术而技术。

PS：关于研究高新技术方面，建议在每个Project完成之后的一周内，对Project进行回顾总结之后，让团队开一个纯技术评估会，找出本次Project中值得深入研究的东西，然后在新Project未启动前，让大家在工作时间（注意！一定是工作时间）去自由学习。这样做的目的，一方面是舒缓Scrum的冲刺压力，另一方面是为了让队员有一个“增值”的机会（程序员还是得依靠技术吃饭），对技术保持敏感性，而公司能够得到技术积累，又不会因为技术的更新换代而人才不继。

Scrum不建议加班（我也不喜欢），长期的加班不是大家的身体夸了，就是大家对编码麻木了，张弛有道才能保持长久的动力。

注意，制定Backlog的Estimate是Sprint的关键。Estimate的估算除了认真细致以外，更重要的是团队全体成员一致通过才行，讨论过程中切忌以权压人或者通过行政手段粗暴干预。

初期Sprint的Estimate估算不准确不要紧，Estimate越往后会越估算准备。