2019-08-13 14:54:13 qq_33407429 阅读数 72
  • C语言程序设计--进阶篇教学视频

    该课程为“C语言及程序设计”系列课程中的第三部“进阶篇”。作为终结篇C语言教程,介绍了在实际应用中应用广泛的结构体数据表示和处理、利用文件进行输入输出、利用多文件组织项目开发,并结合对程序设计的进一步学习需求,概述数据结构及其选择问题和问题求解方法。以实践为主线的学习将继续,“银行储蓄系统”的开发将会迭代到第5版和第6版。

    40739 人正在学习 去看看 贺利坚

今天部门大佬让我去设计并且开发一个为游戏中的AI精灵小助手的数据提供接口,强调了是敏捷开发原则。由于不太明确敏捷开发原则是什么,就去设计了一个AI精灵小助手中问题的后台管理页面,以及DB中表的设计。然后设计了一个很完善但是开发时间略长的实施方案。然后汇报工作的时候就被嫌弃太麻烦,可以简单实现,下个版本在完善。在这里插入图片描述

敏捷开发原型

简单设计,快速实现,根据客户需求迭代,需要高效沟通

  1. 需求评审,用story的形式去描述需求
  2. 根据story描述的去划分需求
  3. 概要设计
  4. 详细设计
  5. 开发
  6. 自测
  7. 联调
  8. 灰度上线(灰度发布也称金丝雀发布,让一部分人去使用新版本,剩余部分的人去使用老版本,逐渐扩大范围直至全面上线)
  9. 全面上线

优点

注重沟通、客户写作、需求变化快、快速适应、建造模型

缺点

无法适用于大型项目,沟通需求大,造成成本大

瀑布开发原型

将功能实现和需求设计分开。将软件生命周期划分为:

  1. 制定计划
  2. 需求分析
  3. 软件设计
  4. 程序实现
  5. 测试
  6. 运维

优点

为项目提供了按阶段划分的检查点、只需要关心当前和下游功能实现、一般多嵌套于其他开发模式上

缺点

①各阶段间的联系较少,极少有互相反馈②只能在项目后期才能看到成品③根据设计文档的时间点跟踪项目的各个阶段④对需求的变更的适应力差

迭代开发原型

从某种角度上,迭代开发是一次完整经过所有流程,类似于小瀑布模式的开发流程,每次迭代都有一个成品,它也是最终成品的一部分(子集)

优点

①降低了一个功能增量的风险 ②需求变更可以在迭代的版本中实现③加快开发的进度④对新需求或者需求的变更的适应能力强

缺点

快速成型的软件可能会导致产品质量低

快速原型模式

快速建造原型,根据原型去细化需求,确认好需求的时候就可以抛弃原型,进行重新架构和开发。

2011-03-29 19:33:00 cheny_com 阅读数 2546
  • C语言程序设计--进阶篇教学视频

    该课程为“C语言及程序设计”系列课程中的第三部“进阶篇”。作为终结篇C语言教程,介绍了在实际应用中应用广泛的结构体数据表示和处理、利用文件进行输入输出、利用多文件组织项目开发,并结合对程序设计的进一步学习需求,概述数据结构及其选择问题和问题求解方法。以实践为主线的学习将继续,“银行储蓄系统”的开发将会迭代到第5版和第6版。

    40739 人正在学习 去看看 贺利坚

软件“可运行”了就可以评审且通过了?这是个问题。

在多年前参加Scrum Master培训的时候,老师拿出一个很好的表格,每行是一个故事,每列大致如此:

编码完成

功能测试

单元测试

集成测试

压力测试

自动测试

……

这样在计划会的时候,PO就告知大家每个故事他的要求是什么,一方面大家会因此对于要估计的用户故事有一个更明确的理解,另一方面就是约定了评审会上这个故事的完成标准。

 

这个方法已经不错了,不过后来又发现一个更好的:EA(一家游戏公司)将其所有故事完成标准分为5级,分别是:

1. 可提供反馈的(就是马马虎虎做出来能玩就行)

2. 可运行的

3. 可提供玩家评价的

4. 可提供玩家体验的(在体验服务器上安装(在线游戏),或发行预览版(单机游戏))

5. 完美的(可上线和销售的)

这种方法更好地从客户价值理解了“完成准则”,看到准则等级,就知道该如何使用此功能。

当然两种方法并不矛盾,因为“可提供反馈的”这种基于客户价值的完成标准一定有对应的基于实现的完成标准,比如“可提供反馈的 = 编码完成+功能测试”。

 

另一个话题是有了这些标准,如果只在最后评审会才使用,一定会制造不少“惊喜”。所以在迭代中期如果有些功能已经完成,完全可以随时评审,并基于评审结果当时就做改进。有一家公司在长度为一个月的迭代中的10、20天分别进行两次评审;而游戏公司普遍采用的是在功能完成的同时就进行评审。评审中发现的问题属于要拥抱的变更(在《迭代期内无变更与……》的两篇博文中有描述)而非要拒绝的变更,以便使得迭代能交付更多客户价值,MoSCoW会防止变更损伤承诺。

 

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2018-08-10 11:26:13 fan2252228703 阅读数 276
  • C语言程序设计--进阶篇教学视频

    该课程为“C语言及程序设计”系列课程中的第三部“进阶篇”。作为终结篇C语言教程,介绍了在实际应用中应用广泛的结构体数据表示和处理、利用文件进行输入输出、利用多文件组织项目开发,并结合对程序设计的进一步学习需求,概述数据结构及其选择问题和问题求解方法。以实践为主线的学习将继续,“银行储蓄系统”的开发将会迭代到第5版和第6版。

    40739 人正在学习 去看看 贺利坚

第一个管理的项目采用的是敏捷开发,以下是个人对敏捷开发的一点实践总结。希望能给大家提供一些帮助。

(关于敏捷开发的3355,敏捷宣言,十二准则在最下边有。)

敏捷开发流程:

1.首先需求负责人理清需求。

2.团队内部要熟悉了解(可以做做游戏)。

3.当天下午及晚上迭代任务拆分。评估工时。

4.开始第一天每日例会领取任务。

5.迭代中旬测试用例评审,接口文档评审,故事验收标准。

6.期间每天早上的站会主要是总结昨天做了什么,遇到了什么问题,今天要干什么(承诺)。负责人需要对问题进行解决。不要阻塞开发。

7.迭代结束需要开迭代评审,迭代回顾。晚上进行任务拆分。

8.上一迭代未完成的任务放进下一迭代。需求变更的也放入下一迭代。

 

 

详细过程:

1.一周主要有以下几个过程:

每日立会。

迭代评审。

迭代回顾。

迭代计划会。

接口评审。

测试用例评审。

故事验收标准。

周报。

演讲分享。

 

每日立会:

每日立会是用来回顾自己在昨天做了什么,还有什么任务没有完成,为什么没有完成,遇到了什么问题需要解决。自己今天要做什么。根据反应的情况进行调整。负责人需要对所有的问题故障进行尽快的解决。

每日立会的公开性透明性能够清楚的认识到每个人的能力和问题。团队成员领取任务是一种承诺,既然承诺了就需要去完成。

 

迭代评审:

迭代评审是对本次迭代的评审,需要严格按照故事的验收标准来进行评审。是检验本次的迭代成果的时候。检验本次的完成情况并进行梳理,看有哪些没有完成,为什么没有完成,是否有什么风险,并将没有完成的移到下一迭代。完成后需要将本次迭代的成果交给甲方进行验收,看是否有需要改变的地方。如果有的话将需要改变的需求移到之后的迭代进行。

 

迭代回顾:

 

回顾本次迭代的团队情况。每个人需要写团队的三个评价:

好,不好,待改进。必须是针对团队的,不能针对个人。之后将统计结果写在黑板上,由团队人员进行投票。每个人必须对每个栏目进行投票,可以投多票反对,一票赞同,赞同票必须投,反对票可以不投。完成后总结团队的情况并解析。下次迭代改进。

 

迭代计划会:

迭代计划会需要对下次迭代的需求进行讲解和任务划分。将故事划分成一个个任务,由相应人员进行工时评估,录入系统。完成后将任务和故事打印出来,贴到看板上。

 

迭代本身:

这个暂时不知道是什么意思。

 

接口评审(迭代中旬):

对团队人员写的接口进行评审,看是否符合标准,解释是否明了,需要用到该接口的人员有什么问题都可以提出来。需要修改的则现场进行修改。

 

测试用例评审(迭代中旬):

对测试人员编写的测试用例进行评审,主要是测试人员进行评审看用例有那些缺陷或不严谨的地方。反思自己写的测试有什么不足。

开发人员则需要注意看看测试人员会测试那些东西,反思自己思维上有哪些没有考虑到,尽量的在开发阶段进行完善。不要提交到测试那一大堆bug。

 

故事验收标准:

故事的验收标准需要由团队人员来进行编写,提交给负责人,负责人同意后,则迭代评审时按照该标准进行评审。

周报:

每个人需要在一周结束时写一份周报来总结。周报内容应包括以下内容:

1.本周所做的工作

2.本周完成的工作

3.本周遗留的工作

4.有挑战性的工作

5.有成就感的工作

6.所学到的知识

7.自己需要改进的方面

8.建议团队需要改进的方面

9.其他

 

演讲分享:

这个是附加的,因为咱们都缺乏一些经验性,常识性的东西,所以需要以演讲的形式来为团队成员扩充知识面。

 

 

敏捷开发术语解析:

分组:开分前需要分好团队,根据不同情况将一个团队分成几个组,可以不分。并取个名。

迭代:一个项目可以分成多个迭代来进行完成。每个迭代完成一部分任务。以主线程为中心。以价值为核心。来判定优先级。

用户故事:将所有的需求划分成一个个用户故事,如果一个用户故事的任务量太大时必须拆分成几个小故事。用户故事有史诗级用户故事和普通用户故事。史诗级用户故事就是特别打的一个任务点。必须拆分成n多个任务故事。

用户故事举例:作为xxx,我要通过xxx,进行xxx。

用户故事地图:用户故事地图就是由许多许多的用户故事及任务张贴到物理看板上之后组成的一个地图。

任务:每个故事可以拆分成多个任务。由不同人员进行认领完成。

任务划分:每个用户故事可以拆分成很多任务,常规的有:前台页面开发,接口文档设计与开发,后台逻辑开发,测试用例编写,接口自动化测试,页面测试。  数据库设计一般在开发前就以完成,不过也可以在开发时添加数据库设计任务。

燃尽图:

所有的用户故事和任务被划分工时后会形成一个燃尽图,燃尽图以一个迭代为周期。随时间推移,团队人员需要为燃尽图进行工时的增减。燃尽图可以直观的看出团队任务的完成情况。

电子看板更新:

每日立会开完后,需要跟新电子看板,将自己认领的任务拖到相应位置。一天当中完成任务后需要将任务拖到完成状态,如果阻塞需要拖到阻塞状态。完成后可以继续认领新的任务。并将物理看板上认领相应的任务,当一天结束时,如果手头的任务没有完成则需要更新剩余工作量。

 

敏捷看板:

敏捷看板有物理看板和电子看板,物理看板只能每日立会的时候可以拖动,电子看板可以随时拖动,敏捷看板可以让团队人员更加直观的看到团队的完成成果和项目进度。

看板有以下几个字段:

用户故事,todo,doing,block,done.

 

 

工具:

敏捷开发的工具网上有很多,我们用的是自己的。

需要具备的功能:

敏捷看板 电子看板及燃尽图的展示。

用户需求 将一个模块拆分成多个用户需求

用户故事 将一个用户需求拆分成多个用户故事

迭代计划 迭代计划时长,迭代完成情况统计,团队人员完成情况统计等等。

缺陷管理 当测试人员测出bug后可以提出缺陷有开发人员进行修改。

用例管理 对测试用例进行管理。

模块管理  一个项目首先划分为一个个模块

 

持续集成:一键自动化集成部署。

 

自动化测试。测试人员进行自动化的接口及页面测试。

 

代码扫描。对所有代码进行,不合规范的将会报错。

接口管理:我们使用的是本地搭建的rap2。

敏捷宣言:

个体和互动 优于 流程和工具

工作的软件 优于 详尽的文档

客户合作 优于 合作谈判

响应变化 优于 遵循计划

 

SCRUM这个框架里面包含了这几个核心的要素:

1、3个角色:SM、PO、开发团队(自然包括了我们的开发人员和QA)。

2、3个产出物:Product Backlog、Sprint Backlog、交互的可用软件工件。

3、5个活动:计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理(发生在整个SCRUM周期的任何时间)。

4、5个价值观:公开、专注、勇气、承诺、尊重。(这五个价值观尤其重要,贯穿整个敏捷开发。)

十二条准则:

12原则作为敏捷开发对于软件开发流程的指导性纲领,其实是对敏捷宣言进行了具有实际操作意义的解释。下面是敏捷宣言12原则:

我们遵循以下准则:

1、我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。

2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。

3、要不断交付可用的软件,周期从几周到几个月不等,且越短越好。

4、项目过程中,业务人员与开发人员必须在一起工作。

5、要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。

6、无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。

7、可用的软件是衡量进度的主要指标。

8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9、对技术的精益求精以及对设计的不断完善将提升敏捷性。

10、要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。

11、最佳的架构、需求和设计出自于自组织的团队。

12、团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

 

 

 

 

 

2018-07-25 16:05:16 weixin_42161283 阅读数 101
  • C语言程序设计--进阶篇教学视频

    该课程为“C语言及程序设计”系列课程中的第三部“进阶篇”。作为终结篇C语言教程,介绍了在实际应用中应用广泛的结构体数据表示和处理、利用文件进行输入输出、利用多文件组织项目开发,并结合对程序设计的进一步学习需求,概述数据结构及其选择问题和问题求解方法。以实践为主线的学习将继续,“银行储蓄系统”的开发将会迭代到第5版和第6版。

    40739 人正在学习 去看看 贺利坚

什么是敏捷开发?

敏捷开发(Agile Software Development)是一种应对快速变化的需求进行迭代、循序渐进的开发方法。
在敏捷开发中,软件项目的构建被切分成多个子项目(子任务),各个子项目的成果都经过测试,具备集成和独立可运行的特征。
敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。
团队节奏紧凑、推进迅速、调配灵活是敏捷开发的重要特性。

为什么要敏捷开发?

按传统的瀑布式开发,要求每个开发阶段都需要做到最好,最终达到最好的整体交付。这种开发方式,在初期产品经理撰写需求的阶段,已经要求尽善尽美了。
比如某些可能在后几个开发阶段才完善的细节,也是需要在产品需求文档考虑到,以保障后期开发的顺利。这种做法非常耗时,并且每个阶段的持续时间很久,单从产品需求阶段,可能长达2周到一个月时间,用来修改完善需求文档。如果需求从一开始的设定就是方向错误,到完整交付的时候才发现的话,会出现巨大的损失。因而在小型团队做某个小的想法的时候,应该优先考虑敏捷开发模式,一边开发一边复盘,以快步小跑的形式时刻保障开发进程在正确的轨道上面,以降低错误的概率。

在这里我们先来讨论的是比较流行的 Scrum。

Scrum 的工作流程,我们先要了解几个官方术语,后面再通过我之前的实践稍作补充解释:

Sprint:冲刺周期,也就是实现一个“小目标”的周期。我与团队实践的时候,把周期定为一周(5个工作日),按具体项目,有的项目需要2周时间,具体问题具体分析。
User Story:用户的外在业务需求,可以理解为故事版,用户在特定场景下的特定需求如何被满足。拿微信产品来说的话,用户的分享行为就是一个 Story,这个 Story 还可以被拆分为分享到朋友圈、分享给好友两个任务 Task。
Task:由 User Story 拆分成的具体开发任务, Task 下面还有子 Task。
Backlog:需求列表,可以看成是小目标的清单。分为 Sprint Backlog 和Product Backlog。
Daily Meeting:每天的站会,用于监控项目进度。每日早上的10分钟例会,快速回顾昨天的开发进程,和简要描述今天的开发目标,这个很有必要,让团队保持高度紧密的沟通。
Sprint Review Meeting: 冲刺评审会议,通常这个过程在测试前,拿出可供测试版本给团队成员内测并纠正显而易见的 bug。
Sprint Burn Down:冲刺燃尽图,记录当前周期的需求完成情况。
Release:开发周期完成,项目发布新的可用版本。

上面的一些官方术语,在实践过程中还是有差别的。敏捷开发是从美国传过来的方式,在中国需要更本地化一点,但基础的框架是八九不离十的。

一般来说,在项目启动之前,会由团队的产品经理(Product owner)按照需求优先级来明确出一份Product Backlog,为项目做出整体排期。这个需求文档会简明扼要地叙述这个需求的使用场景,交互方式,并且做初步的大模块拆分。表达再接下来几周的迭代周期里面希望达到的交付效果。

随后在每一个小的迭代周期里,团队会根据计划(Sprint Plan Meeting)确定本周期的 Sprint Backlog,再细化成一个个 Task,分配给团队成员,进行具体开发工作。每一天,团队成员都会进行 Daily meeting,根据情况更新自己的Task状态,整个团队更新任务列表的任务状态。

当这一周期的 Sprint backlog 全部完成,团队会进行 Spring review meeting,也就是评审会议。一切顺利的话,会发布出这一版本的Release,并且进行Sprint回顾会议(Sprint Retrospective Meeting)。

通常情况下,整个敏捷开发过程并不会很顺利。

为什么这么说?因为从敏捷开发的特性决定,Sprint Backlog 并不会详尽得面面俱到,在我们开发某小程序商城的时候,就深有体会:

第一,需求评审

当产品经理的 Sprint Backlog 下发给工程师后,工程师会对需求进行初步评审,这时候需求列表加上类似的产品例子或者市面上已有的类似开发源码,将会对开发进度有良好的促进作用。这是加强表达,降低工程师理解成本的方式。
然后产品经理与工程师们一条条需求过,并且确保工程师能对需求有80%以上的理解,以最大程度在开发过程中目标一致。
过完需求后,工程师将对已有优先级需求进行时间估算。
图片

第二,迭代节奏

我习惯将迭代周期设为一周一迭代,而开发任务则是团队讨论后决定如何在一周内尽可能多地完成需求并且发布一个版本。
将每周二设为小版本上线(bug 修复,改个文案、图片之类可以集中发布一次),周四设为本周期的一个正式版本上线(如约而至的新功能,之前团队商讨好可交付的版本)。
图片

第三,紧密沟通

每日例会,早上花上10分钟来回顾和简要说明今天的任务,有很好促进作用。但很多时候产品经理非常勤快每天穿梭在工程师中的话,也无需坚守每日例会这件事,毕竟这是以加强沟通为导向的方式而已。

第四,版本发布

对于冲刺评审会并没有很严格的要求,只要约定开发的功能具备可用性,在测试环境即可给内部同事进行预览体验,及时发现问题,然后埋头修复,再进行内测,如此重复,直到正式发布。
图片
本次分享就到这里,希望对大家有用,也欢迎大家的探讨,共同进步。

2019-09-29 19:29:51 weixin_42661815 阅读数 32
  • C语言程序设计--进阶篇教学视频

    该课程为“C语言及程序设计”系列课程中的第三部“进阶篇”。作为终结篇C语言教程,介绍了在实际应用中应用广泛的结构体数据表示和处理、利用文件进行输入输出、利用多文件组织项目开发,并结合对程序设计的进一步学习需求,概述数据结构及其选择问题和问题求解方法。以实践为主线的学习将继续,“银行储蓄系统”的开发将会迭代到第5版和第6版。

    40739 人正在学习 去看看 贺利坚

  随着敏捷开发的流行,目前越来越多的互联网公司使用“敏捷迭代”来进行项目管理了,且目前最常见的敏捷迭代都是使用“两周一迭代”的形式,那两周中的第一周都需要做些什么呢?

  第一周很多公司都会当作“开发周”,开发周各岗位都需要关心并产出什么?

  产品:通常情况下产品需要在开发周或者上一迭代测试结束前进行需求评审(具体可以根据实际项目情况确定需求评审时间),并输出最终prd文档;

  开发:拿到prd终稿后,开发需要进行开发排期计划和输出开发计划,并且在本周输出详细涉及文档、完成代码开发、自测及冒烟

  测试:拿到prd终稿后,测试与开发一样首先需要进行测试排期并输出测试计划(目前有很多公司的需求评审都成为了产品讲需求,如果存在此类问题的团队建议内部抽1-2小时内部再过一遍需求,整理出评审中存在的问题并让相关业务方进行确认。),但不同的是:测试需要在第一周产出测试用例、对组织测试用例评审,如果涉及接口,还需要整理对应的接口并输出接口用例,评审完成后提供冒烟用例给开发。

 

敏捷开发原理

阅读数 15

没有更多推荐了,返回首页