导语：
敏捷式开发(Agile Development)对开发人员来说，是个非常熟悉的名词，相比于传统的瀑布式流程，短平快的敏捷团队的协作方法可能更加高效。我们公司从去年的7月份开始，也慢慢地走向了敏捷开发的转型。因此，组织架构也做了相应的调整，从以前的各项技能团队变成了跨职能团队，也就是说一个团队中含有各种的角色：产品，设计师，开发，测试...这意味着每一个团队都是一条产品功能线，需要和各种职能的人进行交流沟通。转变之大，让每一个职能人都要重新审视定位自己的角色，当然也包括设计师这一角色。
现在在「敏捷开发」团队中也快一年了，也是走过了不少的弯路，刚开始总觉得时间太短不够用（太敏捷了！），到后来渐渐地抓到敏捷开发的步调，因此想把作为设计师的我在这个团队中的一些改变给记录下来，或许也能让正在看这篇文章的你收获到一些小的知识，运用到工作当中去。
1.什么是敏捷开发？
敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。（来源：百度百科）
敏捷开发有12条准则，并总结成了一份《敏捷宣言》，它描述了一种流程，一套方法论。在「敏捷开发」的定义范畴中有一些更精确的分支，其中一种就是“Scrum”(译者注：本义为英式橄榄球中的并列争球行为），它以2到4周为一个迭代开发出有价值的商业功能。Scrum团队有两个明显特征：他们是多面手（例如：他们具备完成工作所必须的所有技能）；他们是自管理的（例如：团队不断探索如何把工作做的最好的方法）。不论哪种，「敏捷开发」必然包含了迭代的、不断增进的周期型工作。
2.设计师在团队中是怎样的一个角色？
在传统的团队中，产品经理先把需求理好给到设计部的主管，然后再把任务分配下来，此时，你接到的任务可能就是这个产品或项目里的的里的某一小部分。为了做好这个产品或项目，就得要花大量的时间去了解清楚这个产品或项目的来龙去脉，然后做完这一个小部分。并且还会出现产品任务优先级的问题，每一个职能团队都有很多的任务，那么，刚传下来的任务是否需要马上设计呢？如果需要，那是不是需要打断现在正在做的任务？这样一来，产品的迭代时间就会拖的很长。而对于设计这一块来讲，设计师也只是完成了一个任务，只对设计的界面负责，产品最后到底怎样，可能与我们无关，到最后就变成了大家所认为的"美工"。
在「敏捷开发」的团队中，完成一个产品或产品功能而后顺利的上线，是大家共同的目标，而设计师在这里属于一个承上启下的作用。在整理需求阶段，可以和Product Owner（传统团队中的产品经理，简称 PO）一起讨论并整理需求，这样就会让设计师初步了解这个产品的由来，做起设计来也得心应手一些。需求整理完后，团队会组织开一个需求澄清会议，也就是确定在这一迭代中，开发人员所需要做的需求，如果做不完这些需求，开发人员有权拒绝部分的需求，推到下一个迭代来做，当然，这些都需求整个团队的人员来进行评估，也还有Scrum Master（类似于团队的管理者）来进行把控。当需求确定下来之后，进行迭代计划会议，评估在这一迭代中所有需求的故事点。
在「敏捷开发」中，还存在每日站会，利用10到15分钟左右的时间，大家通过Sprint Backlog（迭代待办事项列表）来给大家讲一下在这一迭代中的进程，并为将要开始的一天设定方向。在开发人员做的差不多的时候，设计师还要给产品进行 Review，确保开发出来的产品与设计尽量一致。设计师也可参与部分测试工作，这样，更深入的了解自己做的产品。总结下来，在「敏捷开发」的整个产品中，设计师需要全程的参与进去，对整个产品负责。
3.在「敏捷团队」中，设计师应该怎样做呢？
（1）了解产品与公司发展的方向
在「敏捷团队」中，每个人都要对产品负责，因此，设计师不能只盯着界面表现这一点，应该要跳出传统设计师的格局，以产品远景及公司的角度来思考许多决策。因为只有敏捷地面对市场的反应，随时调整前进的方向，才是让公司的发展跟上时代的变化。而且现在很多的公司都是以业务导向，如果你做的设计没有满足业务的需求，即使交互做的再好，界面做的再漂亮，对于用户来讲，也是一无是处。所以，要做出一个好设计，首先要基于产品的需求，使其功能戳到用户的痛点，进而让公司获得有效的发展，这才能给产品得到一个很好的验证，也认可了身为设计师的这一角色。
（2）要与团队达成良好、敏捷的沟通
在一个跨职能的团队里，只有良好、敏捷的沟通，才能让设计工作事半功倍。在「敏捷团队」里，需要与设计师需要打交道的，不外乎就是产品经理（PO）和研发人员（RD），这里总结一下与他们交流的原则：
与 PO 打交道的最大原则：
1. 确保了解每一项设计的需求，并且在约定的时间内达成。
2. 要给自己留出解决急性事件的弹性空间。
每日站会就是沟通工作进度的一个很好方法，这让我们在每一天刚开始工作时，就能够同步所有的信息，让接下来的一整天能够有完整的工作时间以及正确的工作方向，并且让 PO 清楚掌握设计师的工作负荷量，有助于 PO 判断每件任务的轻重缓急。
与 RD 打交道的最大原则：
1. 明确交待设计稿上的细节，但是要保有一定的弹性空间，让 RD 去修改。
2. 适当了解 RD 的开发方式，藉以调整设计，而达到大家最高的工作效率。
RD 每天要编写很多新的代码，有时候可能因为新开发的功能而导致旧的代码出现了 bug，而又在修复 bug，所以，如果能够减少 RD 调整框架的时间，相对研发的时间就会提升，产品整体的稳定性、效能以及体验一定会更好。而且以敏捷开发的角度来看，提前让产品功能完整的上线远比完美的视觉感受更重要。
（3）产品的功能性比界面更重要
在上面有说，产品功能的完整远比完美的视觉感受更重要。现在，很多的设计师在做设计的时候往往将视觉美感放在第一顺位，这会使设计师在产品设计初期就花太多时间在斟酌颜色与字体的细节，但其实用户并没有那么关心其美丑，产品的好用永远比好看重要!
以这次的交易大师产品来说，在订阅大师的界面，出现了很多的红色，这让设计师的我很是难受，认为整个界面没有抓住重点，没有给用户看到大师最重要的收益率，没法吸引用户来订阅大师。而对于这个产品来讲，可能只需要有一个订阅按钮可以将这个页面跑通了。
因此，在设计初期，设计师在意的应该是在每一次产品的开发周期内，优先设计用户的"使用"体验，而不是"视觉"体验，让用户清楚体验到这个产品解决了什么问题，远比让用户觉得你的产品很美来得重要。
结语：对于「敏捷开发」，有很多的地方我们也不能全部的照办照抄，比如在《敏捷宣言》中就提出工作的软件高于详尽的文档，但其实详尽的文档也是必备的，是基础。如果开发没有一纸文档，只凭PO 或设计师口中的功能界面讲解，那么最后做出来的东西肯定与最初定的想法千差万别。因此，在这点上，我们要更改一点点：相对于详尽的文档，我们需要更注重工作的软件。所以，在敏捷开发的团队中，也需要结合自己团队的特色来合理地使用「敏捷开发」。
