2011-10-27 08:58:52 VipWangJian 阅读数 91
  • C语言程序设计--进阶篇教学视频

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

    40847 人正在学习 去看看 贺利坚
迭代评估会议。

对本次迭代做一个评估和总结,及时吸取经验教训,同时增强团队信心和提高团队效率。

迭代回顾会议。

通常是在迭代结束时侯,召集项目团队成员,每人发不同颜色的几种便签纸(比如红、

黄、绿),分别独立写下本次迭代做得好的,存在的问题,改进的建议,然后归类汇总每个人

的意见,通过全体成员投票选择最需要下个迭代改进的几个点,并在下个迭代中落实,从而达

到改进的目的。

同传统的迭代总结不一样,迭代回顾会议更多的是全体成员都参与发表自己的看法,寻找改

进,而传统的阶段总结会议更象是一个总结报告会。

RCA根因分析(可选)。

建议将SDV测试发现的问题做一次RCA分析,还应该考虑RCA和遗留问题如何在后续迭代开

发中改进和避免。
2011-10-26 10:45:11 VipWangJian 阅读数 201
  • C语言程序设计--进阶篇教学视频

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

    40847 人正在学习 去看看 贺利坚
2、迭代计划会议
重新讨论、确定本次迭代需要实现的Story,达成共同理解;
若有必要的话,则继续细化Story;
对Story进行优先级排序;
开发、测试、资料人员认领任务,估计工作量并做出承诺,这是敏捷的重要实践之一:开发团队决定承诺完成工作量的多少,而不是由SE或项目PL安排工作量。
共同制定本次迭代的迭代开发计划。要输出针对本次迭代的详细的开发计划,开发、测试、资料是以Story为单位的,所以迭代开发计划也是以Story为核心的。计划中要包括本次迭代要开发的每个Story的开发人员是谁?测试人员是谁?什么时候开始?什么结束?谁来Review?等等。


优秀实践:
明确任务责任人(包括开发、测试、资料)和任务完成时间点;
任务和问题都可作为跟踪项进行跟踪;
计划中根据Story优先级和依赖关系,严格按Story驱动制定计划,尽量减少Story并行开发;
2011-06-12 07:45:00 zhangweia 阅读数 7478
  • C语言程序设计--进阶篇教学视频

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

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

      敏捷是一柄双刃剑,用的好能极大的提升开发效率,适应需求的变化!用的不好则会导致项目的混乱。现在很多公司都说自己在用敏捷开发,很多程序员也说自己懂敏捷开发!简单的认为敏捷就是站立会议,就是迭代的开发,到最后敏捷变成了混乱,然后开始说敏捷的不好等等。其实他们都只是表面上的敏捷,而没有真正的理解敏捷的含义。敏捷做为一种新的编程方法论,是有他一套完成的方法学的。

      敏捷开发提倡迭代开发,小版本的发布和测试,首先我们来看看迭代的开发流程和附加要求,然后我们对怎样做好每个流程就行详细的设计。

image

因为敏捷开发提倡一个迭代80%以上的时间都在编程,几乎没有设计的阶段,因为我们必须保证我们的代码的质量。因此在整个迭代过程中我们要持续做到以下几个方面:

image

2016-04-19 00:03:23 lilin9105 阅读数 2927
  • C语言程序设计--进阶篇教学视频

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

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

敏捷开发迭代会议,主要是挑出产品设计和功能问题,保证迭代版本的产品原型完整性、正确性、合理性。如果产品大致功能没有多大问题,留下些小问题,那么可以进行项目拆分、工时估算。(一个细节要提醒的,产品必须在迭代会议之前,把原型提前2-3天交给相关人员,开发人员可以在会议上提出交互细节的问题、竞品分析)

迭代会议一般 14-18点   或 15-17.30;前半场PM主导,讲解原型,Team提出疑问、细节问题;后半场 SM主导APP团队拆分项目,引导团队成员进行工时估算。



--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

PO或PM场

会议流程

一、PO或SM 公开迭代时间表

二、PO 讲述 Product Backlog,对应的业务价值和优先级

注意点:

1、有些功能程序员同事觉得多余 、或没必要做的;PO或PM要特别交代 业务价值。 

         2、相关业务也要对接其他部门、 或公司资源(如分享账号)、支付宝 微信交易的公司账号 或第三方银 行的要交代跟谁对接

三、团队针对Sprint Backlog和优先级达成一致

注意点:

1、开发时候优先完成主要模块功能点再完成交互细节

        2、在提前两到三天,Team拿到 原型后对产品没交代明白的流程、

交互细节做竞品分析记录, 会中向PM或PO提出讨论明确细节

四、Scrum Master和团队成员共同确定Sprint Backlog

1、基本上产品设计都要做,只是一些特别的因"外部原因"、"资源不确定"不做要记下

参与成员

Scrum Master :敏捷教练或懂敏捷开发的项目组长

PM 或PO:产品经理

Team(开发人员或项目实施人员): 前端、后台、app组、测试、UI美工


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

SM引导Team场(有两种方式)

一种前面提到如果产品提前3天给了,这三天里面不确定因素已经跟产品确认了。这种情况下可以让team  app开发组来进行模块的故事讲解拆分(迭代拆分)

一种因为team缺少拆分经验、对故事讲解不熟悉,产品给的时间较短,那么这时候就要  SM去主导全程进行结合技术进行模块的故事讲解、拆分;引导队员完成项目评估任务

会议流程

1、团队成员针对Sprint Backlog共同分解任务;

2、团队成员共同进行工作量评估 (每个Task不超过2天),确定开始时间和完成时间;

3、团队成员共同认领任务;

4、共同确定DoD,团队达成一致;(DoD  Definition of Done 完成的定义     )

5、团队共同确认迭代目标和价值;

参与人员

一、Scrum Master

1、组织讲解拆分细节      

       2、让组员认领任务

3、与组员之一共同评估时间(一般安队员能力 评估为准)                                        

        4、记录Sprint Backlog  拆分的任务与时间

        5、考虑能力及业务熟悉度   优先制定重要的任务

       给能力强的或熟悉的人, 将简单的任务分给新人或较薄弱的人

二、团队成员

1、前端和后台组、UI组、测试组 可团队内部组织分工。  

       2、后台分工完成后将分工表发至 交流群,并且接口文档上各个接口 标明谁负责

        3、美工明确出图时间、与切图时间;  明确出图的规格:分辨率

三、其他人员选择性参加

1、对接公司账号中心对接人

2、资源对接人(明确资源到位时间)



--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

PS:DoD表示没明白到底是什么意思,如果是成功标准或完成标准那么可以这么几个阶段


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

以下Dod时间是以18天-21天的迭代

一、后台:(迭代会议前 1个星期就已经介入后台设计及功能开发,评审完后出接口文档)

在原型评审前,后台就提前一周或两周介入;

迭代会议评审完之后的两天后出接口文档进行接口文档给app,app在拿到接口文档后当天或第二天进行接口评审

1、接口是否规范

2、key是否统一、接口设计是否规范

3、一般一个界面初始化的接口不会超过两个

4、更高的安全性、快捷性相关设计是否到位token还是 session;)

接口确认阶段差不多占用4天时间,这个添加了一些不稳定因素


·测试:(项目评估完后,测试3天内熟悉原型、跟进反馈上一个迭代版本问题)

1、测试接口是否畅通

2、是否按接口文档输出数据

3、json格式是否错误

4、关于一些增删改查是否完整等等(这块我应该理解不到位)


ui:(项目评估完7-10内出完UI及ios切图及android大部分切图 )

差不多按照迭代提前一个星期出ios  UI     2X,时间 不够的  android先用这套 (ios&安卓设计标准规范)

android现在基本上用1080 * 1920p 切图了,不知道ios 1080*1920的用,看上面文章应该不能通用;

app:(平均每人5-8天工作日的开发时间,项目的后一半时间,根据接口继续完善逻辑、及接口问题跟踪解决;需要留给测试一半时间测试app)

按照优先级完成任务;没有评估时间内没有完成那么个人留下加班,比较棘手问题那么团队成员有时间的帮助解决棘手问题,保证项目进度正常完成。

2015-01-15 14:43:33 mvpyao 阅读数 5404
  • C语言程序设计--进阶篇教学视频

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

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

现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解;所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助。

 什么是敏捷开发?

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发;

 

为什么说是以人为核心?

我们大部分人都学过瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

 

什么是迭代?

迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

 

关于Scrum和XP

前面说了敏捷它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

 

什么是Scrum?

Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程,运用该流程,你就能看到你团队高效的工作。

 

【Scrum开发流程中的三大角色】

产品负责人(Product Owner)

主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

 

流程管理员(Scrum Master)

主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

 

开发团队(Scrum Team)

主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

 

 

Scrum流程图

 

//------------------------

下面,我们开始讲具体实施流程,但是在讲之前,我还要对一个英文单词进行讲解。

什么是Sprint?

Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint。

 

如何进行Scrum开发?

1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;

2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;

3、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

4、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);

6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

7、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

8、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

 

 

下面是运用Scrum开发流程中的一些场景图:

上图是一个 Product Backlog 的示例。

 

上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。



任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。


 

每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)

 

 

 上图可不是扑克牌,它是计划纸牌,它的作用是防止项目在开发过程中,被某些人所领导。

怎么用的呢?比如A程序员开发一个功能,需要5个小时,B程序员认为只需要半小时,那他们各自取相应的牌,藏在手中,最后摊牌,如果时间差距很大,那么A和B就可以讨论A为什么要5个小时...

 最后呢给大家推荐一本书:硝烟中的scrum和xp

敏捷开发的4句宣言

个体与交互 胜过 过程与工具

可以工作的软件 胜过 面面俱到的文挡

客户协作 胜过 合同谈判

响应变化 胜过 遵循计划

原文转自:博客园博文 http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html
没有更多推荐了,返回首页