我很幸运能与杜克大学一群杰出的学生一起工作，他们是课堂内外的领导者。作为 CSbyUs 的成员，这是一个位于杜克大学的非营利性学生运营组织，我们将大学生与主要来自北卡罗来纳州研究三角园 Title I 学校 的中学生联系起来。我们的使命是通过培养在数字时代蓬勃发展所需的关键技术技能，来激励来自资源匮乏学习环境的未来变革推动者。
CSbyUs 技术研发团队（简称 TRD）最近设定了一个雄心勃勃的目标，即在一个秋季学期内构建和部署一个强大的 Web 应用程序。我们六人团队知道，我们必须对工作流程进行一些改进，才能在寒假前发布产品。在我们的中学课堂上，我们教导学习者使用敏捷方法和设计思维来创建移动应用程序。在 TRD 团队中，我们意识到我们需要实践我们在课堂上所宣讲的内容，才能在学期结束前发布高质量的产品。
这是一个关于我们如何以及为何利用我们教给学生的原则来部署技术的故事，这项技术将扩展我们的使命，并使我们的教学资源开放且易于访问。
场景设定
在过去的两年里，CSbyUs 一直“在实地”运营，通过课后辅导项目将杜克大学的本科生与达勒姆的中学联系起来。在教授和评估了我们独特的、以学生为中心的移动应用程序开发课程的几个迭代版本后，我们看到了很有希望的结果。我们的中学生正在创建功能性移动应用程序，与他们的导师建立联系，并在离开课堂时对他们的计算机科学技能更有信心。自然而然地，我们想知道如何扩展我们的项目。
我们知道我们应该采纳自己的建议，并倾向于使用基于 Web 的技术来分享我们的工作，但我们并不立即确定我们需要解决什么问题。最终，我们决定创建一个 Web 应用程序，作为一个集中枢纽，用于开放源代码和开放访问的数字教育课程。“CurriculaHub”（名称灵感来自 GitHub）将成为 CSbyUs 新网站的定义支柱，教育工作者可以在其中分享和调整资源。
但愿景和实施并非一蹴而就。
考虑到我们的紧迫感和“CurriculaHub”的潜力，我们希望从一个明确的计划开始这个项目。风险很高（而且现在仍然很高），因此计划，尽管有时很乏味，但对我们的成功至关重要。就像我们教授的课程一样，我们用设计思维和敏捷方法来构建我们的工作流程，这两个关键的 21 世纪框架往往被我们在高等教育中忽视。
接下来是对我们的设计思维过程的逐步解释，从灵感到最终交付原型。
我们的流程
步骤 1：准备工作
为了理解我们的目标背后的原因，您必须了解我们的团队是谁。
这个团队的成员都很忙。我们所有人都在 TRD 相关职责之外为 CSbyUs 做出贡献。作为一个目标远大的组织，除了创建一个基于 Web 的平台之外，我们还必须协调我们的“实地”承诺（即课程管理、研究和评估、导师培训和实践、会议演示等）与我们的“云端”技术目标。
除了平衡组织内的时间外，我们还必须在沟通方式上保持灵活性。作为团队的远程成员，我正在西班牙撰写这篇文章，但我们团队的其他成员都在北卡罗来纳州，这增加了协作挑战。
在投入开发（甚至问题识别）之前，我们知道我们必须为团队的运作方式设定一些明确的期望。我们借鉴了课程团队的做法，并从一些 参与规则 开始。实际上，这是 一种有据可查的方法，用于设置团队的 社会契约，已被整个技术领域的团队使用。在 IBM 的夏季实习期间，我记得项目前的会议上，我的经理和团队花费了一个多小时来澄清互动原则。每当我们团队运营中遇到不确定性时，我们都会拿出参与规则，几乎立即澄清问题。（题外话：我发现这种策略不仅在我的团队中非常有效，而且在所有关系中也都非常有效）。
考虑到我们团队的远程性质，我们最喜欢的工具之一是 Slack。我们几乎将它用于所有事情。我们不能进行便利贴头脑风暴，所以我们创建了 Slack 头脑风暴线程。事实上，这正是我们生成参与规则的方式。我们铭记于心的 一个开源原则是透明度；Slack 允许我们存档并公开地与团队的其他成员分享我们的思考过程和决策步骤。
步骤 2：共情研究
我们来到这里的原因各不相同，但我们找到了一个共同的交集：渴望扩大公平获取高质量数字时代教育的机会。
我们团队的每位成员都很幸运能够在杜克大学学习。我们知道拥有无限的机会以及才华横溢的同伴和著名教授的支持是什么感觉。但我们意识到这并不正常。在全国乃至全球范围内，这些机会少之又少。即使存在，它们也被限制在高等学府的戒备森严的围墙内，或者伴随着高昂的价格标签。
虽然我们团队成员扩大访问权限的共同愿望是明确的，但我们努力将我们的决策扎根于研究。因此，我们的团队在每个学期开始时都会 回顾 研究，这些研究证明了我们存在的合理性。TRD 与 CRD（课程研究与开发）和 TT（教学团队）（我们 CSbyUs 的另外两个子团队）合作，讨论数字教育访问的当前趋势、其系统性根源以及扩大访问权限并使材料与学习者相关的创新方法。我们不仅在学期初进行合作研究，还在子团队中每周举行站立式研究会议。在这些会议中，CRD 经常展示我们从采访现有教师和深入研究我们当地社区的当前访问状态中收集到的新发现。它们是我们以数据驱动、激发共情的研究的持续来源。
通过这种基于共情的研究，我们发现对以学生为中心的教学和数字时代教育感兴趣的教育工作者缺乏一个集中空间，用于存放经过验证且可调整的课程和教案。塑造美国课堂学习的官僚主义和僵化结构使得围绕学生的个人需求重塑课程变得令人生畏，而且似乎不可能。作为学生、教育工作者和技术专家，我们想知道如何通过分享我们自己的资源并创建一个在线支持生态系统来释放他人的创造力和能动性。
步骤 3：定义问题
我们想避免因使命和愿景定义不清而导致的 范围蔓延（这种情况在某些组织中太常发生）。我们需要结构来定义我们的目标并保持范围的清晰度。在想象我们的应用程序功能之前，我们知道我们必须从定义我们的北极星开始。我们将生成一个明确的问题陈述，以便我们在整个开发过程中可以参考。
这对我们来说是常见的做法。在致力于新的项目、新的合作伙伴关系或新的变更之前，CSbyUs 团队总是回顾我们的使命和愿景，并问：“这有意义吗？”（事实上，我们将我们的使命和愿景张贴在每次会议纪要文件的顶部）。如果它符合并且我们有能力去追求它，我们就去做。如果我们不这样做，那我们就放弃。在“否”的情况下，我们始终确保记录什么和为什么，因为正如工程师所知，详细的日志几乎总是一个好的决定。TRD 收集了这种大局观的智慧，并实施了一个团队定义的问题陈述，以指导我们的子团队使命和未来的开发决策。
为了制定一个简洁的问题陈述，我们每个人都首先发布了我们自己对这个问题的看法。然后，在我们每周一次的 30 分钟不多不少的站立会议 中，我们确定了共性和差异，最终 将我们所有的想法合并为一个。归根结底，我们确定教育工作者、家长和学生在分享、修改和讨论开源和易于访问的课程方面存在巨大障碍。 当然，我们的使命将是通过以用户为中心的技术来打破这些障碍。这个“北极星”作为一个高度可见的文档存在于我们的 Google Drive 中，它影响了我们的功能优先级和未来的方向。
步骤 4：构思解决方案
在定义了我们的问题并建立了我们的参与规则之后，我们准备好构思一个解决方案。
我们相信有效的结构可以确保精英管理和社区。有时，某些个性会主导团队决策，而几乎没有留下协作输入的空间。为了避免这种陷阱并最大限度地提高我们发言的平等性，我们倾向于使用“离线”个人头脑风暴，并在网上合并集体想法。这与我们用来创建参与规则和问题陈述的过程相同。在构思解决方案的情况下，我们从三个 S.M.A.R.T. 目标 的“离线”头脑风暴开始。这些目标将是我们可以作为软件开发团队实现的目标（特别是由于 CRD 和 TT 团队提供不同的技能组合），并解决我们的问题陈述。最后，我们在会议纪要文件中写下了这些目标，将共同目标聚集在一起，并最终确定了描述我们应用程序功能的主题。最终，我们确定了三个：支持、反馈和开源课程。
从这里开始，我们将自己分成子团队，在这些团队中重复目标设定过程——但方式特定于我们的功能。如果到现在还不明显，我们意识到基于 Web 的平台将是支持学生、教育工作者和家长的最优化和可扩展的解决方案，它通过提供一个用于共享和调整经过验证的课程的中心来实现这一点。
为了高效工作，我们需要具有适应性，加强有效的结构并消除无效的结构。例如，我们在制定会议议程方面投入了大量精力。我们力求仅包括那些我们必须当面讨论的主题，并将所有其他内容放在 Slack 上进行离线讨论或单独组织的通话中。我们也实时实践这一点。在我们定期的 Google Hangouts 会议期间，如果有人提出一个并非高度相关或紧急的主题，当前的站立会议负责人（每周轮换的角色）会将其“停放在一边”，直到会议结束。如果我们在最后有空间，我们会从停车场中取出它，如果没有，我们会将该讨论保留在 Slack 线程中。
这种优先级排序结构极大地提高了会议效率，并专注于进度更新、共享技术难题讨论、集体决策以及分配可操作的任务（一个人承诺采取的后续步骤，记录在案，并附上他们的名字供所有人查看）。
步骤 5：原型设计
有趣的部分开始了。
鉴于我们的需求（例如交互式用户体验、协作处理博客和课程的能力以及接收用户反馈的能力），我们开始确定最佳技术。最终，我们决定使用 ReactJS 前端和 Ruby on Rails 后端构建我们的 Web 应用程序。我们选择这些是因为两者都有大量的文档和活跃的社区，以及连接两者关系的维护良好的库（例如，react-on-rails）。由于我们选择 Rails 作为后端，因此从一开始就很明显，我们将在 Model-View-Controller 框架内工作。
我们大多数人以前都没有 Web 开发经验，无论是在前端还是后端。因此，独立地开始使用任何一种技术都会呈现陡峭的学习曲线，而将两者粘合在一起只会使其更加陡峭。为了集中我们的工作，我们使用开放访问的 GitHub 存储库。鉴于我们在 Web 开发方面的经验相对不足，我们的成功取决于极其高效和开放的协作。
为了解释这一点，我们需要重新审视结构的概念。我们的一些结构包括同行代码审查——我们可以在其中交流最佳实践和可重用的解决方案，维护最新的技术和用户文档，以便我们可以回顾并理解设计决策——以及（我个人最喜欢的）我们在 Slack 上的问题机器人，它温和地提醒我们在单独的 Slack #questions 频道中发布和回答问题。
我们还尝试了其他策略，例如用于生成基本 React 组件并在 Rails Views 中呈现它们的教学视频。我尝试了这一点，在我的第一个视频中，我介绍了我们的存储库结构的基本介绍，以及生成 React 组件的最佳实践。虽然这被证明是有用的，但我们的团队此后意识到，大量的在线资源充分记录了这些技术的各种实现方式。此外，我们根本没有足够的时间（但我们可能会在未来重新审视它们——敬请期待）。
我们还对我们的基于云的实现感到兴奋。我们使用 Heroku 来托管我们的应用程序并管理数据存储。在接下来的迭代中，我们计划扩展我们当前的功能，并使用诸如 Jenkins 之类的服务与 GitHub 集成来配置持续迭代/持续开发管道。
步骤 6：测试
由于我们 刚刚部署，我们现在正处于测试阶段。我们的目标是收集用户对我们功能领域和整个应用程序体验的反馈，特别是当他们与我们的特定受众互动时。鉴于我们最初的约束（即时间和人力），此迭代是未来众多迭代中的第一个。例如，未来的迭代将允许个人用户注册帐户并将外部课程直接发布到我们的网站上，而无需通过额外的电子邮件步骤。我们希望扩展并最大限度地提高我们的效率，这是我们将在未来迭代中部署的秘诀的一部分。至于用户测试：我们通过我们的联系表单、通过我们团队内的非正式测试以及通过结构化的焦点小组收集用户反馈。我们欢迎您提出建设性的反馈和合作。
我们的团队仅仅通过开放原则和方法的强大力量，就能够将具有高度不同经验的新人团结起来。幸运的是，我在这篇文章中描述的每一个原则都几乎适用于每个团队。
无论您是在软件开发团队、教室工作，还是，嘿，甚至在您的家庭中 工作，诸如透明度和社区之类的原则几乎总是成功组织的最佳基础。
3 条评论