团队作业1——团队展示&选题(诺亚方舟)

这个作业属于哪个课程 https://edu.cnblogs.com/campus/gdgy/Networkengineering1834
这个作业要求在哪里 https://edu.cnblogs.com/campus/gdgy/Networkengineering1834/homework/11149
这个作业的目标 学习 Git 分支管理,学习团队协作、学习团队合作的原则以及流程、设计团队项目、规划项目计划

一、团队展示

1.1 团队名称及团队宣言

  • 团队名称:诺亚方舟开发团队
  • 团队宣言:让编程改变世界,拥抱前沿科技

1.2 队员信息

队员名称 学号
黄晓楷(组长) 3118005327
黄裕煜 3118005328
潘宇恒 3118005335
林瑜 3118005332
林佳锐 3118005330
艾买提·阿布都克力木 3118005311

1.3 队员风采

黄晓楷

  • 风格:和平和平
  • 擅长技术:Python 后台开发、数据挖掘、深度学习
  • 编程的兴趣:研究深度学习算法方面的知识,现阶段希望能有一些自己的成果,想要在这条路上越走越远
  • 软工角色:算法工程师、测试
  • 一句话宣言:不是总有人因为你的退让与软弱而同情你,大多数时候退让只会让人得寸进尺

黄裕煜

  • 风格:低调闷骚
  • 擅长技术:Java 后台开发
  • 编程的兴趣:学习新技能,钻研已有技能
  • 软工角色:开发、测试
  • 一句话宣言:大家一起共同努力共同进步

潘宇恒

  • 风格:少说话多做事
  • 擅长技术:前端
  • 编程的兴趣:渴望得到新知识、新理解
  • 软工角色:开发、测试
  • 一句话宣言:为共同的远景而努力

林瑜

  • 风格:如沐春风
  • 擅长技术:简易 Python 开发、Office 、Axure 原型制作
  • 编程的兴趣:无
  • 软工角色:PM
  • 一句话宣言:dl带带我

林佳锐

  • 风格:无
  • 擅长技术:算法与数据结构
  • 编程的兴趣:学习新知识
  • 软工角色:开发、测试
  • 一句话宣言:为996美好生活而奋斗

艾买提·阿布都克力木

  • 风格:是一个比较沉稳的大孩子,奉行少说话多做事。
  • 擅长技术:其实很难说本人擅长某一技术,对各个领域都有涉及,但都不是很深入,相对来说对前端(主要是桌面网站)和多媒体技术有较多的了解。
  • 编程的兴趣:很喜欢捣鼓桌面小应用,有个小目标,开发出一个超高集成度的系统工具箱。
  • 软工角色:测试工程师,现在也有叫“质量保证工程师”,我个人认为这是一个非常关键的角色,有关调查显示,通过必要测试,软件缺陷可减少75%,甚至更多,我可以负责开发出的软件推向市场的最后一环,既保证没有有缺陷的软件上线,更要保证用户有最佳的用户体验和安全体验。
  • 一句话宣言:奋斗中的菜鸟,不比正翱翔的雄鹰差!

1.4 团队的特色描述

  • 运用机器学习技术,实现网站的智能化
  • 团队内分工明确、各司其职,各个模块都有相应的人负责
  • 团队规定明确,有严格规范,对评分规定、代码规范、Git 分支与提交管理具有详细的规范
  • 团队成员各有所长,优势互补

1.5 团队原则——MSF的八个核心原则

推动开放式沟通:

开放式沟通的观念,简单来讲就是让资讯公开透明,所有人都能取到他需要的资讯,所有人都会共享他获得的资讯。但是根据实际情况也可以有一定的区分,比如一个是共享的资讯是否要分层级,因为不是所有人都需要知道所有讯息,某一层成员如果得到了过多对自己无用的讯息可能会出现咨询过量的情况,越往后看到他人分享的咨询就自动忽略了;另一个是 need-to-know 的资讯分享模式,讯息拥有者可能不会完全的,即时的分享讯息,只在他认为有人需要这个讯息的时候才会分享出来。我建议大家在分享讯息时在这两个模式之间取一个平衡。💕💕💕

为共同的前景而工作:

这个就更容易理解了,一个团队的所有人尽管分工不同、责任划分不同、团队内角色不同,但是所有人的最终目标是一致的,在我们的队伍里所有人都目标就是通过这段时间的努力,保质保量的按时完成我们的团队作业。我们的目标是通过团队内讨论最终所有人均同意的,相信每个人都会为自己的选择而持续奋斗。😎😎😎

赋予小组成员权力:

“在最优秀的小组里,不同的个人会在不同场合下体现出其领导能力,他们会在其专长的领域里担负起领导职责。没有哪个人是永远的领导,因为如果这样的话,这个人就无法和其他人融为一个整体,而小组的互动会因此而开始分裂。小组的结构应该是一个网络型的而不是一个层次型的。”

——技术分析师Tom DeMarco 和 Timothy Lister

和上面的一样,要说领导可能有点过了,但至少成员之间要有足够的信任和充分的尊重,信任各个组员的技术水平,肯定各个组员的努力,认可各个组员的能力与付出,而我们的队伍就是这样一个队伍。🤞🤞🤞

建立清晰的责任与共同的职责:

软件开发团队,是一个“一荣俱荣、一损俱损”的团队,只有这样才能把全部人的利益扭在一起。团队的每一位成员,肩负起自己所在领域的责任,团队的每一位成员共同对最终解决方案负责,同时鼓励小组成员对非他们直接负责的领域作出评论和贡献。每领域的负责人对自己的工作负责。另外一个方面,软件是团队共同劳动成果,所有人对最终的解决方案负责,最终解决方案只有有问题,就是整个团队的责任,最终解决方案取得优异成绩,就是整个团队的功劳。✌✌✌

关注交付业务价值:

敏捷宣言的第一条原则就是关于向客户交付有价值的产品,价值并不是与金钱直接挂钩,价值还可以有以下的存在形式:

    1. 促进效率
    2. 改善组织文化
    3. 提高生产力
    4. 提高灵活性

总而言之,向客户所交付的产品必须以解决客户的某些痛点为重心,持续性的产生价值。

保持灵巧,预测变化:

需求时刻在变,人们对于需求的理解也时刻在变。项目进行中,Project stakeholder可能变化,会有新人加入,也会有旧人离开。Project stakeholder的观点也可能变化,努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行,项目环境也在不停的变化,因此开发方法必须要能够反映这种现实并且合理调节适应变化。

质量投资:

项目投资者为了开发出满足自己需要的软件,需要投入时间、金钱、设备等各种资源。投资者应该可以选取最好的方式投资,也可以要求团队不浪费资源。并且,他们还有最后的发言权,决定要投入多少的资源。没有人喜欢烂糟糟的工作。做这项工作的人不喜欢,是因为没有成就感;日后负责重构这项工作(因为某些原因)的人不喜欢,是因为它难以理解,难以更新;最终用户不喜欢,是因为它太脆弱,容易出错,也不符合他们的期望。所以,当投入了如此多资源、金钱、心思后,我们也需要将他们转化成质量投资进入产品中。

学习所有的经验:

产品形成过程中可以参考以往的项目,观测他们的发展历程,以及直接竞品的历史以及当下的运营状况,取其糟粕,取其精华。

1.6 团队项目描述

面向广大摄影爱好者的共享影像作品为中心的社交网络服务里的图片管理网站

1.7 团队分工

职责 参与成员
前端开发 艾买提·阿布都克力木、潘宇恒
后端开发 黄裕煜、林佳锐
智能化功能开发 黄晓楷
产品设计(PM) 林瑜
测试 艾买提·阿布都克力木、潘宇恒、黄裕煜、林佳锐、黄晓楷、林瑜
文档和复审 林瑜、艾买提·阿布都克力木、黄晓楷

1.8 团队合照

二、团队选题

2.1 云端文档管理及项目托管地址

2.2 项目介绍

2.2.1 概述

​ 一个面向摄影爱好者的共享影像作品图片管理网站,和以此为中心搭建的社交网络。平台主要有两大功能,一是图片分享与管理,我们会提前预设好几个分类,其中之一是以中国传统的动画形象为元素进行分类,从而起到推广弘扬中国的动画元素。用户可以上传图片并加以标签和描述,每次上传时会产生一次动态,类似于微信的朋友圈动态,用户间可以通过图片页面或者动态页面进行点赞、评论或收藏从而与作者进行互动,找到志同道合的伙伴。

2.2.2 预期用户量

我们的计划是从本校出发辐射大学城内其他高校,预期产品运营完善后用户量为月度活跃用户为1万人。

2.3 项目阐述

  • 可用:该图片网站有分享、检索、检测图片管理等功能。
  • 真实:为了让广大苦于没有同好的摄影爱好者能够找到有相同兴趣的同志。
  • 价值:为中国广大影像爱好者提供一个作品共享平台,促进中国摄影业的发展。
  • 情怀:我们希望开发一个实用且能够广泛传播的摄影作品管理系统,从而建立一个面向摄影爱好者的摄影作品共享平台,让更多的人能够找到与自己相同兴趣的人。
  • 目标:将我们的构想变成一个真实可用的产品。

2.4 文档的版本化和增量式管理

  • 增量式管理

    • 先主要功能文档,后次要功能文档,逐步完善
    • 开发过程需要继续改动的文档在开发过程文档库中暂存,升级为正式文档后上传到正式文档库
  • 版本管理:

    • 文档命名规范:文档名+V1_1,如

      规范文档-V1_1.md
      
    • 第一位数字表示一个项目的小阶段(每周一期),每周改动一次

    • 第二位表示一个小阶段内的不同,单周内改的只动第二位数

2.5 项目迭代和规范

  • 开发需求明确且明示

  • 要求项目提交要规范,如下所示:

    commit message 包括两个部分:Header、Body

    Header:描述当前commit的类别,主要是以下几种

    • 功能:提交功能点。
    • 修复:修复bug。
    • 重构:代码重构,未新增任何功能和修复任何bug。
    • 配置:修改项目工程文件配置。
    • 文档:修改文档

    Body:对本次commit的概要描述

  • 其他规范:如代码规范、分支命名规范、 issue 命名规范等,详见 GitHub 仓库

三、团队计划

3.1 开发计划

3.1.1 计划时间表

第 6 1.团队组队、团队博客
2.团队介绍、成员展示、角色分配、选题确定
3.制定团队计划安排,团队贡献分的规定
第7周 1.需求规格说明书
2.原型设计,队员估计任务难度并学习必要的技术
3.编码规范完成、平台环境搭建完成、初步架构搭建
第8周 1.原型改进(给目标用户展现原型,并进一步理解需求)
2.架构设计,WBS, 团队成员估计各自任务所需时间
3.测试计划
第9、10周 1. 团队项目Alpha任务分配计划
2. 连续7天的Alpha敏捷冲刺,7 篇 每日Scrum Meeting博客+代码提交
第11周 1.用户反馈+测试计划改进
2. 团队Alpha阶段个人总结
3. 团队项目Alpha博客:发布说明、测试报告、展示博客、项目管理
第12周 1. 团队项目Alpha博客:事后分析

3.1.2 开发计划甘特图

gantt dateFormat YYYY-MM-DD title 团队项目开发计划甘特图 section 设计 需求:done,des1, 2020-10-15,2020-10-20 原型:active,des2, 2020-10-18, 3d UI设计:des3, after des2, 5d 未来任务:des4, after des3, 5d section 开发 学习准备理解需求:crit, done, 2020-10-15, 5d 设计框架:crit, done, after des2, 2d 开发:crit, active, 3d 未来任务:crit, 5d 休息时间:2d section 测试 功能测试:active, a1, after des3, 3d 压力测试:after a1, 20h 测试报告: 48h

3.2 团队成员绩效评估方法

  • 主要公式:

    成员的绩效 = 团队获得的分数 + 个人的团队贡献分

  • 个人贡献分采用不同的指标进行计算,并参考所有成员的意见,各指标占比如下:

    指标 占比
    积极程度 30%
    任务完成质量 30%
    按时完成任务 20%
    是否提出创新性意见 15%
    其他 5%

    个人共享分通过团队成员全体成员评分,并取用分均值,对评分有意见的成员可以提出异议,公平公正公开。

posted @ 2020-10-19 20:49  Boyle-Coffee  阅读(266)  评论(0编辑  收藏