这段时间，一直在负责一个项目的管理与开发。在时间短、任务紧，而团队人员又大部分是没有经验的菜鸟的恶劣情况下，我带领接近40人的团队，终于在客户规 定的时间范围内如期交付产品。这其中，经历了需求变更、人员变动（因为其它任务，先后有近10人离开团队）等诸多问题，项目仍然取得成功了，不能不说有几 分侥幸，但此外也有一些经验与教训可以与大家分享。
- 添加新评论
- 阅读次数：
双方前锋紧紧地站在一起，裁判哨声响起，球被掷出，双方球员奋力拼搏，反复地冲刺，竭尽全力向自己的目标冲去。这是英式橄榄球中Scrum的场景。 然而这样的活动，却被Ken Schwaber和 Jeff Sutherland巧妙地借助隐喻的方式引入到敏捷项目管理中，仔细思索，却又如此的恰如其分。在橄榄球运动中，固然需要强健的体魄与迅捷的速度，但更 重要的却是组织、协作、交流，以及一位优秀的指挥官。虽然二者的方式不同，然而赢得比赛与成功交付产品的目标其实是完全一致的。
Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代、递增的软件开发过程。Scrum方法最初实践于Easel公司，现已被数十家公司数百 个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发。作为一种项目管理方法，Scrum与其它方法颇有不同之处，规则与名称也自成一套体系。 在Scrum管理活动中，包含三种不同的角色：Scrum Master，Product Owner，Team。Scrum的每一次迭代被称为Sprint，意为“冲刺”，生动形象地展现了项目开发活动的迭代过程。Scrum将功能需求称之为 Product Backlog，它们通常是由Product Owner提出。Product Backlog会在Scrum Master主持的Sprint Planning Meeting中确定，并在确定了Sprint之后，形成Sprint Backlog。Scrum非常重视团队成员的交流，除了Sprint Planning Meeting之外，还要求召开Daily Scrum Meeting，以及Sprint Review Meeting与Sprint Retrospective Meeting。
- 添加新评论
- 阅读次数：
在InfoQ发表的一篇文章《实施TDD时的常见问题》中， Chad Meyers提出了关于TDD实施的问题，如下所示：
- 我该容忍多大限度的预先设计？你怎么知道应该何时停止（也就是说，“当人们开始讨论算法，就是该测试的时机了”）？
- 对于象“我心里清楚我们需要这个”这类东西——我们该如何处理（例如，在控制台main()方法中加上一个try/catch{Console.WriteLine(ex);}？）
- 编写测试时，为了让代码编译通过，你不得不写下一两个接口，一个实体类，在类中还有一些NotImplementedExceptions等等。这一步该走多远？
- 如果在测试一个用户故事期间，你发现先前的预先设计有问题，你是会马上停下来跟你的搭档讨论，做该做的事，然后继续；还是折返回去，在当前的故事中采用完整的测试优先模式？
- 在处理一个新的用户故事时，你发现针对前一个故事所编写的测试已经不再体现需求。你是否会立刻重构那个测试，还是把它标记为“忽略”，等你完成当前的故事再回过头去处理那个被忽略的测试？还是有其它做法？
- 如果新的用户故事要求对某个已有的测试做出轻微调整，你是会调整它，还是会写一个新测试，把旧的扔掉（也就是，“不许更改现有的测试代码！”，或者“只有出现小的编译问题时才准动它，否则就别碰！”）？
- 如 果你构建了模型并且通过了测试，但是你发现这个设计很幼稚，而且即将要做的用户故事肯定会对其进行重大修改，并生成一个新的完全不同的模型。你是应该退 一步，考虑进行大型重构吗？还是应该继续修修补补，调整现有的模型，尽管这个模型最终会被目前看来显然超出该用户故事范围的工作所改进？
- 添加新评论
- 阅读次数：
我有这样的一个经验，当你拿着你的proposal去和你的客户洽谈，希望通过超强的技术拿下这个项目时，往往不能如你所愿。诚然，当你炒出一大堆概念， 例如面向对象设计、设计模式、AOP、敏捷或者SOA，客户的谈判代表往往会为你口若悬河的一番谈吐而佩服得五体投地，甚至于晕晕乎乎，但客户总能把握自 己最后的底线，“咬定青山不松口”。终究说来，要去洽谈项目，除了要看公司的实力、项目经验以及业务人员的关系之外，客户最关注的还是你的WBS和报价， 以及项目或产品的交付时间。
所以谈方法，可以让客户佩服你，却不能让客户认同你。
- 添加新评论
- 阅读次数：
在项目中，我定义了一个ThrowHelper辅助类，用于抛出项目中的自定义异常。例如定义了这样的一个异常：
{
public EmployeeException()
: base()
{ }
public EmployeeException(string message)
: base(message)
{ }
public EmployeeException(string message, Exception innerException)
: base(message, innerException)
{ }
}
- 添加新评论
- 阅读次数：
InfoQ发表的文章《给敏捷团队发奖金就像在刀尖上跳舞》令人深思，单从标题就可以看出其中的“惊心动魄”，显然我们需要高超的技艺，以及皮粗肉糙的脚底，就像某些非洲土著那样，方才能够游刃有余地舞动在刀尖之上。
确实如此，通过发奖金的形式来激励团队成员，本身就是一把双刃剑，弄得不好，可能就会破坏团结，导致彼此之间的矛盾与冲突，这对于一个团队而言是绝对致命的。然而，如果一个团队缺乏合理的激励方式，又无法调动成员的积极性。如何取舍，真是伤透脑筋。
看完这篇文章，我思索良久也没有寻求到一个好的答案。昨日阅读Larry L. Constantine的《人件集——人性化的软件开发》，才发现其实Constantine早已给出了答案，就在书中的第59章《受奖励的程序员》中。 原来，我们为什么要受限于发奖金这样一种形式呢？套用一句俗语说，“提到钱，就难免伤感情了。”要激励团队成员以及开发团队，我们还能够寻求到很好的方式。
- 添加新评论
- 阅读次数：
在敏捷开发过程中，我们还需要对系统架构进行设计吗？事实上，Martin Fowler在《Is Design Dead?》一文中已经给出了答案，那就是我们同样不能忽略对系统架构的设计。与计划性的设计（Planned Design）不同，我们需要演进式的设计（Evolutionary Design）。在敏捷开发的生命周期中，我们通过每一次迭代来丰富与更新我们的设计方案，以使其最大限度地符合客户对系统的需求。这里所指的需求，包括 功能性需求和非功能性需求。
在Agile Journal四月刊中，IBM's Methods Group的敏捷专家Scott W. Ambler详细地阐述了在敏捷语境中的架构设计方法，他提出了所谓“架构预测（Architectural Envisioning）”的方法，以应对敏捷开发中逐步演进的架构设计过程。
Scott指出，敏捷模型驱动开发（Agile Model Driven Development，AMDD）明确地包括了初始需求分析与架构建模，这个过程发生在敏捷项目开发的第0次迭代中。所谓第0次迭代，就相当于项目的热 身活动，是项目得以启动的基础。在此迭代期间，团队需要充分地理解项目的范围，甄别可行地技术策略。这个阶段所能够收集到的信息将有助于你对整个项目最初 的粗略估计，以制定合适的项目计划，从而获得启动项目的资金与足够的支持。
- 添加新评论
- 阅读次数：
张逸(Bruce Zhang)
