任务量

　　不同的功能模块其工作量也不尽相同，我们可以按以下三种类型划分：

　　1、Large

　　一般来说每个User Story都需要在一个Sprint内完成，避免太大而跨越几个Sprint。如果出现太大的User Story导致一个Sprint塞不下，则需要将User Story分解，这个Sprint完成一部分，但是不release，只是demo给PO/PM， 余下的在接下来的Sprint里完成。

　　2、Normal

　　按正常流程进行快速迭代设计。

　　3、Mini

　　JDI （Just Do It）， 一些小功能的实现无需文档，任何沟通方式都可以用来传达你的设计思路，然后交由开发去实现。

　　关于文档

　　原本瀑布开发模式下设计师的唯一交付物Specification，在快速迭代设计中已经不是那么重要，因为快速变化的用户需求让设计节奏加速，不断更新维护Specification成本太高。用户是为你设计出的产品或者功能付款，而不是你的设计文档，所以传递设计思想才是主要目的，PPT、Visio等Wireframe或者email、meeting notes等记录都可以作为设计参照。

　　对于文档，我们一般遵循如下原则：

　　尽可能在文档中简单的描述需求、分析结果、信息架构和设计细节，只要它们恰好满足PO的要求即可。

　　如果该Scenario的逻辑足够复杂，那么请毫不犹豫的用文档详细的描述，以开发团队恰好能充分理解为宜。

　　文档的简繁程度需要经过几个Sprint的迭代，才能找到最合适的level。

　　保持一直设计

　　设计对产品来说如此重要，特别是在敏捷开发流程中，没有一个专门的设计阶段（There is no design phase），整个流程都伴随的设计。从前期纸片概念，白板框架，用户场景测试，到具体细节代码实现，终极用户测试，都离不开设计的跟随。这不再是那个只需要在早期完成设计就弃之不管的模式，他要求你每天都不停的参加讨论参入迭代参与设计。

　　Epilogue 后记

　　我们团队面对的是一款由公司早期元老打造的工程领域软件，它的用户基数庞大，它的地位曾经显赫。然而它的功能逐渐老化，模块架构也相对固化，开发团队很难对整个系统进行改动，因为整个软件架构已经固定，任何大的改动都是牵一发而动全身，不但会造成许多与改动处无关的环节出现问题，莫名其妙的regression defect也让QA措手不及。一些设计改进都必须得在之前设计的基础上进行调整，力求一致性，很难加入全新的交互模式和UI风格。同时，正是由于产品功能没有大幅度的更新，瀑布模式比较擅长的低风险复杂功能开发已经无法满足用户需求的小快灵。 因此，我们目前所使用的敏捷设计流程尽管无法跟全新开发的产品一样自由，只是在大框架的制约下进行功能的迭代更新，但也取得了不错的效果，3年做下来完成了许多小功能的快速成功发布，提升了大家对于Scrum流程继续使用的信心，致力于建立一个持续的可改进的快速响应团队。本文所提及的流程并不适用所有情况，希望大家各取所需，保留对自己有价值的部分，摒弃不适合的。