【问题标题】:methodology for a team coursework [closed]团队课程的方法[关闭]
【发布时间】:2010-11-21 14:03:37
【问题描述】:

我需要一种方法来组织我的团队完成大学作业。

我是一名大学生,已经有一些编程经验。我在一个相对较大的项目中在超过 2 人的团队中工作的经验是,由于计划、组织和沟通问题,在上周左右,一切通常都完成得非常快而且很糟糕。一月份我将不得不在一个 6 人的团队中完成一个(对我的技能相当具有挑战性的)编程项目(Oracle 上的 Java 应用程序)。我已经认识了我的团队成员并被选为项目负责人。期望人们在任何有意义的时间里聚在一起是不现实的——每个人在不同的时间都有空,而且可能每周 1 小时的会议是现实的。人们努力工作并致力于成功,但每个人都有自己的情况。大多数分布式工作是可能的方式。

我浏览过 XP、Scrum,但它们都需要坐在一起(不太可能),旨在全职开发项目(人们有其他任务和兼职工作)和客户参与(我们将有书面规范,就经验而言,来自导师的电子邮件将在 2-3 天内得到答复。

对如何组织人员和分工有什么建议吗?我很认真地研究这个话题,因为以后会有更多这样的作品。

任何帮助表示赞赏。

【问题讨论】:

标签: project-management project-planning methodology


【解决方案1】:

虽然不是一个编程项目,但我目前的职位与您相似 - 在 5 人小组任务中被选为小组组长。我们将提前两周完成,所以我会说这个小组是成功的。作为组长,我做了一些事情来确保这一切发生(我还借鉴了在“现实世界”情况下管理项目的经验,所以也许有更多优势):

  • 从偏移设置基本规则。确保每个人都知道对他们的期望:出席会议、工作截止日期、如果他们遇到困难该怎么办。我们在我们的大学有一个系统,如果人们不“尽自己的力量”,可以将他们从群体中移除。如果您的大学有类似的事情,还应概述您启动该程序所采取的步骤。例如,错过两次会议,您将被“黄牌”。错过另一个,那就是一张“红牌”。
  • 将任务分解为可管理的块,然后确定时间线。如果你已经知道每周应该做什么,那么每周分配任务就会容易得多。或者,当然,无论您决定什么时间框架。
  • 会议。应该有一个初步会议,决定以上所有内容,可能是一个相当长的会议(我们的第一次会议花了 90 分钟)。在那次会议上,列出下次会议前要完成的任务。然后,在随后的每次会议中,验证每个人所做的工作,确保它既完整又正确。然后,当然,委派任务完成下一次会议。等等……
  • 每个人、每个人或其他任何人都应该离开并自己独立完成工作。因为会议时间很短(就像我们一样),所以会议应该是确保一切都完成、制定计划并委派任务。
  • 通讯。我为我的小组成员建立了一个论坛,以交流他们正在做的工作并上传完成的材料。我还有一个特定的子论坛,人们可以在其中发布他们可能遇到的任何问题 - 规则是他们应该在下次会议后的充足时间内这样做 - 以便其他人可以提供帮助,或者可以重新分配任务。重要的是每次会议都有记录并为下一次会议设置议程。我将这些上传到论坛,这样任何错过会议的人都不会被蒙在鼓里,并且确切地知道他们需要做什么。

由于您的项目是一个编程项目,因此以下内容可能有助于团队保持组织性和凝聚力:

  • 尽早 - 最好在第一次会议中 - 将您的程序分解为“模块”或类/程序/其他;基本上,要编写的可管理的、独立的代码块。然后可以每周将这些分配给某人。为了确保时间不会浪费在以后不必要地更改代码上,请决定您的全局变量(如果有)。在开始任何编码之前,最好也决定每个类的方法和属性。
  • 正如 sgolodetz 建议的那样,您可能还希望使用版本控制来跟踪正在编写的代码。同样,如果您这样做,请确保制定了更新时间/频率的规则/指南。
  • 或许可以安排从事相关任务的人员在会议之间开会,以确保他们的代码能够很好地集成。这样,他们可以一起工作,以确保每个人的代码与其他人的代码“合作”。

我认为这里的关键是要井井有条。制定严格、详细的计划并尽可能坚持下去。

至少在大学里,我认为有一定程度的冷酷无情很重要——请记住,如果人们不竭尽全力,也会影响你的成绩。可能只是我,但是一旦制定了规则,就应该遵守并打破它们(即:不完成工作或不让人们知道你在挣扎,不出席会议等)应该始终 导致“卡片”系统 - 正如一开始就同意的那样。你的未来岌岌可危,所以不要让不在乎的人危及它。

【讨论】:

  • +1 - 都是非常好的建议,我完全同意。我要说的一件事是,虽然从团队中移除人员可能是必要的,如果他们真的没有减轻他们的体重,最好尽可能通过提前关注每个人来尝试避免此类问题,让他们按照自己的意愿工作实际上可以做,等等。你应该毫不犹豫地删除那些真正破坏你项目的人,但你应该尽你所能确保你没有为他们做贡献,例如为他们设置不切实际的截止日期等。
  • 哦,是的,当然。 +1 澄清我的观点。我主要是在谈论那些没有付出适当努力的懒惰人。
【解决方案2】:

去年,我是一个团队项目(6 人)的负责人之一。根据我的经验,我有几个要点。

虽然论坛、在线聊天、电子邮件、SVN 提交消息等都是非常好的沟通机制(我确实推荐它们),但没有什么比每周会议更重要的了。这些应该包括委派/讨论/监控任务,讨论一般问题和更大的图景,做出集体决策,以及简单地使用你的应用程序并将其作为一个群体来识别问题。通过这样做,人们在他们的任务中处于什么位置,他们可能会在什么地方感到困惑,以及他们是否了解需要做什么,这些都变得显而易见。这是至关重要的,因为“迷失”和不知道从哪里开始往往是取得进步的最大障碍,而不是懒惰。此外,小组决策最好亲自做出,你们可以相互交流想法……这一切都有助于建立共享所有权的感觉。

没有一种最好的方法来制定、委派和监控任务。但重要的是,您可以将工作负载(尽可能多地)划分和并行化为大小合理的任务,并确定它们之间的依赖关系。我们小组在我们的存储库中维护了一个 TODO 文件,其中包含任务、日期和错误列表。我们根据一些因素对任务进行优先排序,例如它们是强制性要求还是可选的细节(想想莫斯科),它们是否在关键路径上,它们有多少风险/不确定性等等。我们为大多数任务分配了一个或两个人关于他们的长处以及他们是否真的想做这项任务,但我们也将一些任务留给任何想要他们的人(这也有潜在的危险)。我们几个更强大的程序员也扮演了“浮动角色”,这意味着我们可以帮助完成任何任务。一个关键点是任务描述应该包含会议中讨论的任何内容......什么,为什么和几个“如何”的句子作为启动(即“要完成这个,你可能想阅读 blablabla” )... 任何能让你的队友轻松进入任务的东西。

【讨论】:

  • 作为后续问题:您是否有专门的团队领导和架构师/设计师(也许两个角色都在一个人身上)?还是“集体”做出设计决策更好。您是否尝试过使用 UML,或者这种项目的开销是否太大?
  • 我们没有专门的建筑师/设计师。最初,我们将工作量分为 3 个主要部分,每个部分由两个人负责 - 这意味着重要的早期设计决策都由至少两个人做出。之后,我们集体做出了一些设计决策,但它们大多是由从事每项任务的人做出的。我们没有使用 UML,但事后看来我们可能应该有...
【解决方案3】:

一些想法:

  • 通信 - 可能使用 IRC 或 wiki
  • 将人员分配给任务 - 您需要弄清楚人员的优势和劣势在哪里,将项目分解成块并相应地分配它们
  • 监控 - 人们远程工作的项目的一个大问题是他们可能无法按时完成工作;您需要考虑如何掌握这一点(例如,使用版本控制,并查看签入) - 为了使这项工作发挥作用,每个人都需要预先购买它
  • 战略储备 - 让一个人(如果你是最强大的程序员,也许你是最强大的程序员)在整个项目中承担其他人发现难以防止人们陷入困境的任务可能是值得的

【讨论】:

    【解决方案4】:

    首先,为项目建立一个版本控制系统。这服务于所有团队都可以使用已签入的代码,如果有人破坏了您可以恢复到早期版本,并且所有像样的专业商店都使用源代码控制,所以这是一项工作技能,很好使用习惯。

    现在您可以检查进度了。如果乔没有检查任何东西,你就知道他没有做这项工作。如果 Sally 在期中辞职,你就会记录下她所做的一切。

    您想要做的另一件事是代码审查。每个人的代码都会被一个或多个其他人审查。你们都会从中学到很多东西,这也是专业开发人员必备的技能。

    计划必须按什么顺序完成。确保开发其他一切所依赖的东西的人是您团队中最可靠的开发人员,并且他们将按时完成任务,否则其他人将无法完成他们的工作。

    每周举行一次进度会议,不要害怕因为某人没有尽到他或她的职责而大声疾呼。你越早发现一个人没有减轻他的体重,你就能越早解决这个问题。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多