写代码是不可能会写代码的,只有每天抄抄别人的代码这样子才可以维持一下生活 ------ 博客首页

磁感线

阿巴阿巴阿巴
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

第10组 Alpha冲刺 (3/6)

Posted on 2020-11-13 23:02  磁感线  阅读(43)  评论(0编辑  收藏  举报

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天天线下一起肝,玫瑰园的椅子都快被我们霸占了。