用户故事在软件管理中的应用

最新推荐文章于 2021-12-21 11:50:07 发布

alex_liu的技术堡垒

最新推荐文章于 2021-12-21 11:50:07 发布

阅读量732

点赞数

文章标签：敏捷开发产品任务文档测试活动

本文链接：https://blog.csdn.net/liu3417/article/details/6245303

版权

这是学院软件管理课程要求写的一篇论文：

摘要

本文从笔者在工程实践中的对敏捷开发方法中用户故事的应用从发，分析用户故事在软件管理中起到的一些作业。

关键词 ：敏捷开发; 软件过程; 用户故事。

軟件過程的認識

软件过程（Software Process ）是指一套关于项目的阶段、状态、方法、技术和开发、维护软件的人员以及相关Artifacts （计划、文档、模型、编码、测试、手册等）组成。

软件过程(Software Procedure) 是指软件生存周期所涉及的一系列相关过程。过程是活动的集合；活动是任务的集合；任务要起着把输入进行加工然后输出的作用。活动的执行可以是顺序的、重复的、并行的、嵌套的或者是有条件地引发的。

　　软件过程可概括为三类：基本过程类、支持过程类和组织过程类。基本过程类包括获取过程、供应过程、开发过程、运作过程、维护过程和管理过程。支持过程类包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程。组织过程类包括基础设施过程、改进过程以及培训过程。

　　软件过程主要针对软件生产和管理进行研究。为了获得满足工程目标的软件，不仅涉及工程开发，而且还涉及工程支持和工程管理。对于一个特定的项目，可以通过剪裁过程定义所需的活动和任务，并可使活动并发执行。与软件有关的单位，根据需要和目标，可采用不同的过程、活动和任务。

所在組織軟件過程應用程度

我所在公司背景是一个私有上市企业，集团总公司是做手机运销的，为了在互联网市场上抢占份额，新成立了一个全资子公司，因为是新成立的公司，管理方面带有浓厚的运销企业的风格，在基础管理中运用了大量绩效的考核。

开发人员，测试人员的考核实际上也流于形式，基本由经理确定，和经理关系好就能够获得比较高的绩效。在初级开发人员中，绩效奖金占的比例又过低，实际对初级开发人员没有起到实际的促进作用。公司初期引进的敏捷开发，本意是想解决运销型公司风格向技术性公司转型中带来的一系列问题。

从广义上来给敏捷开发下定义，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

公司初期想达到的目标也在于如此，但是初期产品人员完全秉承老板的意图来进行开发，丧失了部门的独立性。这也在于产品经理这个职位是近来才兴起的一个职位，很多人员都是从前端人员或者技术人员转型过来的，这并非说这不好，由于任务的排期是产品人员制定的，他们缺乏专业的开发技能，又由于是受老板的控制，制定了一些比较庞大又不是很有用的开发计划。

比如我们公司打算做一个手机小说阅读网，产品人员为了有别于其它阅读软件，设计了语音阅读的功能，这并非是不可以实现的功能，但是在项目排期上却是列入了高优先级，而初期我们开发人员人手严重不足够。

我介绍一下我们团队的组织结构：

客户端：4 人（symbian ，android ），后期达到了13 人，增加了J2ME 开发组，平均从业时间3 年

服务端：初期3 人，选用了pyhton 作为开发语言，由于适合敏捷开发，学习曲线比较低。人员情况是平均从业时间是1 年左右，实习生一个，负责人是从业4 年。

产品部：4 人，包括美工2 人，产品经理是技术人员，后来因为和老板发生冲突，辞职走人。剩下的都没有技术开发背景，老板因此控制了产品部。

测试部：13 人。负责整个公司的项目，并非全为我们项目提供服务。

市场部: 1 人。负责产品推广，长达半年多的时间没有推广，因为产品没有上线的原因。前期负责产品的问卷调查等工作。

产品计划：

服务端一期完成开发新闻和小说阅读频道，互动社区。二期进行产品优化，三期完成小说阅读站的作者线上创作功能。

客户端完成小说阅读的相关功能，分为symbian ，android 和J2ME 版本。

因为服务器人手严重的不足，加上开发人员的平均从业时间不长，公司的预期目标过大，这导致了出现了员工加班时间长，产品部和技术部，测试部三个部分扯皮的事情经常发生，三个部门之间矛盾很深，员工的离职率相当的高，而且老板经常干涉开发计划，不按照流程来做事情，对技术部人员的使用很多时候也是不太恰当，大量使用实习生来做事情。导致公司事业部在元旦筹划的项目开发计划拖延至 6 月份依然没有完成。

故事驱动开发在公司中的应用

我们都知道敏捷开发的核心价值宣言是，

个人和交流重于过程和工具

正在运行的软件本身重于复杂的文档

与客户的沟通和交流重于使用合同约束客户

对变化的快速响应重于跟随计划

一个成功的敏捷开发小组应该具有“我们一起参与其中”的思想。虽然敏捷开发小组是以小组整体进行工作，但是小组中仍然有一些特定的角色。有必要指出和阐明那些在敏捷估计和规划中承担一定任务的角色。

第一个角色是客户团队。主要职责包括：确保软件满足用户需求的所有人，这意味着客户团队可以包括测试人员，产品经理，实际用户和交互设计师。

第二个角色是开发人员。这里使用开发人员来概指所有开发软件的人。它包括了程序员、测试人员、数据库工程师、可用性专家、技术文档编写者、架构师、设计师，等等。

公司在6 月份的时候，发现了项目无法收工，而且需求出现了严重的偏离，客户端朝着做浏览器方向去了，再加上产品部的文档冗长，我们都知道软件开发项目失败的原因是方方面面的，但是软件需求确实被识别为最常见的痛苦根源。不论是行业的研究，还是权威人士的讨论。针对此挑战，多年以来行业中的解决办法是使用越来越冗长的文档，尝试用精确的语言来记录越来越细化、越来越具体的所谓全面的需求。制定标准的各个组织提供各种的文件模板和相应的语言书写规范让大家来清楚地定义需求。数不尽的书籍和文章论述怎样用详细的文档来描述需求。不知道多少森林因为各个组织产出堆积如山的需求文档而被砍伐。公司鉴于快速上线，而砍掉了新闻服务，当然还在于我们没有独立的新闻从业人员，所有的来源都是抓取网上的，这有很多的法律风险。

公司管理层引进了故事驱动开发，具体做法是，出资让技术部，测试部，产品部参加敏捷培训，然后根据公司的实际情况进行了开发流程的改造，由产品部提供用户故事，辅之以少量说明文档，然后由技术部讨论技术难度，在该轮迭代中，选择最简单的功能点作为基准开发点，大家讨论开发它需要的时间，然后其他的功能点参照基准开发点标明点数。然后以一周为一个迭代发布时间，通过捕获一目了然的格式一致的用户故事，我们掌握了足够的信息可以继续前行。我们给用户故事排优先级，并且先开发最重要的。我们按需及时展开，通过交谈获取所需要的细节。我们产出具有真正价值的软件，成果可以被审核和验证甚至交付使用。然后我们继续开发后续最重要的用户故事。