[转载]敏捷开发注意事项

敏捷开发,对于很多经历过梦魇般的编程项目的程序员来说,无疑是是一件极好的事情。

敏捷开发过程中很难避免Bug的产生,因为做的东西比较快,Bug量会比传统模式开发的高,但是经过最后几个周期下来以后,质量是可以得到控制的。

敏捷开发过程中至少有几个要素值得注意。

首先就是要控制团队成员规模,人不能太多,最多不宜超过10个。超过10个以上项目经理核查难度就会加大,因为每个人做什么根本就搞不清楚,每天有个短会,如果人太多每人讲三分钟半小时就过去了,已经失去敏捷开发的意义了。3~6个成员是比较合适的,可以最大程度上掌控进度并随时调整的。在团队规模比较小的情况下,成员分工也相对灵活。

  此外,要真正保证产品交付,还需要确定每个Sprint。Sprint就是一个周期,每个Sprint周期一般是4到6个星期,实在要短也不能少于3个星期。Sprint在开始的时候,可能花半天左右做一个Sprint的计划,比如分4个星期,这4个星期里面能够完成什么。

时间: 2024-11-11 21:42:46

[转载]敏捷开发注意事项的相关文章

创业公司如何实施敏捷开发(转载)

转载自LANCEYAN.COM 说起敏捷开发,并不是因为敏捷而敏捷.这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式. 大家都知道,创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品,不过大部分创业公司没有那么容易一下就能做出来,很多公司还没有成功的产品资金链就断掉了,公司也死掉了.我们公司是这样一个状况,有一条产品线可以维持公司开支并仅仅刚够盈余,要扩大高速发展还不够,一直维持就

敏捷开发之站立会议注意事项!

敏捷开发-站立会议要点: 1.站立会议全员都需要参与: 2.当值员必须提前准备,识别出问题和风险,做好协调: 3.每个组员汇报进展和当天的计划.对于承诺的任务,需要完全执行: 4.每日站会实践不能超过15分钟: 5.三段论:昨天完成什么,今天计划做什么,困难: 6.成员之间信息共享,每个组员都能了解项目总体进展: 7.不要陷于技术细节的讨论,当值人员应该记录下所有的阻碍并跟踪: 8.把每个问题用跟踪卡片(或在JIRA)跟踪起来.

谈谈我理解的敏捷开发--转载

"敏捷开发" 几乎成了互联网家户喻晓的一个热门话题.每个人都在聊敏捷.Scrum.XP. 我对"敏捷"的认识还算是在一个正在探索的阶段.网上有非常多的资料,五花八门,对于初学者来说无形之中会设了很多的坎.刚好借此机会写个文章帮助自己进行知识的梳理和总结,另外一方面也希望对刚接触的人有所帮助. "敏捷开发" 知多少? 敏捷开发(Agile Development)是一种以人为核心.迭代.循序渐进的开发方式. 它并不是一门技术,而是一种开发方式,也就

Project Management: 敏捷开发纵横谈

摘要:在IT界中,“敏捷”是一个很酷的词汇,“敏捷”的相关理论可谓铺天盖地.“敏捷”一词实质没有统一定义,各家有自家的说法,本教程将让你了解“敏捷”的来龙去脉,抓住“敏捷”本质,并能在工作中实践“敏捷”. 特别声明:如需转载此文,请给出指向本网站的连接,如下:作者:张传波摘自:http://www.umlonline.cn如不能按此要求,请不要转载此文. 大纲:“敏捷”陷阱为什么会有“敏捷”这个说法?极限编程敏捷开发RUP敏捷开发的实质是什么?如何才能敏捷起来? 正文: “敏捷”陷阱 小甲想到某

互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么?

作者:暗灭 第一   为什么需要敏捷开发. 在几万年以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多,测试了半年多,修改Bug用了半年多.总计花了很长很长的时间,然后上线后发现有很多需求已经不存在了,同时又出现了很多新的需求. 怎么办?继续改.这一改又是半年多的时间过去了.马丹用户的需求还再改,怎么办? 这是困扰软件开发项目的最大的问题,越大的项目,参与的人越多,风险越大.文档越规范,维护起来的难度就越高,导致项目中遇到的问题越来越多.

实验三 敏捷开发与XP实践

实验步骤 (一)了解敏捷开发与XP 敏捷开发(Agile Development)是一种以人为核心.迭代.循序渐进的开发方法. 一项实践在XP环境中成功使用的依据通过XP的法则呈现,包括:快速反馈.假设简单性.递增更改.提倡更改.优质工作. (二)编码标准 Eclipse菜单下的source->Format可以按Eclipse规定的规范缩进 为了更加有层次感和规范性,根据代码逻辑加入一些空行 (三)结对编程 了解结对编程的重要实践意义,并和杨凤完成扫雷的实验 杨凤负责徐龙负责代码的课题选择以及代

我和敏捷开发的故事--敏捷角色PO

在前面的三篇文章中对敏捷开发进行了一个背景铺垫,是以笔者个人的经历为主线来逐渐从个人的角度来理解敏捷开发. 通过结对编程完成了开发框架的搭建,在搭建框架的时候其实我们的正式敏捷流程还没有开始,真正开始是大家都可以行动的时候.当敏捷开始的时候整个团队定是在相关的分工下完成任务,所以不同的人有不同的角色,接下来主要对敏捷开发中的角色进行了解. 第一个要说的角色是PO 敏捷开发中的PO即ProductOwner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑.流程.设置等方面事宜的人员,一

关于敏捷开发的26个心得

关于敏捷开发的26个心得 我收集各式各样的至理名言.最近我一直在研究敏捷软件开发:有收获吗?下面就是能够指导敏捷软件开发团队的26条核心原则. 用例一完全能够运行后再开发用例二.厨房里有一种说法正好可以印证这个问题:"做好一盘菜后你再做下一盘". 对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务.因为不可避免的,我们设计的功能中总会有一部分会被放弃砍掉,如果提前开发,很可能做无用功. 一次只开发一个用例(或很少几个用例,这根据你的开发团队的大小而定): 让这个用例功能完整:

敏捷开发实战(三)--每日晨会,是否只是摆设?

经过上面总结的两篇博文敏捷开发实践(一)–谈谈我对敏捷开发的理解和敏捷开发实战(二)–你真的了解Scrum吗?,我们已经对Scrum进行了整体的认识和学习,这篇博文我们一起讨论和学习,我在实施敏捷的过程发现的一个问题. 问题描述 相信实施过敏捷开发的博友,每天会在同样的时间和同样的地点召开会议,此会议在Scrum五大活动中被称为每日Scrum会议. 有这样的一种现象,团队中的新成员刚开始接触Scrum时,积极性会特别高,在会议中会比较积极的发言,但是对于大部分经过长时间开发的老成员来说,经常会在