# 态度和能力
很多组织在定义职位描述时,都过于强调表面上的角色和责任.然而,如果Scrum想要成功,看必须采取另一种不同的方式来探寻Scrum团队必须必备的基本态度和能力.
# ScrumMaster
ScrumMaster 是一个公仆式的领导,它开始于一个人想要得到服务,得先为他人提供服务.优秀的ScrumMaster是连接不同职能部门的桥梁.
ScrumMaster需要:
- 丢掉自我意识
- 真正从骨子里关心产品和团队
- 公平,始终如一的对待所有团队成员
- 工作时可以表现出自信和谦虚
- 随时随地可以联系到,沟通无障碍
- 引入变革,无畏惧心里
- 有策略,但不玩办公室政治
- 无私心,单不低估团队角色的重要性
- 保护,但不过分溺爱团队成员
- 有技术知识,但不需要成为专家
- 不固步自封
优秀ScrumMaster的至少5个性格特征：
- 负责：优秀的ScrumMaster能够并愿意承担责任。这不是说ScrumMaster要对项目的成功负责——这是整个团队的责任。但是，ScrumMaster要对最大化团队的产出和支持团队成员实施以及使用Scrum负责。
- 谦逊：谦逊的ScrumMaster不会把自己的需求排在第一位，而是愿意去做任何能帮助团队实现目标的事情。谦逊的ScrumMaster理解全体团队成员的价值，并以示例促成其他人得出相同观点。
- 协作：优秀的ScrumMaster的工作是保证团队中存在一种相互协作的文化。ScrumMaster需要确保团队成员能够把问题拿出来公开讨论，并在这样做时得到他人的支持。正确的ScrumMaster通过语言和行动帮助团队形成协作的氛围。当争执发生时，合作性强的ScrumMaster会鼓励团队用大家共赢方式的思考，而不是以赢家和输家的方式思考。优秀的ScrumMaster通过与组织的其他ScrumMaster一起工作，为这类行为树立典型。除了打造合作的态度，优秀的ScrumMaster还会为团队合作建立规范，并指出不合适的行为。
- 投入：尽管做ScrumMaster并不总是一份全职的工作，但是确实要求全力以赴的投入。ScrumMaster必须与团队成员一样，对项目及其目标具有高度的奉献精神。一名好的ScrumMaster不会遗留问题还没有解决。
- 有影响力：ScrumMaster应该懂得如何向别人施加影响，同时又避免独裁式的“因为我这样说了”的风格。尽管所有的ScrumMaster要懂得如何运用自己的个人影响，但理想的方式还是具备一定程度的技巧。虽然ScrumMaster不必成为市场大师或者编程专家，但他们确实对这两者要有足够多的了解，这样才能有效地领导团队。
# 态度与能力
我曾经有过几年一线开发的经验,当时负责部门移动端核心架构设计和组件的开发,结合近几年的经历,我想说工作的态度有时远远高于实际能力,不要误会我的意思,能力当然重要,但如果要在一个态度超认真的熟练工程师和一个坏脾气的天才工程师之间二选一,我会毫不犹豫的选择前者.
在IT圈子里兴起了一种视图招聘"摇滚明星"式的开发人员的潮流.他其实是向市场上发出了一个混乱的信号,摇滚明星通常是有魅力的,有创意还有个人主义,这些看起来都是不错的品质.但我们看看硬币的另一面,看看他有哪些不那么值得赞赏的品质:喜怒无常,爱出风头,傲慢,还有目中无人.这样的人虽然可以给我们带来惊喜,但是这样的人能在需要紧密合作的Scrum团队中如鱼得水吗?我不这样认为.
# Scrum价值观
怎么样才能确保团队不会因为各自强烈的自我意识和持续不断的争吵而分崩离析呢?最好的方法是所有团队成员首先都要拥护Scrum的核心价值观,形成其职业特质.
Scrum的价值观包括: 开放,勇气,尊重,专注,承诺.
# 活力
我们需要保持整个团队的活力,暮气沉沉的团队成员会影响到整个团队的士气,我们需要帮助团队成员解决他的烦心事,让团队保持一个向上的活力.
# 共情
在一个凝聚力强的团队里工作需要耐心和理解.每个团队成员互相依靠,合力达到一个共同的目标,团队成员需要互相理解其他人的困境,当这些事情不可避免的出现时,团队伙伴需要站出来,临时揽过重担保持团队的凝聚力.
# 好奇
开发团队是跨职能的,理想的团队是T型技能成员组成的,如果需要,他们可能要做一些非专业的事情以消除团队的瓶颈.团队成员需要对事物保持好奇心,愿意并渴望扩展自己的技能,抓住每一个机会学习来自我学习.
# 友善
在选中团队成员时,不仅他看是否有礼貌,还要看他是不是真诚友善.和友善的人在一起合作会有趣的多,我们需要稍微多的了解一些团队成员的生活及他们的爱好,友善的对待他们将会让工作有一个非常好的开始.
# 尊重
尊重是Scrum的核心价值观之一,我们在团队沟通中经常会陷入一个证明对方"错了"的误区,这导致集体讨论活动的最后气氛都会变得紧张.参会者警惕的等着其他人疏忽犯错,同时吹毛求疵的提出错误.
敌意是会扼杀创意.团队成员应该知道即便自己不赞同某个想法或观点,但一样会尊重他们.对别人的观点要保持尊重,而不是说:"你错了...".没有足够的尊重将会使好的想法枯萎,我们需要鼓励并尊重其他人的观点或建议,并从中吸取养分.
# 选择团队
在为Scrum团队选择成员时,一定要考虑很多因素,包括态度,性格和搭配,技能的搭配,团队的大小,职能专业的配比,共享的资源,工作后勤情况等等.团队需要保持一个意识,就是告别"我们"和"他们".
# 人人都是开发人员
一个成功的自组织的Scrum团队容不下小集团导致的不同职能之间的隔阂,例如研发和测试,测试和UI设计师.
Scrum避免这类问题的方法很简单:它对所有的开发团队成员统称"开发人员".它通过提供给每一个人同样的机会来增强公平性,而且反映出要开发软件,所有角色都能参与进去.如果一定要区分每个工种及所擅长的不同,我们也可以用特别的头衔,比如"测试专家","设计专家"等等.
# 开发团队的配备
通常一个理想的Scrum团队建议控制在5~9人,我比较倾向于相对少一些,例如5~7人的团队.
没有一个规则可以定义开发团队的人员组成,因为每个项目和团队都各不相同.在团队组成毫无头绪时可以试着使用这样的配比: 3个程序员,1个测试人员,0.5个"精深专家"."精深专家"是指专注于某一领域的开发人员,例如DBA,UI设计师或某专业领域的专家,0.5意味着可以适当的将其分配在其他的项目中进行工作.
Scrum的原则是尽快开展已开始的任务,为了加快价值流动速度,齐心协力显得尤为重要.齐心协力不是 意味着多个开发人员各自处理产品列表中的不同任务,而是尽量减少同时处理的任务个数,鼓励多个开发人员在某一时刻专注于完成尽量少的任务,要鼓励开发人员培养T型技能,有T型技能的开发人员在某一专业领域拥有很深的造诣,而在其他较广的领域(比如测试,用户体验设计)具备不一定很深的技能.
# 碎片任务分配
理想的Scrum团队成员最好都专心致力于所在的团队,话虽如此,我发现让一个专家把所有时间用在一个团队既无必要(需求角度)也不现实(成本角度),这意味着我们得具备大多数需要的技能,因为在很多情况下我们承担不起配备全职专家的豪华阵容.
一个专家可以分配到两个项目中,每个项目只把其擅长的工作以碎片任务的形式分配给他,同时可以让这个精深专家当做顾问或者培训师,辅导其他团队成员,他除了协助特定的任务外,还要教导其他开发人员.但不建议把专家分到三个甚至更多的项目中,因为这种任务切换可能非常影响效率.
# 拥抱多样性
由于不同文化背景,年龄,经验和专长的队员组成的团队通常都比较多样,所以多样化的团队里,团队成员需要当心不合适的做事方式可能会无意冒犯团队成员.
在团体中,我们可能不得不小心的拆分同一地域或者同一属性的小团体,因为这样的小团体在公共工作区使用不同的语言交流或者不同的工作方式工作,Scrum中非常反对团队中的小团体,在团队中我们要拥抱多样性,换一个角度看待问题,可能会有一个新的想法.