修改导语：作为一名 UI/UX 规划师，在作业中接触到 灵敏 一词时，也会感觉到方式和难以了解。从需求到规划每一步都需求了解清楚，那么灵敏开发这种方式该怎么做呢，咱们一同来看看吧。

　　在互联网职业中，一个项意图完好生命周期都是由一个团队完结的，团队成员或许会改变，但任何一个人物都不可或缺。

　　为了更好地完结一起方针，团队成员除了在自己担任的范畴是专家，还需求了解其别人的作业内容及整个团队的作业方式。作业方式是衔接团队成员的一种运作办法，要求每个人都明晰了解，并认同。

　　起源于 20 世纪 90 时代，由开发程序员提出，是相对于传统软件开发办法（如瀑布流模型）而言的一种新软件开发方式。这儿以为该方式不仅仅适用于开发，也适用于团队除开发外的其别人物，因而将它视作为团队作业方式。下图为灵敏开发的价值观。

　　作业的软件高于翔实的文档：看文档是一件让人头疼的事，无论是需求或技能文档，编撰和保护都需求消耗很多的人力，文档的不灵活性让其位置在灵敏开发中位置下降，因而这儿的文档要尽或许精简，能用软件代替文档的使命首选软件。

　　客户协作高于合同商洽：客户对产品的需求会跟着他自己的认知和心境改变，能从一开端就确认细节的项目真实太少，常常与客户交流，给予反应才干促进项意图成功。

　　呼应改变高于遵从方案：和瀑布流中将产品的功用彻底规划好后会集开发不同，不断改变的需求让灵敏从业者拟定方案时尽或许的简化，这儿能够结合 MVP（Minimum Viable Product 最小可行性产品）的概念去了解。

　　每次迭代交给一个可用的最小功用，这个功用时是不完美的、粗陋的，只能满意用户最基本的需求，然后经过后期客户的正反应渐渐完善功用。这种办法试错本钱低，能快速应对需求改变。

　　一个开发阶段称为一个 Sprint（冲刺），每个 Sprint 开端前，都会举办一个 Planning Meeting（方案会）来一起规划这个迭代的开发使命，会议主持人一般为 PM（产品司理）或 PO（Product Owner，产品担任人）。

　　最终，团队成员之间聊个五毛论题增进感情，Planning Meeting 就算完毕了。在接下来的两周内，每天上午团队成员要开一个简略的 Standing Meeting（站会），每人阐明昨日做了什么，完结度怎么，如有推迟是因为什么原因，是否需求其他成员协助，以及今日方案要完结的使命。

　　一周下来，要开一个半程回忆会，了解开发进展，若有推迟，及时做出对应调整。两周下来是一个全程 Review Meeting（回忆会），回忆这个迭代的完结度，并展现完结的功用，现场 Demo。

　　需求由 PO 树立，是将用户故事（User Story）简化后的产品，描绘在什么场景下需求完结什么样的功用，对开发而言便是一个开发使命（Task）。

　　功用比较复杂的需求往往会被拆解成多个需求，拆分到以用户视点可接受的最小颗粒度功用作为子需求，以父子需求的办法进行相关。开发的视点上看能够由一个开发（Story Owner）接下这个使命，再分配给其他开发人员。

　　需求池里记录着待开发的需求及优先级，优先级依照对用户的价值进行排序，高的会先开发。PO 在表述需求时往往不会有惟利是图的需求文档，一般会用简略的文字描绘在需求概况里，再加上面对面交流将需求传递给规划或是开发。

　　以卡片的方式展现当时迭代的进展，包含使命内容，优先级，处理人，状况等信息。PO 可从这儿清楚地看到团队的进展，开发也能够经过挑选来了解自己各种状况的开发使命。

　　工时是影响一个迭代完结度的重要因素，涉及到使命处理人对工时的预估，假如实践工时高于预估，势必会形成使命延期或开发加班，影响整个迭代的完结度，假如实践工时低于预估，便会形成人力资源的糟蹋，影响功率。

　　精确的预估工时需求开发人员有丰厚的经历，掌握业务逻辑，了解自己的开发才干，此外工时还包含安全时刻，以处理特殊情况。

　　一般每个开发一周有略低于 40（5 × 8）个工时的使命量。处理 Bug 所用时刻不算在工时内，Bug 秉承优先处理，谁开发谁处理的准则。

　　面对面交流让信息传递的质量随传递人数的添加而下降，从产品到规划到开发再到测验的信息传递会呈现误差，这让灵敏在大项目大团队中的施行变得困难

　　较少的文档在团队人员过多，人员变化或项目持续时刻较长时无法全面了解到产品的全貌，交流本钱添加

　　实施灵敏的意图是为了协助团队高效地协作交流，过程中的去文档，去流程，面对面交流都只是手法，最终还是以成果为导向。牢记灵敏流于方式，纠结于过程！

　　灵敏要求团队成员有很强的主观能动性，并能自动推动整个项目行进，当别人停滞不前时，PUSH 他们。

　　灵敏团队的树立需求时刻和经历堆集，当使命呈现问题时自动承当职责优于互相推诿，成员间切忌心存芥蒂，这样才干坚持团队的凝聚力。