编辑导语：作为一名UI/UX设计师，在工作中接触到“敏捷”一词时，也会感觉到模式和难以理解。从需求到设计每一步都需要了解清楚，那么敏捷开发这种模式该如何做呢，我们一起来看看吧。
刚接触敏捷时我对这种模式是不能理解的，没有调研没有文档，从需求到设计用的方法和学校里所学的完全不一样，但经过两年的工作后，我的认知开始发生变化，下面我将作为一个UI/UX分享一些我对敏捷式开发的理解。
在互联网行业中，一个项目的完整生命周期都是由一个团队完成的，团队成员也许会变化，但任何一个角色都不可或缺。
为了更好地完成共同目标，团队成员除了在自己负责的领域是专家，还需要了解其他人的工作内容及整个团队的工作模式。工作模式是连接团队成员的一种运作方式，要求每个人都清晰了解，并认同。
一、敏捷式开发宣言（Agile Program Development）
起源于20世纪90年代，由开发程序员提出，是相对于传统软件开发方法（如瀑布流模型）而言的一种新软件开发模式。这里认为该模式不仅仅适用于开发，也适用于团队除开发外的其他角色，因此将它视作为团队工作模式。下图为敏捷开发的价值观。
个体和互动高于流程和工具：人是最重要的因素，敏捷提倡打破部门的概念，人与人之间面对面沟通，交流。敏捷的办公室常常是很热闹的。
工作的软件高于详尽的文档：看文档是一件让人头疼的事，无论是需求或技术文档，撰写和维护都需要耗费大量的人力，文档的不灵活性让其地位在敏捷开发中地位降低，因此这里的文档要尽可能精简，能用软件替代文档的任务首选软件。
客户合作高于合同谈判：客户对产品的需求会随着他自己的认知和心情变化，能从一开始就确定细节的项目实在太少，经常与客户沟通，给予反馈才能促成项目的成功。
响应变化高于遵循计划：和瀑布流中将产品的功能完全规划好后集中开发不同，不断变化的需求让敏捷从业者制定计划时尽可能的简化，这里可以结合MVP（Minimum Viable Product 最小可行性产品）的概念去理解。
每次迭代交付一个可用的最小功能，这个功能时是不完美的、简陋的，只能满足用户最基本的需求，然后通过后期客户的正反馈慢慢完善功能。这种方式试错成本低，能快速应对需求变化。
二、工作流程
这里简单描述自己工作中两周为一个迭代的工作流程。
一个开发阶段称为一个Sprint（冲刺），每个Sprint开始前，都会举行一个Planning Meeting（计划会）来共同规划这个迭代的开发任务，会议主持人一般为PM（产品经理）或PO（Product Owner，产品负责人）。
会上，PO会向团队成员展示列入这个迭代开发的需求。
每一个需求都是一个或多个任务（Task），PO根据优先级安排要开发的任务，描述每个任务要达到的目标，和设计、开发、测试确认，在Scrum Master（敏捷教练，一般为技术大牛）的协作下找到任务处理人并以工时为单位预估任务完成需要的时间。
最后，团队成员之间聊个五毛话题增进感情，Planning Meeting就算结束了。在接下来的两周内，每天上午团队成员要开一个简短的Standing Meeting（站会），每人说明昨天做了什么，完成度如何，如有拖延是因为什么原因，是否需要其他成员帮助，以及今天计划要完成的任务。
一周下来，要开一个半程回顾会，了解开发进度，若有延迟，及时做出对应调整。两周下来是一个全程Review Meeting（回顾会），回顾这个迭代的完成度，并展示实现的功能，现场Demo。
三、部分概念理解
注：这部分示例图来自腾讯敏捷类办公产品Tapd。
1. 需求及任务（Story and Task )
需求由PO建立，是将用户故事（User Story）简化后的产物，描述在什么场景下需要完成什么样的功能，对开发而言就是一个开发任务（Task）。
功能比较复杂的需求往往会被拆解成多个需求，拆分到以用户角度可接受的最小颗粒度功能作为子需求，以父子需求的方式进行关联。开发的角度上看可以由一个开发（Story Owner）接下这个任务，再分配给其他开发人员。
2. 需求池（Backlog）
需求池里记录着待开发的需求及优先级，优先级按照对用户的价值进行排序，高的会先开发。PO在表述需求时往往不会有详细的需求文档，一般会用简短的文字描述在需求详情里，再加上面对面沟通将需求传递给设计或是开发。
3. 故事板（Story Board）
以卡片的形式展示当前迭代的进度，包括任务内容，优先级，处理人，状态等信息。PO可从这里清楚地看到团队的进度，开发也可以通过筛选来了解自己各种状态的开发任务。
4. 工时
工时是影响一个迭代完成度的重要因素，涉及到任务处理人对工时的预估，如果实际工时高于预估，势必会造成任务延期或开发加班，影响整个迭代的完成度，如果实际工时低于预估，便会造成人力资源的浪费，影响效率。
准确的预估工时需要开发人员有丰富的经验，掌握业务逻辑，了解自己的开发能力，此外工时还包括安全时间，以处理特殊情况。
一般每个开发一周有略低于40（5×8）个工时的任务量。处理Bug所用时间不算在工时内，Bug秉承优先解决，谁开发谁解决的原则。
四、成也灵活，败也灵活
敏捷的特点，优点，缺点都是灵活。
优点：
- 应对需求的灵活性让功能的开发时间缩短，可尽早得到市场的反馈，提高规避风险的能力
- 人与人之间的直接沟通能充分利用时间，工作效率提高
缺点：
- 面对面沟通让信息传递的质量随传递人数的增加而降低，从产品到设计到开发再到测试的信息传递会出现偏差，这让敏捷在大项目大团队中的实施变得困难
- 较少的文档在团队人员过多，人员变动或项目持续时间较长时无法全面了解到产品的全貌，沟通成本增加
五、总结
- 敏捷是一种理念，原则，价值观，不同的团队在实行这个模式都是不同的。
- 实行敏捷的目的是为了帮助团队高效地合作沟通，过程中的去文档，去流程，面对面沟通都只是手段，最后还是以结果为导向。切记敏捷流于形式，纠结于步骤！
- 敏捷要求团队成员有很强的主观能动性，并能主动推进整个项目前进，当他人停滞不前时，PUSH他们。
- 敏捷团队的建立需要时间和经验积累，当任务出现问题时主动承担责任优于互相推诿，成员间切忌心存芥蒂，这样才能保持团队的凝聚力。
本文由 @B端交互设计师 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于CC0协议
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。