金枪-鱼-CSDN博客

翻译地理上分布式敏捷开发-简介

介绍在敏捷开发联盟[1]2010年的一份问卷调查中，90%的受访者表示他们所在的团队不同程度地使用过敏捷研发方法。同一受访人群中，65%的人表示他们所在的团队是分布式，高于2009年时的57%。此外，45%的受访者表示在外包类项目上他们正在采用或者计划采用敏捷研发方法，这一数据高于2009年时的41%。很显然，分布式开发不仅仅是众多团队面临的现实状况，而且还是一个正在增长的敏捷社区。但

2013-12-05 14:31:17 1295

翻译 SpecDD系列：团队成功之道

评估个体和交互胜过评估流程和工具这一说法是有它背后的原因和意义的。流程和工具是对通用经验的提炼。随之而来的，对于一些不常见的经验，流程和工具就无法适应了。只有人可以。这就是个体和交互介入的时候了——搞清楚如何在不寻常的情况下取得进展。在面对新奇事物时，盲目遵循流程和工具，好比面对常规重复性事务时还坚持多样、辩论、谈判，和创造力一样是无意义的。Kent Beck — 敏捷工具如果决定将团队进

2013-10-08 15:39:00 868

翻译 SpecDD系列：6个确保您执行“充分”QA测试的技巧

确保团队执行“足够的”测试覆盖面是非常困难的，尤其是对敏捷开发团队来说。对于初学者而言，一个开发Sprint中要完成多少的质量保证工作才够呢？我们知道，敏捷的标准是在开发Sprint结束的时候要完成一个可交付的产品。那么这是什么意思呢？这意味着软件不能有严重的商业缺陷，不会丢失数据，不会奔溃，同时没有功能性缺陷阻碍基本功能的使用。虽然这个标准提供了一个很好的指引，但大部分敏捷团队实际中都对这个标准

2013-10-08 15:20:06 1018

翻译 SpecDD系列：“完成” 的定义

在当今充满变数和快节奏的大环境下，一个产品的上市时间已经成为产品成功与否的重要因素。如果对于“完成”没有一个清晰的定义，那么很可能会遭遇产品延期，风险，并且增加公司成本。“完成的定义”也被俗称为DoD，它是一个很有用的工具，可以用来为产品的交付定义各种条件和参数。每个组织根据不同的参数为产品勾勒出不同的DoD。产品参数可能包括团队资源，技术水平，剩余时间，客户的验收标准等，所有这些

2013-10-08 14:45:14 991

翻译 SpecDD系列：敏捷项目管理 - 简介

最近几年，科学技术急速发展。软件的复杂性和CPU处理速度也呈指数增长，而不是线性上升。这种增长率的变化导致的连锁反应，增加了市场的波动，这反过来又要求企业能够快速适应消费者的需求。行动缓慢的庞然大物被普遍认为是缺乏竞争力的，在交付新特性方面也存在更大的风险，这已经是“老生常谈”或是过时的问题了。这也为敏捷开发方法的兴起做出了贡献，例如极限编程（XP），SCRUM，功能驱动开发等。这些方法

2013-09-13 11:38:29 1765

翻译 SpecDD系列：敏捷应用生命周期管理(ALM)

由于敏捷开发正成为越来越多开发团队的标准，敏捷应用生命周期管理持续呈现增长势头。一个已经被证明了的事实，那就是很多工具供应商发现把自己的产品标识成敏捷工具甚至是敏捷ALM工具，是很管用的。然而，何谓敏捷应用生命周期管理？应用生命周期管理结合了技术因素和功能因素，为常见的项目活动（如开发，配置，部署，发布，测试，质量，集成，和需求管理）提供一个综合方案。敏捷ALM用敏捷的价值观和

2013-09-13 11:28:09 1877

翻译 SpecDD系列：敏捷项目管理原则

软件敏捷开发宣言中提出了以下12个原则：持续、尽早交付有价值的软件以满足客户，是我们优先要做的首要任务。拥抱需求变更，甚至是在开发的后期。敏捷过程利用变更为客户带来竞争优势。频繁交付可执行的软件，从几周到几个月，交付时间越短越好。在整个项目过程中，业务人员和开发人员必须每天在一起工作。激发每个团队成员的积极性来打造项目。为他们提供所需的环境与支持，并且信任他们可以完成工作。在一个开发团队内

2013-09-13 11:19:21 1356

翻译 SpecDD系列：（混合的敏捷方法模型）主要过程概述

敏捷已成为当今使用最广泛的开发方法。有趣的是，敏捷方法的流行性并不是因为它取代了其他开发方法，相反它与这些方法进行了更好地融合。现实世界众多敏捷项目的成功，也证明了敏捷将走向杂化的未来。 SpecDD是由周铁人博士创立的一个以需求为核心的混合敏捷开发方法。它基于同时支持敏捷开发和非敏捷开发流程而设计。SpecDD 过程模型在SpecDD过程中，开发过程由一组连

2013-08-30 15:40:26 1471 1

原创敏捷开发中，基于Points 的burndown

敏捷开发，很大的成功，来自于将开发的过程简单化，同时让整个团队的工作变得透明。在团队工作透明化过程中，burndown report 起了很大的作用。通过查看整个团队、某个Story或某个任务的Burndown，能很清晰的了解到工作的进展。Burndown report可以通过以下两种方式来生成基于剩余工作时间的burndown基于剩余Points的burndown基于剩余时间

2013-05-16 14:17:10 2479

原创 Sprint 过程中，如何扩展团队并与质量做整合

在和某个想上敏捷研发管理的客户交流过程中，发现客户存有一种认识，即团队的研发管理模式从传统的管理方式，迈入新的敏捷研发管理的模型，只是研发模型的变更，团队还是同一个团队。角色定义要变化么？很多时候，客户会觉得不用啊，还是原来的开发团队，还是继续做开发，只不过快速响应需求，然后开daily standup meeting就好了。这里其实存有误区。一个Agile 开发团队，常常可由开发人员、外

2013-04-22 15:38:32 861

原创敏捷开发中，需求优先还是开发优先

当一个团队采用敏捷开发后，项目负责人和管理层，会自然而然的希望团队能正确交付可执行产品的同时，也能提高交付的效率。但实际项目执行的过程中，往往遇到设计团队和开发团队互相抱怨的情况。产品负责人在计划会的时候，会向团队讲解备选的需求故事。由于客户的需求可能更多是一个想法，技术如何实现，最后的产品会用何种方式来表达，可能都还是比较模糊的。产品负责人更多关注，以客户价值导向的角度来介绍Story。

2013-02-17 15:33:57 1114

原创敏捷开发中，Product Backlog 是否足以实现需求管理？

敏捷方法指导团队将产品需求置于Product Backlog中管理，并按照优先级对每个产品需求进行必要的排列。在计划会(Planning Meeting)之前，由Product Owner从Product Backlog中挑选迭代周期准备开发的意向表（Willing List）进行总体介绍，然后分配到Sprint研发过程中。以Scrum为代表的纯敏捷方法，认为首先不需要对需求做分析，因为需求一

2013-01-11 08:59:30 11653

原创需求空间和 Word 集成的完美协作

需求空间，我们之前已经有所介绍。通过引入统一 “需求空间” 的管理，能够对用户需求、产品需求等需求项进行更细、更清晰的管理，不但提高了需求可视化，也大大增强了需求的完全可追溯性（Totally Traceability）。借助需求工作流等管理，对需求进行量化和拆分，从而更好的推动项目的整体实施。此外，借助 “需求空间”，需求项的信息也将变得更加饱满和全面，例如需求项状态、负责人、

2013-03-21 13:30:02 910

转载最高效的程序员

美国一家基础设施公司的安全审计发现，该公司的一位顶尖程序员将自己的工作外包给中国沈阳的一家软件公司。该公司为雇员提供了VPN允许他们在家里工作。内部的安全审计发现，公司明星程序员Bob的VPN登陆日志显示他固定的从中国沈阳访问公司主服务器，他们找来电信设备供应商Verizon帮助调查。调查排除了恶意程序或黑客入侵的可能性。Verizon调查人员发现，Bob雇用了沈阳的一家软件咨询公

2013-01-17 10:08:10 554

原创 SpecDD系列：SpecDD模型系列的注释

SpecDD是TechExcel公司总裁周铁人博士，结合超过20多年的研究和产品开发经验，创立并完善的一种混合的敏捷开发方法论。本人在工作中有幸参与其中，未来会不断在这里分享些 SpecDD 模型中的新探讨和交流，希望整理成 SpecDD 系列的文章；为自己积累知识的同时，也希望能和大家学习好的项目管理经验。周铁人博士TechExcel公司CEO兼首席软件架构师周铁人博士是

2013-01-08 14:45:27 883

原创混合的敏捷开发方法SpecDD模型

敏捷开发用短短十年时间发展为当今最为广泛使用的开发方法，其原因在于它简单且有效地提高了开发团队的生产率。敏捷方法指导团队将产品需求置于Product Backlog中管理，并按照优先级对每个产品需求进行必要的排列；通过计划会(Planning Meeting)、Daily Standard Up Meeting(每日立会)、ProjectReview Meeting(评审会)等，从Produc

2013-01-08 14:35:13 2291

原创软件配置管理与CMM/CMMI-三库管理

随着企业业务发展，产品线也变得越来越丰富。新产品的研发，可能由于周期短，有时直接快速组建一个新的项目组，大家热火朝天，技术攻关很快就把产品研发出来了。很多的设计点子，产品架构，技术攻关等通过高效的线下沟通，反倒推动了产品更快的问世。但常常这些讨论过程所产生的“智慧”，也很容易被项目组所遗忘；产品完成后，项目组也就随之解散。未来，当企业需要对已有的产品线进行维护升级，从而更好地赢得市场的时候，往往会

2012-08-30 09:08:00 15348

原创开始自己的小博客

毕业后，几年间一直忙于岗位工作上的技术任务，每当自己解答一个技术问题后，心里总有丝丝的兴奋感。也不曾想过专门找时间，把这些整理成日志类的文档放到网上。一来觉得工作时间匆忙（其实还是有点懒导致的 ^_^）；二来觉得每天都有新技术，现在解决的问题将来是否还会有需要值得重新翻回查看，也不见得。因此就这么一直拖着，耗着，也没想专门弄个自己的博客，和大家交流。但今天处理了一个有关 Perforce 集成

2012-05-15 17:49:23 588

金枪鱼的专栏