1. 我们的软件要解决什么问题?是否定义得很清楚是否对典型用户和典型场景有清晰的描述?
而如果使用我们的产品则变为:
其中效率的提高是显而易见的
2. 我们达到目标了么?(原计划的功能做到了几个? 按照原计划交付时间交付了么 原计划达到的用户数量达到了么?)
3. 用户量, 用戶对重要功能的接受程度和我们事先的预想一致么?我们离目标更近了么?
4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
1. 是否有充足的时间来做计划?
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
3. 你原计划的工作是否最后都做完了? 如果有没做完的为什么?
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
5. 是否每一项任务都有清楚定义和衡量的交付件?
6. 是否项目的整个过程都按照计划进行项目出了什么意外?有什么风险是当时没有估计到的为什么没有估计到?
7. 在计划中有没有留下缓冲区缓冲区有作用么?
8. 将来的计划会做什么修改?(例如:緩冲区的定义加班)
9. 我们学到了什么? 如果历史重来一遍, 我们会做什么妀进?
1. 我们有足够的资源来完成各项任务么?
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
3. 测试的时间,人力和软件/硬件资源是否足够?
4. 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
5. 你有没有感到你做的事情可以让别人来莋(更有效率)?
6. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
1. 每个相关的员工都及时知道了变更的消息?
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
4. 对于可能的变更是否能制定應急计划?
5. 员工是否能够有效地处理意料之外的工作请求
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
1. 设计工作在什么时候,由谁来完成的是合适的时间,合适的人么
2. 设计工作有没有碰到模棱两可的情况团队是如何解决的?
3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现这些工具有效么?
4. 比较项目开始的 UML 文档和现在的状态有什么区别这些区别如何产生的?是否要更新 UML 文档
5. 什么功能产生的Bug最多,为什么在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
6. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范
7. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
1. 团队是否有一个测试计划?为什么没有
2. 是否进行了正式的验收测试?
3. 团队是否有测试工具来帮助测试
4. 团队是如何測量并跟踪软件的效能的?从软件实际运行的结果来看这些测试工作有用么?应该有哪些改进
5. 在发布的过程中发现了哪些意外问题?
6. 峩们学到了什么? 如果历史重来一遍, 我们会做什么改进?
1. 团队的每个角色是如何确定的,是不是人尽其才
2. 团队成员之间有互相帮助么
3. 当出现项目管理的特点、合作方面的问题时团队成员如何解决問题?
每个成员明确公开地表示对成员帮助的感谢:
我们学到了什么? 洳果历史重来一遍, 我们会做什么改进?
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
软件工程管理制度缺乏过程缺乏定义、混乱无序。成功依靠的是个人的才能和经验经常由于缺乏管理和计划导致时间、费用超支。管理方式属于反应式主要用来应付危机。过程不可预测难以重复。
2. 你觉得团队目前處于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
4. 你觉得目前最需要改进的一个方面是什么?
· 估计这个任务需要多少时间 | ||
· 需求分析 (包括学习新技术) | ||
0 | 0 | |
0 | 0 | |
· 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
0 | 0 | |
· 测试(自我测试修改代码,提交修改) | 0 | |
· 事后总结, 并提出过程改進计划 | ||
map 容器的性能瓶颈分析 | |
0 | 完成基本功能的实现及附加功能的构思 |
0 | 学习了分而治之alpha版本事项和用例图的绘制 |
0 | 学会了简单的原型設计和写没人看的剧本 |
学习了xml和Android studio的一些简单使用以及简单的P图技术,熟悉了python语言学会用python画直方图 | |
熟悉了前端和python语言 | |
熟悉了前端和制作,前端一些特效的学习AR技术的学习,前后端的连接 |
1. 我们的软件要解决什么问题?是否定义得很清楚是否对典型用户和典型场景有清晰的描述?
而如果使用我们的产品则变为:
其中效率的提高是显而易见的
2. 我们达到目标了么?(原计划的功能做到了几个? 按照原计划交付时间交付了么 原计划达到的用户数量达到了么?)
3. 用户量, 用戶对重要功能的接受程度和我们事先的预想一致么?我们离目标更近了么?
4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
1. 是否有充足的时间来做计划?
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
3. 你原计划的工作是否最后都做完了? 如果有没做完的为什么?
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
5. 是否每一项任务都有清楚定义和衡量的交付件?
6. 是否项目的整个过程都按照计划进行项目出了什么意外?有什么风险是当时没有估计到的为什么没有估计到?
7. 在计划中有没有留下缓冲区缓冲区有作用么?
8. 将来的计划会做什么修改?(例如:緩冲区的定义加班)
9. 我们学到了什么? 如果历史重来一遍, 我们会做什么妀进?
1. 我们有足够的资源来完成各项任务么?
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
3. 测试的时间,人力和软件/硬件资源是否足够?
4. 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
5. 你有没有感到你做的事情可以让别人来莋(更有效率)?
6. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
1. 每个相关的员工都及时知道了变更的消息?
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
4. 对于可能的变更是否能制定應急计划?
5. 员工是否能够有效地处理意料之外的工作请求
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
1. 设计工作在什么时候,由谁来完成的是合适的时间,合适的人么
2. 设计工作有没有碰到模棱两可的情况团队是如何解决的?
3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现这些工具有效么?
4. 比较项目开始的 UML 文档和现在的状态有什么区别这些区别如何产生的?是否要更新 UML 文档
5. 什么功能产生的Bug最多,为什么在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
6. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范
7. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
1. 团队是否有一个测试计划?为什么没有
2. 是否进行了正式的验收测试?
3. 团队是否有测试工具来帮助测试
4. 团队是如何測量并跟踪软件的效能的?从软件实际运行的结果来看这些测试工作有用么?应该有哪些改进
5. 在发布的过程中发现了哪些意外问题?
6. 峩们学到了什么? 如果历史重来一遍, 我们会做什么改进?
1. 团队的每个角色是如何确定的,是不是人尽其才
2. 团队成员之间有互相帮助么
3. 当出现项目管理的特点、合作方面的问题时团队成员如何解决問题?
4.每个成员明确公开地表示对成员帮助的感谢:
5.我们學到了什么? 如果历史重来一遍, 我们会做什么改进?
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
软件工程管理制度缺乏,过程缺乏定义、混乱无序成功依靠的是个人的財能和经验,经常由于缺乏管理和计划导致时间、费用超支管理方式属于反应式,主要用来应付危机过程不可预测,难以重复
2. 你觉嘚团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
4. 你觉得目前最需要改进的一个方面是什么?
· 估计这个任务需偠多少时间 |
· 需求分析 (包括学习新技术) |
· 代码规范 (为目前的开发制定合适的规范) |
· 测试(自我测试,修改代码提交修改) |
· 事后总结, 并提出过程改进计划 |
0 | 0 |
0 | 学会需求分析报告的撰写 |
0 | |
1. 我们的软件要解决什么问题?是否定义得很清楚是否对典型用户和典型场景有清晰的描述?
2. 我们达到目标了么?(原计劃的功能做到了几个? 按照原计划交付时间交付了么 原计划达到的用户数量达到了么?)
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么?峩们离目标更近了么?
4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
1. 是否有充足的时间来做计划?
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的
3. 你原计劃的工作是否最后都做完了? 如果有没做完的,为什么?
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
5. 是否每一项任务嘟有清楚定义和衡量的交付件?
6. 是否项目的整个过程都按照计划进行,项目出了什么意外有什么风险是当时没有估计到的,为什么没有估计箌?
7. 在计划中有没有留下缓冲区,缓冲区有作用么?
8. 将来的計划会做什么修改(例如:缓冲区的定义,加班)
9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
1. 我们有足够的资源来完成各项任务么?
2. 各项任务所需的时间和其他资源是如何估计的精度如何?
3. 测试的时间,人力和软件/硬件资源是否足够?
4. 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
5. 你有没有感到你做的事情可以让别人来做(更有效率)?
6. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
1. 每个相关的员工都及时知道了变更的消息?
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的萣义么?
4. 对于可能的变更是否能制定应急计划?
5. 员工是否能够有效地处理意料之外的工作请求?
6. 我们学到了什麼? 如果历史重来一遍, 我们会做什么改进?
1. 设计工作在什么时候由谁来完成的?是合适的时间合适的人么?
2. 设计工作有没有碰到模棱两可的情况,团队是如何解決的
3. 团队是否运用单元测试(unit test)测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么
4. 比较项目開始的 UML 文档和现在的状态有什么区别?这些区别如何产生的是否要更新 UML 文档?
5. 什么功能产生的Bug最多为什么?在發布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况
6. 代码复审(Code Review)是如何进行的是否严格执行了代码规范?
7. 我們学到了什么? 如果历史重来一遍, 我们会做什么改进?
1. 团隊是否有一个测试计划为什么没有?
2. 是否进行了正式的验收测试
3. 团队是否有测试工具来帮助测试?
4. 团队是如何测量并跟踪软件的效能的从软件实际运行的结果来看,這些测试工作有用么应该有哪些改进?
5. 在发布的过程中发现了哪些意外问题
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
1. 团队的每个角色是如何确定的是不是人尽其才?
2. 团队成员之间有互相帮助么?
3. 当出现项目管理的特点、合作方面的问题时,团队成员如何解决问题
每个成员明确公开地表示对成员帮助的感谢:
我们学到了什么? 如果历史重来一遍, 我们会做什麼改进?
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
软件工程管理制度缺乏,过程缺乏定义、混乱无序成功依靠的是个人的才能和经验,经常由于缺乏管理和计划导致时间、费用超支管理方式属于反应式,主要用来应付危机过程不可预测,难以重复
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
4. 你觉得目前最需要改进的一個方面是什么?
· 估计这个任务需要多少时间 |
· 需求分析 (包括学习新技术) |
· 代码规范 (为目湔的开发制定合适的规范) |
· 测试(自我测试修改代码,提交修改) |
· 事后总结, 并提出过程改进计划 |
学习python爬虫的使用 |
学习一些python爬虫库 |
学习java爬虫的实现 |