ogc是一个非营利性组织

我很幸运能与杜克大学一群令人印象深刻的学生一起工作，他们是课堂甚至其他领域的领导者。 作为总部设在杜克大学的非营利性学生组织CSbyUs的成员，我们将大学生与中学生联系起来，其中大部分来自北卡罗莱纳州研究三角公园内的一等 学校 。 我们的使命是通过培养在数字时代蓬勃发展的关键技术技能，从资源不足的学习环境中激发未来的变革推动者。

CSbyUs技术研发团队（简称TRD）最近设定了一个雄心勃勃的目标，即在一个秋季学期的时间内构建和部署功能强大的Web应用程序。 我们的六人团队知道，我们必须对工作流程做些事情才能在冬季休假之前运送产品。 在中学教室中，我们教我们的学习者使用敏捷方法和设计思维来创建移动应用程序。 在TRD团队中，我们意识到我们需要练习在这些教室中讲的内容，以便在学期末之前交付高质量的产品。

这是一个故事，说明了我们如何以及为什么利用我们教导学生的原理来部署能够扩展我们的使命并使我们的教学资源开放和可访问的技术。

设置场景

在过去的两年中，CSbyUs进行了“实地”运营，通过课后编程将杜克大学的本科生连接到达勒姆中学。 在教授和评估了我们独特的以学生为中心的移动应用程序开发课程的几次迭代之后，我们看到了可喜的成果。 我们的中学生正在创建功能性的移动应用程序，与他们的导师建立联系，并使班级对他们的计算机科学技能更有信心。 自然，我们想知道如何扩展我们的编程。

我们知道我们应该听取自己的建议，并倾向于基于Web的技术来共享我们的工作，但是我们不确定要解决什么问题。 最终，我们决定创建一个Web应用程序，将其用作开放源代码和开放式访问数字教育课程的集中枢纽。 “ CurriculaHub”（名称受GitHub启发）将成为CSbyUs新网站的定义Struts，教育工作者可以在该网站上共享和调整资源。

但是愿景和实施并非一朝一夕就能实现。

鉴于我们的紧迫感和“ CurriculaHub”的潜力，我们希望以一个明确的计划开始这个项目。 赌注很高，因此规划（尽管有时很乏味）对我们的成功至关重要。 就像我们所教授的课程一样，我们以设计思维和敏捷方法为工作流程流程提供了支撑 ，这是我们在较高版本中经常无法实践的两个关键的21世纪框架。

接下来是对我们设计思维过程的逐步解释，从灵感到最终交付的原型。

我们的流程

步骤1：准备工作

为了理解为什么我们的是什么 ，你必须知道谁是我们的团队。

这个团队的成员很忙。 除了与TRD相关的职责外，我们所有人都为CSbyUs做出了贡献。 作为一个远超目标的组织，除了创建基于网络的平台外，我们还必须将“实地”的承诺（即课程策划，研究和评估，指导培训和实践，会议演示等）与“在云端”的技术目标。

除了平衡整个组织的时间外，我们还必须灵活地进行交流。 作为团队的远程成员，我正在撰写西班牙的这篇文章，但是我们团队的其他成员都位于北卡罗来纳州，这给协作带来了挑战。

在投入开发（甚至是问题识别）之前，我们知道我们必须对团队的运作方式设定明确的期望。 我们从课程团队的书中记下了笔记，并从参与规则入手 。 实际上，这是建立起整个技术领域中的团队所使用的团队社会契约的有据可查的方法 。 在夏天的IBM实习期间，我记得在项目前会议上，我的经理和团队花费了一个多小时来阐明交互的原理。 每当我们在团队运营中遇到不确定性时，我们都会制定出参与规则并几乎立即清除所有问题。 （顺便说一句：我发现这种策略不仅在我的团队中而且在所有关系中都非常有效）。

考虑到我们团队的远程性，我们最喜欢的工具之一是Slack。 我们几乎将其用于所有用途。 我们不能有便签式头脑风暴，所以我们创建了Slack头脑风暴线程。 实际上，这正是我们为制定参与规则所做的工作。 我们牢记的一个开源原则是透明度 ; Slack使我们能够存档并与我们团队的其他成员公开分享我们的思维过程和决策步骤。

步骤2：共情研究

我们在这里都是出于独特的原因，但是我们发现了一个共同的交叉点：渴望在获得优质数字时代教育方面扩大公平。

我们团队的每位成员都幸运地在杜克大学学习。 我们知道拥有无限机会并得到有才华的同行和著名教授的支持的感觉。 但是我们要注意，这是不正常的。 在全国范围内和其他地方，这些机会很少。 它们确实存在的地方，被局限在高等学府的守卫之墙内，或者标价很高。

尽管我们的团队成员普遍希望扩大访问范围，但我们仍在努力将我们的决定植根于研究。 因此，我们的团队在每个学期开始审查 研究 ，证明我们的存在是正确的。 TRD与我们的另外两个CSbyUs子团队CRD（课程研究与开发）和TT（教学团队）合作，讨论数字教育访问的当前趋势，其系统根源以及拓宽访问范围并使材料与学习者相关的新颖方法。 我们不仅在学期开始时进行协作研究，而且每周与子团队进行立式研究会议。 在这些过程中，CRD经常会提供新的发现，这些都是我们从采访现有教师并挖掘当地社区的当前访问状态中获得的。 它们是我们不断进行数据驱动，促进同情心研究的来源。

通过这种基于同情心的研究，我们发现对以学生为中心的教学和数字时代教育感兴趣的教育工作者缺乏集中的空间来证明和适应课程和教学计划。 塑造美国课堂学习的官僚机构和僵化的结构使围绕学生艰巨且看似不可能的学生的个人需求重塑课程。 作为学生，教育者和技术专家，我们想知道如何通过共享我们自己的资源并创建在线支持生态系统来释放他人的创造力和代理力。

步骤3：定义问题

我们希望避免因任务和愿景定义不清而导致范围扩大 （某些组织中经常发生这种情况）。 我们需要结构来定义目标并保持范围清晰。 在想象我们的应用程序功能之前，我们知道我们必须先定义北极星。 我们将生成清晰的问题陈述，在整个开发过程中都可以参考。

这是我们的惯例。 在致力于新的计划，新的合作伙伴关系或新的变化之前，CSbyUs团队总是回顾我们的使命和愿景，并问：“这有意义吗？” （实际上，我们将我们的使命和愿景张贴在每个会议记录文件的顶部）。 如果适合并且我们有能力追求它，我们就会坚持下去。 如果我们不这样做，那么我们就不这样做。 在“否”的情况下，我们始终确保记录什么以及为什么 ，因为工程师知道， 详细的日志几乎总是一个好的决定 。 TRD收集了大人物的智慧，并实施了小组定义的问题说明，以指导我们的子团队任务和未来的发展决策。

为了表述一个简洁的问题陈述，我们每个人都首先发表自己对问题的看法。 然后，在每周一次30分钟或更长时间的站立会议中 ，我们确定了共性和差异，最终将我们的所有想法融合为一个 。 归根结底，我们发现教育者，父母和学生在共享，修改和讨论开源和可访问课程方面存在巨大障碍。 当然，我们的使命是通过以用户为中心的技术来消除这些障碍。 这个“北极星”在我们的Google云端硬盘中以高度可见的文档形式存在，这影响了我们功能的优先级设置和未来的发展方向。

步骤4：构思解决方案

确定了问题并建立了参与规则后，我们准备设想解决方案。

我们认为，有效的结构可以确保精英阶层和社区 。 有时，某些人会主导团队的决策，而很少留下协作输入的空间。 为了避免这种陷阱并最大化我们的声音平等，我们倾向于使用“离线”个人头脑风暴，并在线合并集体想法。 这与我们创建参与规则和问题陈述的过程相同。 在构思解决方案的情况下，我们从三个SMART目标的 “离线”头脑风暴开始。 这些目标将是我们作为软件开发团队可以实现的目标（特别是因为CRD和TT团队提供不同的技能）并解决我们的问题陈述。 最后，我们在会议纪要文档中写下了这些目标，聚集了共同的目标，并最终确定了描述我们应用程序功能的主题。 最后，我们确定了三个：支持，反馈和开源课程。

从这里开始，我们将自己划分为多个子团队，与这些团队一起重复设定目标的过程，但是要以我们的功能特有的方式进行。 而且，如果现在还不很清楚的话，我们意识到基于Web的平台将成为共享和改编经过验证的课程的枢纽，从而成为支持学生，教育者和父母的最佳和可扩展的解决方案。

为了有效地工作，我们需要具有适应性，加强有效的结构并消除无效的结构。 例如，我们在制定会议议程上付出了很多努力。 我们努力只包括那些我们必须面对面讨论的主题，并列出其他所有内容以供Slack或独立组织的电话进行离线讨论。 我们也实时进行练习。 在我们关于Google Hangouts的例行会议上，如果有人提出了一个不太相关或紧迫的话题，则当前的站长（一个每周轮换的角色）会“停工”直到会议结束。 如果最后有空间，我们将从停车场撤出，否则，我们将讨论保留为Slack线程。

这种优先安排结构使会议效率得到了极大的提高，并专注于进度更新，共享的技术障碍讨论，集体决策和分配可执行的任务（一个人承诺采取的下一步行动，并附上他们的名字记录在案）。大家查看）。

步骤5：原型制作

这就是乐趣的开始。

鉴于我们的需求（例如交互式用户体验，在博客和课程上进行协作的能力以及从用户那里接收反馈的能力），我们开始确定最佳技术。 最终，我们决定使用ReactJS前端和Ruby on Rails后端构建Web应用程序。 我们之所以选择它们，是因为它们都有大量的文档资料和活跃的社区，并且具有维护良好的库，它们桥接了两者之间的关系（例如，rail-on-rails）。 由于我们选择了Rails作为后端，因此从一开始就很明显，我们将在Model-View-Controller框架内工作。

我们大多数人都没有Web开发的经验，无论是在前端还是在后端。 因此，使用这两种技术独立启动和运行都会呈现出陡峭的学习曲线，而将两者粘合在一起只会使学习曲线更加陡峭。 为了集中我们的工作，我们使用开放访问的GitHub存储库。 鉴于我们相对较新手的Web开发经验，我们的成功取决于极其有效和开放的协作。

为了解释这一点，我们需要重新审视结构的概念。 我们的一些服务包括同行代码审查-我们可以在其中交换最佳实践和可重用的解决方案，维护最新的技术和用户文档，以便我们可以回顾和理解设计决策-以及（我个人最喜欢的）关于Slack的问题机器人，这轻轻地提醒我们在单独的Slack #questions频道中发布和回答问题。

我们还尝试了其他策略，例如用于生成基本React组件并将其呈现在Rails Views中的指导视频。 我尝试了这一点，并且在我的第一个视频中， 我简要介绍了我们的存储库结构和生成React组件的最佳实践。 尽管这被证明是有用的，但我们的团队此后已经意识到了丰富的在线资源，这些资源可靠地记录了这些技术的各种实现。 此外，我们只是没有足够的时间（但是我们将来可能会再次访问它们-请继续关注）。

我们也对基于云的实施感到兴奋。 我们使用Heroku托管我们的应用程序并管理数据存储。 在接下来的迭代中，我们计划既扩展当前功能，又使用与GitHub集成的Jenkins之类的服务配置连续迭代/连续开发管道。

步骤6：测试

既然我们已经部署了 ，那么我们现在处于测试阶段。 我们的目标是收集整个功能域和整个应用程序体验中的用户反馈，尤其是当它们与特定受众互动时。 考虑到我们最初的限制（即时间和人力），此迭代是许多迭代中的第一个。 例如，将来的迭代将允许单个用户注册帐户并直接在我们的网站上发布外部课程，而无需执行电子邮件的额外步骤。 我们想要扩展规模并最大程度地提高效率，这是我们在未来的迭代中将部署的配方的一部分。 关于用户测试：我们通过联系表格，团队内部的非正式测试以及结构化的焦点小组收集用户反馈。 我们欢迎您的建设性反馈和合作 。

我们的团队只有通过开放原则和方法的力量，才能将经验丰富的新人们团结在一起。 幸运的是，我在这篇文章中描述的每个人实际上都适用于每个团队。

无论您是在软件开发团队中，在教室中， 甚至在您的家庭中工作，透明性和社区性原则都是成功组织的最佳基础。

翻译自: https://opensource.com/open-organization/19/2/building-curriculahub

ogc是一个非营利性组织