2008-01-03 09:51:00 mengtech 阅读数 577
  • Qt项目实战之网络电子白板

    本课程使用Qt技术实现了网络电子白板,支持直线、矩形、椭圆、三角形、涂鸦等图形元素。本课程实现的电子白板,可以在多人之间共享,每个人都可以进行任意绘制,每个人的绘制都可以同步显示在其它人的白板上。服务器端使用Qt Network开发,客户端使用Qt Network和Qt Graphics View Framework开发,数据传输使用JSON数据格式。

    11390 人正在学习 去看看 安晓辉

原文地址:http://www.infoq.com/articles/agile-kanban-boards

我把原文去粗取精了一下,保留了一些核心思想,去掉了小日本的广告.

1 任务板

任务是分解到手头的实际的工作

把要做的任务,正在做的任务和已经完成的任务,用简单的贴士贴在白板上.不同的颜色表示不同的重要程度.

可以画一些横的泳道来表明任务应该是谁来完成.

 

2 需求特性板

需求特性是软件大的功能需求,通常按照月份来进行归类.

3 敏捷开发需要把软件设计分成三个部分: 特性->用例->任务

特性: 对最终用户有意义的一个功能
用例:由特性分解而来的一个可以用来做功能测试的小情节
任务:用例分解而来,有开发人员需要完成的一个最小的工作单元

4 敏捷过程中,时间分为: 发布->迭代->每日

发布:通常一到六个月
迭代:通常一到四周
每天:

5 我们把工作和时间对应起来,就是这样

在每一个发布过程中,我们完成需求.
在每一个迭代周期中,我们实现案例
每一天,我们都要完成多个任务

6 更形象一点,我们把他们都结合起来:

你要准备三块黑板:

需求特性黑板:每一列标识一个发布需要完成的特性
案例黑板:每一列标识每一个迭代周期需要完成测试的案例
任务黑板:每一天要做的任务



Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1763113


2007-08-30 11:08:00 nuaalfm 阅读数 5706
  • Qt项目实战之网络电子白板

    本课程使用Qt技术实现了网络电子白板,支持直线、矩形、椭圆、三角形、涂鸦等图形元素。本课程实现的电子白板,可以在多人之间共享,每个人都可以进行任意绘制,每个人的绘制都可以同步显示在其它人的白板上。服务器端使用Qt Network开发,客户端使用Qt Network和Qt Graphics View Framework开发,数据传输使用JSON数据格式。

    11390 人正在学习 去看看 安晓辉

原文地址:http://www.infoq.com/articles/agile-kanban-boards

我把原文去粗取精了一下,保留了一些核心思想,去掉了小日本的广告.

1 任务板

任务是分解到手头的实际的工作

把要做的任务,正在做的任务和已经完成的任务,用简单的贴士贴在白板上.不同的颜色表示不同的重要程度.

可以画一些横的泳道来表明任务应该是谁来完成.

 

2 需求特性板

需求特性是软件大的功能需求,通常按照月份来进行归类.

3 敏捷开发需要把软件设计分成三个部分: 特性->用例->任务

特性: 对最终用户有意义的一个功能
用例:由特性分解而来的一个可以用来做功能测试的小情节
任务:用例分解而来,有开发人员需要完成的一个最小的工作单元

4 敏捷过程中,时间分为: 发布->迭代->每日

发布:通常一到六个月
迭代:通常一到四周
每天:

5 我们把工作和时间对应起来,就是这样

在每一个发布过程中,我们完成需求.
在每一个迭代周期中,我们实现案例
每一天,我们都要完成多个任务

6 更形象一点,我们把他们都结合起来:

你要准备三块黑板:

需求特性黑板:每一列标识一个发布需要完成的特性
案例黑板:每一列标识每一个迭代周期需要完成测试的案例
任务黑板:每一天要做的任务

 
2014-08-30 09:14:06 wowkk 阅读数 2926
  • Qt项目实战之网络电子白板

    本课程使用Qt技术实现了网络电子白板,支持直线、矩形、椭圆、三角形、涂鸦等图形元素。本课程实现的电子白板,可以在多人之间共享,每个人都可以进行任意绘制,每个人的绘制都可以同步显示在其它人的白板上。服务器端使用Qt Network开发,客户端使用Qt Network和Qt Graphics View Framework开发,数据传输使用JSON数据格式。

    11390 人正在学习 去看看 安晓辉

    一晃就又是一个月过去了,到了管理端,心里想的就是如何把乱七八糟的事情有序排列,让团队持续地的产出。虽说基本不用敲代码,但同时参与3个项目,感觉略累,这是一场马拉松,要么走过终点吐口气,要么走火入魔。

    经过大概一个月的准备,8月份一个正式的创业项目终于确定下来,进入开发阶段。

    该项目虽然技术难度不高,属于是垂直领域的产品,但大大的挑战还是有的。

    我们的优势:

    线下运营团队已经实战两年,并且有过万的客户量,领头大哥也有强悍的市场地推能力。

    技术成员有2个,并且熟悉该业务;具备国际视野的设计师有1个。

    我们的挑战:

    我们是学生团队。技术不够强悍,对外招聘又不现实。

    解决方案:

    我出面找有比较有能力的学生参与进来,最终项目成员有7人;一人设计,一人APP界面实现,一人APP整合,一人APP交互,一人web前端,一人java后端,而我来做架构&项目管理。

    OK,简单的前期铺垫就到这里,接下来进入本文主题,按敏捷开发宣言的路线走。

    敏捷开发宣言:

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

团队合作的最大难度不是技术,而是人。对于我们这个立马从外部拉起,立马开工的团队,敏捷开发适合我们吗?要知道,敏捷开发最重要的就是团队默契,其次是个人综合能力,最后就是专长。
在这个点上,有一个比较成熟的套路,那就是每天几分钟的站立会议,大家来交心,昨天做了什么,今天要做什么,遇到什么问题&解决思路。但这个套路我们用不了,因为我们工作时间太过自由(不是公司制度)。
一开始是这样的,我跟大家说,我们每天下午一起到机房工作如何?其它时间就自由安排。但只有3人说可以做到这样。缘由就不说了,没问题的,有时需要集结,再一起过来就行了。
敏捷开发的话,团队协作工具是为沟通&交互的。
我们技术部组建了QQ群,可以及时发布,大家测试&交流;我加了其他所有人飞信,需要集合的适合,会群发短信给大家;然后使用了worktile,进行工作分配。
worktile
 目前的主要个体交互点是这样的:设计&APP界面实现;APP整合&APP交互;web前端&java后端;我&所有人;但没有极限编程的元素。

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

我们只有简陋版的文档,用word表格画的界面,标志其关联的数据库表。


我也只通过processon.com做了简单的概念架构图等,把每个模块说明清楚,具体设计&实现就交由相关负责人(当然不是丢过去就是了~)


事实证明,我们在开发过程中,需求还是在改动的,有时是减法,有时是改进,因为能力有限,没办法预先拿出最佳方案。

可以工作的软件,不一定是整合完的,不同人不同时间做出来的模块,都是“可以工作的软件”,软件出来了,思考点马上就清晰了。当然每周任务交付,也不是那么容易实现的,我设计的第一次迭代任务,就完成不了了,所以现在的话,提早进入了大乱斗阶段,整合工作放后,增强沟通,防止战场分散得太厉害。

客户合作 胜过   合同谈判

我们是为自己开发的,当然也有客户,因为项目不是我们技术团队主导的,而是市场运作人员。但即使是内部人员,也无法在一起工作,他们经常要跑动,我们不想出宿舍。开发人员一般也不喜欢开会,所以,每周我会跟客户碰面两次,讨论进展&各种情况,回来可能会调整下载工作计划。

响应变化 胜过   遵循计划

虽说这一点是敏捷开发的好处,但谁愿意听到“变化”这两个字?需要“变化”,是谁的错?

一次完整的开发,就是一场战争,一鼓作气,再而衰,三而竭!

所以响应变化,只能出现在我这个环节。开发前要把各主要系统独立开来,在第一次迭代的过程中,就得与客户确定第二次迭代的内容,当然客户是不懂的设计迭代的内容的,所以由我来安排优先序,最不确定的,最可能改变的,就先不做。(一般是建议最重要,最简单的先做,但我会加多考虑,是否是容易变化的)。

结论

敏捷开发第一建议,团队都要坐到一起,旁边要有白板贴纸……
而这第一小步,我们就没做到了,但开发进度还是可以推动的,虽然不快,我也不知道算不算敏捷,但目前还算顺利,没什么大bug出现。
计划9月15号完成项目初期工作,9月25号发布……
2010-09-13 15:36:00 dcross 阅读数 46
  • Qt项目实战之网络电子白板

    本课程使用Qt技术实现了网络电子白板,支持直线、矩形、椭圆、三角形、涂鸦等图形元素。本课程实现的电子白板,可以在多人之间共享,每个人都可以进行任意绘制,每个人的绘制都可以同步显示在其它人的白板上。服务器端使用Qt Network开发,客户端使用Qt Network和Qt Graphics View Framework开发,数据传输使用JSON数据格式。

    11390 人正在学习 去看看 安晓辉

    软件组开始实现敏捷开发已经半年多了。虽然没有什么指导,上级也没有给予特别的支持(给了块白板),一路坎坎坷坷的过来。

    开始我还以为去推行敏捷开发会受到开发人员的抵触,因为任务的时间被卡死了,一个两天的任务如果做了四天,开发人员在开日会的时候就会不好意思。还好大家也很配合,项目组对一些延期的任务也会给予理解,也有人主动去加班来保证按时完成任务。

    从以往的瀑布式开发到敏捷开发,我估算了,大概项目的时间会减少20%左右。这些时间并不是大家加班加出来的(我最讨厌加班了),而是任务的安排根据科学了。

   比如同时有3个任务,A,B,C,A有A1,A2,A3几个小任务,B有B1,B2,B3,如果按照以往瀑布式开发,3个开发人员(x,y,z)肯定是x一人做A,y一人做B,z一人做C,最后大家整合。但经常遇见的情况是,B1可能要依赖A3,这时候y就在等待着x把A3做完,但x并不知道,他是A1->A2->A3这样做的。这样的等待就造成了资源的浪费。

    在敏捷开发中有几种解决方法:

1、让y去做A3

如果这些功能每个人都可以做(同一语言,同一架构)

2、让x先做A3

如果功能是跨项目,甚至跨语言的,A3这个任务y是做不了的,A3又是可以提出来先做的

3、没有办法?只能等待?

这就是任务的计划有问题了,是不是应该把B1放到下个sprint?

 

    当然,频繁的任务切换是有代价的,过多的切换会带来效率的低下。所以我们在一个sprint出来的时候,其实已经初步安排好了每个人的工作和计划,当然这没有任何记录,因为任务会在进行中随时变化,本来是x的某个任务最后可能是y做了,因为y把自己的工作先完成了。为了保证sprint按时完成,大家会互相帮助的。

   

    可以说,瀑布式开发就是美国片,每个人都是hero,大家都独挡一面。但是敏捷开发中的每个人都很平凡,加一起就无敌了(天罡北斗阵)。但是对于人员跳槽频繁的现在,还是天罡北斗阵安全些。

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