【Alpha阶段事后总结】命劫开发

1产品

1.1.1产品定位：

设计之初完全将产品定位在了团队管理上面，但是在实现阶段项目整体还是很依靠社交功能和即时通讯，于是我们在新的阶段改变了产品的目标，将其定为为更能够协助团队进行协作的即时通讯app，集包含社交功能也包含团队和用户之间的事件管理以及会议记录等，我们的主题任然不变，依旧通过Time Shaft·时间轴来作为我们的项目特色。

1.1.2典型用户和场景：

本产品应用场景分为以下几类（包含用户类型）：

1. 沟通交流
2. 任务管理
3. 协同办公
4. 交友聊天

群组管理系统：为团队办公定制的群组模式，提供高效、简洁、清晰的团队社区
独特的会议模式：我们将在团队群组中设计专门的会议板块，对会议主题、会议标签、会议描述、会议总结、参会人员进行设计
独特的时间轴模式：我们将以时间轴的组件模式来管理团队会议，既成员可以清晰的从时间轴上看到已经结束的会议，并点击查看会议回顾，也可以看到即将召开的会议等。
系统所提供的业务会让用户与用户之间产生什么样的关系？
具备日常社交需求：为用户与用户之间提供友好、便捷的即时通讯，针对消息进行单独回复，节省时间的同时也避免了群里消息刷屏造成的困扰
设置独特的会议标签：用户无需被消息繁多冗余、花费大量时间在查找会议/群聊内容等问题所困扰，为用户带来便捷的工作环境和较为轻松的工作状态

1.1.3目标完成度：

如图所示红色虚线表示尚未完成的预计功能，同时为了在beta阶段能够更好的提供多样化功能，我们也对部分已完成的功能进行了重新的开发。对部分代码进行了重新设计。

交付时间：

交付时间延迟了1天因为bug的处理和应对服务器被攻击的问题

计划用户：

原计划200用户实际上只有100左右

1.1.4用户反馈：

用户对功能需求的反馈和我们前期收集到的问卷基本一致，主要问题在于开发时间受限，我们尚未完成团队群聊相关功能以及团队会议管理等功能，用户的体验局限于用户之间的事件时间轴管理和即时通讯。这部分内容我们也在快速开发，并设计最新的问卷收集用户的新需求。前期用户的主要反馈为BUG的反馈，我们已经对相关BUG进行了修复

1.1.4经验教训：

1. 代码管理规范：

   我们项目在前期的管理不够规范，在一个服务器上进行测试和发布，导致最后发布版本出现问题。在这之后我们也及时调整，再租一台服务器，完全按照企业管理规范来进行test和发布版本的管理。我们在test服务器上可以由开发人员进行push和merge，正式服务器只有在经过了测试和完成阶段任务之后由正式服务器管理员进行merge管理

2. 团队任务分配：

   之前团队任务分配当中前后端功能较为分散，没有痕迹总的进行一系列功能的推进，这样使得开发整体速度较为缓慢。于是我们采用了模块化的功能开发，以功能为单位，用pingcode软件对功能极其复杂结构进行任务分配。

3. 服务器安全性：

   停用传统的mod5算法，采用更高级别的循环哈希加密；将未上传的鉴权内容重新发布

4. 定位：

   我们的项目在开始的定位仅仅局限于团队管理，然而实际开发中我们发现我们的项目的主要载体仍是即时通讯和社交功能，我们的亮点是在这基础上的团队写作功能的开发和特殊的时间轴记忆模式，我们也及时调整了项目定位，我们发现这并不影响我们项目的原定目标用户

2 计划

• 是否有充足的时间来做计划?

  alpha阶段我们的计划非常模糊，主要是区分大体的功能模块，没有计划性的拆分功能所以导致计划不够充分。新的阶段我们采取议轴提前制度计划，每次都在一周前不知下一周的任务，同时计划内容也会根据实际情况进行调整

• 团队在计划阶段是如何解决同事们对于计划的不同意见的？

  主要通过团队群中交流或者当面进行交流，遇到不同的意见我们会提出，在整个团队进行分析，通过整体来进行协商和利弊分析，最终达成整个团队都比较满意的结果

• 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

  并没有完全做完，原因如下

  • 我们误判了即时通讯部分的内容复杂度，发现前期需要大量的学习成本和时间成本来设计握手情况和服务端-客户端的报文信息处理，我们为了更加安全实时的完成交互功能花费了较多时间，对其它功能的实现有一定的影响
  • 时间很紧张，团队成员并不都在学校，也有同学在准备自己实验室的科研和论文，无法按照理想情况下的“极限开发”要求进行，所以整个团队的整体开发时间周期要小于alpha的预计时间
  • 任务分配并不完全合理，太过于局限在前后端的任务分离，我们后续采用模块化开发对功能进行更加细致的划分，并采用pingcode进行任务管理，任务的进度和状态会更加清晰

• 有没有发现你做了一些事后看来没必要或没多大价值的事？

  • 对一些前端的展示细节过于较真，导致功能的开发进度受阻。我们希望能完成基本功能后在进行细节处理，并且专门安排了2位同学进行UI的设计和补充
  • 过多聚焦于数据结构的设计，花较多的时间在了怎么考虑前端计算复杂度，实际上对整体结果影响很低，这种无用的思考太占用时间了

• 是否每一项任务都有清楚定义和衡量的交付件？

  任务在粗粒度上具有清楚的定义和衡量，但是实际开发过程中不得不考虑细粒度的问题，我们在alpha姐u但对细粒度的考量不到位，总是遇见问题之后才临时考虑。

• 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？

  项目整体还是按计划进行的，只是进度比预期的要慢一点。

  项目出的意外就是服务器的数据库被黑客清空了，黑客大哥还留下一句话“请往xxx账户打款0.01比特币”，导致我们前期的测试用户信息全部丢失。我们最初没想到这个问题，没想到阿里云服务器的安全性这么差，于是我们只好重新收集用户，重新注册测试用户，并在redis定期备份数据库。

• 在计划中有没有留下缓冲区，缓冲区有作用么?

  计划中是留下了一定的缓冲区的，因为担心时间的问题和前期对人物的错判，调整过程中需要花费更多的时间，所以我们也希望通过缓冲区来弥补这一过程。整体来看我们的预先分配缓冲区起到了一定作用，还是能够帮助项目在特定时间内基本完成需求功能。

• 将来的计划有什么修改？

  留足提前量，转变产品定位思路，在整体开发阶段改变验收模式和任务粒度

• 我们学到了什么？如果历史重来一遍，我们会做什么改进？

  学习到了团队的管理；项目的开发推进；成员的管理；任务的分配；突发事件的处理；技术能力

  如果重来一遍：我们在项目功能的前期计划和任务管理上会更加细致，争取提高开发效率。

3 资源

• 我们有足够的资源来完成各项任务么？

  团队共有七人，任务资源分布正常。基础任务的资源是足够的，设计之初的视频等功能由于资金限制和服务器性能限制无法实现，在后续我们自费租了两台服务器，已经足够完成项目开发

• 各项任务所需的时间和其他资源是如何估计的，精度如何？

  我们在每周的scruming当中由三次左右的例会，我们会通过例会来讨论任务量和功能量，并依据团队成员能力进行估计，整体精度在1天左右，希望的任务分配误差不超过2天。

• 测试的时间，人力和软件／