Baseline Pattern, Coaching Pattern Series
人类社会能进步，就是因为它学会了既要叛逆也要服从，发现了在漫长岁月里平衡两种品性的社会机制 --斯莫林, 物理学的困惑
模式名称
- 基线模式
意图
- 通过从整个团队都同意的一组原则和实践开始,避免"强加给团队既有方案"带来的负面问题, 包括片面的理解机械的遵守带来的争执等.
动机
开发过程中经常有一些关于实践纪律的争论, 比如修复失败的构建是否是优先级最高的事情, 比如是否严格遵守WIP Limits等. 一边是诸如XP, Kanban各类实践的纪律性, 一边是基于”团队应该选择自己的流程”,“项目结束时的流程不应该和项目开始时一样”之类理念对实践的各种修正.
另外一些容易引起争论的是团队日常的开发习惯, 比如使用专门的工作站结对时是否可以把自己的个人电脑放在旁边, 换Pair的频率等等.
这些争论对团队的士气和效率都有影响. 团队成员无法在一个感到舒适的环境和规则下工作. 每个人都觉得其他人的某些做法降低了团队效率. 争论还是相对好的结果, 至少问题暴露, 得到修复的机会. 更多的是隐忍, 对个人和整体都是一种长期的伤害.
这里的问题在于, 团队里的每个人对每个实践都有自己不同的理解. 每种实践都自己的前提约束, 适用范围和后续影响. 不同的团队既有相通的问题, 又有自己独特的问题. 而很多最佳实践, 往往被缺省配置, 没有经过团队的讨论, 实际上是团队基于传统, 基于圈子文化, 被动的无意识的接受了这些规则. 于是它顺理成章的也会被无意识的违反.
方案
争论不可避免, 我们要做的是把它提前, 理性化和公开化. 团队应该基于自己的实际问题, 挑选合适的规则和实践. 只要团队同时拥有反馈机制, 随着时间的进展问题的变化, 实践自然也会跟着调整.
而最初的挑选, 应该在项目初期, 所有成员都参与的情况下来进行. 而最终需要达成某种共识, 作为基线, 包含团队同意的各种规则. 争论应该在此过程中发生. 一旦决定做出, 在下次讨论这个主题进行调整之前, 团队成员都应该遵守这条基线. 最终的决策过程未必是少数服从多数, 可以是任何团队同意的决策过程, 只要确保团队成员能充分的表达自己的意见, 每个人都了解彼此的想法.
已知应用
- Guangtao同学在Tiger Team成立初期跟团队一起制定了日常工作规范的Agreement.
相关模式
- 问题驱动模式. 该模式强调的是最初的规则和实践应该从何而来
Pattern Series: