团结一致

抱成一团还是一盘散沙，这是个很简单的选择。但工作中，一个传统职能组织中的每个人都能够团结一致，相互帮助、相互补位又是一种很难达到的状态。

对于传统职能桶式的组织而言，虽然成员的岗位归属在一个组织中，但各自有各自的职能目标。比如产品要出需求，技术要写码，测试要进行测试。各职能之间与其说相互配合，不如说相互打架，各自都觉得自己没责任，同时都觉得上游不负责，下游事儿太多，苦活累活都自己干了还不讨着好。

敏捷团队首先定义了明确的团队目标，并通过口头沟通和可视化看板明确这些目标，同时这个目标是衡量团队成员工作成果的唯一体现。因此，当流程中某一节点出现问题时，由于大家共同关注的是产品的上线和价值，组织成员为了确保最终目标的达成，能够相互补位，对自己手头的事情也会根据当前的情况作出适当的调整以适应变化。比如，当需求太多而技术开发不完时，产品不是幸灾乐祸地觉得自己出活快，骂技术水平低，而是能够停下来一起分析细化需求，帮助开发更好理解，同时调整backlog迭代范围，以保障小版本上线；而当测试积压时，开发可以主动介入测试，与测试人员一起快速消灭待测代码。

敏捷团队能够团结一致,荣辱与共,这是一种文化,也只有具备这种文化的团队,才能在瞬息万变的市场中找到方向。

队伍纪律严明

不深入理解敏捷宣言,很容易误入歧途地认为敏捷就是没有规矩.恰恰相反,一直真正优秀的敏捷队伍,一定是纪律严明的.这种严明,不是军事化管理,而是为了更好地适应敏捷定义的各种约束。

敏捷团队人人平等,但为了组织更好的协作,清晰地定义了Scrum Master、Product Owner等角色和职责，确保每个人都能够在自己最擅长的领域发挥最大的价值；同时敏捷团队要求组织成员进行每日站会，养成良好的Face to Face沟通习惯；另外，对卡片故事、看板、燃尽图等工具的使用也有清晰的要求。敏捷试图通过最简单、直接的方式进行沟通协作，并使信息透明，以提高效率；而传统的职能团队或虚拟项目组也有很多制度，目的是告诉下游“我是按规矩做的，这个问题责任不在我”。

快速反应

天下武功，唯快不破。快于好总是一对冤家，因为我们总认为产品交付“必须能拿得出手”才能体现我的价值，这个观点毒害了一批又一批职场新人。因为价值是最后的结果，过程基本都是炮灰，为了炮灰精雕细琢是最可耻的浪费。

很多没有经历过敏捷的同学有满腔热血，也亟需证明自己，从被别人认可中找到快感，于是很简单的事情，不憋出个龟波气功的大招是绝不会发射的。一个功能讨论，从国外是怎么发展的，竟品是怎么做的，到我们这么做的优势和特点被多少论文论证过，然后是精美的、华丽的Axure原型，交互效果另前端的同学都叹为观止，最后的PDF写了100多页文档。这种认真令人感动，这种方式令人痛恨。

真正的敏捷，不是为了形式敏捷，而是为了最后的价值实现。价值不是凭空想的，也不是拍着脑袋做的，而是用户愿意用，愿意为其买单才能体现的。如果沉浸在自己的完美主义中，不断优化完善，跟自娱自乐烧钱玩没什么两样。失败不可耻，浪费自己和团队的时间、浪费投资人的金钱、因为懦弱没有勇气面对用户才是最可耻的。为了用户的认可，别顾忌那可笑的面子，睁开眼睛享受用户的谩骂吧，2周/版本的迭代速度，就足以把一切谩骂都甩在屁股后面。

乐在其中

别愁眉苦脸，别郁郁寡欢，别目光呆滞，嘿，这里可是敏捷团队，我们都是产品的主人，我们都是创业者！

一个真正睿智的管理者，是不会天真的认为只靠KPI就能带来好的结果的，如果你不能让员工从工作中找到快乐和成就，就等着自己成为他们职业生涯的垫脚石吧。

所有人都喜欢激励，敏捷对团队成员而言，激励可不仅仅是产品最终被用户认可，更多的是体现在了每一个小的迭代周期中，自己消灭了一些卡片，获得了直接的反馈同时分享出去，并且在过程中能够与团队成员并肩作战，享受大家的鼓励和用户的抱怨。也只有快乐并充实的工作，才能让敏捷焕发出如此强大的生命力！

建议继续学习：

1. 腾讯敏捷开发及快速迭代    (阅读：6361)
2. 测试驱动开发(TDD)跟敏捷开发有冲突    (阅读：3679)
3. 多些时间能少写些代码    (阅读：3241)
4. 如何对待开发团队中那个拖后腿的人？    (阅读：2989)
5. 在敏捷    (阅读：2680)
6. 敏捷开发者必读书籍    (阅读：2611)
7. 以产品线划分组织架构    (阅读：2240)
8. 利用设计工具成为个人设计团队    (阅读：2214)
9. 在淘宝大半年的零散体会    (阅读：2038)
10. 从敏捷宣言理解敏捷交互设计    (阅读：2006)