敏捷软件开发实践:概括

应朋友之邀,我准备写一组文章关于敏捷软件开发的实践,也帮助广大没有用过Agile的或者只停留在书本内容上的朋友亲临敏捷软件开发这个惊心动魄的历程。

所谓敏捷,书本上有很多的介绍,我也不想重复发明轮子了,反正就我的理解,敏捷的精髓就是面向变化,敏捷这个词语,我最早遇到是出现在玩各种游戏中,所谓的“力量型”英雄,“敏捷型”英雄,比如暗黑的亚马逊,比如魔兽世界的猎人,这种职业往往有很高的闪避,而且可攻可守,或者说三国杀里面最典型的赵云“闪杀杀闪闪,能进能退”, 对于项目,我觉得这个意思很像,因为可攻可守,面向变化,所以就算需求改变,我们需要“守”,能守得住,如果我们项目进度不足,我们可以去做一些研究,总结,代码审查之类的活来填充我们的effort,这是“攻”。

不扯远话题了,总的来说,我想说下敏捷实践中的如下话题(都是来自我们真实团队的实践):

(1)Sprint Setup Meeting

(2)Sprint Story Point Etimation

(3)Sprint Task Split

(4)Sprint Status Track

(5)Team Management

(6)Code Review Process

(7)Release Plan

(8)Sprint Retrospective Meeting

(9)Daily/Weekly Status Report

具体见后续博文

本文出自 “平行线的凝聚” 博客,请务必保留此出处http://supercharles888.blog.51cto.com/609344/1261087

时间: 2024-05-22 17:33:32

敏捷软件开发实践:概括的相关文章

敏捷软件开发实践-Sprint Status Track

介绍: 对于敏捷软件开发来说,能时刻保持跟进项目的进度是非常重要的,因为你可以随时了解团队的健康状况,并且对各种突发情况进行突发的处理,从而保证每个迭代结束后我们的项目可以按时的交付. 实现方式: 看项目进度的最好的工具当然是burndown chart,我们使用Jira做项目管理工具,Jira中有一个Report视图,可以非常直观的显示story的burn down 曲线,从而让团队直观的明白这个sprint进展的如何. 当然了,这个是从story级别的,它衡量的是随着时间的流失,story

敏捷软件开发实践-Code Review Process

介绍: 在敏捷软件开发中,从代码的产生速度上来看,要比传统Waterfall产生速度高很多.因为我们把时间安排的更加紧凑了.那么这么多的代码,如何能保证这些代码质量呢?很多人可能直接想到静态代码检测工具.没错,那些是可以定义一个代码检查规则来确保代码的质量,但是那个仅仅是从语言角度,那么逻辑是否已经最优化了?可重用性是否已经优化到极致了?这些是静态代码工具不能完成的,所以我们需要Code Review 实现方式: 对于已经在项目组很久的人来说: 虽然传统的code review就是把代码从仓库c

敏捷软件开发实践-Sprint Story Point Estimation

介绍: 对于story来说,一个很重要的衡量它的大小的因素就是story point,它不等同于软件工作量评估中的Function Point,因为story point只是用来粗略的相对的估计story的大小,而Function Point则是用来衡量功能模块的精确大小并且要参与到公式计算的,这里澄清下. story point的估算是一门很深的学问,而且我们不能马虎,因为如果我们估算少了,那么就会导致实际我们的花费时间远高于估算时间从而导致team加班加点,如果估多了,会导致我们team很闲

敏捷软件开发实践-Team Management

介绍: 对于敏捷开发团队来说,团队管理也是必不可少的,我带领的团队分2部分,1个是开发团队,一个是测试团队.开发团队,我大体上比较放心,因为毕竟已经运行1年多了,文档充足,而且技术方面也有很多资料或者现成代码可以参考,测试团队是刚组建没多久的,因为原来测试团队放在onshore那边,但是现在他们测试团队解散了,所以我们这边就组建了一个测试团队.这里共享下我管理团队的一些经验. 实现方式: 其实我也不是一个专职的团队管理者,因为我是一个纯粹做技术的人,我甚至连PMP都没有.我曾经做过专栏,我做过云

敏捷软件开发实践-Sprint Setup Meeting

介绍: 对于一个迭代周期Sprint来说,最先开始的活动并且也是最重要的活动之一就是Sprint Setup Meeting. 在这个会议上,我们主要会去探讨一些这个Sprint我们需要完成哪些story,并且这些story的具体需求是什么.其实,我们公司走的是离岸开发模式,这种模式下,我们由于和我们的客户有个时差(9小时) ,所以很难大家坐在一起然后和标准的Sprint Setup Meeting一样开始plan. 在这种模式下,我们有2种方式来实现. 实现方式: 一种实现方式是,我们offs

敏捷软件开发实践-Sprint Task Split

介绍: 在开完了Sprint Setup Meeting,并且吧所有的Story Point都合理的估算之后,下面一步就是吧story细分到每个开发者/测试者手里,让他们在story下面建sub-task. 这里最关键的问题是,如何更高效的利用团队的人力资源并且做最合理的分配. 实现方式: 这个其实都是根据skill set来的,因为大家都知道,一个团队的人的水平,经验都层次不齐,有高级/中级的工程师,有这个领域专家,有的擅长另外一个领域. 所以我们团队,去年刚建立的时候,第一件事情就是收集下每

敏捷软件开发实践-Release Process/Release Plan

介绍: 因为我们的开发周期是迭代进行的,以Sprint为单位,我们每个Sprint如何去和客户说我们的成 果呢,那么我就需要Demo和release一些新功能,或者一些bug fixing.Demo我这里不讨论了, 大体上就是部 署都服务器上然后运行下给meeting的所有人看下,我们这里主要讨论和发布(release)有关的话题. 实现方式: 话题1:我们如何让发布者知道我们这个Sprint做的功能?因为就像jdk一样,它的每次大 的release和小的release都有一些评注来说明他们这次

《系统分析与设计方法及实践》一2.2 敏捷软件开发

2.2 敏捷软件开发 在传统的软件开发方法中,工作人员努力构建客户想要的产品.他们花费大量的时间努力从客户那里获取需求,针对需求进行分析和建模,并且归纳成规格说明书.然后,评审说明书,与客户开会讨论,最后签字.表面上看他们开发的产品是符合客户的要求的,但通常事与愿违.在项目快要结束的时候,需求和范围.产品的适用性成为争论的焦点. 敏捷软件开发方法告诉我们开发项目是一个学习的体验.没有谁能完全理解所有需求之后才开始项目,即使是客户也一样.客户一开始有一些主意,但是他们也会随着项目的进展进一步了解他

Visual Studio Team Architect 团队的敏捷软件开发(第一部分)

在最近几次与客户面对面的交流中,我有幸分享了我们团队如何在日常工作中进行敏捷软件开发.毫 无疑问,这在中国开发人员中是个热门话题,我也想利用博客这个平台与更多的读者进行书面的交流.当 然关于敏捷开发利弊得失的争论有不少,而相关的开发模式也分成了TDD (Test Driven Development), Scrum, XP(eXtreme Programming)等流派.就我个人而言,一个团队是否严格遵循某种既定的敏捷方法并 不重要,但一定得选择并采用一种(或几种)最适合自己开发团队和开发项目的