标签：exit view 应该 技术分享 cmmi 区别 修改 自己的 其他
小组名称：Thunder
项目名称：爱阅APP
小组成员：王航 李传康 代秋彤 邹双黛 苗威 宋雨 胡佑蓉 杨梓瑞
我们组开发的软件组要解决在线阅读和本地导入1阅读。功能领域定义的很清楚，通过典型用户和典型场景又清晰的描述。
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
我们原计划做19个功能，没项任务都按照交付时间交付的。原计划的用户数量为18人（包括组内成员8人），最终实现了18人的用户量。
3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
用户量和用户对重要功能的接受程度和我们事先预想的一致。我们离目标更近了。通过用户的反馈情况来看，我们的需要做以下改进：
1、在计划实现具体功能之前，多采纳用户的意见和建议，这样可以提高用户的满意度。
2、没有明确了解用户对软件的真实想法，也没有很好的了解用户的需求。
1、是否有充足的时间来做计划?
是，有充足的时间来做计划。
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
在Scrum master 的带领下，每位组员发表自己的观点和建议，将观点分类，再对这些分类进行探讨，找出每一个分类的优缺点，最后将矛盾化整为零，意见统一。
3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作都做完了。共共有19个计划，都是按时完成。
4、有没有发现你做了一些事后看来没必要或没多大价值的事?
没有。
5、是否每一项任务都有清楚定义和衡量的交付件?
有比较清楚的定义和衡量的交付件。
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
整个过程都按照计划进行，项目没有特别的意外。在“本地导入”功能的实现中，将本地的很多文档扫描出来，没有具体的分类，导致查找文档费时费力。这是没有考虑到的问题。
7、在计划中有没有留下缓冲区，缓冲区有作用么?
没有留下缓冲区。计划的时候没有考虑缓冲区。
8、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
所有计划要具体落实到每一位成员上，按时完成任务，整体计划中加入缓冲区进行测试，提前发现问题并解决问题。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
首先，制定好所有计划，严格按照计划实施。每天都要开Scrum会议，每位组员都要好好总结自己遇到的困难，分享经验。杜绝一切消极态度。
没有足够的资源。因为大部分小组成员对安卓开发完全不知，都在不断的努力学习。
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
根据大家自我陈述的学习能力和对安卓知识掌握程度来估计所需时间。基本都能在规定的时间内完成。
3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
没有缓冲区，所以没测试。
低估了难度，美工其实不简单啊，结果和预期不一致。
4、你有没有感到你做的事情可以让别人来做（更有效率）?
有。熟悉安卓开发的同学实现一些功能要比我实现这些功能的效率高很多。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
了解自己拥有的资源，好好分配资源，了解相关的技术难度和重点。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据实现功能的难度和用户需求来决定。简单的必须要实现，用户需求度不高且难度大的推迟实现。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有，预期功能都基本实现就算做好了。
4、对于可能的变更是否能制定应急计划?
未能做出应急计划，因为我们未想到一些紧急情况。
5、员工是否能够有效地处理意料之外的工作请求？
按照原计划实施，无意外的工作请求。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
提前考虑到变更情况，并作出相应的应急计划。对意外情况进行防范，并考虑是否添加心计划。
有，设计“实现翻页效果”功能时出现模棱两可的情况。在Scrum Master的带领下，讨论出该功能的存在价值，最终决定实现该功能。
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有用过。
4、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
“实现翻页效果”功能Bug最多。因为要涉及到触屏，所以具体实现起来有很多困难。刚开始单纯的认为，该功能特别简单。
5、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
没有进行代码复审，代码不规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
考虑好各种Bug出现的情况，要对程序进行单元测试，要进行代码复审，要让代码规范。
没有测试计划，未考虑到。
2、是否进行了正式的验收测试？
没有进行正式的验收测试，仅在课堂上演示了一下实现的功能。
3、团队是否有测试工具来帮助测试？
虚拟机、手机。
4、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
只在虚拟机和手机上进行了测试，未进行测量并跟踪软件。有用，多运用测量和跟踪软件，提早找出问题并能及时解决。
5、在发布的过程中发现了哪些意外问题？
没有意外发生。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
测试很重要，要学会用一些有助于优化功能的软件帮助我们改进。
根据每个人的学习能力和拥有的技术能力，做到人尽其才。
2、团队成员之间有互相帮助么？
团队成员有相互帮助。
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
各自表述自己的想法，取利益最大的方案。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
做到人尽其能。
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
属于CMM阶段。
你觉得团队目前处于 萌芽/磨合/规范/创造阶段的哪一个阶段?
我们团队处于磨合阶段。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
知道要用软件来对程序进行测试，多沟通，人尽其能。
你觉得目前最需要改进的一个方面是什么?
设计计划方面，关注用户需求，根据他们的需求和意见修改计划。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
“以有进取心的人为项目核心，充分支持信任他们”。我们都在规定的时间完成任务，互相信任。
九、全组讨论的照片
标签：exit view 应该 技术分享 cmmi 区别 修改 自己的 其他
原文地址：http://www.cnblogs.com/wangh013/p/7792921.html
