设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
……我们软件很明确的定义为，实现微信图书销售小程序
……典型用户：广大微信用户
……典型场景：微信小程序
2. 我们达到目标了么（原计划的功能做到了几个？按原计划交付时间交了么？）
……原计划功能： 实现用户登录，我的页面（包括：用户账号信息修改，用户查看订单，对订单进行管理，收货地址管理（增删改查），查看图书收藏，查看店铺收藏，点击对应的收藏店铺可以进入店铺详情页面），图书商城首页（包括搜索模块，新书上架，热销榜，猜你喜欢），图书分类页面（包括上方搜索框，图书分类栏，图书显示），购物车页面（可创建订单，选择收货地址），高调用的页面---图书详情（内含对图书所属的商店进行收藏，对图书进行收藏，查看图书评价，评价在订单里面进行评价，加入购物车功能）。
……实现情况：
全功能已经实现
……交付：
按期交付，但是服务器一期没有配好，该小程序只能在本地模拟器进行。
……经验教训：
由于前端由3个组员进行开发，每个人的布局分格斗不同，导致对接时会发现有不少问题，带来不少麻烦，而且前期每个人都是自己的开发者工具上进行开发，对接的时候处理了很久，后来在验收前一周采用github工具进行开发，在对接的问题上变得十分简单。
计划
1． 是否有充足的时间来做计划?
我们组在开发之前花了大量时间来做准备，包括需求分析，微信小程序的开发与PHP后台开发的学习，反复和老师确认需求，迭代计划的编写，第一次迭代的UML图绘制，数据库的设计与完善，前端页面的与后台请求的确认以及相应格式的统一，开发阶段的具体分工，每一个周末整个组一起讨论，一起完成。大家也都很积极配合，也正因为前期花了大量时间准备，所以我们组的进度很快，我们组的开发效率很高，所以一起开发就很顺利的进行与完成。
2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
在计划阶段也有遇到一些不同的意见，这也很正常，我们也很好的解决了，比如说：
a) 需求分析阶段：首先我们根据老师的文档列出所有需要实现的功能，这时就有些组员反馈需求太多，可能完成不了，毕竟时间太短。这是我们组内就一起讨论以及和老师沟通，根据组内成员的能力来确定，去掉一些要求太高的需求。这样问题就很好的解决了嘛。
b) 数据库设计阶段：设计数据库的时候有不同意见我们就会根据老师上课讲的方法以及书上的内容一起分析到底采用哪种方法才能让数据库更加高效合理，没有冗余等。
c) UML图的绘制：因为我们项目的UML图比较多，所以我们就分工绘制，每个人负责几个文件，最后有什么问题再一起讨论，所以这部分并没有什么不同的意见。
3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
由于我们的前期准备做的很充分，所以我们的开发效率就很高，并且管理模式也很合理，一次迭代的计划就全部完成了，并且我们是提前完成的。
4.有没有发现你做了一些事后看来没必要或没多大价值的事?
柴博宇：我们第一次迭代的时候没有使用代码管理工具，所以最后整合代码的任务就很重，整合就搞了一天多吧，应该早点使用Github的。
黄富枝：咋们应该早点分工的，这样效率可能会更高。因为前几周都一直在看微信小程序开发，最后却做的是后台开发。
刘明杰：早知道云服务器有校园版的，我们就不用花那么多钱了买服务器了啊。
汪庆祥：早知道原型设计可以用专门的软件完成，我们就用不着在草稿本上苦逼的画图了，还画的很难看。（别急，咱们先稳一手）。
黄帅：早知道用PowerDesigner可以用来设计数据库概念模型并且可以自动生成物理模型，我们就用不着在其他地方画了E_R图，还要画一遍物理模型，太浪费时间了。
5.是否每一项任务都有清楚定义和衡量的交付件?
定义：对于每一个模块，每一个功能，每一个请求，我们都在开发文档中写的很详细，开发的时候完全按照我们自己的标准来，如果发现有什问题就及时商量修改。
交付件：因为我们是把任务具体分配到每个人身上，所以自己负责自己的部分，最后提交代码汇总。
6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目的开发流程我们完全是按照老师给的软件管理流程来做的，而且基本上都是提前完成任务。
如果硬要说过程中有什么没有预料到的意外，那可能就是我们没预料到老师会一直给我们加需求，开一次会加一次需求，让我们就有点慌。
7.在计划中有没有留下缓冲区，缓冲区有作用么?
因为我们第一次迭代是提前了一周多时间完成的，所以留下的缓冲时间就很多，我们也是考虑到留长一点时间用来测试，为第一次验收做好充分的准备。
作用肯定是有的啊，在缓冲的时间内，我们测试出了不少的bug，才让第一次验收比较完美。
8.将来的计划会做什么修改？
管理模式：我们组的氛围比较活跃，大家关系也都很好，一起做事的积极性很高，所以希望我们能坚持下去。
开发模式：我们开发都是严格按照计划来的，经过第一次迭代的验收，开发效率还挺高的，所以方法应该是没什么问题的，二期要继续坚持下去。
9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
柴博宇：
在团队的合作项目中，学习到了很多开发的知识，也学习到了部分PHP知识。虽然花了很多时间进行页面设计，但最后看着自己完成的页面还是很有成就感的。最后的一期整合是由我进行的，由于项目的分散，整合用时大大超出了我的预期，尽管如此，还是顺利的完成了整合，但整合的艰辛让我决定带动组员使用github。
如果能重来，一定要选对项目啊……还要选对PM……
黄富枝：
经过团队项目第一次迭代开发，学习到了PHP后台开发的知识，感受到了PHP开发的魅力，并且设计数据库的过程实践了不少老师讲的理论，感觉很好。
如果能重来，我们可以继续优化一下后台代码，减轻服务器的压力。顺便可以参与一下前端的开发。
刘明杰：
因为自己是前端开发的，完成之后看到自己做的页面，心中感到无比的自豪，当然也是因为自己学习到了很多开发的知识，现在已经熟练掌握了，感到很充实。
如果能重来，可以再把界面设计的更加完美。
汪庆祥：
做事一向很稳，总是要追求完美，所以做东西之前一定要做好充分准备，当然做出来的东西肯定也是很完美了。很享受这种边学边做的过程。
如果能重来，一定要做一下另外两位同学的页面，来证明一下自己的实力。
黄帅：
作为PM，当然是感触很多了，首先我是写后台代码的，这让我对MYSQL语言更加熟悉了，也对PHP后台开发有所收获。然后是与一群关系很好同学做事情，收获到的不仅是知识，更是一直人与人之间的信任，所以感觉很不错，我也很喜欢我们团队。
如果能重来，我会选择去做一点前端的页面，毕竟自己也感到很好奇想去学习。
资源
1、我们使用了哪些资源？
资金：用于进行服务器的购置；
图书资源：我们从当当网收集了100本图书的信息录入了数据库用作项目测试资源；
人力资源：团队一共由五个人构成，我们按照前端页面和后端服务两个部分分别分配了3个人和2个人进行开发；
时间：为了保证开发的顺利进行，在迭代开发前期我们花费了大量的时间学习开发相关的知识，同时开发过程也花费了不少时间。
2、资源是否足够我们完成各项任务？
资源中限制我们项目的主要是时间。资金对于我们来说仅仅用于购置服务器并没有额外花费的需求，人力资源从我们一期迭代的结果来看分工合理，并没有出现工作量严重失衡的情况；时间是限制我们项目的一大因素，在有限的4周内完成一期迭代部分的开发和测试对我们来说是一个不小的挑战，尽管如此，我相信我们已经在着4周的时间中做到了最好，虽然不能称之为完美。
3、各项任务的时间是如何分配的，精度如何？
我们认为合理分配任务时间的前提是对项目以及编程语言/工具有了充分的了解。最开始我们并没有自信能确定一个明确的时间，仅仅是粗略的根据感觉的任务量来进行时间分配。随着一期开发的进行，我们对项目越来越熟悉，我们根据积累的经验再次对一期开发的各部分的时间进行了调整，尽管并不能精确到小时，但仍能保证项目按照计划进行发展，各部分花费的时间均在预期内。
4、是否存在低估/高估某一部分的所需时间的情况？
这种情况肯定存在，在开发前期的数据收集过程中，我们严重的低估了收集图书信息所需的时间，花费了比预计时间多3倍的时间，值得庆幸的是我们预留了足够的缓冲时间并且在我们后续的努力中很快“追回”了时间误差。此外，我们也严重低估了一期结束时各部分汇总的时间，尽管我们使用了腾讯工蜂来进行代码管理，但在整合过程中出现的一系列连接问题仍然超出了我们的预计，这导致我们不得不匀出一部分用于测试的时间来进行整合。
4、有没有感觉到自己的事情可以让别人来做(更有效率)？
我们认为在任何一个团队中都有水平很高的人来作为团队的支撑，每个人有时都会认为自己的部分交给这样的“大佬”来进行将会更有效率，然而团队是以合作和相互促进发展的目的建立的，除非有接管的绝对必要，否则我们认为做好自己的部分(即使效率确实不如让他人来做)更有助于自身水平的提高，同时这也是团队的进步。
5、有什么经验教训？如果历史重来一遍我们会做什么改进？
严重低估部分任务需要的时间是我们最大的教训，连续两次对任务时间的低估造成我们用尽了预留的缓冲时间还消耗了其余项目的规划时间，如果再来一次我们将会增强开发过程中各部分负责人之间的交互，避免在整合部分浪费太多时间，同时我们会根据积累的经验重新审视项目的时间规划，调整预留的缓冲时间，增加可能会出现问题的部分的规划时间。
没有考虑到项目过程中可能出项的“突发情况”，在一期迭代中期组员的开发工具崩溃需要重装，延误了服务端与前端页面的对接，还好在其余组员的帮助下很快解决了问题没有影响到其余部分的开发。
会更加注重代码规范，在一期迭代开发过程中，尽管我们使用了自认为的比较合理的命名方式来对各个组件和变量来进行命名，但仍然出现了组件重名的情况，在小组间代码互检时也因此被扣了分数，这次经历让我们更加重视代码规范，在二期迭代开发过程中也会注意这方面的问题。
变更管理
1. 每个相关的员工都及时知道了变更的消息？
……我们团队编程前期这点做得还不错，前后台的代码开发双方都有交流，通过项目团队的QQ群可以及时知道改动，同时每个页面跳转之中的逻辑联系、传值都有交流。问题在于页面整合的时候，由于很多页面，每个人做的部分，图片存的地址等等问题，改动部分较多，花的时间较长，后来采用了github管理，这部分的问题基本没有了。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？
……我们一期迭代前已经确定了项目最终要实现的功能，我们一期是实现主要功能，主体部分（普通用户使用得到的功能，基本上淘宝能做的我们都能做，除了支付那块是假支付，只能改变订单，但却没有钱到老子的腰包里面），二期打算完成一些附加功能（推迟部分）
3. 项目的出口条件有清晰的定义吗？
……对弈Aphla版本，我们只要能做到普通用户的所有体验和假支付基本上已经可以出口了
4. 员工是否能够有效第处理意料之外的工作请求？
……那我们在这方面必须棒棒哒，如果从边老师原来给我们的项目需求，其实我们一期已经完成了，但是和指导老师每见一次面，就会多出很多新需求，诸如实现聊天，VIP，在APP端实现管理者模式，店家模式（图书管理员）等等功能，我们组员都能快速应对，对数据库进行微改，分工等等。
5. 对于可能的变更是否能制定应急计划？
……这方面我们小组都很优秀好吧，我们的项目可能就是这么多团队项目中完美阐释什么叫做永远不变的是需求的变化，每次和指导老师见面开会，指导老师都特别负责任地关心这个项目能给我们带来什么提升，尽量在助教0参与开发帮助的情况下（事实如此）给我们添加需求，对于这种频繁的需求变化，我们小组都能立即进行小组讨论，有时候一周讨论3 ，4次，一次4小时情况很正常，正是小组这种高认真态度，我们的项目进度能跟得上需求变化的进度。
6. 我们学到了什么？如果历史重来一遍，我们会做什么改进？
……讲真的，这个项目让我们很快掌握数据库设计，比数据库课程进度还快，同时对一种陌生的语言，比如PHP，微信开发语言都快速掌握并上手，同时深刻知道，团队开发，需要很多准备，不是一拿到项目就要开始工作，往往一个项目的开发设计，开发确定，设计框架这部分要花很多时间，真正敲代码需要的时间并不是想象中的那么多。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
整个设计是在项目初期由所有组员拿到老师给的需求文档之后，大致了解了项目的需求，然后组员一起讨论需要哪些功能，对老师提出的需求进行取舍，最后决定做哪些功能，哪些功能放到以后做。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在设计时我们发现项目好像是和淘宝差不多，所以我们大体上参考淘宝的架构，对于一些我们不知道的部分（比如卖家、软件客服等等）只能依靠我们讨论之后决定做哪些具体的功能。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
我们有使用UML图来帮助设计，我们也根据市面上有的软件来进行我们的设计
4. 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
由于前期讨论不够细节，越到后面文档越丰富，在项目的实现过程中，我们会不断的更新文档
5. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
最常见的就是数据的显示bug（已修复），比如在页面显示的应该是31.00，结果区县市30.00000009这种情况，还有就是微信支付bug（现在未实现）
还未发布
在设计时已经想到了这个bug,申请微信支付需要企业账号，我们现在实在是不能成功，但是这只是其中一个模块，我们讨论的结果是支付直接跳出一个收款二维码，就是不知道能不能成功发布
6． 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由于做项目也是边做边学习语言，在前期做项目是只管完成任务，没有进行规范。在做完之后我们会对代码进行规范：先每个人将自己的代码进行规范，然后再由其他组员进行检查并改正，努力使代码符合规范
测试/发布
1. 团队是否有一个测试计划？怎样测试？
有，每次组员提交页面或者PHP代码之前都会仔细检查，提交之后所有组员共同检查，尽量找出bug，最后在项目完成后所有组员会在一起检查代码规范问题
2. 是否进行了正式的验收测试？
是，第一次迭代进行了验收以及小组之间的代码复查
3. 团队是否有测试工具来帮助测试？
没钱没资源
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
好像没有
5. 在发布的过程中发现了哪些意外问题？
还有没发布
团队的角色、管理、合作
1. 团队的每个角色如何确定，是否人尽其才？
团队角色在个人能力的基础上，以个人意愿进行预分配，同时，再根据各个角色所要承担的任务和团队成员进行磋商，进行合理的调整，保证团队分工的合理性和公平性。
2. 团队成员之间是否有相互帮助？
团队成员的合作意识较强，互帮互助，负责前端的组员积极帮助负责后台的组员解决问题，同时负责后台的组员也积极指出负责前端的组员开发出来的页面的bug，共同提高项目的质量。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
有专门的大佬解决项目管理的问题，比如当有组员不小心提交错误的源码到腾讯工蜂上时，导致相关源码被覆盖，这个问题就有专门的组员来恢复源码，避免进一步错误。
对于合作方面的问题，我们小组的团队合作意识较强，有时可能会因为个人能力的强弱，有组员负责的模块做得不是很好，但是我们都相互包容，相互理解，一起解决其所负责的模块的难题。
总结
1. 你觉得团队目前处于萌芽/磨合/规范/创造的哪一阶段？
经过第一次迭代开发，我们团队已经渡过萌芽、磨合和规范的阶段，并且第一次迭代开发在大家的共同努力之下取得了应有的成果，下一阶段是创造阶段。
2. 你觉得团队在这个里程碑相比前一个里程碑有什么改进？
团队成员之间彼此更加了解和熟悉，团队成员之间的合作意识进一步加强。
经过第一次迭代开发，团队成员之间的协调配合能力和开发效率得到进一步提高，项目开发变得更加井然有序，不像刚接到项目时的一头雾水，不知从何下手。
迈过前一个里程碑，通过真实的项目开发训练，团队成员的开发能力得到进一步提高，敏捷开发的观念广为团队成员所接受和理解。
3. 你觉得目前最需要改进的方面是什么？
项目的部分界面UI做得不是很美观，在一期开发没有过于专注界面的设计，而是专注于实现，下一步要在已经实现的基础上进一步美化界面。
后台开发成员也要参与到前端界面的测试之中，不能开发完后台就觉得完事了，俗话说“当局者迷，旁观者清”，前端开发成员不一定能发现其开发出来的界面中的bug，所以后台开发成员也要参与到前端界面的测试，而且根据时间和成本曲线图，尽早发现并修复bug，可降低修复bug的成本，否则越拖到后面修复成本越高，并有可能会导致修复完当前bug，又会导致另一些bug的产生。
团队成员之间还需加强沟通，并将项目进行每日整合。比如第一次迭代开发就遇到这样的问题，由于分完模块，就是各自开发各自的，也没有将项目进行每日整合，导致后期整合时出现一大堆的bug，不是变量名同名，就是函数名同名，还有就是文件名同名，所以团队成员之间加强沟通很重要。