zoukankan      html  css  js  c++  java
  • 第10组 Alpha冲刺 (3/6)

    1、基本情况

    组长博客链接:https://www.cnblogs.com/cpandbb/p/14050808.html

    答辩总结:

      ·因为alpha阶段的产品做得偏离了方向,所以beta冲刺大家非常拼命,也拿出了相应的
      成果,基本功能已经初步完成,剩下的就只有更多的数据收集和一些bug的修改,以及柯
      老板提出的拍照上传的功能,我们会在最后的final阶段完成的。      
    

    讨论照片:

    工作流程:

      ·beta阶段的开发阶段分为重构首页,美化地图,优化推荐功能以及收集数据,分配给不同人手进行开发。
    

    分工以及贡献比例

    组员 组员分工 工作量比例
    黄纯朴 分工协调、团队督促、博客撰写、美化地图 10.5%
    魏祖文 前后端交互、云开发 16%
    谈世宏 前端开发、云开发 16%
    苏炜斌 前端开发主力 16%
    谢鑫杰 前端开发、收集数据 10.5%
    蔡震泽 前端开发、ppt制作以及答辩 8%
    李赫 云开发 7%
    熊崟 收集数据、前端开发 8%
    平措旺堆 收集数据、工具人 8%

    2、总结

    2.2.1. 设想和目标

      1、我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
            解决在校学生到食堂吃饭不知道吃什么的问题。
            定义得很清楚。
            典型用户:在校学生以及学校教职工。
            典型场景:到食堂吃饭,可是档口太多,不知道吃啥。
      2、我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?
            原计划功能基本完成,数据收集尚未齐全。beta阶段按照原计划时间交付。已经发布了,争取早日达到目标用户量。
      3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
            用户暂时为我们的开发人员,所以大体一致。我们会继续努力,在final阶段尽量拉多一些人来使用,争取一步一步向目标靠近。
      4、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
            经验教训:时间还是留得不够多,最后一天晚上的时间超级赶,还是要留下更多时间呀。
            改进:多留一些缓冲区。
    

    2.2.2. 计划

      1、是否有充足的时间来做计划?
            有很充足的时间来做计划,我们从团队建立就开始讨论选题内容了。
      2、团队在计划阶段是如何解决同事们对于计划的不同意见的?
            团队在计划阶段没有什么不同意见,如果有的话,会进行讨论,最后大部分情况下遵从少数服从多数、菜鸡服从大佬的规则。
      3、你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
            大部分工作完成了,小部分没有完成。原因:预想的和现实不一样,能力不足。
      4、有没有发现你做了一些事后看来没必要或没多大价值的事?
            我们组的重心放错了,所以在功能实现方面上绕了不少弯路。
      5、是否每一项任务都有清楚定义和衡量的交付件?
            一开始没有考虑这个情况,没能给每一项任务下一个清楚定义和衡量的交付件,导致后面有些任务节奏有点乱。
      6、是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
            并没有完全按照计划进行,因为在alpha阶段重心偏离,做得不好,所以beta阶段大家时间紧任务重,开发人员
            累得都快晕过去了。风险:alpha阶段重心偏离了。原因:我这个组长的锅呜呜呜。
      7、在计划中有没有留下缓冲区,缓冲区有作用么?
            有留下缓冲区。缓冲区起到了很大的作用。
      8、将来的计划会做什么修改?(例如:缓冲区的定义,加班)
            重新制定我们接下去要完成的任务,合理安排人手来干活,会考虑加班完成,留下更多的缓冲区。
      9、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
            计划制定应该更加详细,组员之间交流沟通应该更加密切。
            改进:之后会制定更加详细的计划,作为组长我也会加强督促组员,让组员间的沟通交流更加密切。
    

    2.2.3. 资源

      1、我们有足够的资源来完成各项任务么?
            组内大家都缺少项目开发经验,导致学习成本较高,时间资源较为不足。
      2、各项任务所需的时间和其他资源是如何估计的,精度如何?
            各项任务所需时间和其他资源主要由负责完成任务的组员估计,精度一般,只大概估计一下,有一些情况当时未能考虑进去。
      3、测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
            不够充足。
            我们没有低估难度,但美工设计实在是得有天分,我们大家地图平面设计实在做得很差。
      4、你有没有感到你做的事情可以让别人来做(更有效率)?
            大家都没有啥开发经验,所以也不存在让别人来做更有效率吧,只能大家一起不断努力。
      5、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
            要充分利用资源,抓紧空余的时间,尽早地完成任务,防止意外情况发生,没办法有充足的时间处理。
            如果历史重来,会在比较空闲的时间安排多一点的任务,在有意外情况(比如考试以及考试复习)发生时,减少任务。
    

    2.2.4. 变更管理

      1、每个相关的员工都及时知道了变更的消息?
            如果有变更,会在群里艾特全体成员通知大家,保证消息通知到位。
      2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
            在需求分析部分,我们就已经决定好重点开发内容,但是我们却跑偏了,很尴尬(组长我背大锅)。
      3、项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
            项目具备了能完好运转核心功能及其他相关的基本功能。
      4、对于可能的变更是否能制定应急计划?
            一开始并没有制定应急计划,等到碰到突然地变更时才临时改变计划,导致后期的任务完成得比较匆忙。
      5、员工是否能够有效地处理意料之外的工作请求?
            若出现意料之外的工作请求,会根据组员现有的任务情况来判断哪个组员比较适合完成,在给予分配,保证能完成请求。
      6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
            安排任务时也要考虑一下突发情况,预想好会出现的情况并考虑解决办法。如果历史重来,会再考虑周全些,把一些可能出现
            意外情况也考虑进计划安排里。
            改进:根据任务重要性和难易程度,合理进行安排。
    

    2.2.5. 设计/实现

      1、设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
            设计工作是在Alpha冲刺快开始的时候,由组长组织会议,组员共同讨论决定。是的。
      2、设计工作有没有碰到模棱两可的情况,团队是如何解决的?
            共同讨论解决。
      3、团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
            暂时还没有,uml挺有用的。
      4、比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
            有区别,但是不大。一开始想法太多,代码实现无法实现所有功能。否。
      5、什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
            刷一刷功能。智能推荐难度太大了,没办法做好。刚开始饼画太大了。
      6、代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
            由于时间不足,暂时没有进行严格的代码复审。
      7、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
            代码复审应该随时进行,而不是等项目完结后再进行。测试要及时赶上。
    

    2.2.6. 测试/发布

      1、团队是否有一个测试计划?为什么没有?是否进行了正式的验收测试?
            有,计划在项目大致完成时进行测试。
            否,因为项目完成进度还差很多。
      2、团队是否有测试工具来帮助测试?
            使用微信小程序自带的真机调试进行测试。
      3、团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
            小程序还未完全完成,暂时不考虑测量和跟踪软件性能。测试工作的效果和需要改进的地方还无法得知。
      4、在发布的过程中发现了哪些意外问题?
            1.0版本发布遇到了用户重复授权以及刷一刷遇到机型适配的问题,我们之后开发的2.0版本要用户上传
            信息以及调用摄像头,估计会遇到问题。
      5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
            要留更多的时间来完成测试。
            改进:加紧完成任务,留出更多的时间。
    

    2.2.7. 团队的角色,管理,合作

      1、团队的每个角色是如何确定的,是不是人尽其才?
            根据成员意愿和能力来确定角色,但是部分组员基础较差,感觉没有合理人尽其才。
      2、团队成员之间有互相帮助么?
            有,大家互相帮助,不局限于自己任务。
      3、当出现项目管理、合作方面的问题时,团队成员如何解决问题?
            进行共同讨论来进行解决
    我很感谢 谢公子对我的帮助,由于某个时刻思维混乱 导致刷一刷界面的某重要功能一直没有实现 谢公子另辟蹊径搞定了该功能  
    	/谈世宏对我的帮助,教会我使用Github desktop 使得代码进度可以更方便的同步 
    	/我自己 这一周居然天天莫名加班(虽然beta冲刺结束就变回了废物)
    
       4、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
            学会了相关任务的知识,队友间的合作也越来越顺畅。如果历史重来,会再好好安排一下团队的角色,争取更大的人尽其才。
    

    2.2.8. 总结

      1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
            管理级。
      2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
            磨合。
      3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
            分工明确,小组成员间更加熟悉。
      4、你觉得目前最需要改进的一个方面是什么?
            除了几个大佬,大家基础差,应该继续学习。
      5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
            原则5-要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
            事例:鼓励几个开发大腿,始终相信他们能够完成任务。
            原则4-业务人员和开发人员在项目开发过程中应该每天共同工作。
            事例:beta阶段xdm天天线下一起肝,玫瑰园的椅子都快被我们霸占了。
  • 相关阅读:
    第四节 修改表结构之alter
    第三节 数据表的创建和相关的一些指令
    第二节 数据库的创建以及相关命令
    运维不容错过的4个关键指标!
    服务器监控之 ping 监控
    Docker 监控- Prometheus VS Cloud Insight
    几种 Docker 监控工具对比
    临阵磨枪,血拼季网站优化的最后三板斧
    Java 8 vs. Scala(二):Stream vs. Collection
    Java 8 vs. Scala(一): Lambda表达式
  • 原文地址:https://www.cnblogs.com/magnetic/p/13971807.html
Copyright © 2011-2022 走看看