敏捷开发描述

《敏捷开发描述》由会员分享，可在线阅读，更多相关《敏捷开发描述（3页珍藏版）》请在金锄头文库上搜索。

1、敏捷开发过程描述1. 敏捷开发的原则原则一:个体及交互比流程与工具更具价值原则二:可用的软件比冗长的文档更有价值原则三:与客户的协作比合同谈判更有价值原则四:对变化的响应比遵循计划更有价值由此可见敏捷开发更注重人的作用，更注重人交流，团队协作。2.敏捷开发-ScrumScrum 是一种迭代式增量软件开发过程，通常用于敏捷软件开发。 Scrum 在英语的意思 是橄榄球里的争球。 Scrum 的开发过程如下图所示:用需代码质量保证步骤市场 需求SprintUseUser StoryCase/TaskBacklogBacklog一个项目包含很多用户需求，可以把这些需求都划分成多个sprint(冲刺/

2、快跑)来完成， 每一个sprint就是一个迭代过程，也就是一个项目由多个迭代sprint组成。每个sprint包含 需求-分解功能-细化-开发-测试-演示等工程，这样保证了每一次sprint开发出来 的版本都是“可用的软件”。Scrum 使用的软件：(1) Jira + greenHopper :项目实施和 BUG 跟踪(2) Bamboo：持续化集成(3) Confluence: wiki 共享(4) Selenium:自动化UI测试(5) Jmeter:压力测试3.敏捷开发-Scrum实施过程(1) 需求分析需求主要是由需求部门完成，见如下表格:传统瀑布开发模式Scrum敏捷开发1. 进行

3、详尽的需求调研2. 形成详细的需求文档1.需求方参与，提供ProductBackLog即需 求简述列表3.以后的设计与开发与需求相关，需求 不可再变化2.计划、开发中不断交流迭代需求Scrum 要求需求方以 ProductOwner 的角色参与到项目中，直到开发结束。在需求阶段需要 ProductOwner 提供一份 ProductBackLog 来简述产品的需求列表，并且根据这些需求的 重要程度给出需求的权重值，以便在计划中优先处理高级别的需求，ProductOwner可以根 据需求的大小估算出产品开发的工作量（人/小时）。如下列表为示例ProductBackLog序号（ID）名称重要 性工

4、作量估算（小时）如何做演示备注1存款305登录，打开存款界面， 存入10元，转到我的账 户余额界面，检查我的余额增加了 10元需要UML顺序 图，目前不需要考虑加密问题2查看自己的 交易明细108登录，点击“交易”， 存入一笔款项，返回交 易贝面，看到新的存款 显示在页面上使用分页技术避 免大规模的数据 库查询。和查看 用户列表的设计 相似在需求形成的过程中，可以在 jira 中新建一个项目，添加各种模块以及策略。并且把ProductBackLog录入jira系统中，jira中针对ProductBackLog的类型为Epic即大块的需求。（2）计划会议计划会议的参与人员包括ProductOwn

5、er， ScrumMaster, Team，大约4-6个小时的时间 进行。进行的顺序如下： ProductOwner在jira中逐条介绍产品backLog； （30-60分钟） 一起把backLog拆分成story，每一个sotry都必须估算时间；（180分钟） 本次sprint的目标，起止时间以及演示时间（30分钟） 确定哪些在本次sprint中开发（30分钟） 确定sprint的立会的时间地点（5分钟）计划会议中，把产品BackLog细化成Story，并录入jira中的Story类型中，每一个story 要尽量的细化，最好工作量是在2个小时以内（包括UI的设计），在sprint初期阶段工作

6、量的 估算主要是靠人的经验。在确定了此次 sprint 的起止时间以后，就可以知道开发大体的时间是多少，然后确定哪 些story可以放到此次sprint中，尽量选择权重高的story首先完成。在确定了 sprint要完成的story同时可以确定哪些story属于哪个team即分配story。 在估算每个team的工作量的时候一定要考虑实际情况，估算中每人6时/天为通用值。（3）迭代开发计划完毕以后就可以进入开发了，每个teamer都有了自己的任务列表，队员应该根据 情况由易到难，由简到繁的顺序快速开发。开发中要尽量使用快速开发工具Tenace。每日立会要风雨不改，定时定点的举行，立会中每个人都

7、要回答三个问题：过去的一天 完成了什么；下面将要进行什么开发；在开发的过程中遇到了什么困难。如果有技术难题不 要再立会中进行，立会的时间不超过15 分钟。Teamer在开发的过程中如果开始了哪个story,则在jira中设置哪个story在开发过程中，如果开发完毕则置为开发完毕，发给测试组测试，任务面板如下：未进行开发中开发完毕测试中测试完毕权限管理用户添加 用户修改用户查询这样开发和测试不断的循环，形成每个story都是迭代的。Teamer在开发的过程中要尽量针对每一个类都写Junit测试类，如果时间紧迫也一定要针对相关的 Manager 写测试类。利用bamboo进行每日构建，保证所有的类

8、编译以及Junit类测试方法都是没有问题的。 测试人员看到开发完毕的story，迅速测试反馈。测试过程中，先利用selenium录制脚 本以便回归测试，测试完毕后如果有bug立刻利用jira的bug进行提交，小bug可以直接找 到开发人员口述(沟通)。快速测试快速反馈。开发人员要合理利用自己的时间边开发新的边修改BUG。遇到大的拦路虎要尽量先跳过，StrumMaster要承担起来这种困难。如果在计划的时间太短则需要抛弃一些story，首先保证此次sprint做出来的东西是可 用的。(4) 演示与回顾演示就是更新正式平台，把sprint完成的可用的功能全部更新到正式平台中，让用户体 验，在演示会议中，StrumMaster或者测试人员主动的给Productowner等实际操作的人员直 接演示，如果有条件可以每个人都点击一下，或者给Product部门的人几天的时间让他们反 馈。有些技术性的东西无法演示的时候，选择不演示。甚至如果演示的成本过大则不演示。 回顾主要是总结sprint过程，以便提升。定期制作scrum过程调查，以便调整。