作者:手机用户2502922607 | 来源:互联网 | 2023-06-02 21:37
发际线跟我作队实验四团队作业1:软件研发团队组建一、实验目的与要求项目内容课程班级博客链接https:edu.cnblogs.comcampusxbsf2019nwnucs本次作业
发际线跟我作队 实验四 团队作业1:软件研发团队组建
一、实验目的与要求
项目 |
内容 |
---|
课程班级博客链接 |
https://edu.cnblogs.com/campus/xbsf/2019nwnucs |
本次作业要求链接 |
https://edu.cnblogs.com/campus/xbsf/2019nwnucs/homework/12578 |
团队名称 |
发际线跟我作队 |
团队的课程学习目标 |
(1)体验软件项目开发中的两人合作,练习结对编程(Pair programming)。 (2)掌握Github协作开发软件的操作方法。 |
这个作业在哪些方面 助团队实现学习目标 |
(1)可以克隆其他同学的项目运行体验,比较感受自身项目的不足。 (2)结对方式学习有利于两人思想交流。 |
团队博客链接 |
https://www.cnblogs.com/Moki231/p/16111661.html |
二、实验内容与步骤
1、任务二:团队组建
(1)在实验三结对基础上,结对小组两两自由组合,组建软件项目研发团队;
成员学号 |
成员姓名 |
个人博客地址 |
备注 |
---|
201971010115 |
蒋敏敏 |
|
组员 |
201971010157 |
张颖 |
|
组员 |
201971010231 |
毛玉贤 |
|
PM |
成员 |
擅长技术 |
编程兴趣 |
风格 |
承担角色 |
一句话宣言 |
---|
201971010115_蒋敏敏 |
python、C |
比较喜欢人工智能、游戏开发方面 |
实干型,动手能力强,喜欢一个人解决问题 |
开发测试 |
实践出真知 |
201971010157_张颖 |
C、java |
对做微信小程序、网站情有独钟 |
总结性强,适应性强 ,对文字敏感 |
文档设计与测试 |
不塞不流,不止不行 |
201971010231_毛玉贤 |
C++、python |
喜欢前端、系统开发 |
偏理论性强,能够提出新需求,想法丰富 |
开发与测试 |
夏虫不可语冰,井蛙不可语海 |
2.1.5 团队特色描述,言简意赅的描述团队特点或核心竞争力
特点:风格明确,各司其职,互相交流,共同进步,团队包容性强,氛围融洽,有共同的价值观和行为规范;
核心竞争力:团队成员各有各的闪光点,三人能力互补,学习能力教强,积极向上,对事物充满兴趣。
(2)申请开通团队博客,点击链接https://www.chaojibiaoge.com/U/url/7lxwx4sx提交团队信息,将团队博客加入到班级博客;
提交团队信息
加入班级博客
(3)阅读《现代软件工程—构建之法》第5章内容
2.3.1 第五章 团队与流程 总结
<5.1> 非团队和团队
- 非团队特点:临时组建、乌合之众、无合作协作、做完任务就走人;
- 团队特点:团队有一致集体目标,团队一起完成该目标;团队成员有各自分工,互相依赖合作,共同完成任务。
<5.2> 软件团队的模式
- 主治医师模式:像在手术台一样,有一个主刀医师,其他人负责协助主刀医师
- 优点:初衷很好,一个软件团队中,有首席程序员,负责主要模块的设计和编码,其他人尽可能从各个方面支持他的工作
- 缺点:在一些学校的软工课上,这种模式逐渐退化成“一个学生干活,其他学生打酱油”
- 明星模式:主治医师模式运用到极点
- 优点:对“明星”个人的成长进步可能会有所帮助
- 缺点:团队模式强调的是团队的作用,而不是个人的独角戏,这种模式显然违背了团队模式的初衷,效率也很低
- 社区模式:由很多志愿者参与,每个人参与自己感兴趣的项目,贡献力量,大部分人不拿报酬
- 优点:“众人拾柴火焰高”,成功案例:开发和维护Linux操作系统的社区,成功案例往往需要严格的代码复审和签入的质量控制
- 缺点::“只烤火,不拾柴”,“拾到的柴火质量太差”
- 业余剧团模式:团队中各人扮演各人的角色
- 优点:在业余玩票、培训的环境中,每个人都可以尝试不同角色,大家可以比较平等地讨论
- 缺点::在竞争性强烈、创造性要求高的团队,不会存在完美主义的民主气氛。
- 秘密团队:有一些软件项目在秘密状态下进行,别人不知道他们具体在做什么
- 优点:团队内部有极大的自由,较高的热情,没有外界的干扰。
- 缺点::不可能成为普遍模式,只会针对个别项目。
- 特工团队::软件团队由一些有特殊技能的专业人士组成,负责解决一些棘手而有紧迫性的问题
- 优点:效率高
- 缺点:对成员的知识面要求十分广,较为针对技术人员,不可能成为普遍模式
- 交响乐团模式:各司其职,像交响乐队一样
- 爵士乐模式:与交响乐模式存在相当多的对立
- 优点:领导给出一个主题,然后成员们百花齐放,各显本领,快收尾时再总结
- 缺点:人员不能太多
- 功能团队模式:具备不同能力的同事们平等协作公共完成一个功能
- 优点:效率高
- 缺点:每个小组必须与其他小组就编程规范达成一致
- 官僚模式:脱胎于大机构的组织架构,几个人报告给一个小头目,几个小头目报告给中头目,依次向上
- 优点:有助于技术的交替与互补
- 缺点:容易掺杂一些追名逐利,往往会使团队效率大打折扣
<5.3> 开发流程
- 写了在改模式
- 要写一个有实际用户、解决实际需求的软件,这个方法缺点太大;
- 瀑布模式
- 前一阶段完成后,您只需要去关注后续阶段,但各个阶段之间极少有反馈;只有在项目生命周期的后期才能看到结果;
- 瀑布模式的各种变形
- 为了解决瀑布模型的各种问题,人们在实践中提出了各种模型;
- 统一流程(RUP)
- 最小可行产品,又称为最小功能集把产品最核心的功能用最小的成本实现出来(或描绘出来),然后快速征求用户意见;
老板驱动的流程
渐进交付的流程,MVP,MBP
- 当系统的主要需求和架构逐渐明确后,软件团队进入了一个不断演进的循环中:
- TSP的原则
- ①使用妥善定义的流程,流程中的每一步都是可以重复、可以衡量结果的。
- ②团队的各个成员对团队的目标、角色、产品都有统一的理解。
- ③尽量使用成熟的技术和做法。
- ④尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
- ⑤制定切合实际的计划和承诺,团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
- ⑥增加团队的自我管理能力。
- ⑦专注于提高质量,争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)
(4)记录完成《实验四 团队作业1:软件研发团队组建》各项任务实际花费的时间
任务内容 |
实际花费的时间(min) |
---|
任务一 |
101 |
任务二 |
109 |
确定团队名称 |
2 |
确认成员信息 |
10 |
组建群聊、申请团队博客、 申请团队github地址 |
39 |
加入班级博客 |
3 |
学习MSF |
25 |
阅读第五章 |
30 |
任务三 |
54 |
(5)谈谈完成本次作业的感受和体会
- 本次作业,在实验三的基础上两两组合,不仅运行了别人的优秀项目,体会到多角度实现客户需求的想法和技术,还构建了团队,团队成员都比较喜欢交流,有利于提升我们团队协作的能力,以及个人水平,在以后的学习工作中相信都会受益匪浅。