第07组 Alpha事后诸葛亮

1.请在博客开头给出组长博客链接（3.1 2分）

团队：摇光

队长：杨明哲

组长博客：这里

2.参考邹欣老师的问题模板进行总结思考（3.2 27分）

设想和目标（2分）

1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们软件要解决的是学生缺乏了解项目、讨论项目、展示项目的平台。定义清楚（面向学生的项目开发博客及辅助开发平台）。有清晰描述（例如想找合适的项目练手的学生，展示项目及招募队友等）。

2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
我们已经达成了部分目标，原计划要完成摇光博客，摇光速浏，摇光编辑器和摇光测评。其中如期交付了摇光博客和摇光速浏功能，摇光编辑器和摇光测评尚未完成。

3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
由于尚未上架测试，还没有用户数据信息。

4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
教训是部分组员对JS不够熟悉导致分工的工作难以协作完成，如果历史重来一定会好好学好JS。

计划（5分）

1.有是否有充足的时间来做计划?
有充足的时间来做计划，我们在作业发布的前一天晚上就开过会了。

2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们团队是以组长为核心的，所有遇到不同意见就在讨论后由组长决定。

3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作没有都做完。因为我们太菜了，组长认为我们没有能力完成原先预定的任务，就简化了一下。

3.有没有发现你做了一些事后看来没必要或没多大价值的事?
其实是有的，因为在刚开始学习的时候，并没有很明确的思路，所以做了不少无用功。

4.是否每一项任务都有清楚定义和衡量的交付件?
是的，我们组在分配任务时就明确地定义了交付时的要求。

5.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
没有都按照计划进行，出现的意外是我们太菜了，所以组长简化了项目。暂时没有风险问题。

6.在计划中有没有留下缓冲区，缓冲区有作用么?
有留下缓冲区，在项目开始之前，我们就定了一个较为灵活的deadline，比如某个界面最理想的deadline是什么时候，最迟是什么时候，缓冲区让我们能够更加灵活的分配时间。

7.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
计划暂时没有要修改的地方，按照原计划进行。

8.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了在团队协作过程中要增强交流，并且要定义好借口的规范，我们做项目过程中就出现了接口接不上的情况。如果历史重来一次，我们会事先更加严格地定义好接口的规范。

资源

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

2.各项任务所需的时间和其他资源是如何估计的，精度如何?
根据任务需要学习的内容难易程度还有开发难度，给与适当的时间；根据实现功能实现需要什么来确定资源，精度一般

3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试时间不充足，由于前面走了一些弯路所以留给测试的时间不是特别充足，人力和软件、硬件资源足够。否。

4.你有没有感到你做的事情可以让别人来做（更有效率）?
这里，emmm，组长做什么都会更有效率，组长nb！

5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
 因为任务有所变动，导致不能使用原先的页面设计，所以只是定了颜色基调就开始页面实现，一开始出来的效果不够好。后面重新布局，经过大家的努力页面总算达到了不错的效果。如果再来一遍，我们会明确所想要的风格，以及一些细节要求，布局合适后再动手实现，就能省去很多不必要的无用功。

变更管理（4分）

1.每个相关的员工都及时知道了变更的消息?
知道，通过博客任务邮箱推送以及群里会艾特全体成员，大家都能及时得到消息。

2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据项目的核心功能，以及实现的可行性，决定实现的优先级别。必要功能如博客渲染展现、GitHub快速浏览“必须实现”，编辑器和测评功能可以“推迟”。

3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有，基本完成核心功能，无明显bug，根据实际使用情况和用户反馈来定义。

4.对于可能的变更是否能制定应急计划?
小部分有计划，无法做到面面俱到，有变更时再做出反应和调整

5.员工是否能够有效地处理意料之外的工作请求？
基本可以，可能会比较简陋，能基本实现，若任务比较难，无法突破，就会成为遗憾。

6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
一起打代码效率很高。多多一起打代码，实时交流！有所突破。

设计/实现（4分）

1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在项目刚刚开始的时候由组长杨明哲提出来的，这是合适的时间也是合适的人。

2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有遇到模棱两可的情况，团队主要核心以队长为主

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

4.比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
刚开始的UML文档更复杂，功能和类更多，但在实际过程中由于时间和技术一些功能被简化，应该需要更新文档。

5.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
博客的逻辑产生的bug最多，因为技术原因，在发布之后还没发现重要的bug，因为刚开发是过于乐观，没有预料到问题会如此复杂

6.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
博客的逻辑产生的bug最多，因为技术原因，在发布之后还没发现重要的bug，因为刚开发是过于乐观，没有预料到问题会如此复杂

7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到很多代码设计与实现方面的思想，如果历史重来一遍，会更加客观理性地分析问题和进行设计工作，不过于乐观。

测试/发布（3分）

1.团队是否有一个测试计划？为什么没有？                 
没有，因为当时没想到

2.是否进行了正式的验收测试？           
没有（功能还没完善完全 所有没有正式验收）

3.团队是否有测试工具来帮助测试？    
没有

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

5.在发布的过程中发现了哪些意外问题？                        
没有

6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?                
学到了怎么测试项目 重来一次，我们会更加认真完成测试项目

团队的角色，管理，合作（3分）

1.团队的每个角色是如何确定的，是不是人尽其才？
是根据大家学习意愿，自己选择前端或者后端学习。还算是人尽其才，大家都尽力做好自己的部分工作，没能完成的也在其他组员的帮助下完成了。

2.团队成员之间有互相帮助么？
有的，大家遇到问题的时候都会在群里发出来，大家一起解决。

3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们大部分情况会选择开会，当面讨论。

4.每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢朱丽辰对我的帮助， 因为某个具体的事情:她的视频很不错。

5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在这一次的alpha冲刺中，我们充分体会到了时间安排和分工明确的重要性，我们因为这两个问题浪费了不少时间。如果可以重新来一次，我们会预先安排好时间，并且更加明确分工和个人工作量。

总结:（3分）

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我觉得团队目前的状态属于CMM/CMMI中的可重复级。

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

3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
我觉得在这个里程碑中相比于上一个里程碑完善了用户需求，对于项目的基础雏形已经诞生。

4.你觉得目前最需要改进的一个方面是什么?
目前项目的功能比较少，因此我认为丰富功能才是应该改进的。

5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
我认为我们小组做得最好的是遵循协作规则在项目中取得更好地成功和稳步工作不应该有生产爆发原则。我们团队有明确的分工，每个人每天定量完成任务，发布在自己的软工小群中。除此还会固定时间在线下开会，讨论任务，比如美工和前端的设计以及前端和后端的连接等等。

3.答辩总结（3.3 6分）

评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例（禁止一锅端平的情况，如果没有评估，全组平均后，组长得分减 50%）

工作流程：先是划分了前端后端，之后因为项目内容调整，增加了编辑器，再次划分工作。

组员分工：

前端：陈碧芬，薛紫微，容慧珺，朱丽辰
后端：杨明哲，林兴源，卞永亨，黄森敏，高星，林鑫

组员工作量比例

团队成员	贡献比例	工作量
杨明哲	30%	分工，后端，博客的拉取，转化和部署
林兴源	4%	做PPT，尝试与队友合作完成摇光编辑器失败
卞永亨	3%	博客评分
林鑫	4%	写了一次博客，做ppt，研究了代码编辑器。
薛紫微	12%	写了第三次博客，参与制作博客页面初始版本和最终版本，参与前端界面的设计，完成了404页面，github走失页面，项目首页，文件列表页面和绑定页面。
陈碧芬	12%	写了第七次博客，参与制作博客页面初始版本和最终版本，参与前端界面的设计，完成了404页面，github走失页面，项目首页，文件列表页面和绑定页面。
容慧珺	11%	参与制作博客页面初始版本和最终版本，参与前端界面的设计，完成了文档页面和项目池页面的编写
朱丽辰	15%	写一篇Alpha博客，设计主页的原型，设计小程序所需物料，参与前端页面制作，演讲ppt，做旱獭视频。
黄森敏	5%	参与制作博客页面初始版本，注册创建小程序项目，制作现场演示小视频
高星	4%	写了两次博客,发布页面，研究代码编辑器

求出本组的现场答辩得分：去除最高总分，最低总分，求平均分（保留1位小数）

83.9

收集其他组对本组提出的问题，并回答（每少回答一点，该项得分扣除10%，扣完为止）

1.除了秒览github，能应用上什么其他的功能吗？
还有发表博客的功能，我们有静态页面同步github上的博客。

2.如何去保证用户量，我觉得一般初学者是不会去用的。
网站的项目速览来的比Github更快，此外这是整合在新的网站中，省去了在GitHub寻找的步骤，起初吸引用户可能比较慢，当项目池达到一定数量应该可以更加吸引人。

3.类似平台功能较完善也较方便，如何突出你们的优势？
优势目前比较微弱，就是速度和整合整理的优势，其他好像没有了。

4.你们对于用户的公共仓库和私有仓库是否有进行区分？
出于对用户账户安全保护，不支持私有仓库

5.未提问

6.未提问

7.相比很多类似平台，你们的优势何在？据我所知，甚至ipad上的类似平台已经很成熟
相较类似的平台，应该说我们的用户范围确定的比较小，就在本高校内。就好像闲鱼、bilibili和淘宝都在卖东西，但是他们的受众面和用户范围不一样，所以都有存在的必要。我们也一样。

8.比起直接用GitHub，除了访问速度还有什么优势吗？
解释同上。请大家减少重复的问题。

9.这个项目的突出优势是什么？
优势，博客支持搜索引擎检索，访问速度快，博客在自己的仓库不会因为，博客平台倒闭而消失

10.服务器那么多的代码如何实现管理？
分路径，存在不同路径下

11.未提问

12.能否给出可运行的源码或Demo：[戳我](https://github.com/jihuayu/github)

PSP与学习进度条（4 4分）

• 个人PSP

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	10	10
Estimate	估计这个任务需要多少时间	10	200
Development	开发	0	0
Analysis	需求分析 (包括学习新技术)	0	0
Design Spec	生成设计文档	50	50
Design Review	设计复审	10	15
Coding Standard	代码规范 (为目前的开发制定合适的规范)	10	20
Design	具体设计	20	20
Coding	具体编码	20	180
Code Review	代码复审	15	30
Test	测试（自我测试，修改代码，提交修改）	10	0
Reporting	报告	10	50
Test Repor	测试报告	5	5
Size Measurement	计算工作量	10	10
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	10	20
	合计	200	220

• 个人学习进度条（每周追加）

• 学习进度条

周数	新增代码（行）	累计代码（行）	本周学习耗时(小时)	累计学习耗时（小时）	重要成长
0-8	为kx打工	不计其数	很多时间	海枯石烂	累死了
9	530	530	2	2
10-11	800	1330	10	1 2
11	1000	2330	9	21
11	300	2630	3	24
12	120	2750	4	28
12	210	2960	3	31
12	300	3260	5	36

博客要附上全组讨论的照片。（3.5 1分）