InfoQ

InfoQ

主题/标签专用视图

敏捷技术相关的内容


最新“敏捷技术”相关专题内容

特性注入:成功三部曲

主题
敏捷,
敏捷技术

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。

“敏捷技术”相关新闻

敏捷团队应对打扰的七种方法

主题
敏捷,
企业级敏捷,
敏捷技术

每个团队都必然会遇到工作被干扰的情况,如果不能合理应对,那么很可能会影响到团队的交付能力。最近,在Agile Advice网站上,Mishkin Berteig发表了一篇文章,讲述了当Scrum或者其他一些采用迭代方式的敏捷团队遇到工作被干扰的情况时,可能可以采用的七种应对方法。

专家建议:以特性团队扩展敏捷项目

主题
敏捷,
敏捷技术

敏捷专家建议缓慢地增长团队规模、超越Scrum of Scrum并且使用类似于特性团队的技巧,扩展敏捷项目。一个特性团队一次承担一个或两个特性的责任,整个团队作为整体工作于其上,直至特性完成。一旦交付特性,每个团队成员加入另外一个特性团队,从事下一个特性的开发。

“敏捷技术”相关文章

把大象放进冰箱——技术型复杂项目的特性裂解

主题
互联网,
敏捷技术

在刚刚结束的QCon杭州2011大会上,来自腾讯的高级项目经理黄志斌,进行了名为“把大象放进冰箱——技术型复杂项目的特性裂解”的演讲。特性裂解是一个能提升快速交付能力的敏捷实践。在QCon演讲上,黄志斌主要讲述了对技术型复杂项目,如何通过对业务、技术和组织的调整,实现快速交付的目的。演讲结束后,InfoQ中文站对黄志斌进行了采访。

《实例化需求》采访与书评

主题
敏捷,
交付价值,
敏捷技术

Gojko Adzic是《实例化需求》(Specification by Example)一书的作者, 在该书中他给出了一些建议和原则,帮助大家在软件开发项目中采用实例化需求去创建活文档。

“敏捷技术”相关技术演讲

Scrum doesnʼt work in China!?

主题
敏捷,
敏捷实施,
敏捷技术

演讲者分析了在不同国家实施Scrum成败的几个因素,包括经济、文化等等,最后分析出Scrum在中国是否适用。本演讲录制于Shanghai Scrum Gathering 2010。

微软研发团队的敏捷开发实践(下)

主题
故事和案例分析,
敏捷,
敏捷实施,
敏捷技术,
.NET

本视频为此演讲的第二部分,介绍了微软的质量门、用户故事、设计、测试(单元测试)、持续集成、以及如何通过各种手段保证最终产品的质量,最后介绍了在这其中的经验与教训。

“敏捷技术”相关技术访谈

陈怡斐谈敏捷中的领导力

主题
团队协作,
敏捷,
企业级敏捷,
敏捷技术,
领导能力

传统开发和敏捷开发中的领导力差别显著。陈怡斐作为经历过传统开发和敏捷开发的管理实践者,告诉我们领导力在两种模式中转变,以及组织为了支持这个转变需要做好的准备。

袁峰谈CMMI在国内企业的实践以及敏捷评价

主题
敏捷,
敏捷技术

国内CMMI领域专家袁峰在该访谈中,谈到CMMI在国内企业的应用现状,传统企业对软件的需求,并结合CMMI谈到敏捷开发方法的适用性,最后对软件团队应该采用何种开发方法给出自己的评价。

“敏捷技术”相关迷你书

看板和Scrum——相得益彰

主题
敏捷,
敏捷实施,
敏捷技术

Scrum和看板是敏捷软件开发中的两股风潮 ── 内容简单,但力量强大。它们之间有什么关系呢? 本书的目的是拨开重重迷雾,让大家明白如何在自己的环境中应用看板和Scrum,进行改进。

高效程序员的10个习惯

主题
Ruby,
敏捷技术,
.NET,
敏捷,
技术,
Java,
质量交付

本迷你书列举了成为高效的开发人员所需具备的10个习惯、思想观念和方法,涵盖了软件开发进程、编程和调试工作、开发者态度、等多个方面。本迷你书精选自《高效程序员的45个习惯》。

ThoughtWorks文集(精选版)

主题
敏捷,
故事和案例分析,
敏捷实施,
敏捷技术

本迷你书从《ThoughtWorks 文集》的13篇文章精选5篇编撰成集。这几篇文章有一个共同点:它们介绍的是一些最根本、最易施行、又最能立竿见影的敏捷实践。藉由这几篇各自独立而又相互关联的文章,我们希望帮助读者从持续集成和测试入手,建立行之有效的项目健康保障体系,并掌握必要的面向对象编程和重构技能,从而切实提升软件质量,并为更进一 步的改进打下坚实基础。

硝烟中的Scrum和XP

主题
故事和案例分析,
敏捷,
敏捷技术

在本书中,作者Henrik Kniberg讲述了他在一年的时间里,带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸(3~12人)、sprint长度(2~6星期),定义“完成”的不同方式,不同的backlog格式,各种测试策略,在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱动开发等等,还试过了把XP跟Scrum组合。