• 第02组 Alpha事后诸葛亮


    1. 组长博客(2分)

    2. 总结思考(27分)

    2.1. 设想和目标(2分)

    • 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
      • 解决任务群不够好用、想问学校的相关信息却不知去哪里问- 我们的软件定义得很明确。
      • 典型用户是使用QQ任务群或经常查找校园相关信息的福大学生。
      • 典型场景:同学A想让别人给他领快递
    • 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?
      • 尚未达到目标。原计划在Alpha冲刺完成的功能达成了基本的页面设计和任务悬赏的主要功能,还有校园百科的主要功能没有完成。并没有成功按照原计划时间交付。并没有达到原计划的用户数量,因为尚在开发中,并未交付
    • 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
      • 尚未推广,并没有用户量。我们正朝着目标稳步前进。
    • 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
      • 规划的时候应当保守一些。如果历史重来一遍,我们会预先一一排雷,检查功能的可实现性,从规划中排除比如调用微信支付这种难以实现的功能

    2.2. 计划(5分)

    • 是否有充足的时间来做计划?
      • 是。但是我们之前忽视计划的重要性,讨论得不够,导致计划需要随着开发进展不断修补
    • 团队在计划阶段是如何解决同事们对于计划的不同意见的?
      • 我们团队确实出现过严重的意见分歧,解决的方法是意见方先回宿舍准备一天,然后在第二天开会的时候陈述利弊,最后交由大家不记名投票表决。
    • 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
      • 没有。作为组长,需要掌握实时的开发情况,但是我却没有主动去了解,导致后来产生了计划与实际的脱节。
    • 有没有发现你做了一些事后看来没必要或没多大价值的事?
      • 暂时没有。
    • 是否每一项任务都有清楚定义和衡量的交付件?
      • 没有。这需要前后端充分沟通后,再进行详细的计划后,才能达成的。我们中并没有谁有开发经验,大家都是走一步看一步。
    • 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
      • 没有。Alpha冲刺历程中经历了若干次考试,一遇到考试,相关人员的开发进度就会暂搁两天。像这种突发性事件就是之前没有估计到的。主要是对时间的把控不够灵活
    • 在计划中有没有留下缓冲区,缓冲区有作用么?
      • 之前有计划预留最后三天为缓冲区,大家停下手头的开发专心弄Alpha冲刺展示。确实派上用场的,虽然只是最后一天。
    • 将来的计划会做什么修改?(例如:缓冲区的定义,加班)
      • 加大每一天的工作量,尽量将工作提前到Beta冲刺之前完成的。毕竟马上就有大波考试来袭
    • 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      • 应该以模块划分项目,这样容易对开发进度有直观的掌握,且便于任务分配
      • 分配任务的时候,要给出明确的deadline和要求,并在验收时根据成品的情况进行评估,并调节之后的开发任务。

    2.3. 资源(3分)

    • 我们有足够的资源来完成各项任务么?
      • 主要是学习资源的问题。知识就在网上,问题在于如何获取并吸收它。如果增大精力、时间投入,就能有足够的资源来完成了
    • 各项任务所需的时间和其他资源是如何估计的,精度如何?
      • 主要是通过负责该任务的人自行估计。精度很差。
    • 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
      • 人力、资源是足够的,问题是调度太差了。在我们的开发过程中,经常遇上个别人在开发,其他人在等待的情况,再充分的资源利用不当也是白搭。我们没有低估那些不需要编程的资源 (美工设计/文案)的难度。
    • 你有没有感到你做的事情可以让别人来做(更有效率)?
      • 没有。我没有参与开发,相对他人来说已经是轻装上阵了,若连这一点工作都推诿他人,怕是颜面尽失。
    • 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
      • 事先沟通好开发语言吧。我们后端中两人Java,两人Python,最终统一为Java。这也是我们之前没有预测到的不确定因素
      • 对时间资源的调配要留有余地:预先留下缓冲区,避免考试等其它因素对开发产生较大阻碍作用

    2.4. 变更管理(4分)

    • 每个相关的员工都及时知道了变更的消息?
      • 基本是的。经常发全体成员消息、公告
    • 我们采用了什么办法决定“推迟”和“必须实现”的功能?
      • 挑拣出核心功能,把不确定性大的、难以把握投入的、过分细节的功能推后
    • 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
      • 有。功能完备,易用性强
    • 对于可能的变更是否能制定应急计划?
      • 很难,基本上就是粗暴堆时间(熬夜)
    • 员工是否能够有效地处理意料之外的工作请求?
      • 还行吧,一般有这种情况都要求赶紧和组长说,组长再找人一起解决,摊匀了突发压力
    • 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      • 在开发之前,将模块的实现和个人职责分割得更详细,这样就能比较有效减少模糊地带

    2.5. 设计/实现(4分)

    • 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
      • 前端的界面设计工作是三周前开始的,由文彬、文涛负责。后端是稍晚一些,由世杰牵头完成的
    • 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
      • 有的,通过讨论利弊后下决定的
    • 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
      • 没有,下次考虑引进。
    • 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
      • 有一点区别,主要是需求有在变化,可以更新UML文档
    • 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
      • 接口调试相关的Bug最多,因为涉及到前后端的交互。由于一开始都不了解,所以很难考虑到这些情况。
    • 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
      • 大家一起看代码,代码规范上尽量向阿里巴巴靠拢。
    • 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      • 学到了代码规范的重要性,如果历史重来一遍,我们会更加注意代码的规范。

    2.6. 测试/发布(3分)

    • 团队是否有一个测试计划?为什么没有?
      • 没有。直到Alpha冲刺快结束的时候仍没有足够多的功能设计完备,团队工作重心仍在开发商
    • 是否进行了正式的验收测试?
      • 没有
    • 团队是否有测试工具来帮助测试?
      • 没有
    • 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
      • 在工具上实时测量调试。有用。改进:还可以使用更专业的软件
    • 在发布的过程中发现了哪些意外问题?
      • 没有
    • 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      • 学到了测试的重要性,实时调试。改进:更加注重测试阶段。
      • 看到别组服务器被攻击,我们之后会避免暴露接口,也要准备应对措施

    2.7. 团队的角色,管理,合作(3分)

    • 团队的每个角色是如何确定的,是不是人尽其才?
      • 角色主要是依据需求分析阶段,各自提交的志愿调和而成的。后来有个别调动。称不上是人尽其才,但能说是人尽其力。
    • 团队成员之间有互相帮助么?
      • 有。基本上是大佬带小白。尤其是世杰,有应必答。
    • 当出现项目管理、合作方面的问题时,团队成员如何解决问题?
      • 直接在前端/后端的群里说出来,当线上无法解决的时候再线下沟通
    • 每个成员明确公开地表示对成员帮助的感谢 (并且写在各自的博客里):
      • 我感谢世杰对我的帮助, 因为他是团队中最carry的人,还经常帮助我收拾烂摊子
      • 我感谢团队里所有人对我的包容,当然我并不想要这个,有错误就指出来,这样才利于整个团队,毕竟一将无能累死三军。
    • 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      • 我们学到了交流的重要性,如果历史重来一遍,我们会深化沟通和合作,解决开发短板

    2.8. 总结(3分)

    • 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
      • 我觉得团队尚处于CMM的初始级。我们确实在项目开发过程中出现缺乏健全的管理制度。开发项目成效不稳定的情况
    • 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
      • 规范阶段。现在大家都熟悉自己的职责了,当然开发规范仍得加强
    • 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
      • 沟通和合作能力大大提高
    • 你觉得目前最需要改进的一个方面是什么?
      • 计划。我们之前进行的开发都是比较盲目的。
    • 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
      • 避免不必要的开销。我们经常是先开工,当然这么做会比较盲目。我们也拖延了难以把控开发投入的任务,专心于实现核心功能

    3. 答辩总结(6分)

    3.1. 团队贡献比例

    组员 贡献百分比 分工 备注
    杨世杰 17% 后端 表现很好
    陈文彬 15% UI 表现很好,拥有稳健的开发步伐
    林宏海 15% 前端 表现很好
    林文涛 12% UI 表现很好
    龚洋林 10% 前端 符合预期
    苏伟欢 10% 后端 符合预期
    活跃
    林小棠 10% 后端 符合预期
    张越洋 4% 制作PPT、展示、写博客 没有按时完成博客和PPT
    没有预先模拟PPT展示,导致展示时重心偏移
    没有把控好开发进度
    缺乏沟通
    邓志雄 4% 提问、评分、制作评审表 符合预期
    王淇弘 3% 测试 严重缺乏沟通

    3.2. 现场答辩得分:49.5

    小组 评分情况
    1 46.8
    2 52.8
    3 46.6
    4 51
    5 49.8
    6 54.6
    7 54.6
    8 45.2
    9 50.4
    10 48.6
    11 49.2
    12 43.2

    3.3. 回答提问

    小组 提问 回答
    1 筛选里是否考虑加任务分类? 有的,将在beta版本上线
    3 如何平衡赏金机制? 是指发布者给予的酬劳吗,根据市场价格发布者自由决定
    4 怎么保证所发出的任务的时效性? 发起者可设置任务持续时间或到期时间,beta版本上线
    5 市场上的任务悬赏是否具有默认排序?如何更好的让别人查找到想要的悬赏信息 默认按发布时间排序,后续加入信用高的人将优先展示;可使用筛选/搜索功能
    6 如何确保支付的安全性? 通过完善流程后续跟进
    7 能否保证支付的安全和线上支付? 线上支付步骤较为繁琐,若反响较好后续会加入
    8 后端算法如何更新任务,例如通过什么算法对任务进行排序? 信用度优先,其次按照时间降序
    9 可以通过支付的信用问题,设置每个用户的信用分吗 后续可以考虑
    10 如果是不碰面的任务,如何解决支付问题? 线上支付,通过完成订单进行反馈
    11 可以尝试用微信本身的支付接口 申请较为繁琐,反响较好后续将会继续跟进
    12 状态设计是否完备? 目前有未接单,已接单,beta版本将跟进已完成状态

    4. 全组讨论的照片(1分)

    5. PSP与学习进度条(4分)

    5.1. 个人PSP表

    PSP2.1 Personal Software Process Stages 预估耗时(分钟) 实际耗时(分钟)
    Planning 计划 30 10
    · Estimate · 估计这个任务需要多少时间 30 10
    Development 开发 50 40
    · Analysis · 需求分析 (包括学习新技术) 50 40
    · Design Spec · 生成设计文档 0 0
    · Design Review · 设计复审 (和同事审核设计文档) 0 0
    · Coding Standard · 代码规范 (为目前的开发制定合适的规范) 0 0
    · Design · 具体设计 0 0
    · Coding · 具体编码 0 0
    · Code Review · 代码复审 0 0
    · Test · 测试(自我测试,修改代码,提交修改) 0 0
    Reporting 报告 40 50
    · Test Report · 测试报告 0 5
    · Size Measurement · 计算工作量 0 5
    · Postmortem & Process Improvement Plan · 事后总结, 并提出过程改进计划 40 50
    合计 120 110

    5.2. 个人学习进度条(每周追加

    第N周 新增代码(行) 累计代码(行) 本周学习耗时(小时) 累计学习耗时(小时) 重要成长
    1 300 300 7 7 增强代码能力
  • 相关阅读:
    数据库服务器计数器
    性能测试之操作系统计数器分析方法
    性能测试之Windows常见性能计数器
    企业级 SpringCloud 教程 (三) 服务消费者(Feign)
    企业级 SpringCloud 教程 (二) 服务消费者(rest+ribbon)
    企业级 SpringCloud 教程 (一) 服务的注册与发现(Eureka)
    Spring Cloud构建微服务架构:服务容错保护(Hystrix断路器)
    Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)
    Spring Cloud构建微服务架构:服务容错保护(Hystrix依赖隔离)
    Spring Cloud构建微服务架构:分布式配置中心
  • 原文地址:https://www.cnblogs.com/dicky99/p/11923458.html
Copyright © 2020-2023  润新知