2016-12-21 22:49:32 fanyang_1996 阅读数 622
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

实验目的:

 

l  练习面对面交流的方式进行需求获取,澄清用户需求;

l  根据用户需求建立用户故事清单,使用敏捷开发方法为用户故事建模卡片,规划优先级,估计工作量,构思迭代计划;

l  练习使用VersionOne为项目建立Scrum迭代计划(可选);

l  练习使用MockupBuilder为每个用户故事设计原型;

l  练习用户评审。

 

实验内容:

 

l 小组A首先扮演项目开发团队的角色,小组B扮演用户团队角色。B组3人根据A组开发的软件系统,构思自己的需求;A组3人通过提问交流的方式,了解清楚小组B的需求,并完成实验任务;

l A组完成迭代计划和原型设计之后,B组对对方的产出物进行评审,评判是否符合自己提出的需求;

l 角色反转,小组B扮演项目开发团队的角色,小组A作为用户团队,针对B组开发的项目进行上述实验。


实验心得:


1.      在我看来,面对面获取需求肯定可以帮助开发者澄清用户需求。因为相比于使用e-mail或者电话、短信的方式进行沟通,面对面的方式可以让我们更加具体、更加完整的了解双方的观点,可以避免很多不必要的误会。另外,无论是开发者团队,还是用户团队,往往都不止一人,面对面沟通可以最为方便地让我们在多人之间交换意见,在通过聆听别人的观点时,可以及时的提出自己的看法,或者分享出自己临时想到的新点子。

2.      在面对面获取需求时,要学会去启发、诱导用户提出新的需求,因为用户往往只有一个总的目的,比如要用这个项目去实现一个什么功能,但是对于细节方面的设定,我们开发者往往会具备更加丰富的经验。这个时候,就需要我们来提示用户,在这些细节问题上应该如何处理、如何抉择,要由我们来告诉用户,他们真正需要的是什么。有的时候用户听到我们的意见,会恍然大悟,这不仅能增进用户和开发者直接的关系,而且对于我们开发者而言,帮助用户提出合理的需求,也可以让我们自己更加简单的完成项目。

3.      我们先确定一个总的目标,对于我们组而言,就是将网页上的表格转存至本地数据库,然后我们将这个目标分布,如从网页上识别表格、选择表格中需要的内容、获取选中的内容、将获得的内容转存至本地数据库。通过这几步,就能实现我们的基本功能。然后针对用户提出的每一项需求,我们讨论决定应该在哪一步实现这个功能,及我们将同一步骤内实现的所有用户故事看作一个优先级相近的集合,集合内通过用户故事之间的依赖关系再进一步的划分优先级。工作量则主要按照我们以往编程的经验,先预设一个实现用户故事的方法,然后根据这个方法来估算它所需要的时间。

4.      VersionOne是一款集便捷与专业于一身的敏捷开发工具。我们既可以通过安装客户端来使用它,也可以直接在网页上使用它的功能。其次,它支持诸如条目拖动等操作,并且通过各类可视化视图来返回我们需要的结果,这些都为使用这个工具的人提供了很大的便捷。另外,VersionOne也是十分专业的,我们可以通过“taskboards”和“teatboards”来规划每一天的开发任务,然后我们可以通过燃尽图来查看项目推进的进度。我们还可以方面的从表格中导入用户故事,并对其进行优先级划分。这些都帮助我们更好的安排项目开发活动,大大提高了我们完成项目的效率和质量。

5.      在我看来,在编写项目之前设计原型,就好比在写作文之前编写大纲,它可以帮助我们,在逐步实现项目功能的时候,不会偏离最初的设计思想。就好比给我们项目的发展定下了一个笼统的框架,我们在这个框架内,不断完善我们的项目,实现用户提出的各个新的需求,但都不会离开我们抓取表格的根本要求,它可以帮助我们,确保项目推进的过程中,我们写出来的程序,一直围绕着基础要求的主干,在一定的范围内进行发展、优化。

6.      通过这次实验,我明白了,开发者和用户之间的关系并不像我们原先预想的那么简单,用户提出多项需求,然后开发者逐一实现。实际上,在提出需求是,开发者也扮演着十分重要的角色,由于开发者比用户更加了解项目开发的过程、更加清楚各个功能实现的难度,也有更加丰富的项目开发经验,因此我们要去主动的启发用户,提出合理的需求,这不仅可以帮助用户更好的理解他们想要的是什么,也可以帮助开发者在推进项目的过程中省去很多不必要的麻烦。


2010-08-22 17:14:19 iteye_16329 阅读数 26
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

1、敏捷项目管理分为:敏捷项目管理,敏捷需求分析,敏捷软件开发

 

2、商务分析师是用来充当现场客户角色的

 

3、商务分析师的职责:与客户交谈,了解和分析客户的需求,并将其制作成故事,代替客户验收功能测试

 

4、敏捷的核心是与人交流,所以需求问题实质是交流问题

 

5、当用户说想要什么什么,这个时候可能这个并不是客户的真正需求,商务分析师要详细的询问为什么,以挖掘出真正的需求

 

6、这时候,商务分析师进行需求分析:是否真的需要这个需求,有没有更高的解决方案,有没有简单并且低廉的方式,换一种方式是不是也能达到这种需求,这个需求有多少地方涉及到以前的软件变更

 

7、之后,既可以写用户故事,用户故事遵循如下方式:作为(系统的一个涉众),我想要(做一件事情),从而(达到一个商业价值)。如:作为一个普通用户,我希望能够用用户名密码登录,以享受个性化服务。

 

8、可测试性

 

 

 

 

2018-05-21 13:46:17 maxiao66989667 阅读数 85
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

项目:rpg游戏

功能:实现rpg游戏的普遍剧情以及模式之外,有卡池及抽卡环节,让人体会与传统rpg不一样的玩法。

团队:画师负责立绘和背景,脚本负责代码,编剧负责情节和战斗数据

开发:用rpgmaker开发游戏,建立在完整的rpg游戏制作引擎上制作可大大节省时间和精力。

一个典型的软件团队里,除了能写代码、测试代码和画图做设计的成员,还有一类角色,不做上面这些事情但也很重要,即项目经理PM。用于解决团队成员之间的交流成本的问题,并承担开发和测试搞不定的所有工作。作者还告诉我们了一系列PM的能力要求:观察、理解和快速学习能力、分析管理能力(分析重要程度和紧急程度)、一定的专业能力、自省的能力。并告诉我们PM的具体任务:带领团队行程团队的目标/远景;管理软件的具体功能的生命周期;创建并维护软件的规格说明书;代表客户和用户利益,协调并决定各种需求的优先级;分析并带领其他成员对缺陷/变更需求形成一致意见并确保实施/带领其他成员确保功能/时间/资源的合理平衡,跟踪项目进展;推动项目成员持续改进,提升士气。

2015-02-21 17:44:58 lostaway 阅读数 14734
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

原文链接:http://blog.yeyuzhen.cn/?p=264

       最近朋友打算在项目组中推广Trello的看板管理方法。由于之前自己项目组也实践过半年的Trello看板管理方法,就与他交流了使用经验。其实,去年半年的Trello使用体验还是不错的,有不少的心得。不过,没有系统的总结过,未能很好的分享出来。趁着春节大假,该补补了。

       Trello,是免费的在线多人协作看板系统。操作体验非常好,加之看板管理的理念简洁易懂,使trello是个分分钟上手的东西。

在实践Trello之前,参考了《精益开发实战——用看板管理大型项目》。结合自己的实际情况,设计了如下的Trello看板管理方案。

Trello看板管理方案

       trello.Board 表示一个项目或一些相关的项目。可以把相关的小项目组合起来放到一个Board中,Board太多管理起来很麻烦,也容易遗漏任务。我的建议是一个项目组只用一个Board,这样容易在Board中看到整个项目组的工作瓶颈,优化项目流程。

       trello.List 是任务列表。从左到右,List 组成的一个工作流,任务在列表之间转移,走完任务的生命周期。我经过多次的调整,创建了如下的List:

待定任务
    ||
    \/
未处理需求任务、未处理优化&&学习任务、未处理Bug任务
    ||
    \/
本周待处理任务
    ||
    \/
本周处理中任务
    ||
    \/
本周测试中任务
    ||
    \/
本周已完成任务
    ||
    \/
历史测试中任务
    ||
    \/
历史已完成任务

“待定任务”任务列表用来收集一些可能做也可能不做的任务,多是一些关于项目的较长远的任务。如确实需要开发,则移动到相关的下游的未处理任务列表。

“未处理需求任务”是工作需求分解后的任务,即关于实际业务的需求,一般就是领导交代下来的任务。

“未处理优化&&学习任务”,这个就是自己优化系统性能的人,以及与项目密切相关的新技术学习任务。这个列表中的任务,体现了你对自己的要求。

“未处理Bug任务”,Bug,都是伤心事,就不多说了。

“本周待处理任务”、“本周处理中任务”、“本周测试中任务”和“本周已完成任务”是周迭代的相关的4个列表。经过,多次的调整,发现以周围迭代周期是比较合适的。周一上午,花个把小时讨论并安排一周的工作。从未处理任务列表中移动任务到“本周待处理任务”列表。开发进行开发的时候,就将任务移动到“本周处理中任务”。开发完成后,将任务移动到“本周测试中任务”,进行任务相关的测试。测试完成后,将任务移动至“本周已完成任务”。测试失败,可以将任务打回到“本周处理中任务”。

“历史测试中任务”和“历史已完成任务”。其实,“历史测试中任务”本是不应该出现的分类。项目的需求验收测试需要协调外部资源,无法做到每周一迭代。每周完成任务开发后,自己只能做功能测试。本周结束,未进行验收测试的任务,就只能累积在“历史测试中任务”列表中,等待外部资源的协调。“历史已完成任务”就是已验收完成的任务。

       trello.Card 表示一个任务卡片。每个任务卡片都可以有一个简短的任务描述显示在外,只要合理的设计,任务简述就可以在卡片上显示很多的任务信息。经多次修改后,任务简述模板如下:

任务ID:“XX:20150221_任务简述”,所属系统:???”。[Milestone:v1.0][AAA:BBB]

任务ID是这个任务的标识,会出现在关于这个任务的讨论,关于这个任务的代码提交日志等等,关于这个任务的一切东西中。其中,“XX”表示任务的类型,包括:需求、优化、学习和Bug。后续的中括号对中,可以添加任务相关的属性和状态。如,任务所属里程碑“[Milestone:v1.0]”,任务完成日期“[完成日期:2015-221]”等等。

       周迭代的情况下,在周三下班的时候就要审视一下剩余的工作任务。多“加”少补,T_T。经过多周的练习,大家应该都能比较正确的估计工作量。只要每周能按时完成周迭代,总体的项目进度也不会出现大的偏差。

       由于看板是对所有成员完全开放的,所以应用看板管理时需要全体成员主动参与进来。每个人要完成属于自己的卡片的详细内容填写和卡片在不同列表中的移动。让看板尽量实时的展现项目当前的状态。至少要保证周五下班时的看板和当前项目的进展一致,使得下一周的周迭代能有正确的起点。

简化的看板方案的不足

       以上的看板管理方法可能比较适合10人以下的项目组,任务管理比较粗放,也没有可实践的流程改进方案。《精益开发实战》中描述的是40~60人左右的项目组管理方法,所以更大型的项目组看板管理可能需要如书中所述的更加系统的方法。你需要在看板管理的基础上不断迭代开发流程,找到开发流程的瓶颈,不断提高开发效率。

2010-09-07 18:39:00 nijp2004 阅读数 171
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波
每天,各工程师都有一些功能需要给测试验证,DPM都要知会大家准备,编译、制作安装包,如果没有通过验证,开发工程师修改后,需要能够马上编译,这样才能达到敏捷的要求。
 
目前我们的AutoBuild系统还只是DPM人工触发的,既然是敏捷开发,那就应该更快些,另外,老大和PM希望随时可以看到最新的版本,并且评估后给关键客户做评估。
 
基于这些需求,我们讨论,决定采用日构建+工程师自主构建+递交构建的组合方式。
 
1、日构建
还是需要从用户培养开始,在Team中达成规则,每天下午16:30(暂定)前,工程师确保只有通过验证(开发自测或QA帮助测试)的才上传到SVN的日构建分支上。AutoBuild系统于17:00运行Build活动,生成每日安装包
 
2、工程师自主构建
各工程师通过AutoBuild系统,编译自己负责的工程,编译出dll文件,并从最近递交版本中获得产品其他文件,生成安装包(这些都考虑调整AutoBuild系统来实现,当然,工程师所负责的工程要梳理下,这方面也考验了架构)
 
3、递交构建
递交构建实际上不是真正的构建,实际是把有最新功能的稳定的日构建版本,升格为递交版本,做为正式的递交版本,正式递交需要安装专门的测试任务,这样可以确保发送给客户的评估版本质量。初步定义递交每周不少于两次。
 
当然,方法归方法,能不能很好的运行,一方面看是否可以坚持规则,另外一方面也有赖于产品各模块的耦合程度了。
 
预期两天时间调整AutoBuild系统,下周应该可以尝试新的自动构建了。

互联网

阅读数 28

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