一、管理分析
尝试多种管理方式，探究了比较高效的管理方式。具体可以参考Alpha项目阶段展示。
在管理中，发现能够调用大家积极性的管理方式，无论在客观分析上是否高效，都会在实践中有很高的效率。
此外，PM 一旦确定了产品的灵魂，就可以极大得激发团队的动力。
二、实现分析
2.2 开发过程
项目使用Electron+Vue3框架开发，虽然我们组大部分成员都是第一次接触Electron框架，但这并没有给开发带来太大的困难，这得益于Electron完善的文档，以及可以借鉴的其他项目。
整体上可以分为文件服务、markdown编辑器、图编辑器、markdown中间结构、渲染进程的文件资源管理几大模块，成员分工比较明确，开发过程遵循分析功能确定用例->设计API->具体代码编写->对接的流程，基本没有产生冲突。
因为我们使用的一些组件都有成熟实现，所以我们也在项目中通过引入、fork等方式使用了很多其他项目作为插件。得益于良好的包管理，兼容性基本上没有产生冲突。
2.2 总结反思
主要是开发过程中遇到的一些问题：
- 开发经验不足导致前期架构设计细节不足，实际架构是在迭代中完善的。
- Eslint（代码规范工具）作用有限，一些代码不符合“高内聚低耦合”的要求。
- 调研不足，一些使用的插件出现了严重的性能问题（响应过慢）。
- UI设计上并没有很好的考虑MacOS系统，这与对MacOS系统的认识不足有关。
三、宣发分析
3.1 宣发方式
在宣发思路方面，比预期的要较为激进一些，但是依然保留了一些宣发平台用于 beta 的宣发。
采用的方式是：
- 产品官网
- 网站宣发
- 社团联动
- 社交媒体
具体的宣发数据可以查阅Alpha项目阶段展示。
3.2 总结
宣发的工作量还是很大，为了宣发做了很多事情，最推荐开源社区宣传和知乎，不推荐 CSDN 宣传。
非常感谢大家对于 ficus 宣发工作的支持。
四、开源分析
4.1 开源项目的搭建
开源项目除了需要将代码开发外，我们认为最重要的是搭建一个开源社区：
- 静态网站的搭建：我们用 VuePress 搭建了静态网站，选择这种方式主要是因为静态网站要更加容易搭建和维护。
- 反馈通道：搭建了评论区、用户群、Issue 教程。
- 开源引导：撰写了文档引导用户进行开源操作。
- 博客社区：因为时间问题，并没有搭建
4.2 总结
总体来说，开源的实践并没有预估的要好，虽然有很多人 star，但是只有一个人为我们贡献了代码（其实也是非常感激的）。但是不可回避的是，“开源的招牌”比“开源本身”发挥了更大的作用。
导致这种问题的原因可能是因为管理一个开源社区相比于直接管理一个团队，需要付出相似的精力和成本，这显然是无法支持的，同时 alpha 阶段因为对于开源知识的生涩也导致了成本的进一步的提升。
希望在 beta 阶段有更好的表现。
五、问题
5.1 对比敏捷的原则，你觉得你们小组做得最好的是什么？
敏捷开发的重要原则如下：
-
个体和互动胜过流程和工具
-
可以工作的软件胜过详尽的文档
-
客户合作胜过合同谈判
-
响应变化胜过遵循计划
-
小步快跑，持续交付价值
-
坚持简单，避免过度设计
-
注重技术卓越和良好的设计
-
采用面对面的沟通方式
-
鼓励自组织和跨职能团队
-
注重持续改进和反思
-
采用可持续的开发速率
-
重视客户满意度和价值交付
我们觉得我们在“采用面对面的沟通方式 ”和“鼓励自组织和跨职能团队 ”这个方面做得最好，这两个原则都是在描述具体代码实现过程中的团队合作方式，我们采用了大量的结对编程实践和自组织的群聊（一共有 5 个小群）来进行实现过程中的合作，相较于传统的“中心商议，外围实现”的思路，我们的协作更加“分布式”，具有高效和方便的特点。
5.2 什么是在下个阶段要改进的地方？越具体越好。
我们会从四个方向对我们的项目进行改进：
- md 编辑完善
- 悬浮工具框
- 数学公式强化
- 渲染美化
- 图片增强
- 杂项
- 杂项
- 文档
- 榕树
- 榕林
- 榕图
- 软件完善
- 备份文件
- 更新
- 打开文件和文件夹
- 杂项
- UI 完善
- 逻辑布置
- 菜单栏
- 侧边栏
- 搜索
- ……
具体信息可以参见功能规格说明书。
附：全组讨论截图
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们要解决的问题是目前编辑文档 markdown 文档中的缺陷。它包括三个部分：
- 对于文档内编辑，将 md 文档解析成一个树形结构，直观展示文章的架构。
- 对于联合编辑，将多个文档的树结构进行并行展示，然后编辑。
- 对于文档间编辑，展示多样性的文档间联系，并提供转换方式。
我们觉得经过多次打磨设计书，这里的定义是清楚且直观的。
对于典型用户和典型场景有清晰的描述。
2.我们达到目标了么？
我们原计划的功能全部完成了。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量超过了预期。
我们积累了对于富文本编辑器和我们特色功能的开发经验，我们离完整版的 Ficus 更近了。
5. 有什么经验教训? 如果历史重来一遍，我们会做什么改进?
其实 demo 还是比较保守，如果一开始就上来干，或许可以省下来一些时间，但是因为我们刚进入这个领域，所以花费了一些时间试探。
我们觉得其实最大的经验教训是目前的选题还是工作量过大了。富文本编辑器本来就是软件开发的天坑，更何况是一个有特色功能的富文本功能编辑器。
计划
1. 是否有充足的时间来做计划?
是有的，我们在 alpha 提前了几周进行计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们的计划主要还是由 PM 和美工两个人来完成的，相对来说并不是完全民主的，架构师确保了计划的可行性问题。其他人的意见也会被考虑。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我们的计划功能都开发完全了，我们有一些遗留问题（一般是一些功能加强功能和像 feature 的 bug）：
- 没有开发出即时渲染功能，这是因为我们的能力只允许在“富文本模式”和“即时渲染模式”中选择一个开发。
- 一些渲染问题，这是 lute 插件本身的问题。
- 榕树部分的性能较差，这是插件问题。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
我在设计中，一开始只涉及了两个榕功能的层次，这使得在实现的时候有一些不好的地方。
5. 是否每一项任务都有清楚定义和衡量的交付件?
是的，我们有使用测试，单元测试，issue 描述，文档定义等多个关卡把关。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
最大的意外是对于榕图功能的需求修改，这是因为之前这个部分的设计有些模糊和二义性的地方。
这个风险是估计到了的。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
是留了缓冲区的。
缓冲区的作用是为了有可能的技术难题和设计缺陷准备的，缓冲区发挥了作用。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
在做设计需求的时候，要更加精细化，同时还要讲逻辑。我们打算多个人一起审核。
9. 我们学到了什么? 如果历史重来一遍,我们会做什么改进?
做设计的时候应当讲逻辑，说清楚，务实。
资源
1. 我们有足够的资源来完成各项任务么?
有足够资源。时间、人力、设计、团结，都是有的。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
根据 alpha 前的 demo 和实现难度综合估计。
精度还不错，基本上都是估计准确的。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
是足够的。
没有太低估难度，因为 PM 就是负责估算难度的，他刚好不编程，他甚至高估了自己的难度（手动狗头）。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
基本上没有。
5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
我们的分工比较“正交”，这导致如果一个人进度慢了，那么其他人没法很好的代替它的工作。
基本上没有办法改进，因为确实功能太多了。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
是的，我们有两种信息通知方式，一种是 github issue，一种是 notion ，这两种方式都可以绑定邮箱，很容易获取变更。
此外 PM 会关注大家的动态，如果工作进程没有表示出它知道了这个变更，PM 会私聊提醒。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
采用实现人员和 PM 协商的方式，其基本原则是，如果不影响基本功能，都是可以推迟的。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
是有的，我们的 PM 和架构师会规定好。
4. 对于可能的变更是否能制定应急计划?
有缓冲区设计，也有应急计划（设置对于需求也有低版本计划）。
但是最后依然有一些小崩。但是基本上都平移到 beta 前的一周去做了。
5. 员工是否能够有效地处理意料之外的工作请求？
能，是可以的，我们的心态都很积极平和。
6. 我们学到了什么? 如果历史重来一遍,我们会做什么改进?
如果将出口条件再细致一些，也就是使用 bug 修好时的出口条件，这个部分没法再规划阶段做，所以做得较差。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在 alpha 阶段第一周完成了。
在具体实现前完成，所以是合适的时间。
由对于产品设计理念有整体把握的 PM 实现，是合适的。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有的，PM 没有写清楚规格说明书。
负责实现的同学会向 PM 询问模糊的行为。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
团队主要采用单元测试+集成测试的方法进行测试，使用了Uml绘制工具辅助实现。单元测试是最有效的，保证了在重构代码、增加功能等操作中不会出现严重问题；Uml文档作用有限，因为我们在项目开发中需求变化较为频繁，且对项目本身缺乏基于经验的认知。
与开发时候相比，我们UML文档已经产生了较大变动。这种变动来源于功能的增加，全新的需求导致架构上不得不进行响应的变动。但是项目整体架构因为初级进行了大量的调研，实际上变动不大，所以对UML文档的更新有限。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
富文本渲染的 bug 最多，因为这个部分用户的自由度最高，会有很多的行为，而且这个部分是由其他人开发的，所以我们的控制力比较差。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们通过 github 的 pull request review 机制进行。需要指定适合且对于 pr 较为了解到 reviewer。
严格执行了代码规范，我们这个部分是自动化风格，如果不能通过代码规范测试，则不能合并 pr。
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进
富文本编辑器好难啊！
如果重来，可能我们的项目就变成了开发一个富文本编辑器，而不是用现有的富文本编辑器插件实现一个 Ficus。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
是有的，我们很注重测试。
2. 是否进行了正式的验收测试？
进行了，我们进行了完善的验收测试。可以在我们官网找到报告。
3. 团队是否有测试工具来帮助测试？
单元测试框架 mocha。
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
使用 chromium 自带的profiler，打开模板大文件，对软件性能进行测试，测量渲染时间、模式切换时间等。对于压力测试，多次复制模板大文件，检查软件是否崩溃并对性能进行检查。
5. 在发布的过程中发现了哪些意外问题？
没有啥意外问题（感谢熊助教的提前指导），但是真的十分累人，幸亏肝下来了。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
根据之前的开发经历、个人喜好、能力和团队需要综合考虑进行确定。
应该是比较人尽其才的。比如我们的架构师是 OO 助教，对于整个软件开发很熟悉。美工又很好的美术素养。PM 比较有想法，而且擅长写文档和团结大家。主力实现人员都很肝。自由人啥都会。
2. 团队成员之间有互相帮助么？
当然有了，我们不仅有普通的互相帮助，我们还专门增设了“自由人”的岗位负责救火。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
会议协商，讨论解决方案，挑选一个相对最优解。
总结
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
目前我们属于CMMI中的第三级，明确级。
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我们目前处于创造阶段。我们拥有完善的开发、沟通和管理流程，团队成员知道自己的分工，具有自我驱动精神和能力。
3. 你觉得目前最需要改进的一个方面是什么?
下一阶段继续坚持的问题，alpha 冲刺冲猛了。
4. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
- 删除重复代码、简化复杂的代码、提取通用的代码
- 编写单元测试和集成测试
- 定期进行代码审查和反馈
- 提高代码覆盖率
- 增加注释。
5. 项目管理有哪些具体的提高？
- 更加丰富具体的文档。
- 更加优秀的代码架构。
- 更加明确的原型设计。
- 深度思考交互逻辑。
6. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
- 日活量。
- 我们目前没有办法，这个东西做出来可能会导致安全漏洞。
7. 项目文档的质量如何提高？
- 使用简洁、明确和易于理解的语言编写文档，确保文档有清晰的结构。
- 专人管理，其他成员校对的方式。
8. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
- 我们需要创造一个积极的、鼓励创新的工作环境。
- 培养团队精神，促进队员的密切合作。
482
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
