移动App开发项目应用Scrum模型研究

移动App开发项目应用Scrum模型研究 武汉大学 王斌 应用Scrum敏捷方法项目背景与问题

MJApp1.0版本预期开发周期是3个月，实际开发周期为5个月，延期2个月。实际开发成本是原计划的1.7倍。所以公司希望能够调整软件项目管理方式，提高开发效率，降低成本，并且保证产品质量。MJ公司本身和开发流程存在着诸多问题，在第三章已经进行详细的分析与阐述。基于目前开发方法效率低下，问题颇多，公司希望能通过改进开发方式，2.0版本采用Scrum开发模型。2.0版本产品内容为在1.0版本基础上增加分场景旅行中信息提供功能，初步计划产品开发周期为2-3个月。其主要问题如下：组织结构中的问题 团队分工不明确，导致成员互相推诿任务，造成开发效率低下。 团队意识薄弱，无团队无一致目标。开发流程中的问题 过于详尽的设计造成开发团队不断返工，开发效率低下，开发周期延长。 测试人员在项目后期进入项目，导致项目风险增加，开发周期延长。 需求管理混乱，多端需求不同步，造成不必要返工，降低了开发人员的积极性与开发效率。 缺乏持续改进的过程，产品仅仅在开发结束时才变得可见，不能及时收集用户反馈，设计优化方案。

5.1 应用Scrum模型的组织结构管理 团队组建是在原有开发团队基础上，衡量团队自身能力和任务量估计后，由产品经理重新调整人员组建团队，新团队由一名产品经理、两名移动端开发人员、一名后台开发人员、一名设计师、一名测试人员以及一名知识人员构成，一共七名成员。 接着团队人员依据Scrum的团队角色重新划分，并且按照目前公司的团队分工对Scrum中各个角色的任务进行拆分与重新分配。产品负责人代表着整个产品线的利益，制定产品的方向与愿景，在30人的小公司中没有人比老板更适合当产品负责人了。负责管理确定产品的Backlog，以及Backlog中各条目的优先级这个原本应该由产品负责人负责细节琐碎的工作交给老板便不再适合。ScrumMaster由产品经理担任，在现代互联网公司中，产品经理担任了重要的角色，产品经理负责管理产品需求，并且协调整个团队按期将需求变成可以交付的功能。所以产品经理领导整个团队同时又为团队提供服务。在实际工作中，将管理产品Backlog确定需求优先级的工作交给ScrumMaster做，产品负责人需要对审核Backlog和Backlog条目优先级，以确保Backlog符合产品愿景与产品利益。也就是说，原本由产品负责人负责的工作被拆成制定Backlog和审核Backlog两部分，由ScrumMaster和产品负责人分别完成。 新组成的Scrum团队中每一名成员都将MJAPP2.0开发任务作为优先级最高的任务，每名成员将直接对产品质量和开发周期负责。后台技术人员、设计师和知识人员由原来多名人员为同时多个团队负责变成仅归属一个团队，并由ScrumMaster领导大家服务大家。这样团队成员便产生强烈的团队意识与归属感，团队内部的自我组织能力便得到很大提升。 旅行依然是一件很麻烦的事，MJ产品旨在用技术把旅行变得简单。旅行过程中，信息碎片化且分散。MJ2.0版本是在1.0版本基础上为用户整合并提供行程中所需信息，MJ1.0主要功能是在旅行前为用户智能的规划行程，形成“我的行程”。M2.0增加在行程中，用户查看我的行程时，智能定位到用户当前所处场景，并且为用户提供所需要的信息。例如，用户的行程开始后,APP定位到用户在机场，于是APP便自动展开机场场景页面，提供航班信息、机场地图、免税店攻略等用户所需信息。 MJ2.0功能框架WBS如图5.1所示。基于功能框架WBS，ScrumMaster组织团队共同讨论产品Backlog，如表5.1。

5.2 应用Scrum模型的迭代开发过程管理 制定产品Backlog后，计入项目开发阶段，由于项目周期估计为2-3个月，所以约定每10个工作日（两周）进行一次迭代，以sprint计划会议作为一次迭代起点，每日sprint会议跟踪工作进展，sprint评审和回顾会议作为迭代的结束。 团队一共七名成员，一个sprint10个工作日，一个spint有70/日的工作量，560个工时。 在第一次Sprint计划会议上，根据产品Backlog划分每个Sprint的用户故事，产品负责人给团队讲解项目需求，开发团队根据用户故事评估工作时间。在这次会议上ScrumMaster建立了三个原则，第一，每个sprint的用户故事需要在当前Sprint完成，若有未完成情况，需要加班完成。这个约定保证5次迭代后项目一定会被完成。第二， 每个Sprint的工作内容以用户故事和task来制定，不同工作类型成员可能出现每个sprint的估计工时不足80工时的情况，不同工作类型的成员也需要互相帮助保证在当前sprint内完成任务。第三,由于团队初次尝试Scrum，制定sprint工作量时，预留一部分时间作为机动时间，来处理特殊问题。五次sprint总工时为2800，安排96%的工作量为2696，预留4%的机动时间。 第一次sprint计划会议确定了将完成的用户故事和Backlog，如图，并建立燃尽图实时跟进项目进度，如表5.2、图5.2。 同时，第一次sprint计划会议对本次sprint需要完成的用户故事进行详细的讨论，保证团队中每个人充分理解用户故事和完成目标。并完成任务认领。 第一次迭代的目标一是让团队熟悉Scrum开发方法及工作流程，建立具有自我组织能力的Scrum团队。二是搭建MJ2.0主要框架，让开发者合理认领工作并按计划完成任务。 第一次Sprint的工作时间为532小时，如图 第一次迭代燃尽图展示了第一个Sprint具体完成情况。 从燃尽图看出，在Day10第一个Sprint结束时，剩余完成工作量并未归零。说明实际进度慢于计划进度。通过加两天班按时完成了第一个sprint的backlog。 sprint评审会议对第一个sprint的完成情况进行评审，发现虽然进度比预计慢了两天，不过项目内容完成质量很高，由于一开始测试进入项目，产品功能很完善。 Sprint回顾会议项目成员一起回顾探讨第一个sprint开发中遇到的问题，并一起总结商定解决方案。 以下是第一次sprint过程遇到的问题： Backlog任务划分不够细致，部分需求忽略了设计人员的排期。 各个不同工作人员之间工作交接不够紧密，第一次会议制定好排期后，各个工种并没有一起协商任务的先后顺序，各个工种仅仅安排自己的排期和工作顺序，并没有考虑到有些任务如前端开发需要与其他职能人员协同完成。导致团队花费很多时间沟通工作交接调整工作顺序。 测试人员由于第一次在项目早起进入项目，参与度不足，没有找到合适的方法参与。 每日sprint会议，团队成员没有表达工作进展的习惯，不能及时表达遇到的问题，导致常常发现问题时间较晚，需要花费更多的时间弥补。 团队成员之间的沟通不足，虽然多于原有开发方式，但大家依然没有习惯主动沟通。 在会议中，针对以上问题总结几个改进方法： 对每个backlog各工种成员充分讨论，划分更加细致的任务。 测试人员在项目早期没有测试工作时，给产品经理和设计提供帮助和反馈。 在sprint计划会议团队成员认领任务后，针对需要多工种协同完成的任务整个团队共同制定排期与工作顺序，保证每个团队成员认同当前工作安排。 每日工作sprint会议上，ScrumMater带领大家短暂交流并且反馈自己的工作进展，促进大家相互了解，共同成长，增加团队凝聚力。 每轮sprint改进上轮的问题，又提出新的问题和解决方法，如此循环Scrum团队快速适应Scrum开发模式，并且项目进展顺利，团队凝聚力增加。如图 是第五次迭代燃尽图，实际完成曲线十分接近计划完成曲线，甚至进度还有所提前。 Scrum开发过程中，测试验收过程与瀑布模型相比有本质上的飞跃，MJ1.0版本使用瀑布模型开发App，测试人员在编码与接口调试全部结束后进入项目，需要花大量时间了解项目设计，但依旧无法在短时间内了解充分，这种情况造成前期测试效率底下，当测试进行一段时间后，bug集中爆发，给整个项目带来严重的影响，大量bug需要花费大量时间修复导致项目延期，大量集中出现的bug严重的打击了士气，导致整个团队气氛低落，效率低下。而应用Scrum开发模型，测试人员从迭代初期便参与项目，在测试工作较少时，帮助产品经理评审文档工作帮助设计校对等工作。对于整个项目来说，测试人员的加入，在开发前期便开始质量控制，测试人员全程参与，充分掌握项目细节。并且开发团队每完成一个功能模块，测试便对此功能进行独立的测试工作，保证及时修正bug，这样到最后项目全部完成进行整合测试时，单独功能模块几乎不会出现大的问题，在项目后期就不需要对代码进行大规模修改与重写。这种开发方式正适合开发App这种变更多，功能点小的软件类型。MJ2.0的顺利完成，对团队来说是一个奇妙的过程。基于Scrum敏捷方法的软件开发过程，极大的提高了团队的开发效率，迭代过程中灵活调整设计方案避免开发无用功能和重复开发工作。本文基于最新的敏捷开发模式，根据移动App的开发过程特点和团队规模，对众多敏捷模型比较分析选择，最终确定使用Scrum开发模型。对移动App开发项目从团队组建，需求设计，迭代开发过程，评估验收几个方面入手进行研究，并且将研究结果应用于实际项目MJ2.0的开发过程中。实现了小型团队应用Scrum敏捷方法开发移动App的过程实践。 本文完成的主要工作如下：分析了目前移动互联网面临的高速发展的市场，并通过在创业互联网公司实习，深入开发项目，发现目前开发过程存在的问题，并且提出需要改进开发流程以适应高速变化的市场需求，提升产品竞争力。 通过研读文献，对敏捷开发过程管理进行研究，明确敏捷开发的灵活性和以人为核心的特点。 对传统的软件开发模型进行分析，并且以实习公司MJ1.0开发过程为例，分析应用瀑布模型开发App存在的问题。 对敏捷开发模型进行分析，结合团队规模和移动App开发特点，选定Scrum敏捷模型作为研究对象，Scrum的特点为：适合5-9人的小型团队应用，Scrum要求每次迭代的交付成果应该是可以使用的功能，每次迭代由设计、实施、评审和回顾四个阶段构成，并且重视实施过程中团队的交流合作，这种开发模式很适合MJ公司的创新性移动APP的开发团队。 基于实习公司产品新版本MJ2.0实施Scrum敏捷方法，重新组建Scrum团队，项目经历5次迭代周期，每次迭代经历需求设计、开发、评审验收过程，5个迭代周期后项目顺利完成。团队通过Scrum四个会议持续跟进调整开发过程，迭