产品经理对敏捷模式一直都心驰神往，这次回上海，跟老东家的老同事凯哥一起吃饭时，不断地聊到敏捷。老东家在这方面做得相当不错，经历过敏捷的历程，是种快感十足的体验。虽然刚开始，对新模式会有一段时间的排斥，但是随着后来高产的成果频频捷出，对敏捷思想也有了新的认知。

本文将结合我自己的敏捷经历，谈谈我对敏捷模式的理解，本文清单：

 1、说说敏捷开发。

 2、敏捷是一种形式。

 3、敏捷是一种思想。

 4、敏捷不是一个人在战斗。

5、敏捷的迁移。

 1、说说敏捷开发

1.1 敏捷背景？ “敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流，往小了说是改进了开发方法，往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。随着敏捷开发越来越流行，人人都在谈敏捷，人人也都在学习scrum等敏捷开发方法。

1.2 敏捷是什么？以及相对于传统的开发有什么区别？ 传统开发如瀑布模型，强调预见性，严格遵循计划、分析、设计、编码、测试和维护等几个阶段。瀑布模型开发各阶段间具有严格的顺序性和依赖性，必须等到前一阶段的工作结束后才能开始下一阶段的工作，前一阶段的输出文档是后一阶段的输入文档，只有前一阶段的输出文档完全正确，后一阶段才能获得正确的结果。 敏捷开发与传统开发相比具有很大的不同，其特点是适应性而不是预测性，强调沟通和反馈，开发团队不仅包括开发人员，还包括管理人员和客户。它鼓励团队成员的相互交流通过反馈机制尽早纠正开发中的错误，提高开发效率，同时为需求的调整提供更多机会，保证产品向正确的方向发展。

2、敏捷是一种形式 敏捷是一种形式，而形式往往是倒逼内容的，正如“怎样分饼决定了饼最后能做多大”一样，工作也是如此。在敏捷开发中，通过每日晨会和敏捷看板，每个人都能很清楚的看到自己的进度和别人的进度，相互督促和相互帮助自然产生。 具体形式表现在：

 （1）每日站会：done ? to do ? block ? 简洁有效的小团队沟通方式。

（2）敏捷看板：直观反映工作进度，反映流程遵守情况，反映流程缺陷。

 （3）迭代式开发（用户故事）：整个开发过程被分为几个迭代周期（若干个用户故事），每个迭代期是一个定长或不定长的时间块，每个用户故事完成发版一次。

 （4）增量交付。产品在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束时一次性交付。每次交付的都是可被部署到用户应用环境中的、能给用户带来即时效益和价值的产品。

（5）敏捷角色：PO(product own)产品拥有者、SM（scrum master）流程控制者、SC（scrum coach）敏捷教练和其他team member。

3、敏捷是一种思想 我不止一次地在我的文章中提到“快速响应变化往往比心思缜密的计划来得更为高效。”敏捷的精髓恰恰就是迅速响应需求，快速反馈结果。 显然，敏捷开发的一个基本要求首先就是团队的行动要迅速，反应要快、要灵敏。除了反应快，响应快，开发中的各种快还包括：交付快，发布快，开发快，纠错快，收效快等等，这些快都与时间有关，代表了开发的速度与高效。

4、敏捷不是一个人在战斗 奖赏也是一个团队的奖赏，背锅也是一个团队一起背锅，在敏捷中，以团队为单位，强调团队建设，赋予高度的责任，支持开放、透明的交流环境。另外，在开发中还需要不断地响应用户的反馈，强调与用户保持密切的联系和交流。

 5、敏捷的迁移 不仅开发如此，生活中的很多事情如果借用敏捷的思想，也许会有很多不一样的创意和收获。正如有些功能好不好用，有些需求是不是切中了用户痛点，有时候先上去试试，再看看数据显示，往往会有不一样的反响。 曾经听过一个清华大学的教授在《东西方现代艺术》的课程中反复提到的一个思辨：到底是想好了再画，还是画好了再想？同样地，生活中的很多事情是想好了再做，还是做好了再想？这始终是一个极其耐人寻味的话题。 正好，我目前工位的对面刚好坐着一位设计师大牛Duan兄，几天前我们聊到这个话题，他告诉我，他是画好了再想，而不是想好了再画。这的确是一种蛮好的方法论，在很大一部分事情上，我对这种想法深有共鸣。 穷究和叩问也许并没有答案，如同武侠小说里的内功心法，运用之妙存乎一心。敏捷的思维如果能好好运用，没准儿会拥有一个敏捷的人生。 你是如何看待敏捷的呢？ 欢迎留言与我一同交流。