《scrum敏捷软件开发》

第九章：技术实践

scrum 团队需要进行的变革不只是在新的职务、角色和职责这些方面。对于一个渴望真正成功的团队来说，他们必须超越Scrum基本的、显而易见部分的实施，需要在创造产品的实际工作方法方面做出真正变革的承诺。

追求技术进步

→ 【测试驱动开发】：主要将研发者做单元测试的工作，融合到研发过程中；

image.png

→【 集体所有权】：是指所有的开发人员共同负责开发过程中的所有产出内容，特别是代码和自动化测试。
【例如】：”这是xxx的代码，我们不能碰它“，程序员要修改某个功能时，他要与最初写这个模块的人共同负责这模块的质量。
【职责】：
①确保开发人员不会变得太专以至于只能在某一个方面做出贡献。
②确保没有一个地方变得太错综复杂以至于只有一个开发人员可以明白和完成其工作。
【好处】：这样的氛围会鼓励开发人员学习系统中的新东西，也同时学了新的做事方式。
【反对情况的例子】：
“这不是我的代码，我不想解决其他任何人的缺陷。”
我不怪你，但请记住，他们也在修复你的缺陷。事实上，根据我的经验，一个采用集体所有权的团队，会写出更干净的代码，而且可能因此减少缺陷。

→ [结对编程]：是指两个程序员一起写代码。
好处：虽然看起来使用结对编程的人数会增加，但是总的工作周期的减少是可以抵消损失的，而且能够提高质量，同时也有助于知识传递，帮助程序员成长。我们最担心的不是人数，而是发布时间。

技术实践的改进并不是可有可无的，而是，一个优秀的敏捷团队成员应该熟练掌握的。

总结：

本次阅读，强化了自身从事互联网行业这么久的感触，技实践大家都了解，但是真正做到的，少只又少，我认为还是两个方面：找到优秀的人，营造一个好的氛围；

【招聘】（找到优秀的人）：自己也面过很多人，拥有学习主动性的人，可以算是稀有物种了，组建一个优秀团队真的很难（难之一：公司要控制成本；难之二：而且就算答应加人，找到优秀的成员何其容易），会有大把的时间，放在招聘上，招优秀的人太难了，曾几何时，老想着差不多就行，没有十全十美的人，但现在想想，想要实现自己的目标或者愿景（在一个足够优秀的团队里面工作是一种享受），必须要做好第一关，否则就是给自己埋雷，给团队埋雷，一旦自己不经意触动那根保险，得到结果，全是自己种下的因。

【氛围】这个维度，我们的团队在一些细分维度有做努力改变，目前还没达到理想效果，想想还是团队管理方面、部门人员结构、项目推进方式，不够成熟，出现的问题，没有权利或实力及时解决，不得已搁置；（但还是相信🌈，问题该总结总结，该反馈反馈，从我做起，做个scrummaster）