事后诸葛亮分析

Alpha冲刺，很多同学经历了“Learning by doing”的学一门新的编程语言、学Git、学做一个完整的项目。但是，各组对于软件工程的“Learning by doing”的内涵了解的还不深刻，遇到的问题也不少。停一停，开个总结会，来次事后诸葛亮，为了下一步走的更好。请各小组在Deadline之前，召开事后诸葛亮会议，发布一篇事后分析报告。

1.总结的提纲内容，请参照课本15章内容或邹欣老师的博客：

a. 项目管理之事后诸葛亮会议：http://www.cnblogs.com/xinz/archive/2011/11/20/2256310.html

设想和目标

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？ 3 每一问1分

相比传统的笔记本记账，电脑等，人们更喜欢通过手机来记账，这样随时随地都可以记录自己的财务明细，更加及时了解自己的财务状况，而不是很麻烦的用笔记本或者开电脑。所以，对于智能移动的终端开发软件类型之一的记账微信小程序设计是非常有意义的。定义比较清楚。典型用户为大学生，很多学生感觉记账是一件麻烦的事儿，不愿意去记录自己的消费情况，从而无法很好的了解自己的财务情况。所以，我们小组所做的就是制作一款专门针对于大学生的记账小软件。通过简要方便的记账形式，便利的操作模式改善或者促进用户记账的积极性及兴趣，让大学生了解自己的消费情况，从而有效控制花费，对自己未来的消费可以制定合适的计划。

和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高？具体提高了多少？如何衡量的? 3 每一问1分

上一阶段即http://www.cnblogs.com/xss6666/p/8824744.html 主要解决的问题有:

1.问题的定义及规划

软件开发与需求放共同讨论，主要确定软件的开发目标及其可行性。

2.需求分析

在确定软件开发可行性的情况下，对软件需要实现的各个功能进行详细需求分析。需求分析阶段是一个很重要的阶段，这一阶段做的好，将为整个软件项目的开发打下良好的基础。“唯一不变的是变化本身”，同样软件需求也是在软件爱你开发过程中不断变化和深入的，因此，我们必须定制需求变更计划来应付这种变化，以保护整个项目的正常进行。

3.软件设计

此阶段中偶要根据需求分析的结果，对整个小程序系统进行设计，如系统框架设计、数据库设计等。好的设计将为软件程序编写打下良好的基础。

如果说上一阶段是小程序开发的理论阶段 那么和上一阶段相比我们进入了实践阶段 即 将小程序设计的结果转化为计算机可运行的程序代码。在程序编码中制定统一、符合标准的编写规范。以保证程序的可读性、易维护性。提高程序的运行效率。

我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?) 3 每一问1分

原计划本软件有如下功能：用户登录，并对用户信息进行保密；(已实现)

可随时增加，删除，修改消费记录；(已实现)

可以统计查询出某天某月等的收入支出；(已实现)

可以对各项消费作预算；(待实现)

可以发现一些好的理财方式；(待实现)

备注功能。(待实现)

原计划达到的用户数量并没有达到 ,因为服务器的配置是个问题 没法发布,所以在Alpha阶段只是面对内部的测试,并没有公测.

用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么? 1

因为服务器的配置是个问题 没法发布,所以在Alpha阶段只是面对内部的测试,并没有公测.所以用户体验不得而知.

计划

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

是,团队成员多同一宿舍,有问题有想法随时都可以交流.

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

多人合作难免产生分歧,不过有分歧是好事，说明大家都在思考问题。需要让大家知道共同目标是为微信记账小程序的开发，实现利益最大化。可在适当的时候组织大家聚会畅谈问题，不知不觉大家就解决了问题,而且不会为这次分歧而产生距离了.

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

原计划本软件有如下功能：用户登录，并对用户信息进行保密；(已实现)

可随时增加，删除，修改消费记录；(已实现)

可以统计查询出某天某月等的收入支出；(已实现)

可以对各项消费作预算；(待实现)

可以发现一些好的理财方式；(待实现)

备注功能。(待实现)

原因:团队成员能力有限+时间有限.

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

一开始又想界面很炫，又想结构新颖，还想使用没有过的新技术，结果进度很慢。

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

并没有每一项任务都有清楚定义和衡量的交付件,功能能简化就简化，界面也简单到极点，尽早做出能用的小程序.

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

并没有按照计划进行,任何事物的发展都是前进性与曲折性的统一.主要问题是服务器的配置 ,没人会.

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

没有.时间太紧迫.

将来的计划会做什么修改？（例如：缓冲区的定义，加班） 2

希望改进整个项目没有指定里程碑或规定设计评审期，什么时间节点完成什么任务不能如期，再去进行下一个阶段的开发计划与实施。摊子铺得太大，人员和准备严重不足。

资源

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

并没有足够的资源.

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

团队成员根据自己擅长的方面在Alpha阶段开始之前进行任务的认领以及自己进行所需时间的估计....精度还行,但是不高....经常有到时间不能进行任务的交付.

测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? 2

小程序完成的并不是很好所以没有更多的精力人力去进行小程序的测试.. 对于那些不需要编程的资源大大低估了其难度,特别啊,是这个博客ＥＭＭＭＭＭＭ．

你有没有感到你做的事情可以让别人来做（更有效率）? 2

有，各种文案的编辑．

变更管理

每个相关的员工都及时知道了变更的消息? 2

能及时知道变更的消息，团队成员多同一宿舍,有问题有想法随时都可以交流．

我们采用了什么办法决定“推迟”和“必须实现”的功能? 2

确定目的， 确定典型用户群体， 准备详细问题。先进行问卷调查，进行问题分组，整理，分析 .提取用户的需求作为必须实现”的功能 .

团队觉得有必要但用户并没有反馈的内容作为"推迟实现"的功能.(用户答不上来的问题，错过的信息，也可能非常重要)

项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么? 2

Alpha阶段仅仅是满足于“软件可以使用”或“功能能够实现”.

对于可能的变更是否能制定应急计划? 1

没有,团队十分脆弱,随时都可能解散了.

员工是否能够有效地处理意料之外的工作请求？ 2

能. 工作进行过程中，难免会出现一些意外情况。为保证项目按计划实施，不受影响，就要学会及时汇报。这样做，一方面可以团队一起商讨进而调整策略.站立式会议均在强调不能将所有步骤都压在完成时汇报，这个时候还是要考虑到每项任务的时间节点。能够在对的时间，把事情提前做好.不能一些问题或者其他都“默默”承受，怕提出的问题让他人认为自己的能力不行等各种考虑，其实完全没有必要.

设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？ 1

在http://www.cnblogs.com/xss6666/p/8824744.html阶段根据需求分析的结果，对整个小程序系统进行设计，如系统框架设计、数据库设计等 .时间合理.

设计工作有没有碰到模棱两可的情况，团队是如何解决的？ 2

设计工作有碰到模棱两可的情况,小事可以含糊过去,比较重要的大家一起探讨再确定.

团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 1

开发时间所限，没有做单元测试。在开发的过程中我们用到了UML图展现各个模块，这样让全体开发人员对于彼此间模块的关联都了解了一下，能大幅提升开发效率。

什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况? 4

增加，删除，修改消费记录功能产生的Bug最多.增加，删除，修改消费记录功能整体的难度是最高的.

1.备注与金额输入为空（增加弹窗提示用户）

2.如果你选择支出但是金额写的是负数，显示出来的还是正数。

3.金额输入字符串，导致合计为NULL,改进成输入字符串弹框提示错误。

原因:没有正规的代码审查;没有使用静态分析工具;没有好好测试

代码复审（Code Review）是如何进行的，是否严格执行了代码规范？ 1

首先每个模块写完，负责的同学都会进行一次自我的代码复审。然后代码汇总后，各同学再一次进行复审。

我们并没有一个严格遵守代码规范，但是我们简要地说明了一些规则来保证代码的可阅读性，例如，变量名尽量起得比较有意义，要进行比较合适的注释，再提交自己部分的代码时要附上自己的测试代码等。

测试/发布

团队是否有一个测试计划？ 2

没有一个十分完整的测试计划。Alpha阶段时间紧任务重，又因为大家都是第一次进行软件工程开发，经验欠缺，无法一开始就制定明确的测试计划。

是否进行了正式的验收测试？ 1

没有.

团队是否有测试工具来帮助测试？ 1

基本上由手工实现。

团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？ 2

没有使用跟踪软件效能的工具，主要还是凭借人工的操作和体验。因此，下一次迭代在这方面要做些功夫。

在发布的过程中发现了哪些意外问题？ 1

服务器配置问题导致的无法发布.

总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次? 1

初始级(initial)。工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定。

计划不能按期完成，大致三种原因，1、计划不合理；2、人员没有抓紧；3、因其它计划外的原因造成延误

原系统的代码规范但没有较好的执行。

开发时因分工不明确，每个任务可能团队所有的人都有参与，这其实出问题的风险是非常大。

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段? 1

散伙阶段。

工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定。计划不能按期完成。

你觉得团队在这个里程碑相比前一个里程碑有什么改进? 1

你觉得目前最需要改进的一个方面是什么? 1

• 计划不能按期完成，以后的阶段会制订更加详细计划，相关成员讨论以决定计划完成日期，制订时间需要科学合理，如果明确后，相关成员需要尽量按时完成，若有特殊原因，比如技术难题，计划外的事情耽误等等，需要给出理由。再由成员共同商议解决时间，以保证全局的进度不受影响。
• 开发的时候，仅仅是满足于“软件可以使用”或“功能能够实现”的情况，并没有关注到每个设计、每次改动、每天的操作。

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。 1

面对面的交谈。冲刺阶段每天都进行站立式会议，讨论项目每个成员的昨天进展、存在问题、今天安排。

及时汇报。这样做，一方面可以团队一起商讨进而调整策略.站立式会议均在强调不能将所有步骤都压在完成时汇报，这个时候还是要考虑到每项任务的时间节点。能够在对的时间，把事情提前做好.不能一些问题或者其他都“默默”承受，怕提出的问题让他人认为自己的能力不行等各种考虑，其实完全没有必要.

可用的软件。 一致的目标都是尽早交付“可用的软件”。

b. 博客要附上全组讨论的照片。

2.根据展示博客中给出的团队成员在Alpha阶段的角色和具体贡献排序：

• 既然同学们上这个软件工程课，那么就希望大家能够认真的参与到软件工程实践中来。当然，同学们的投入程度会有所不同，所以我们就把大家做了哪些工作亮相给大伙看看，把这些情况量化出来，摆在大家面前。 酱油在哪里，大腿在哪里就一目了然。这样我们的团队贡献分就很好决定了。
• **请根据每个团队个人贡献排序，总分为N*20，给出每个人的团队个人贡献分（排序无并列，因此每个人的个人贡献分不同）。**

原文地址：https://www.cnblogs.com/xss6666/p/9039111.html