报名网站建设定做,物流网站购买物流单号,做电商网站哪家好,影视广告公司网页设计1、瀑布式开发
流程关键词关键人员输出立项简述、周期、预算领导立项申请表、立项评审表策划计划项目经理、QA、CM各种计划书#xff08;项目、配置、测试等#xff09;#xff0c;评审需求功能项目经理功能列表、需求规格书、需求开发计划等#xff0c;评审设计UML开发设…1、瀑布式开发
流程关键词关键人员输出立项简述、周期、预算领导立项申请表、立项评审表策划计划项目经理、QA、CM各种计划书项目、配置、测试等评审需求功能项目经理功能列表、需求规格书、需求开发计划等评审设计UML开发设计概要、详细、数据库、分析、评审编码写代码开发源码、单元测试、安装包、产品集成、代码审查测试测试测试需求测试、集成测试、系统测试、缺陷跟踪、评审手册使用文档项目经理安装手册、操作手册验收发布、验收客户确认表、验收单结项评价领导总结报告质保维护QA检查表、问题跟踪表
2、Scrum
2.1 简述
Scrum是迭代式增量软件开发过程是敏捷方法论中的重要框架之一 百度百科https://baike.baidu.com/item/Scrum/1698901?fraladdin 推荐博客https://blog.csdn.net/a715167986/article/details/128716292
2.2 术语
角色
产品负责人 Product Owner 负责维护产品订单的人代表利益相关者的利益。
Scrum主管 Scrum Master 为Scrum过程负责的人确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。
开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。工件
产品列表 Product Backlog根据用户价值进行优先级排序的高层需求。
冲刺订单 Sprint Backlog要在冲刺中完成的任务的清单。
产品增量 Increment最终交付给客户的内容活动
计划会 Sprint Planning Meeting在每个冲刺之初由产品负责人讲解需求并由开发团队进行估算的计划会议。
每日立会 Daily Standup Meeting团队每天进行沟通的内部短会因一般只有15分钟且站立进行而得名。
评审会 Review Meeting在冲刺结束前给产品负责人演示并接受评价的会议。
反思会/回顾会 Retrospective Meeting在冲刺结束后召开的关于自我持续改进的会议。其他
冲刺 Sprint: 一个时间周期通常在2周到1个月之间开发团队会在此期间内完成所承诺的一组订单项的开发。2.3 用户故事
用户故事user story是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素
角色 谁要使用这个功能。
活动 需要完成什么样的功能或目标。
商业价值为什么需要这个功能这个功能带来什么样的价值。用户故事通常按照如下的格式来表达 英文
As a Role, I want to Activity, so that Business Value.中文
作为一个角色, 我想要活动, 以便于商业价值举例
作为一个“网站管理员”我想要“统计每天有多少人访问了我的网站”以便于“我的赞助商了解我的网站会给他们带来什么收益。”需要注意的是用户故事不能够使用技术语言来描述要使用用户可以理解的业务语言来描述。 关于用户故事Ron Jeffries用3个C来描述它
卡片Card - 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述工作量估算等。
交谈Conversation- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认Confirmation- 通过验收测试确认用户故事被正确完成。用户故事的六个特性- INVEST
INVEST Independent, Negotiable, Valuable, Estimable, Small, Testable独立性 可协商性 有价值 可以估算性 短小 可测试性独立性Independent— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划确定优先级工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。可协商性Negotiable— 一个用户故事的内容要是可以协商的用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节实际上限制了和用户的沟通。有价值Valuable— 每个故事必须对客户具有价值无论是用户还是购买方。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候他们将非常乐意写下故事。可以估算性Estimable—开发团队需要去估计一个用户故事以便确定优先级工作量安排计划。但是让开发者难以估计故事的问题来自对于领域知识的缺乏这种情况下需要更多的沟通或者故事太大了这时需要把故事切分成小些的。短小Small— 一个好的故事在工作量上要尽量短小最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大在安排计划工作量估算等方面的风险就会越大。可测试性Testable—一个用户故事要是可以测试的以便于确认它是可以完成的。如果一个用户故事不能够测试那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子软件应该是易于使用的。
2.4 史诗、特性
敏捷中需求通常被分为史诗、特性、用户故事三大类别逐层往下粒度越来越小。需求直到被分解至用户故事时才能放入Scrum迭代。
史诗由多个较小的故事组成的史诗。
特性一组相关的故事有价值的单方向功能集合。
用户故事独立的较小用户的价值交付单元。有可能不足以单独发布。2.5 猪与鸡
2.5.1 鸡和猪的故事
一天一只鸡散步时遇见了猪。
鸡对猪说“嗨我们合伙开个餐厅吧。”
猪说“好啊那准备取什么店名呢”
鸡说“要不就叫火腿和鸡蛋吧。”
猪直接拒绝了“那可不行。我要割肉你只要下蛋。这样下去我迟早要完蛋。”2.5.2 保护“猪”兼顾“鸡”
这个故事实际上反映了软件开发过程中的2种不同角色即需要完全投入的“猪”和只要部分投入的“鸡”。真实项目过程中往往会发生这样的现象产品经理或领导喜欢临时往项目中新增任务打乱原先的开发节奏导致程序员压力倍增士气低落项目延期。
而Scrum就是为了保护“猪”这种角色兼顾“鸡”的感受从而确保整个项目正常交付。它是一套敏捷开发流程。
2.6 Scrum用到的工具
用户故事。迭代计划会议用到Product Owner以用户的角度去描述需求。如作为一个学员我希望能在做完一份试卷后系统能针对我的薄弱点提供相应的指导及练习。Product Backlog。迭代计划会议用到Product Owner事先将所有的用户故事按优先级排好放到一个列表内这个列表就是Product Backlog。Sprint Backlog。迭代计划会议用到整个开发小组通过估点将用户故事按优先级移入到迭代计划内迭代计划中待完成的用户故事列表即为Sprint Backlog。估点。主要用于评估用户故事的大致工作量。下一篇文章会额外介绍估点。燃尽图。主要用于迭代进度的管控。下一篇文章会额外介绍燃尽图。
2.7 Scrum标准流程
2.7.1 Scrum标准流程之Sprint Planning Meeting
迭代计划会议中整个小组通过估点的方式按优先级将用户故事从Product Backlog中移入到Sprint Backlog表示整个小组承诺本迭代要做完的任务。做完的标准是测试通过除非此任务不可测试。
2.7.2 Scrum标准流程之Daily Stand Up Meeting
迭代计划会后小组成员按个人喜好领取自己的任务并在每天的站立会议上讲一下自己昨天做了什么今天准备作什么大概什么时候完成以及遇到了什么问题。当有人提出遇到难题时Scrum Master需要在会后安排人帮忙解决而不是在会议上直接解决。每个人大概30秒-1分钟整个会议一般不超过15分钟。每一个工作日结束后需要画燃尽图下一篇文章会额外介绍。
2.7.3 Scrum标准流程之Review Meeting
一个迭代开发阶段结束后进入内部演示会议工作成果给整个小组演示包括Project Owner。EduSoho的做法是bug及小优化不演示点数较大的功能点做演示。
2.7.4 Scrum标准流程之Restrospective Meeting
内部演示结束后整个小组包括Project Owner召开一个迭代回顾会回顾本迭代中大家哪些做的好哪些做的不好每人各列举3个好的以及不好的列的时候只讲现象不分析原因不找解决方案。然后整个小组投票选出3个不好的分析原因寻找解决方案并指定执行者。
为什么只解决3个不好的每个小组的精力有限如果要一个迭代内解决全部问题不太现实先优先解决3个最重要的多次迭代后会发现整个小组的变化越来越明显。
