题目: 团队作业——Alpha冲刺
17秋 软件工程 Alpha 事后诸葛亮会议
关于评价与建议的反馈
评价1：管理部门我觉得对我已经用处不大了不过对新生用处很大。像学长说的一样，里面不是流程很懂但是界面我们还是可以看一下的。
答1：感谢反馈；我们会在之后的展示中更加注意细节，充分准备相关模块的演示。
评价2：很棒啊完成度很高，UI也很成熟！但是一开始需求中提到的“根据收集部员课表直接生成排班表”似乎没有体现？
答2：非常感谢；我们团队根据需求规格说明书，分析得到用户使用产品中所需实现的基本功能并赋予不同优先级，并在Alpha冲刺阶段中实现了大部分；由于时间有限，我们将在Beta冲刺阶段完成剩余功能，包括"根据收集部员课表直接生成排班表"功能。
评价3：通知最好可以群通知，还要有反馈的功能，比如活动通知，希望可以看到有哪些部员参加什么的。
答3：感谢您的评论；群发通知已被我们列为Beta版本需要开发的主要功能模块之一，活动通知模块的反馈功能也在开发清单中，敬请期待！
感谢各组对我们项目的评论与宝贵的建议，我们在下一阶段取长补短继续前进，同时欢迎各位与我们进行项目互测！
项目的预期计划
详见：
Alpha冲刺阶段需完成的模块包括：
- 部员模块
- 账号管理：账户登录，修改信息以及绑定手机
- 提交入部申请，查看活动通知
- 查看排班，请假/换班以及活动签到
- 管理员模块
- 账号管理：账户登录，修改信息
- 新建/解散部门，一键排班
- 发布通知，发送短信/邮件
- 超级管理员模块
- 登录功能
- 审批活动申请以及新建部门申请
项目的现实进展
Alpha冲刺阶段实现的模块包括：
- 部员模块
- 账号管理：账户登录，修改信息以及绑定手机
- 提交入部申请，查看活动通知
- 【未完成，进度为50%】查看排班，请假/换班以及活动签到
- 管理员模块
- 账号管理：账户登录，修改信息
- 新建/解散部门，一键排班
- 活动添加/发布/查看
- 发送短信/邮件
- 发布通知，发送短信/邮件
- 超级管理员模块
- 【未完成，进度为10%】登录功能
- 审批活动申请以及新建部门申请
注：若未标注未完成，即表明该功能已实现。
完成项目过程中的体会
世强：Alpha阶段，让我再次拾起android开发，由于三四个月没写过APP，开始手有点生，随着项目的推进，手感也慢慢找回来了，除了把之前获得的知识重温一遍，也拓展之前学的东西，如retrofit2,okhttp3,RxJava,greenDao等等框架。这个阶段继续写了很多代码，编码能力和代码规范得到进一步提升。
陈翔：冲刺结束了。本次冲刺历时12天，因此和团队的各位一起度过了难熬的12个夜晚。过程中提升了个人的编码能力和解决问题的能力，学习了诸如使用Flask框架搭建Web后台等知识方法。更重要的是和大家一起完成了整个项目的过程，是十分难忘且宝贵的经历。(发际线又高了呢)
树民：Alpha阶段的这十二天来，我学习了python语法，以及python的flask restful框架。在这12天中，我逐渐了解到了队友间帮助的重要性，这对整个项目都有很大的促进作用，同时也意识到一个好的文档的重要性！有时候只有逼自己一把才行。虽然这12天的成果不想预想中的那么好，但是接下来我会把之前不懂的继续学习，帮助团队开发。
杰麟：经过这12天的alpha冲刺，就好像一口吃掉了个大胖子，接触到的几乎都是全新的知识…后台框架、api、github管理……虽说不能细嚼慢咽每一口，但这段时间中逼迫自己拿出最高的学习效率去学习，也让我体验到很真实的软件开发过程。最深刻的体会还是自己学了一天都不及大神传授的10分钟，然后马上就可以着手参与到后台开发中，很感谢在不懂的时候队友们都愿意耐心的回答我。不管beta阶段是否还能和大家一起，都很开心这段时间的相处，更多的是充实的感觉，贡献的不多，严格上来讲就一两个接口，充实的是在这优秀的氛围里每时每刻脑袋的学习。因为我比较特殊，我是中途插进来的，很感谢大家收留我，所以我已经很满足，我已收获满满，在了解到与进入企业至少是个有用之人的距离以后，确立了今后的学习方向和目标，最后感谢主办方感谢栋哥感谢软工感谢父母感谢嘻哈侠…
媛媛：这次Alpha阶段，我参与了后台部分接口的编写，重新拾起java的学习，学习了解了springboot框架。过程中虽然很累，但是在项目的设计、构建、开发、测试、部署一系列过程中，我对软工的认识一步步加深。
诗尧：听了很久的后台编写却没了解具体是实现什么，这次alpha冲刺我参与了后端部分接口的编写，学习了一波spring boot 框架的使用，参与了项目的设计 构建 开发 测试 部署完整的项目周期。框架使用遇到了一些小问题但都被强大的coderQiang解决，代码编写受到代码规范的约束及coderQiang的影响，将代码分模块编写，思路更加清晰。聚在一起写写代码还是很有意思的，前期下载IDE学习相关语法进展缓慢，希望再提高编码效率。
伟航：本次Alpha阶段，我主要做了app端的原型设计与构建。这是我第二次用sketch绘制原型，让我更熟悉了设计APP的逻辑结构的方式，安排了界面跳转逻辑、UI编排设计，参与设计大部分APP功能，对软件设计有了更深的了解。
港晨：这一次软工实践到目前Alpha阶段正式结束。因为我们小组的项目主要是在app端上，所以在WEB上所花费的时间比较小，难度也比较低。在这个项目上我并没有使用框架，都是利用的原生语法，所以在布局和兼容等问题上耗费了一些时间。总的来说对JS语法的理解和CSS布局问题上有了一些新的理解。希望在接下的beta阶段可以学到东西。
团队成员的分工及在Alpha阶段的工作量比例
分工协作：
- Web后端开发：树民、陈翔；
- APP后端开发：世强、诗尧、媛媛、杰麟；
- 项目前端开发：港晨；
- APP原型设计：伟航；
- APP美工：诗尧、媛媛；
- APP文档：陈翔；
- 产品经理：陈翔。
工作量计算完全参照Scrum1列出的计算规则，详见：Scrum1。
工作量比例(%)：
- 世强 16.27
- 港晨 14.05
- 陈翔 13.09
- 树民 13.76
- 杰麟 12.99
- 媛媛 10.97
- 诗尧 10.30
- 伟航 8.57
下阶段展望与团队总结
设想与目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件针对部门日常的活动进行设计，避免如"逐个发送活动消息很麻烦，还要确认对方是否收到"等繁琐操作，方便简化部门管理人员的工作，通过节省社团中管理人员到部员的冗余沟通时间，实现高效率的社团管理解决方案。
定义见需求规格说明书：需求规格说明书
典型用户和场景见系统设计：系统设计
是否有充足的时间来做计划?
坚持每天晚上面对面Scrum会议，每次会议都有足够的时间，在会议的开始阶段会根据昨日项目的进展对每个人今日需完成的内容进行规划。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
通过以下方法：
- 如果是技术方面的内容，由对应功能模块的开发人员互相协调；
- 如果是项目管理、进展方面的内容，在团队面对面时会详细讨论，PM和组长权衡得出结论。
计划
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大部分完成，但是有小部分未完成。原因主要因为成员经常外出，如参与比赛、实习等；
有没有发现你做了一些事后看来没必要或没多大价值的事?
无，完全按照项目计划和需求规格说明书执行。
是否每一项任务都有清楚定义和衡量的交付件?
有明确清楚的定义；按照需求规格说明书的标准对所开发的功能进行验收。
是否项目的整个过程都按照计划进行？
是。
在计划中有没有留下缓冲区，缓冲区有作用么?
每天的开发计划中有安排缓冲区。原因有：
- 团队成员进度不一致，有些模块实现耗时长，在完成验收时容易出问题；
- 各个模块在对接合并时需要磨合的时间。
将来的计划会做什么修改？
我们会根据Alpha阶段用户的反馈、各组宝贵的建议以及助教的反馈进行计划的修正，主要包括：
- 将修复已知bug列入计划；
- 根据反馈建议优化现有模块。
资源
我们有足够的资源来完成各项任务么?
有。
各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务所需的时间计划见：
一个是根据项目成员以往的开发经验，另一个是根据需求规格说明书中的功能复杂性评估模块完成时间。按照目前开发的进展，精度有较小误差，但基本符合预期。
用户测试的时间，人力和软件/硬件资源是否足够?
用户测试的时间从15分钟到1小时不等。足够。
你有没有感到你做的事情可以让别人来做（更有效率）?
有。由于Alpha时间、成员时间有限，我们在制定每日计划时考虑到熟练度这个方面，将熟悉某个模块的成员以开发或协助的形式参与到该模块的工作中，调控了整体项目的开发速度。
变更管理
每个相关的员工都及时知道了变更的消息?
是的，有两个途径：一个是线下面对面，一个是通讯工具或Github消息邮件通知。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
有以下方法：
- 1.查阅需求规格说明书，判断功能实现优先级；
- 2.面对面讨论协商；
- 3.若上述两种方法没有得出结论，由PM和组长协商决定。
项目的出口条件（Exit Criteria）是否得到清晰的定义?
在系统设计和需求规格说明书中有详细且清晰的定义：
对于可能的变更是否能制定应急计划?
我们在每个模块的开发过程中留有一定的调整空间并加以合理注释；对于需求变更，一是明确用户需求修订需求规格说明书；二是确定需要改动的功能有哪些；三是相关人员面对面讨论确定计划安排。我们认为在需求变更时，我们具备制定应急计划的能力。
员工是否能够有效地处理意料之外的工作请求？
能。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
大体的项目框架和预期实现功能在项目开发之前，主要是在需求分析和系统设计时完成；由组长世强、PM陈翔还有原型设计伟航完成；我们认为是的。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有。我们通过面对面讨论分析出现该情况的原因，在剖析情况之后确定最终的设计实现。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
我们运用了单元测试对项目功能模块进行正确性检验；
没有使用TDD，原因是：冲刺时间短，测试驱动的代码编写消耗的时间成本过高，对于我们团队来说并不合适。
使用UML设计项目类图等，详见：系统设计。
这些工具对于我们的团队开发而言很有效，例如通过单元测试能够及时发现代码中的问题、UML能够让我们明确项目的整体架构等。
什么功能产生的Bug最多，为什么？
图片上传，对于不同Android版本来说该功能不稳定；主要原因：高版本Android对文件共享增加了安全性措施。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
项目的主要管理方法是Github：使用Git进行源码管理，每个成员熟悉使用Github并将主repo fork生成自己分支，编码之后提交Pull Request，经过PM和项目模块其他成员review和探讨之后实现merge。不同模块的开发人员在该模块下的PR中进行code review，在遇到冲突时通过协调解决。
严格执行代码规范，其中Java代码遵守阿里巴巴代码规范规约，并使用代码规约插件检测。详见：系统设计
测试/发布
团队是否有一个测试计划？为什么没有？
有，详情见：测试报告。
是否进行了正式的验收测试？
进行了，详情见：测试报告。
团队是否有测试工具来帮助测试？
有，使用了travis CI、JUnit以及postman，详情见：测试报告。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
跟踪软件的效能测试对于我们的项目来说是很有帮助的。我们通过编写UI集成测试，对整个APP的逻辑进行检验，并统计运行步骤耗时，从而找出性能瓶颈。测试代码只需编写一次，且每一次APP版本构建会自动执行全部测试。
需要改进的地方有：
- 1.测试需覆盖所有可能出现的用户行为；
- 2.目前测试只针对部分模块，需要继续集成剩余模块的测试。
在发布的过程中发现了哪些意外问题？
在发布的过程中，我们团队遇到的问题有：
- 1.Android系统版本的兼容性，如Android 7.1 及其以上版本，官方对文件的共享安全性进行了升级，导致上传图片功能存在问题；
- 2.接口安全性存在不足。
下阶段展望
Beta版本开发阶段需要完成的功能有：
- 一键排班功能；
- 短信群发功能；
- 活动签到功能；
- 部门活动相册；
- 部门解散与人员开除；
- 部门消息主动推送；
- 管理员后台权限验证；
- 完善后台Web端，包括列表数据分页功能和Web页面。
团队总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMM二级，即管理级。
团队在初期制定了初步的分工安排并在项目开发中逐渐完善，在每一天的Scrum会议中对昨日的项目进展和今天需完成的任务进行归纳与总结，并通过代码复核、正确性测试等手段标准化项目开发过程中的管理；此外，及时调整开发节奏，在保证质量的前提下完成每日安排的任务。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段。
- 团队在初期组建时大家都互不熟悉，彼此之间对对方的技术了解并不太全面，但在经过需求规格说明书的制定和项目几次Scrum会议之后逐渐熟络起来。
- 每天晚上的项目开发有条不紊，大家根据前一天的完成的工作及沟通讨论，合理分配工作计划得出今日安排，进展相对平稳，12次会议都没有出现“早退”和“晚归”的情况；
- 当项目开发遇到冲突，如代码合并冲突时，通过面对面Code Review的方式解决；同时要求每个人遵守合理的Github项目团队开发的规范，保证项目的整体质量和开发进展。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
有以下几点改进：
- 1.团队配合更加默契，前后端模块对接的速度在Alpha冲刺后期明显加快；
- 2.每日的Scrum会议都或多或少地发现项目当前进展中的一些问题，在解决的过程中提升了编码能力，拥有了一些宝贵的经验；
- 3.由于人员经常外出变动，项目开发中的人员管理也是我们团队在本次Alpha开发中遇到的难题。通过合理的人员任务分配和调度，避免了项目部分模块进度的停滞。该方面相比之前有了更加成熟且代价小的解决方法。
你觉得目前最需要改进的一个方面是什么?
技术方面需要改进的有：
- 1.在与主页面同级的页面下（比如说活动页面），按下返回键应该回到主界面，而不是直接退出；
- 2.超级管理员管理系统的UI；
- 3.接口的安全性需要改进，接口的规范性也需要进一步商榷。
其他方面需要改进的有：
- 1.文档编写；看了晨瑶组的文档和博文，每一篇的描述都很详细同时符合要求，我们的博文在这个方面尚有不足，会向他们看齐；
- 2.前后端在整体的架构和规范方面的沟通与协调；
- 3.Github PR的签入粒度。
不需要改进的有：
- 敲代码的环境要是有奶茶就更好了；
- 敲代码的环境要是有零食就更好了；
- 敲代码的环境要是有程序员鼓励师就更好了；
要是不用敲代码就更好了。