alpha阶段问题总结随笔
| 这个作业属于哪个课程 | 课程 |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 这个作业的目标 | alpha阶段问题总结 |
| 置顶博客 | 置顶博客 |
设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
要解决的问题：团队项目管理，个人日程归档，项目进度跟进
很清楚，在之前的文档有对用户和场景的描述。 -
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
未达到目标。
后端的功能点已经完成。
iOS任务筛选以及子任务定义还没完成，其他功能都已完成并能够在真机环境下使用。
安卓端完成进度比较慢，页面尚未整合到一个工程里。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
设想和目标一般都会比较“远大”，实际上进行开发的时候会进行一定的妥协。
如果历史再来一遍，会对在任务确定前和成员进行单独的沟通，对成员个体的能力和任务数目以及难度的匹配程度更高些。
另外会把目标进行拆解，把相对困难的目标放在后面通过产品迭代完成。
计划
-
是否有充足的时间来做计划?
有 -
团队在计划阶段是如何解决同事们对于计划的不同意见的？
以人为本，看冲突的具体情况来定。如果冲突的一方有紧急且急迫的原因，则妥协。如果双方都比较紧迫，则讨论出一个双方都比较能接受的方案。不过目前来讲没有出现过这样的冲突。 -
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
后端工作全部完成
iOS部分没有完成，原因：需要协调出一部分时间给考研复习，开发时间上不是很足够
安卓端没有完成，原因：成员基础比较薄弱，开发经验少，需要比较多的试错和学习的时间 -
有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有 -
是否每一项任务都有清楚定义和衡量的交付件?
有相对清晰的定义，因为任务按照页面和功能点进行划分，所以有一些默认的交付标准，比如功能可以正常使用，页面可以正常显示等。但是没有形成文档。 -
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
因为计划里其实是有考虑到成员的经验问题，所以大体上是有按照计划实行的。 -
在计划中有没有留下缓冲区，缓冲区有作用么?
有，有一定的作用。 -
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
其实问题在于需要实事求是地面对这个工程，加班是不可能加班的，因为不同同学对于这门课程的期望不一样。计划会建立在同学的期望之上进行调整。
当然这并不是说组员想做多少就做多少，而是根据成员的具体情况来制定开发目标和分工
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
计划的制定太模糊或太细致都是有问题的，特别是在风险程度高的模块。
而弹性的时间意味着需要有更多的时间来分配，所以实际上这是一个需要去妥协理想和实际的问题。
如果历史再重来一遍，会对风险模块进行更深度的刨析计划。
资源
-
我们有足够的资源来完成各项任务么?
后端资源、iOS端资源足够
安卓端有一定风险。 -
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间足够
没有低估难度，因为小组里没有比较专业的美工，所以设计还是比较麻烦的。 -
你有没有感到你做的事情可以让别人来做（更有效率）?
有一部分文档工作的整理可以给其他成员来做。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
前一阶段的开发的资源主要是人力资源。因为在冲刺之前已经有很长一段时间的准备工作，所以主要是针对开发的人力资源管理。在进行分配的时候已经根据模块的风险对人员进行分配了。
在人类资源管理的部分，如果历史重来一遍也没有什么可以改进的。
变更管理
-
每个相关的员工都及时知道了变更的消息?
嗯 -
我们采用了什么办法决定“推迟”和“必须实现”的功能?
从两个维度：
是否属于主要的中心功能
是否在技术上可以支撑在日期内无风险的完成 -
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有具体的验收标准 -
对于可能的变更是否能制定应急计划?
可以 -
员工是否能够有效地处理意料之外的工作请求？
iOS端和后端可以
安卓端可能会比较吃力
设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在alpha之前，由项目经理以及比较有开发经验的成员完成。
是合适的时间，合适的人。 -
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，通过大量口头沟通 -
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
单元测试帮助很大，节省了很多后面集成花费的时间。uml有一定效果，但是因为在设计的时候没有根据实际系统进行设计，所以效果还是比较有限的。
从设计的层面来看是没有差别的，从具体实现的层面来看有一定的区别。
我认为不需要更新uml文档，需要更新的是接口文档等详细设计文档。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
具体进行开发的时候也需要大量的沟通，同时需要养成沟通之后进行记录的习惯，保证设计的可追溯性。
如果再来一次会加强对于文档更新和文档变更沟通的管理
测试/发布
-
团队是否有一个测试计划？
有 -
是否进行了正式的验收测试？
还没，因为开发工作还没完全完成 -
团队是否有测试工具来帮助测试？
后端：postman+junit -
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
有关这方面的测试在alpha阶段没有进行。 -
在发布的过程中发现了哪些意外问题？
暂时没有
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
cmm2 可重复级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范
你觉得目前最需要改进的一个方面是什么?
计划管理
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
递增变化：有一些设计上的细节根据进度以及时间上的推进产生变化。比如一开始有一些对于日期的处理在前端进行，后面因为前端开发时间比较紧迫，改成了由后端做，修改了一部分API接口。
快速反馈：前后端交接的时候，会有一些交接上的问题出现，前端反馈给后端后，后端一般都马上回复并进行说明或者修改代码。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
-
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
我认为管理的提高主要是需要衡量两个方面：有效性和成本。我认为提高代码管理的质量主要是要将代码管理过程规范化。
一方面需要加强在编程过程中的代码质量管理，而不是全靠复审，可以通过结对编程或者ide的代码规范插件来做。另一方面是在代码中重视注释，加强代码的可读性，形成以代码和注释为主的轻量说明文档，这样就可以很大程度上减轻审查的压力。 -
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
目前我们的项目因为考虑到避免开发时的冲突，产生了一定的冗余代码。重构代码的话一方面会将这些冗余的部分进行统一。另一方面可能会采用分布式架构来构建代码，从架构的角度提升代码的新能以及拓展性。
架构的质量提高以适应变更的难度来衡量。 -
项目文档的质量如何提高？
明确化定义文档的目标、格式和内容要求。 -
对于人的领导和管理， 有什么具体可以改进的地方？
以人为本 -
对于软件工程的理论，规律有什么心得体会或不同意见？
软件工程的理论是一套工程的理论，他的主体是管理。对于软件开发这种开发工程中，除了一般的工程所需要面临的问题，还特别需要注重对于可追溯性、拓展性、可变性等问题。
同时因为软件开发的主体是人，同时成员之间有紧密的协作关系，所以他产生了更加以人为中心的“敏捷开发”，提升团队的效率。
