标签：耦合 影响 工作量 帮助 ack tor 软件工具 als 比较
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件想降低编程语言入门者的障碍，主要在于消除编程入门者对报错提示的恐惧，以及根据其水平为其推荐合适的题目。事实上在 alpha 阶段前我们对这个需求并不是很明确，对需求的了解也是在 alpha 阶段完成过程中慢慢清晰起来的。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
基本完成了alpha阶段前预期的功能，且按原计划时间交付。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
没有上一个阶段。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
alpha 阶段以最小可用功能为目标，暂时不考虑用户量。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
开发过程中不同组的交流是很重要的一个环节。在前期我们三个组的开发过程其实是处于一种相对隔离的状态，导致我们对需求的了解有些偏差，以及没能非常及时地了解新的需求变更，导致后期时间比较紧张。重来一遍的话我们会更加重视这一点。
其实在本次 alpha 阶段中我们并没有花很多时间来做计划，主要是刚开始时对需求仅有一个模糊的把握，同时觉得前端并没有特别大的工作量。但后来发现有一个明确的计划对于工作的推进还是很有必要的。
我们前端组讨论计划时少有出现意见不一致的地方，主要是大多数成员对前端的开发流程不太熟悉。我们对于计划或需求的困惑或不同意主要来自和其他组协作/协商的时候，这时我们会根据双方的具体情况（实现难度等）做出合理的选择。
都完成了。
一开始我们选用 Vuex 做状态管理，但后来我们发现 Vuex 对于我们这个项目没有太大的帮助，遂摒弃了它。
前期计划中是有的。但在 alpha 阶段后期发生了一次比较大的需求变更，为了快速完成功能我们便没有将后期一些任务记录下来。
项目的一个意外是中途出现的需求变更，当时离 alpha sprint 截止只有三天了，这主要是我们没有和其他组很好地交流导致的。alpha 阶段没有出现意料之外的风险，前期预估的一些风险如组员因赶会议无法抽出时间工作等虽然出现了，但并没有造成很大影响。
我们没有设置缓冲区。事实上我们觉得此次alpha阶段后期对接时出现了许多细小的问题，时间有点紧张，缓冲区的设置是有必要的。
beta 阶段开始时我们应该有更明确的需求，并根据需求将任务分成耦合度低的子任务以方便并行开发。同时应该预留一两天的缓冲期，以避免突发情况。
alpha 阶段让我们意识到团队成员交流的重要性。不管是组内或是组间的交流都是很重要的。同时交流时需要有良好的记录，一方面可以避免任何一方的理解出现偏差，另一方面方便事后回顾。
前端组的开发不需要很昂贵资源，至于从整个团队看，我们有服务器硬件资源，时间资源也算是充足的。
一开始时任务需要的时间也只是给出一个上界，毕竟不知道在开发过程中会遇到什么突发的问题。
最终测试的时间稍微有点长，但还在预期内。前端组虽然人少，且有同学在 alpha 阶段有其他任务，但在开发前我们考虑到了这些因素，所以人手也算足够。alpha阶段由于不追求特别美观，所以没有在美工设计等方面花费太多时间。
对于大的变更我们会在每天的scrum同步，每个同学如果有和其他同学工作相关的变更会在teams群中更新，以让对方及时知晓。
在 alpha 阶段开始前就决定做 MVP，因此在确定需求时就商量好了这两点。
好像没有清晰的定义，我们是以完成“必须实现”的功能作为 alpha 阶段的目标的。
在离 alpha sprint 还有三天时我们获知了一些需求上的变更。对此我们及时召开会议并重新制定计划，分配任务，处理得较为妥当。
一般来说遇到意料之外得工作请求或状况，我们组内都由经验较为丰富的成员来解决，以最大程度地节省时间。
alpha 阶段前端暂不考虑界面特别美观，因此所谓设计更多是基本架构的确定。此工作由组长在 alpha sprint 开始之前来完成。组长之前有过相关经验，因此是合适的人选。
遇到模棱两可时多半是我们组和别的组的理解产生了不一致的地方，对此我们鼓励相关同学积极交流以达成一致。
我们没有做单元测试，主要是因为前端的单元测试不是特别 trivial，为了节省学习时间便暂时不做了。开发时我们的测试基本靠手动，以当前的功能来看尚不算特别麻烦。
编辑器的部分，因为这是整个产品中逻辑最复杂的一块。发布时我们发现我们的产品对不同浏览器的兼容性不是很好，对此我们也有预料在先，但由于 alpha 阶段只做 MVP，所以这不算很大的问题。
没有做太多的 code review，主要是时间不足。我们用 Linter 保证代码规范。
团队在 alpha 阶段开始前便确定了 alpha sprint 最后两三天为整体联调的时间。
没有正式验收。
前端没有使用单元测试。
没有相关措施。
联调过程中发现编辑器总有一些意想不到的问题（用户可以以特殊的方式突破限制，现有限制影响了用户体验等等）。
团队的角色根据大家对前端开发的认识和经验以及自身时间安排来确定的，基本做到人尽其才。
当经验少的成员遇到问题时，经验丰富的成员常常会帮一把手。
找 leader 讨论，并由 leader 最终确定。
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
你觉得目前最需要改进的一个方面是什么?
代码管理的质量需要大家都遵守制定好的 workflow，如使用 PR 合并更新等等。代码规范需要项目的初始化者参考相关的最佳实践（借鉴但不盲从），同时利用相关工具如 Linter 保证提交代码的质量。目前尚没有完善的代码复审的制度，这要求整个团队养成相应的习惯。
目前 alpha 阶段以快速实现为主要目标，许多地方没有遵循 Vue.js 的最佳实践，同时有些地方写得比较 hacky。我们也许可以参考 github 上优秀的项目来做重构工作。
阅读官方文档是最快也是弯路最少的办法，许多工具的 tutorials/guide 很值得初学者一读。
alpha sprint 后发现及时的交流能减少开发过程中遇到的问题。scrum meeting 是一种很好的而形式。
可以借助共享写作平台同步文档，当然如果有可能的话，使用相关工具实现 code to doc 是更高效的方式。
对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
对于软件工程的理论，规律有什么心得体会或不同意见？
标签：耦合 影响 工作量 帮助 ack tor 软件工具 als 比较
原文地址：https://www.cnblogs.com/hsfzxjy/p/11945576.html
