项目的故事_项目管理_非技术区_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 非技术区 > 项目管理 > 项目的故事

项目的故事

 2011/11/16 13:14:24    程序员俱乐部  我要评论(0)
  • 摘要:这是关于一个项目的故事,与其它项目相比,既不非常复杂,也不是很简单:一个应用程序与数据库以及其它两个系统通信。这在技术和架构角度都是主流,而在管理角度则是标准情况:所有工作都应该在昨天完成,但还有很多没有完成的。简而言之,“这很难!”(这是开发者经常表达的一种情绪,但是谁都不会太大声地把它喊出来。)为此我们创建了团队。雇佣了四十位员工并指定了他们的角色。我们把团队分为小组,并在不同的小组之间设置了一种契约。每个小组负责应对特定类型的要求。这样就形成了要求的流程
  • 标签:故事 项目

  这是关于一个项目的故事,与其它项目相比,既不非常复杂,也不是很简单: 一个应用程序与数据库以及其它两个系统通信。这在技术和架构角度都是主流,而在管理角度则是标准情况: 所有工作都应该在昨天完成,但还有很多没有完成的。简而言之,“这很难!” (这是开发者经常表达的一种情绪,但是谁都不会太大声地把它喊出来。)

为此我们创建了团队。雇佣了四十位员工并指定了他们的角色。我们把团队分为小组,并在不同的小组之间设置了一种契约。每个小组负责应对特定类型的要求。这样就形成了要求的流程。指定的小组会承受很大压力,并成为瓶颈: 在上游小组中会创建要求,而下游的小组会等待这些要求。对于那些有压力的小组中的要求,重要的事情会变为紧急的事情。我们必须在紧急的事情之中做出选择,以解决最亟待解决的问题。我们经常需要在任务之间切换,最终,这导致流程变得很慢。

然后发布的最终日期临近了: 就在两个月之后。用户接受测试刚刚开始,但是不同组件之间冗长而痛苦的整合过程导致了测试的延迟。可能正是在团队之间创建的契约让整合变得如此复杂: 其中缺少一些必须的参数,日期格式不合适,只有部分错误代码能够得到解释……

在任何情况下,用户接受测试都会检测出很多的bug,而开发团队来不及解决,这样就无法对系统进行彻底的测试。

因此我们增加了更多人力。我们设置专门的团队来解决bug,在另一个地方的团队会完成开发,还有一个团队会整合不同的组件。但所有这些团队共享同样的代码,对某些代码做出的改变会影响其他团队所做出的修正。

接下来我们可以预测出这样的做法导致的结果: 开发者通宵加班,周末也要工作;最终日期被一再推迟,最初的工作任务范围发生了变更(减少了内容);然而,多亏了计算机科学的奇迹,应用程序最终发布并运行了!

  这是多年以前的事儿了。我认为这是“要走的路”,并且所有项目都以相同的方式管理。从那开始,我经历了各种不同的情况,读了很多资料,并与很多人做过相关的讨论。现在我能够从不同的思想角度来看待这个故事。

  创建IT系统是一种非常复杂的机制,其中不仅混合了技术、架构技能,还有管理以及与人相关的技能。在这两个领域有多种文化,但是关于构架系统的管理和人的部分,我认为Tom De Marco是我最喜欢的作者之一。我还记得他出版的两本书。在第一篇无标题的“软件工程: 关于谁的时代来临和消失的想法”中,De Marco讨论了对软件项目的控制(的幻想)。在第二篇“放松(Slack)”中,De Marco研究了管理学中的经典问题,并说明更多的放松能够如何帮助组织具有更强的适应性,最终获得更高的效率。

  但是,带着这两篇文章中的想法,让我们回到故事中,看看如何才能避免很多典型的问题。

  没有优先级,或者是著名的“我们全都需要”

  Tom Demarco向我们展示了一种方法来避免整体上陷入困境,也就是“每项功能都非常重要”的项目:

  例如,你和团队的领导说,我时刻记着完成时间,但是我不会与你分享这个信息。当有一天我告诉你项目会在一周内完成时,你需要准备好打包,并把你所得到的东西作为最终产品发布。你的工作就是持续地为项目工作,按照相对值的顺序向其中添加内容,并在过程中持续地完成集成、编写文档以及验收测试工作。

  简言之: 工作的目的是第二天就可以发布

  如果不考虑实际的组织和技术上的问题,你需要有意识地对软件进行持续构建。团队之间的合同责任很有限,从而无法在技术上或者任务上组织它们,而只能在业务特性上做到这一点。从技术的角度,每个团队都是这样,要负责让完整的功能可以很好地运行。从管理的角度,经理和业务人员需要作出选择: 什么是必须需要的特性。根据我自己的经验,你在需要符合交付日期的环境中工作的时间越长,这种特性团队和组织就会对你起到更大的帮助。

  管理压力和恐惧文化

  我们在这里还要看看De Marco关于恐惧文化和它的特征是怎么说的:

  “……在具有恐惧文化的组织中,会具有如下特征:

  • 说特定的问题是不安全的(例如,我很怀疑是否能够达到这个限额)。
  • 目标设定得非常高,看起来没有完成的可能。
  • 允许权利超越一般的常识……”

  当我想到恐惧管理的时候,就会想象到一种专横的身体语言,他会在位置上对协作者大喊大叫,会用拳头敲桌子……这是非常具有讽刺意义的样子。这看起来像是在背后说人坏话,但是我们不得不承认,人们经常会处于这样的压力之下,难于提出警告,设定截止日期而不考虑团队是否能够承受,最终,团队会处于经理根据他们自己的地位所做出的提交压力之下。

  当然,了解问题只是第一步。我们怎么才能解决呢? 当经理不了解风险所在,并且拒绝接受那些不可规避的风险,我们应该怎么办呢: 你需要选择,按优先级排序,并协商范围,以确保截止期限,或者把它延后。

  这个任务绝对不是个简单的任务,我现在所能够给出的最佳答案就是backlog和燃尽图的组合。依我所见,在以下各种情况下,这会有些好处:

  1. 把所有任务集合在一起(技术上的、功能上的任务等等)。当然,我们可以通过用例或者特性来组织和统一这些任务。
  2. 把任务与所有项目参与者共享。换句话说,让更多人知道哪些工作是必须要完成的。
  3. 显示出信心,并制定切实可行的截止日期,从而让项目经理可以有效地排定任务的优先级。
  4. 显示所有添加的任务,那可能会推迟最初制定的截止日期。

  在上线前的几周,当前组织的压力比较大,因此我们决定要增加人手

  Brook在1975(我还没有出生)年声明了一条规则:

  “向已经延迟了的软件项目中添加人手,只会使其延迟更严重。”

  我们都已经对此深有体会。但是我们不得不承认,一般我们还是想要通过增加人力来保证在截止日期之前发布,而不是改变最初定义的范围,并保持最优化和合适的团队规模。Brooks对他的规则做出解释,其中有两个主要的观点。 第一点关注于新的团队成员,我们需要对他们进行培训,那会耗费现有人员的工作时间。第二点是一个“神话”,让我们相信开发任务可以任意分解,而不需要考虑工作中很多部分都需要智慧,并且还需要所有开发者之间必要的沟通。此外,我们还能发现更多与组织开发相关的困难,并且需要在所有开发人员之间共享同样的代码。这么多的细节会降低团队的生产力。

  Tom de Marco为我们做出了他对Brooks的规则的理解,他称之为“人浮于事(overstaffing)”。

  “按时完成并非是最重要的。重要的是看起来你已经做出最大的努力来按时完成。在这个“吃得少跑得快”的时候,对于你来说,使用少数(优化的)人员来运转项目是很不安全的。”

  请再次读一下,这次慢一些。你不认为这是一种很有趣的观点吗? De Marco所建议的,或者说我的理解是,我们之所以不增加人力,是因为我们认为那会更快更好地完成工作。我们添加人力只是作为一旦失败时的借口。就像小孩子喜欢说的:“ 那不是我的错,我已经尽力了。”

  这是多么自然的反应啊! 想要改变这种行为,首先需要改变我们的教育方式(并学着从失败和错误中吸取教训),并且组建一些组织,让失败成为其中的一种选择(当然不要太多)……

  “一切都一直在失败”。你为什么不积极处理,而只是忽略它呢?

  和通常情况一样,批评很容易,而艺术地处理则很难。那样,我们会注意到相同的错误一次又一次发生,而很少试一下其他方法(当然,这些方法也会存在其他限制)。“风险管理是为失败做计划的方法”(Slack, Tom de Marco),并且这可能正是我们擅长之处。Werner Vogels说过:“一切都一直在失败”。

  他们所要表述的是: 我们很难避免失败。就像往山上滚石头的人一样,如果想要爬得更高,走得更远,就必须接受石头会落下的事实,那是通往成功的必经之路。所以拥抱它、处理它,并从中学习吧。

  Tom De Marco告诉我们,想要管理风险,首先需要把它们识别出来,然后对其进行监控,设置指示器,当失败发生的时候会为我们提出警告。有时,我们需要找到其他方法。有些人需要培训。我们会开发软件的并行版本,这样,在做决定的最后时刻,我们就能够选择最适合的解决方案(精益管理把这叫做“基于设计设置(set based design)”原则)。

  但是风险管理不仅仅是计划。从架构的角度来看,风险管理当然还意味着可依赖性的管理: 从灾难中恢复……但这种风险管理的方法意味着要为我们的系统制定架构——与业务部门的人员紧密合作——从而管理并拥抱所有这些错误。换句话说,就是尽可能地预测我们架构中可能发生的错误情况:

  • 如何管理一种降级的模式,从而在整个系统的某个部分不可用,或者访问者的数量超出预期时让系统仍然可用?
  • 在发生错误的时候,需要执行哪些过程(如果需要手工过程的话)来终止业务处理?
  • 想要完成业务处理,需要哪些命令信息?
  • 警告机制是什么样的,从而可以根据最终用户的需要提前激活,通知他发生了错误,并帮助他恰当地终止正在处理的工作。

  在现存的系统中,我们需要让它发展(而不是变革),从而确保这些已经检测出来的错误情况都被彻底修正。

  但让我们现实一些。如果你是成本驱动的,那么你会发现所有非业务的需求都没有用。但是,最终我们对于应用程序的信心不正是就它管理错误的能力(弹性和可靠性)吗?绝对不是其它标准吗。

  结论: 那又怎么样呢?

  还有另外一个故事,属于另一个项目,既不非常复杂,也不是很简单。和其它所有项目的情况一样,其中有很多需要做的工作。开始时,IT和市场团队一起定义了清晰的路线图。

  • “我们希望在四个月内发布新平台,其中会实现最简化的市场特性。对于访问量,我们期望每小时会有3000次,而80%的访问者会使用新特性。”这是市场团队所说的。
  • “OK。”CTO说。“我们需要添加一些非功能性的特性来限制对平台的访问,以防我们的预测出现错误。在这些额外的特性中也会有一些技术风险,我们需要尽快确认。可能我们需要在下一次发布中看是否能够完成这些内容。”
  • “没问题。尽快告诉我们关于这些风险的信息。在接下来的月份中,我们就会需要这些新特性……”
  • - …

  随着特性团队负责实现完整的用户故事、修正bug并部署他们的代码,平台变得越来越大。

  当然,IT也遇到了技术问题。业务和IT部门需要一起来对路线图进行修正。最后期限已经到了,而有些特性被推迟实现了。那些都是优先级最低的特性。

  当然,市场预测也不怎么好。CTO向平台添加的非功能特性(例如,记录所有用户行为的日志,或者当达到已知平台限制的时候限制访问)在发布平台的过程中非常有用,帮助市场团队改进了预测。用户愿意使用这个新平台,并且信任它。

  在开放的空间中,墙上也充满了信息。燃尽图和累计流程图显示了团队的速度和问题,以及下次发布的目标……

  在这个项目中,还雇佣了一位技术专家: 那是CTO不想放过的机会。

  不管怎样,项目进行良好,并且还在运行中。技术人员们对自己所做的工作感到自豪……

  查看英文原文:The Story of a Project

上一篇: 大项目的思考 下一篇: 我眼中的DevOps
发表评论
用户名: 匿名