技术部分
持续集成
频繁交付
自动化测试
TDD
重构
懂得技术的最佳实践
自动化部署脚本
测试覆盖率90%以上
结对编程
拒绝代码坏味道
管理部分
技术债管理
Janki卡
每天Code Diff
每两周Code Review
每月团队出去high一次
坚持敏捷流程
努力经营客户关系
每个迭代进行回顾
坚决执行每个团队决定
全功能团队
营造团队向心力和责任感
关心每个人的成长，技术、经验甚至是心理
学习部分
对新技术敏感
团队每周有Session或者Workshop
勇于挑战自己，让自己肩负更大的责任
分享自己所学知识和心得
给团队成员反馈，学会鼓励、提建议
积极参加培训
勇于表达想法
思考
写完之后，我无法判断是否自己太过于理想化。通俗一点的说，是否真的存在这样的团队呢？如果存在，那怎么样建设这样的一个理想团队呢？
我们来做一个大胆的假设，我们可以认为团队建设就是一个项目，把列表里面的每一项都当成一个功能，通过管理者的引导将团队建设成具有一个有一个的‘功能’。排除掉团队人员更改(比如人员流失)等不稳定因素后，团队建设就变成了一个我们熟悉的产品开发项目。说起做项目来，我们就可以利用敏捷方法论来实现。
在敏捷方法论中，有一整套的实践机制来支持项目的健康发展。那么团队建设可以分迭代(Iteration)，可以做迭代计划会议(Iteration Plan Meetting)，可以做发布计划(Release Plan)，可以做估算(Estation)，可以做演示(show case)，可以做回顾(Retrospcetive)。最终在假设的前提下，团队建设——这种见仁见智的模糊问题，通过一个神奇的漏斗变成一个通过具体算法(利用敏捷方法论)来解决的问题。如果假设不成立了，那该怎么办呢？我也不知道，呵呵。