非功能性需求,确定非功能需求
非功能需求一般和系统的状态有关而与系统需要提供的功能无关。通常是系统的“ ilities”功能，比如可扩展性（scalability）、互操作性（interoperability）、可维护性（maintainability）、移植性（portability）、性能和安全性都包括在此类。敏捷团队经常纠结于定义和估算项目的非功能需求。 Mike Cohn建议几乎所有的非功能需求... [阅读全文]
从头再来,软件开发应该以史为鉴,还是从头再来?
作家和顾问温伯格（Gerald M. Weinberg）已在计算机行业活跃了半个多世纪，作为一些最具影响力书籍的作者，他在业内广为人知，备受尊敬。 最近，他在自己的博客“顾问的秘密（Secrets of Consulting）”上发表文章，指出大家对历史的漠不关心，创新和进步被炒作周期所包围，似乎大家都在重复以往，没有组织和个人从前一个周期中吸取教训。 他正在将之前写的书《... [阅读全文]
敏捷的反义词,敏捷和架构的冲突
英文原文：Agile and Architecture Conflict 实施敏捷方法和设计企业架构之间总是存在某种冲突。敏捷开发强调随着对业务领域的深入理解，逐步调整设计和计划。架构设计则要求建立起技术架构（technology stack）。它可以满足质量属性（quality attributes），也可以向感兴趣的利益关系人进行展示，作为一种沟通的途径。当使用敏捷方法来引领所需的架构设计的时... [阅读全文]
tdd敏捷开发,测试驱动开发（TDD）跟敏捷开发有冲突
本文是从 TDD leads to an architectural meltdown around iteration three 这篇文章翻译而来。 这些话来自于我们的软件领袖Jim Coplien——上世纪九十年代最流行的几本C++著作的作者。原话是这样的： 严格的按照YAGNI原则的驱动测试开发(TDD)会导致敏捷开发3次迭代结构的坍塌。 看到反TDD运动已经形... [阅读全文]
教育理论与实践,持续集成理论和实践的新进展
最近雷镇同学将Martin Fowler先生的著名论文《持续集成》第二版翻译成中文并发布出来，掀起了国内对于持续集成理论和实践讨论的新的高潮。笔者在本文中将全面对比持续集成论文前后两版的异同，分析并展示ThoughtWorks在持续集成领域的理论和实践方面的研究成果，以图对国内企业实施持续集成起到参考和借鉴作用。需要说明的是，本文所介绍的内容毕竟限于笔者的水平，并且主要是ThoughtWorks内... [阅读全文]
自组织与他组织,快乐与自组织团队
快乐会影响自组织团队的结果么——积极抑或是消极的？近日，Mark Levison与大家分享了其在心理学方面的一些研究成果，表明选择与控制是可以互换的。他在名为It’s All About Control的文章中说到： 拥有对其他人的控制权以及自身具有多种选择这两点实际上都建立在相同的基础之上，那就是控制，这个观点来自于Psychological Science... [阅读全文]
如何构建敏捷城市,在敏捷世界中构建软件平台的五项首要挑战
引子 过去十年间，敏捷软件开发赢得了大好发展局面，被众多不同规模组织采用[1]。敏捷方法宣扬一整套价值观，并且提出了一系列实践活动去帮助获得并维护这些价值。尽管从一开始，敏捷方法常以提升作为工作单元的小团队的效率为中心，但最近有趋势将敏捷方法拓展到企业层面[3]。然而，在企业层面会产生新的问题，可能需要重新考虑敏捷软件开发的某些价值观与实践活动。构建软件平台来实现企业范围重用策略，是主要问题之一... [阅读全文]
敏捷软件开发,由外而内看敏捷软件开发(上)——从业务视角看敏捷
敏捷很火，也让人迷惑 敏捷软件开发方法受到越来越多的关注。图（一）是来自Google 趋势的数据，它反映了近年来Scrum（敏捷开发方法的典型代表）和 CMMI（传统开发方法的典型代表）的相对搜索量变化趋势比较。在2004年CMMI的搜索量还是Scrum 的接近3倍，2007年Scrum的搜索量第一次超过CMMI。时至今日，Scrum的搜索量已超过CMMI三倍。 图1 Scrum 和 CMMI相... [阅读全文]
固定资产更新决策,架构决策作为可复用设计资产
本文最初发表在IEEE软件杂志，现在由 InfoQ & IEEE 计算机协会为您呈现。 软件架构师在设计时需要作出很多决策。作出正确的关键架构决策，其重要性不言自明。1-3但是，要总结出什么是关键决策绝非易事，更不用说何时以及如何作这样的决策。早先，架构决策作为设计决策的一部分已被定性为做起来很难4，改起来又费劲。5为了澄清这些问题，我们在下面给出的架构决策定义中增加了一些条件逻辑6： 架构决策要... [阅读全文]
持续部署：说起来容易做起来难
JJim Bird指出，人们在谈到持续部署时，说得最多的是一些琐碎的修改，例如小的调整、表面改动或小缺陷的修复。任何大于这些的修改都需要遵循相应细致、严谨的方法。 Jim认为， 数据库模式（Schema）不能一直在变。较大的功能不能、也不应该一直改变，即使是在进行摸黑启动（dark launching）。以Etsy的做法为例（Etsy是典型的应用持续部署的公司），它不会持续部署一些较大的公共模块。... [阅读全文]
持续集成,持续集成之"依赖管理
在前文《分支策略(续)》中，我们讨论了多组件应用程序的持续集成策略，即：为相对独立的组件创建自己专属的代码库，然后通过现代持续集成工具进行组件间的持续集成。Joe的团队在首次发布之后，开始使用这种方式。然而，没有多久，他们就遇到了一个问题：一次提交构建所花费的时间太长。 一天，Joe就早早地来到了办公室。因为他前一天下班前，他开发的用户故事还有一小点就完事儿了。他想利用早上这点儿时间把它搞完，交给... [阅读全文]
敏捷项目管理,Phil Abernathy谈敏捷项目治理和Suncop的敏捷转型
InfoQ的Shane Hastie有机会采访Philip Abernathy，请他谈谈在澳大利亚Suncorp公司内实施组织级敏捷转型的经验。Phil是该公司敏捷转型核心团队的关键成员，领导了这家员工超过20000人，其中IT员工超过4000人的金融机构实施敏捷转型。敏捷方法已成为“我们做事的方式”，并给公司带来数百万美元的收益、同时大大降低了新产品投放市场的时间。在如此... [阅读全文]
人格类型,是否存在敏捷人格类型?
在学术界和从业界只有很少一些关于“人格类型对敏捷团队之影响”的研究。大量的评论人士针对“是否存在敏捷人格类型”这一疑问提出了不同的问题。最常见的答案似乎是“依情况而定”，但是似乎存在一些关键的人格，与敏捷方法有着一定的关系。 三月，《敏捷学报（Agile Journal）》刊发了一篇由Mario Moreira撰写的题为&ld... [阅读全文]
scrum,Scrum之成败——从自身案例说起
从07年中初次接触Scrum的概念到其中几年项目中逐渐实践CI、TDD，到亲自掌握项目实践Scrum近一年，最终我们放弃了Scrum这个框架和所谓的“自组织”。原因为何？ 1. 成员放弃了Scrum所“赋予”的“权利” 比如领用任务、评估工作量、自组织协作、决策等。在第一次Scrum计划会议上排出任务让大家领用时，成员的态度可... [阅读全文]
fredted,Fred George访谈录：关于敏捷开发的精彩见解
关注敏捷开发领域的程序员，对Fred George并不陌生，他是有近40年经验的国际敏捷领域大师级专家、咨询师、架构师。2011年3月中旬，他再次来华访问。值此良机，记者采访了Fred George，让我们一起分享他关于敏捷开发的精彩见解。 记者：很多人为了编写易变更的代码，在采用敏捷时，抛弃许多习惯用法，由你的经验出发，这样做是否属于重造轮子? Fred George：这一行为实际是从传统编... [阅读全文]
不和谐的烈焰,反馈、无反馈、不和谐的反馈
反馈在敏捷开发中的重要性是首屈一指的。从单元测试，持续集成，每日站立会议，回顾会议直到sprint结束时候的演示，它在敏捷方法中无处不在。那么除了这些以外，是不是还有一些不完整的反馈循环呢？ 参考Peter F Drucker的论点，Jurgen Apello认为没有反馈甚至比有反馈更加重要。 Peter F. Drucker曾经写道：比你的客户更加重要的是那些还不是你客户的人。为什么他们不是你的... [阅读全文]
明朝的那些事儿,敏捷测试的那些事儿
敏捷社区的一些成员探讨了几种表述何如进行用户故事的验收测试的技术，以及测试整个主题的方法。 Charles Bradley介绍了几种不同的描述如何进行用户故事验收测试的方法： 列举要点(Bullet points) 在一个用户故事卡片或者wiki上，以列举要点的形式，把对系统行为的期望结果和实际结果记录下来。这种技术适用于较小的或者简单的用户故事。 测试场景/数据…&hellip... [阅读全文]
devops,DevOps不是个技术问题,而是个业务问题
当然，DevOps不乏反对者。反对意见不一而足，有人认为DevOps是个误导（DevOps只是系统管理的一个新名字而已，新瓶装老酒），有人对DevOps不屑一顾（DevOps只是一些疯狂开发者的疯狂想法，他们想摆脱运维人员，或者，DevOps只是一些疯狂运维人员的疯狂想法，他们想像开发者一样工作），甚至有人公开抨击（可惜的很，他们的言论往往毫无逻辑）。 在过去的九个多月时间里，我在公共论坛和客户公... [阅读全文]
不能让你一个人去战斗：单一产品负责人模式的改进之道
产品负责人可以说是Scrum里面要求最高的角色之一了。他需要一个人独立地对项目成败负责，他得帮助团队理解产品愿景，并引领项目开发。产品负责人还被要求帮助团队产出最大的商业价值。这对单个角色来说，是不是要求太多了呢？ Maroko Taipale给出了一些理由，证明单一产品负责人模式已经行不通了。Maroko认为，严格按照产品负责人的定义来实施项目，带来的必然是各方面的低效。 他建议，与其千斤重担一... [阅读全文]
切分音,如何切分用户故事
在把用户故事切分成小块，从而更好地利用敏捷技术时，很多新组建的敏捷团队都会遇到困难。 敏捷社区的成员在多篇文章中为如何有效地切分用户故事提供了指导。 当把庞大的用户故事切分成小块时，是否有一些一般的准则供我们遵循呢？ Rachel Davies建议对每个用户故事都要进行切分，从而让产出的软件： 能够工作 交付价值 能有效地得到用户的反馈 Richard Lawrence提供了以下技术，他认为在... [阅读全文]
盲目自信,敏捷与盲目自信
盲目自信常常源于一厢情愿的想法。它是一个状态，这个状态表现为，预期与现实可能相差很大，然而在一个特定的时间段内它却又给人一种一切尽在掌控之中的感觉。敏捷开发中有很多这样的情况，这导致一个团队即使在每况愈下时，也要坚持那些盲目的自信。 Mike Griffiths引用了Malcom Gladwell在盲目自信的高低程度与信息化呈现水平相关中的一段话，是一个关于精神科医生展示有关病人信息的... [阅读全文]
及时反馈的重要性,敏捷反馈循环的重要性
敏捷社区的一些成员强调了反馈循环对于提高敏捷开发流程效力方面的重要性。 “反馈循环”是什么呢？简单来说，如果某个流程的执行结果可以影响到此流程未来的运作方式，那么它就存在反馈循环。 在敏捷开发流程中存在哪些类型的反馈循环呢？在Henrik Kniberg和Mattias Skarin的著作《看板与Scrum：把两者发挥到极致》（Kanban and Scrum: Makin... [阅读全文]
龙之谷敏捷和致命,再谈敏捷和架构
对于敏捷前面谈的很多，其核心仍然是短周期迭代交付，可视化，自适应调整，开放式及时沟通，所有的敏捷实践基本都是围绕这些核心展开，如果再要对敏捷的核心抽象就是迭代+自适应。 周末和我一个师兄聊天，觉得在原公司实施敏捷后确实带来了很多的变化。原来可能大家都说很忙，确实是否真的很忙不清楚，原来一个任务来了来安排不下去，原来客户要的东西迟迟交付不了，或者是交付后就陷入到持续的变更。实施敏捷后这些问题都得到... [阅读全文]
持续集成,持续集成之"分支策略 （续）
在前文中，咱们谈到生命周期长短不同的两种分支策略。对于不超过二十人的小团队来说，推荐使用短生命周期的分支策略。Joe的团队在首次发布之前，也一直使用这种方式。然而，首次发布之后，因市场反响非常好，公司决定加大开发投入，希望更快地推出升级平台，以及更多基于平台的游戏。 一、按特性分支的持续集成策略 现在，Joe的团队中，开发人员快速增加，已接近30人了。由于首次发布后的市场压力，大家一直在赶进度，... [阅读全文]
持续集成,持续集成之"分支策略
现代版本控制系统（SCM）的作用已不仅仅是保存历史版本，它还是各软件开发组织利用其分支功能实现多人并行开发，提高生产效率的一种工具。对于稍有历史的软件产品来说，一般都会有代码分支的出现，也常常见到一些历史悠久的产品其错综复杂的分支版本树甚至将产品交付团队拖入“无尽维护”的泥潭。分支的目的是希望“分而治之”，而持续集成的目的是“频繁集成&r... [阅读全文]
面向对象编程,面向对象编程已死?
本文是从 Object Oriented Programming is Dead 这篇文章翻译而来。 那好吧，也许是没死，但卡内基.梅隆大学的Robert Harper教授却说(Teaching FP to freshmen)面向对象编程和设计“不适合做为现代计算机科学教学课程”，详细的内容引用如下： “面向对象编程应该完全的从基础课程中删除掉，因为它既是反... [阅读全文]
tfs安装,TFS 安装与管理
整了几天TFS，把相关的一些配置与安装的要点简单记下，希望对大家有用。本篇主要是安装与配置上的内容，下一篇会介绍如何使用以及使用方面的相关心得体会。 本篇内容简要： 1. 安装部署 1.1. 流程 1.2. 安装操作系统 服务器建议2G以上内存，500G硬盘空间。 必须是windows 2003、windows2008。 1.3. 配置操作系统 更改计算机名称。 安装IIS。 ... [阅读全文]
分段划分原则,持续集成之"测试三角形与分段构建策略原则
在《戏说Checkin Dance》一文 中，咱们说到：Joe?的团队实施了带有令牌的持续集成提交流程纪律。由于每个人都做本地构建进行验证后再提交，所以持续集成平台上的构建结果比较稳定，每天持续集成服务器上的构建最多只有 一两次失败(常见的原因是忘记提交某个文件而导致失败，和因本地环境配置与平台环境配置不一致而导致失败)，但一般都能在30分钟内修复。随着项目的进 行，新功能不断地增加，自动化测试用... [阅读全文]
番茄工作法：试试看?
Mark Needham是来自于ThoughtWorks的一名软件开发者与咨询师，热衷于软件开发、测试及面向对象的系统设计。在实践了番茄工作法一段时间后，向各位读者展示了其在实践过程中的收获以及遇到的各种问题。目前国内实践番茄工作法的开发者已呈日益上升的趋势，希望Mark Needham的实践能给广大希望学习番茄工作法的开发者带来一定的帮助。 Mark Needham在两年前知道了番茄工作法，从那... [阅读全文]
scrum,为控制Scrum成本而追踪时间?
Kevin Krac有一个问题，是关于在Scrum中追踪完成任务所需时间的： 当开发人员A把自己的任务搁置一段时间（也许是一整天，甚至两天），以帮助另一位开发人员B对其任务做分析或者编码……他们应该如何说明那个故事/任务的‘实际工作量’呢？ 应该把总时间摊在他们一起做的那个故事/任务上，并乘以2吗（因为他们是两个人）？还是只记录花费的总时间，并算... [阅读全文]
