第一次迭代开发总结

设想和目标

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

　　~解决问题：我们的项目主要是为了软件开发人员在写需求文档的时候，可以对项目中一些固定的模块进行封装，方便于以后在写文档的时候直接引用

　　~定义：快易需求文档编辑系统（从项目名称字面意思可以理解，这个系统是辅助开发人员进行需求文档的编辑）

　　~典型用户：软件开发小组成员，产品经理

　　~典型场景：软件开发项目小组，技术开发公司，大学软件项目开发等需要进行文档编辑的一切对象

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

　　~在项目开始之前，小组成员和指导老师之间多次开会，明确项目的计划分工，并且每周都会开会总结与计划未来一周的任务分工

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

　　~对于计划的不同意见大都会在会议上提出来，大家一起商讨确定最终的周计划

 

 

计划

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

　　~原定计划要实现的功能已经全部完成，只是在一些前端风格上有些不太统一（都是小问题，能很快解决）

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

　　~前期做界面原型设计的时候没有考虑到最后的使用效果，所以做的不是很完美，有一部分是推翻重新做了。（其实也并不是说没有用，对刚开始接手项目的我们有一定的理解作用）

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

　　~没有。有些开发任务是由前期任务引申出来的，所以对有些任务并没有特别明确的衡量交付件

4.       是否项目的整个过程都按照计划进行?

　　~是。每周都会开会总结已完成的任务，查漏补缺，并对之后的任务做一下计划和分工（这里的计划指的是在开发前期的计划框架下，细化到每一个点）

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

　　~有。在项目任务比较繁忙的时候，会抽一定的时间去补补觉、喝喝茶、看看剧，放松一下。缓冲区的作用比较明显，在快hold不住的时候，适当的放松对思考问题有很大的作用

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

　　~不会有太大的修改。一般会根据项目进度和会议讨论结果决定

 

资源

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

　　~在项目准备阶段，我们利用书籍、百度以及购买需要使用的服务器等资源来做准备工作

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

　　~没有做过估计，一般是在工作的过程中根据经验来分配时间

3.       用户测试的时间，人力和软件/硬件资源是否足够?

　　~足够。根据各自任务的完成度，会分配不同模块的模拟测试，完成任务合并之后统一进行了整体性测试

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

　　~大家相互协作完成，遇到问题一起讨论，效率一样很高效

 

变更管理

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

　　~项目的变更信息一般都会在会议上统一通知

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

　　~对于一期版本没有推迟到二期进行的功能

　　~必须实现的功能就是用户在使用该系统的时候能够有很好的体验并得到自己想要的基础结果

3.       项目的出口条件（Exit Criteria）是否得到清晰的定义?

　　~是。对于每一个模块定义都很清晰

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

　　~没有。变更后如果要急需实现，大家会一起合作解决

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

　　~每一周大家都有各自的开发任务，对于其他的工作请求，在能解决的范围内的都会尽快解决

 

设计/实现

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

　　~设计工作是在项目初期动手开发写代码之前，组内成员分工设计前端和数据库。

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

　　~遇到一些比较模糊难以决定的问题时会和指导老师商讨，确定设计方案

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

　　~开发环境使用的是强大的IDEA，在开发时能节省很多不必要的麻烦和时间浪费

　　~另外还使用了UML来帮助大家梳理系统流程及用户操作

4.       什么功能产生的Bug最多，为什么？

　　~bug最多的就是往公共数据库发布构件时会牵涉到用户自身的发布意愿和购买者的权益问题

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

　　~有一些还是严格遵循了代码的规范要求，只是有一部分在审查的时候可能没有太多的去关注，有一些遗漏

 

测试/发布

1.       团队是否有一个测试计划？为什么没有？

　　~有。按照不同的角色去测试不同类型的数据，保证能测试到系统数据的规范性

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

　　~在alpha版本完成之后，统一进行了已实现的功能的多次多组数据测试

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

　　~没有

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

　　~有用。能很快找到项目中的bug

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

　　~项目还没有公开发布给所有用户使用

 

总结

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

　　~CMMI 一级，完成级

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

　　~规范
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进? 

　　~效率会更快
4.你觉得目前最需要改进的一个方面是什么?

　　~在任务分工的时候不能对功能点拆分太细，一个功能的实现要交给同一人，这样效率更好