add framework

blog/en-us/framework/agility.md

@@ -0,0 +1,77 @@
+# 如何理解敏捷开发
+
+## 为什么要敏捷开发
+
+“没有人喜欢敏捷，但我们不得不敏捷。就像没有人喜欢工作，但你必须工作。”这是我经常用来调侃敏捷的一句话。试想一下，拿到一份完整详尽的需求文档，逐个功能Coding，测试部署上线。不需要再次确认需求，不会有人打断思路。没有需求更改，只要自己不犯错，不存在推倒重来这才是大部分开发人员最舒服的工作方式吧，简直太完美了。但它很像瀑布，一点都不敏捷。既然我们喜欢的工作方式是传统的、瀑布的，为什么要敏捷？这还不都是市场环境逼的。今天的市场向我们提出了三个问题：
+
+## 01如何做出真正满足用户需求的产品？
+
+我不确定这世上是否有人可以做到，他所做出的全部决定都是对的。但绝大多数人是无法一次性做出真正满足用户需求的产品的。我们无法预测未来，我们必须通过一次次的测试，去寻找用户需要的产品是什么？想要更快地获得好的产品，必须迅速将产品推向市场，快速试验，避免走弯路。
+
+## 02如何满足不断变化的用户需求？
+
+今天所有的事情的都在快速变化，用户的需求也在变化。毫不夸张地说，我们正在全力开发的一些功能，当它们上线的时候，我们的用户已经不再需要了。我们没有办法让一切不变，我们只能选择去拥抱变化。
+
+## 03如何同时满足不同层次用户的需求？
+
+过去我们的产品会遵循产品生命周期，早期追求新奇的尝鲜者，中期普通大众，后期落后者。今天，产品的生命周期变化非常地快，我们可能会同时面对尝鲜者、普通大众、落后者，不同的用户类型的需求是不一样的，你如何满足他们？我们必须快速响应，没法快速响应，就没法留住用户，没有用户就没有一切。迅速将产品推向市场，拥抱变化、快速响应。今天的市场向所有的从业者提出了一个要求：拥有应对快速变化的需求的软件开发能力。而敏捷就是赋予团队应对快速变化的需求的软件开发能力的方法，而这就是敏捷流行的原因。
+
+## 什么是敏捷开发
+
+敏捷绝非某一种特定的开发方法，它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。敏捷相信，只要符合这两份文档的开发方法，就能让开发团队拥有应对快速变化需求的能力，这样的开发方法都叫做敏捷开发方法。
+
+## 最流行的敏捷开发方式是什么
+
+敏捷开发的方法有很多：ASD、AUP、DSDM、XP、FDD、Kanban、RAD、Scrum。目前国内最流行的应属Scrum。Scrum本意是指橄榄球运动中的“带球过人”，它可以解决非常复杂的项目，并且能高效并创造性地交付高价值的产品。Scrum包含3个角色、3个工件、5个价值观、5个事件 [详情https://www.scrum.org](https://www.scrum.org/)。相比其他敏捷方法，Scrum既不简单又不复杂。它有完善的指南，你可以按照指南，轻易在团队内推广尝试。但想要实践好Scrum，又需要很好的技巧。这种易上手难精通的方法，特别适合培训机构。所以近几年，关于Scrum的培训机构遍地都是。可以说，在Scrum流行这件事上，这些培训机构做了很大的贡献。
+
+## 如何实施Scrum
+
+在团队中实施敏捷开发是一个很有挑战性的工作，尤其是Scrum这种描述比较详细、有很多规则的方法。
+
+**如果你打算把所有人召集到一起，宣布我们要实施敏捷开发Scrum，然后就照着Scrum的描述开发方法直接实施，那么，你离失败不远了。**想要实施好Scrum，你必须一步步来，一点一点改变团队的习惯，当一项新制度已经变成本能之后，再推行下一项制度。
+
+### >>>>第一步，先把团队的开发任务可视化。
+
+你可以用一块白板，让团队成员把所有的开发任务都用便签写好放上去，也可以找一个专业的看板工具。我推荐日事清，当所有任务都在看板上，尽收眼底，那种感觉还是很棒的。团队中每个人的工作都会被所有人看到，会形成一种无形的监督。
+
+### >>>>第二步，引入站会制度。
+
+当团队所有人的任务都在看板后，这些任务的状态是需要有人更新的。无论是专人更新，还是每个人自己更新，都会出现忘记更新，更新不及时的情况。这时，就可以顺势引入站会制度了。每天上班的时候，或者每天下班的时候，所有人站到一起，花15分钟，说一下自己做了什么，准备做什么，所有人一起把看板更新了。
+
+### >>>>第三步，引入回顾会议
+
+当站会制度成熟后，就可以挑一个版本发布的日子。等版本发布后，把团队成员叫到一起，开一个回顾会。让团队成员对这个版本开发的情况做个总结，同时可以让大家用便签把这个开发版本遇到的问题、不满写下来。针对这些问题不满，大家一起讨论一些改进方案。
+
+### >>>>第四步，引入计划会议
+
+如果再开回顾会的时候，有人提出需求不清，拆解不够细致，工时估算不准之类的问题，那你真是太幸运了。碰到这种情况，你顺势提出这个制度：每个版本开发前，产品经理要和团队人员开个会，一起逐条对需求。产品经理要向团队解释每个需求，并且对团队提出的疑问进行解释和澄清。开发团队要将需求分解成任务，估算工时，最终形成一个开发清单。
+
+### >>>>第五步，引入评审会议
+
+当计划会成功开过几次之后，就可以考虑引入评审会了。你可以在某个重大功能发布的时候，把所有项目相关的人员召集起来，向大家展示团队做了哪些了不起的功能，也可以和大家讨论讨论还可以做哪些优化。
+
+### >>>>第六步，宣布引入Scrum
+
+当整个流程都跑顺以后，就可以在某次全体会议上，提出我们要实施Scrum了。你需要任命PO、SM，对团队培训Scrum知识，讲解Scrum的价值观。
+
+## 实施敏捷开发会面临怎样的挑战
+
+1.团队成员对变化的恐惧
+
+实施Scrum最大的挑战来自内部，来自团队对变化的恐惧。每个团队在运营一段时间后都会形成固有的默契和习惯，引入Scrum必然会打破这种习惯。这会让团队很不舒服，团队也会抵制，甚至是反抗。而且实施敏捷的过程，一定不是一帆风顺的，尤其是实施敏捷的早期阶段，不仅不会对团队产生太大的价值，反而会引起混乱。所以，在实施敏捷的过程中，千万要小心，每次只改变一点点，敏捷地完成敏捷。
+
+2.组织人员的专业化水
+
+平敏捷并不会直接提高团队的专业化水平，反而对团队专业化水平有一定的要求。必要的专业分工、合适的专业能力是必须的。敏捷会让开发整个流程持续运转，当某一个环节专业化能力出现问题的时候，会极大地导致整个流程运转停滞。平时团队中的问题会在敏捷中快速暴露。一旦出现专业水平问题，要及时解决，补充人员，或者帮助其提高能力。即使问题并不严重，也要在最短的时间解决，否则会影响团队对敏捷的信心。
+
+3.产品经理这个组织Bug
+
+国内在实施Scrum的时候经常会碰到的问题就是团队中会有产品经理这个角色。
+
+**一般的处理方法是产品经理当PO**，但PO是需要领导开发团队的。国内的产品经理往往不是技术出身，领导开发团队会出很多问题，所以产品经理并不适合当PO。
+
+**另一种做法是产品经理做利益相关者**，这种做法更不靠谱，利益相关者离团队太远，会出现无法及时响应的问题，时间长了也会导致产品和开发之间关系冷漠，出现隔阂。我们目前的做法是尝试是引入一个非官方版本的Scrum（Scrum 3.0），他将PO拆分成了业务拥有者（BO）和团队队长（TC）。产品经理担任BO，开发经理担任TC，目前看效果还不错
+
+我们目前的做法是尝试是引入一个非官方版本的Scrum（Scrum 3.0），他将PO拆分成了业务拥有者（BO）和团队队长（TC）。产品经理担任BO，开发经理担任TC，目前看效果还不错
+
+另外腾讯企业微信里[**TAPD**](https://www.tapd.cn)也是不错的