我心目中理想的团队

技术部分

持续集成

频繁交付

自动化测试

TDD

重构

懂得技术的最佳实践

自动化部署脚本

测试覆盖率90%以上

结对编程

拒绝代码坏味道

管理部分

技术债管理

Janki卡

每天Code Diff

每两周Code Review

每月团队出去high一次

坚持敏捷流程

努力经营客户关系

每个迭代进行回顾

坚决执行每个团队决定

全功能团队

营造团队向心力和责任感

关心每个人的成长，技术、经验甚至是心理

学习部分

对新技术敏感

团队每周有Session或者Workshop

勇于挑战自己，让自己肩负更大的责任

分享自己所学知识和心得

给团队成员反馈，学会鼓励、提建议

积极参加培训

勇于表达想法

思考

写完之后，我无法判断是否自己太过于理想化。通俗一点的说，是否真的存在这样的团队呢？如果存在，那怎么样建设这样的一个理想团队呢？

我们来做一个大胆的假设，我们可以认为团队建设就是一个项目，把列表里面的每一项都当成一个功能，通过管理者的引导将团队建设成具有一个有一个的‘功能’。排除掉团队人员更改(比如人员流失)等不稳定因素后，团队建设就变成了一个我们熟悉的产品开发项目。说起做项目来，我们就可以利用敏捷方法论来实现。

在敏捷方法论中，有一整套的实践机制来支持项目的健康发展。那么团队建设可以分迭代(Iteration)，可以做迭代计划会议(Iteration Plan Meetting)，可以做发布计划(Release Plan)，可以做估算(Estation)，可以做演示(show case)，可以做回顾(Retrospcetive)。最终在假设的前提下，团队建设——这种见仁见智的模糊问题，通过一个神奇的漏斗变成一个通过具体算法(利用敏捷方法论)来解决的问题。如果假设不成立了，那该怎么办呢？我也不知道，呵呵。