项目 | 内容 |
---|---|
课程班级博客链接 | 班级博客 |
这个作业要求连接 | 作业链接 |
团队名称 | 这是个小队 |
团队的课程学习目标 | (1)对完成质量较高的小组项目成果进行学习反思 (2)阅读学习《现代软件工程—构建之法》第5章和第12章内容 (3)开通并加入团队博客,建设团队文化,了解团队成员,建立团队目标 |
这个作业在哪些方面帮助团队实现学习目标 | (1)通过对完成在质量高的小组项目成果学习和运行,对背包问题有了更深的理解,发现同伴的不足以及对自己遗留的问题进行解决 (2)通过阅读学习《现代软件工程—构建之法》第5章和第12章内容,体验任务三实现软件功能,理解软件的使用功能 (3)与团队成员交流沟通,共同建设团队 |
团队博客链接 | 团队博客链接 |
任务2:团队组建
在实验三结对基础上,结对小组两两自由组合,组建软件项目研发团队;
申请开通团队博客,点击以下链接提交团队信息,将团队博客加入到班级博客;(3分)
已按要求完成:
阅读《现代软件工程—构建之法》第5章内容
团队和流程
- 团队共有的特点
(1)团队有一致的集体目标,团队要一起完成这目标。一个团队的成员不一定要同时工作;
(2)团队成员有一定的分工,互相依赖合作,共同完成任务。 - 软件团队的模式
(1)主治医师模式:首席程序员负责主要模块的设计与编码,其他成员从不同角度提供支持;
(2)明星模式:主治医师模式运用的极点,团队“明星”的能力掩盖了团队所有人的缺陷与优点;
(3)社区模式:成员分布不受时间空间的限制,所有人根据喜好选择项目进行开发,一般不要求报酬;
(4)业余剧团模式:没有固定的团队,且成员在不同的项目中没有固定的工作分配,所有成员由“中央指挥”指示;
(5)秘密团队:秘密状态下进行,无外界干扰,团队肩负独特使命,内部成员自由度与热情较高;
(6)特工团队:团队由专业人士组成,负责一些紧急问题的解决;
(7)交响乐团模式:较多大型软件公司采用,成员与领导者能力较强且有相似的项目开发经验,所有成员各司其职但统一受领导者指挥;
(8)爵士乐模式:与交响乐团模式对立,较为松散,领导者完成框架,其他成员在此基础上创作,最后再由领导者收尾;
(9)功能团队模式:没有固定的团队,由不同能力的成员进行组合,协作完成某一项目,项目完成后成员重新组织进行其它不同项目;
(10)官僚模式:脱胎于大机构的组织架构,几人向小头目报告,小头目向大头目报告。容易形成恶性竞争。
- 瀑布模型以及各种变形
- 特点:重计划、重事先设计、重文档表达。
- 统一流程工作流
- 业务建模——需求——分析和设计——实现——测试——部署——配置和变更管理——项目管理——环境——初始阶段——细化阶段——构造阶段——交付阶段
- TSP原则
- 使用妥善定义的流程,流程中的每一步都是可以重复、可以衡量结果的;
- 团队的各个成员对团队的目标、角色、产品都有统一的理解;
- 尽量使用成熟的技术和做法;
- 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定;
- 制定切合实际的计划和承诺,团队计划要由负责具体执行的角色来制定;
- 增加团队的自我管理能力;
- 专注于提高质量,争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作。
- 1.队名;(3分)
- 这是个小队
- 2.团队成员组成,按以下列表形式给出,个人博客地址需加超链接,在备注中标记团队组长(PM);(3分)
成员学号 | 成员姓名 | 个人博客地址 | 备注 |
---|---|---|---|
10116 | 祁英红 | https://www.cnblogs.com/qyhq/ | 组长 |
10119 | 帖佼佼 | https://www.cnblogs.com/-8tjj/ | |
10110 | 李华 | https://www.cnblogs.com/LH-18110/ | |
10108 | 高文利 | https://www.cnblogs.com/gwlg/ |
- 3.成员风采:介绍每位队员的风格、擅长技术、编程兴趣、希望的承担的软工角色(文档、开发、测试、PM等)、一句话宣言等;
成员 | 风格 | 擅长技术 | 编程兴趣 | 希望承担的软工角色 | 宣言 |
---|---|---|---|---|---|
祁英红 | 行事有计划,动手能力强 | web前端 | python | PM | 环境不会改变,解决之道在于改变自己 |
帖佼佼 | 擅长文字撰写工作,文采好 | c++ | web前端 | 文档 | 只要路是对的,就不怕路远 |
李华 | 仔细认真,擅长测试检查 | c语言 | Java | 测试 | 做正确的事,再把事情做正确 |
高文利 | 编程能力好,逻辑思维能力较强 | python | Java | 开发 | 出门走好路,出门说好话,出门做好事 |
- 阅读《现代软件工程—构建之法》第7章,理解MSF的9点基本原则
MSF基本原则:
1、推动信息共享与沟通
此原则要求是将所有信息都保留并公开,讨论要包括所有涉及的角色,决定要公开并告知所有人。在此过程中可能会有技术机密的问题,要注意保护。信息共享和沟通是其他原则实行的基础,无论是被修改了的错误,还是发生了任何变化的过程,团队中的每个人都应该对此了解。宁可过分沟通,也不能使团队合作中的一个部分不透明公开。这会影响之后的学习。
2、为共同的愿景而工作
“共同的远景”是指产品的远景,此原则要求指定产品的最终目标,要求所有的工作人员朝着这个目标努力。如果没有搞清楚项目的目标,或者朝着与目标不同的方向努力时被认为是在做无用功。这是一个项目的关键,是项目第一阶段要达到的主要目标。无论做什么类型的软件都要明确我们项目的目标是什么。
3、充分授权和信任
此原则要求所有成员都应该能得到充分的授权和信任,他们有权在职权范围内按照自己的承诺完成任务,同时他们也充分信任其他同事的承诺。成员之间、团队之间是平等协作的关系,形成网状团队结构。这样做的好处:1.被授权的人会承担自己对项目的责任,同时也期望同事们也同样对项目负责;2.MSF提倡自下而上的计划,每个人有充分的权利估计自己的任务需要多长时间,每个人按照自己的估计去完成任务。人人支持项目计划和时间表。
4、各司其职,对项目共同负责
团队中的每个角色都有自己的职责,每个工作人员尽职尽责,各司其职,并且当要做一件事情,周围人有不少意见时,对此事负责任的角色要自己拿主意。团队的各个角色合起来,对整个项目的最终成功负责任。任何角色的失败都会导致项目的失败,各个角色的工作都是相互渗透、相互依赖的。
5、交付增量的价值
虽然我们都是搞技术的,但是同时我们也是一个商业实体,我们的项目都应该出于商业目的。商业项目需要重视市场和用户。技术处于第三位。“用户体验”,“产品管理”,这两个角色我们都要尊重。要重视商业价值,将目标和商业价值联系起来。此过程并不是功利的,任何产品,都应该注重商业价值。
6、保持敏捷,预期和适应变化
要求注意预期变化,而不是期望变化,意思是适应需求的变化、技术的变化、人事的变动。软件工程,唯一不变的是变化。所以客户的需求不会在第一时间很明确,然后保持不会变。除开客户的外部原因,团队内部也在不断的变化,这就要求团队保持敏捷的身段。
7、投资质量
要求用适量的时间去提升产品质量,但是没有说质量第一,应该把解决用户的问题第一,提高用户的满意度放在第一。团队成员应该有共识:防止缺陷的发生成为团队质量控制的首要任务,所有的角色都应该对质量保障负责,及时发布能够解决用户问题的软件,并能够及时修改软件中的问题。
8、学习所有的经验
强调做到经验总结和分享经验两个方面。MFS在每一个里程碑结束时都要做一个里程碑回顾,而不必等到项目结束后,因为大家对最近的成败都记忆犹新,能提供比较准确和全面的反馈。也是为了让团队成员从别人的成果和失败的例子中学到东西。如果发现了错误,可以马上研究解决办法,在下一个里程碑中通过实践来验证。
9、与顾客合作
MSF强调产品团队与顾客的交流与合作,并不是产品团队拿到合同就开始闭门造车。项目的商业价值要由用户说了算,及早和用户沟通,通过讨论将模糊的需求共同变得具体,当用户不清楚自己的需求时,先和用户一起做出需求分析,项目是由项目团队人员做出来和用户喜欢的先决条件下的产品。
团队成员绩效
队友评估:
-
技术等级/技术能力
-
生产劳动力/结果
-
对团队的贡献(做一些工具让大家的工作更容易,帮助招人)
-
对产品的贡献(除本职工作外,对产品有帮助的活动,比如找bug,测试用户的反馈、产品推广等)
-
完成任务维度
-
团队贡献维度
-
二维评价体系(业绩/价值观)
-
划分等级和公开刺激的做法
-
闷声发财的做法
-
4.组建团队企业微信群,给出群成员截图;(2分)
-
5.团队特色描述,言简意赅的描述团队特点或核心竞争力;(6分)
- 有清晰的目标、相互的信任、相关的技能以及良好的沟通和恰当的领导
-
完成本次作业的时间:
- 任务1 : 2h
- 任务2 : 3h
- 任务3 : 3.5h
-
完成本次作业心得:
对于任务3中选择的团队开发的算法测评平台,阅读了其他同学对本组的使用体验,我们对本组的作业进行了迭代,参考本次对常龙龙和刘佳华同学开发的测试平台,借他人之长,对我们编写的算法平台进行二次更新和更好的用户体验升级,这个过程收获颇丰,在以后的学习过程当中还是要不断的进行迭代.团队组建部分阅读了《构建之法》第五章以及后面的内容,对于邹欣老师的博文中关于团队开发的流程有了很多的认识,相信在本次团队项目开发当中能够运用到邹欣老师在文中说提到的各种方法,让团队的效率更高,开发出好的软件产品。