一.、学期初,实验一中的任务4,大家拟定了5个准备从课程学习中找到答案的问题,通过一个学期的学习,相信大家已经有了答案,请根据自己的学习实践回答自己当初提的问题,并提出一个新的问题。
1.如何避免吵架?
答:“吵”是一种不和谐的体现,为什么会吵呢,因为意见不合,为了避免吵架,就要相互多交谈意见,针对不同的意见要心平气和的交谈,毕竟吵架是不能解决问题的,没准还会让问题更加的严峻,更不利于项目的发展。在为期一个学期的小组软件设计过程中,我总结了如下七点以避免吵架:
(1)使用妥善定义的流程,流程中的每一步都是可以重复、可以衡量结果的。
(2)团队的各个成员对团队的目标,角色,产品都有统一的理解。
(3)尽量使用成熟的技术和做法。
(4)尽量多的收集数据(也包括对团队不利的数据),并用来帮助团队做出理性的决定。
(5)制定切合实际的计划和承诺,团队计划要由负责具体执行的角色来制定(而不是从上级而来)。
(6)增加团队的自我管理能力
(7)专注于提高质量,争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作,而不是在后期匆忙修复问题
2.什么时候适合选择敏捷?
答:如果遭遇到了软件开发的困境,发现项目总是延迟,客户总是不满意,开发人员士气低落,那么就应该考虑采用敏捷开发,如果没有,那么不要因为迷恋方法论而选择它。
新颖易变的创意类产品和相对固化的可预见的制造类产品研发,前者更适合采用敏捷开发。 如果软件研发过程有很多的不确定性,比如采用了新的开发技术、要开发一个创新的产品、市场还比较模糊、员工经验还在积累中,那么应该采用敏捷开发模式。
3.vsts以外的软件测试工具有哪些?
答:免费工具中针对WEB页面或B/S结构进行功能和性能测试的工具有:
开源功能自动化测试工具:PureTest,OpenSTA,Watir、Selenium、MaxQ、WebInject、Fitnesse
开源性能自动化测试工具:Jmeter、OpenSTA、DBMonster
其详细说明具体用法可参考:https://wenku.baidu.com/view/0020fcbbdb38376baf1ffc4ffe4733687e21fce6.html
4.团队怎么让所有人明确责任和驱动?
答:(1)每个责任都有人负责;每个责任都只有一个人负责。 团队承担的所有责任,应当都能找到具体负责的人,团队所有人承担的责任之和,就是团队在组织内部承担的责任。一个责任,只能一个人承担,多于一个人的话,就无法考核了;无法考核,激励就很难公平;激励不公平,就有人不满;有人不满,意味着存在内耗隐患
(2)权责利、义务、能力和岗位名称要匹配。权责利要统一很多人都知道,但是在责任驱动型团队中,强调的是六要素匹配,即权责利、义务、能力和岗位。权,即权力,从做事的角度,权力意即可调动的资源。权力所以大家都喜欢,是因为理论上责任应当和利益相统一,但现实是权力和利益相统一,有了权,就意味着掌握了利益。 责,即责任。承担责任意味着付出,责任没负好,后果很严重,责任承担好了,那是应该的。但是,如果在让人承担责任的同时,还赋予他完成责任所需的权力的话,责任就会变成很多人眼中的好东西,所以,团队中形成有权必担责的文化是组建责任驱动型团队的关键。利,即利益。前面说了,利益不应当和权力统一,而应当和责任统一。在“权责利” 中,责任是桥梁,一头是权力,一头是利益,权力和利益通过责任才能统一,如果不谈责任,只谈权力和利益的话,那就是组织最大的腐败。最后就是岗位。如果把权责利比做“实”或者“利”的话,那么岗位的头衔就是所谓的“名”,孔子是十分重视名的作用的,所谓名不正则言不顺,承担什么责任,就该得到什么头衔,这点也非常重要。
(3)别人的责任,不要擅自去承担,这叫不越权;发现事情来临时,一旦发现有责任事先未明确分配,则应当先主动承担,后再和领导请示明确该责任的承担人,这叫有担待。 要贯彻这条原则,团队应当做到每个成员都了解彼此承担的责任。
(4)互相帮助。我们鼓励这样的帮助方式:当你看到别人需要帮助,或当你收到别人的帮助请求时,你在确保不耽误自己履职的情况下,给予了他人帮助。强烈反对这样的帮助方式:你帮助了别人,结果自己的责任没承担好。如果你是领导,那么你有帮助自己下属完成履职的义务;如果你有领导,那么当你感到履职困难时,你有第一时间向领导汇报的义务,同时,你有得到领导帮助的权力。强烈反对任何人帮别人发起帮助请求,我的原则是,谁的履职有困难,谁自己请求帮助,而不是他的“保姆”去帮他喊“救命”。不是你下属的帮助请求,你有拒绝帮助的权力,没有人可以责怪你。当然,你也可以帮助他,在这种情况下,你收获的是你同事的友谊和感激,他也许会在某一天回报你今天的帮助,但是,从团队的角度,你应该不会得到相应责任的奖励,那个责任属于得到你帮助的人,至于他是否把那个奖励给你,那是他的权力,团队不能代替他做这样的决定。
(5)分歧处理。如果你觉得你的同伴做得不对,请当面告诉他你的建议,而不是背后去告诉他的上级。好的建议,应当给出相应的理由和依据,即你要告诉你的同伴,你为什么要这样建议。
(6)遵守卫兵原则。所谓的卫兵原则是,卫兵的上级领导有撸掉卫兵的权力,但是他没有权力干涉卫兵履职,即要求卫兵放行一个没有通行证的人。这个原则是对领导权力的极大制约。管理是有成本的,多一条管理原则,团队必然要多承担一条原则的成本,所以大家要一视同仁,不能搞“领导例外论”。
5.典型用户在哪类项目中更好使用?
答:在产品开发的过程中,我们经常需要描述一组典型的用户。以前大家通常是以一些抽象的名词来表示用户,如“家用电脑初学者”、“经验丰富的系统管理员”,现在我们建议用一个“典型用户”来代表。典型用户不再是一个抽象的概念,而应该是一个活生生的人物。也就是说,不管是那种项目。哪种类型,想要获得一个较好的需求分析,典型用户是必不可少的。一个典型用户往往描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境 在设计软件的过程中,我们(设计/开发者)往往会以自己使用产品的习惯和对软件行业的熟悉程度出发设计,忘记了我们的软件是给千千万万个不那么会用电脑的人使用的。在这种情况下,搞一个“典型用户”会强迫我们在考虑问题时从用户的角度出发。
新的问题:瀑布模型提供了软件开发的基本框架,有利于大型软件开发过程中人员的组织、管理,在软件工程中占有重要地位,那么在我们刚开始开发维护一个项目的初期,可以直接利用瀑布模型做一个初级规划呢?还是应该结合各种因素在各个模型中找到一个最优模型,一次解决呢?
二、完成课程的实践总结和给你带来的提升,包括以下内容:
1、统计你在软工课程实践中,完成了多少行的代码;
答:约7000行。
2、软工实践的各次作业分别花了多少时间?累计花了多少个小时在软工实践上?平均每周花多少个小时?(做一个列表)
软工作业 | 花费时间/h |
实验一 软件工程准备 | 4 |
实验二 软件工程个人项目 | 8 |
实验三 软件工程结对项目 | 10 |
实验四 基于原型的软件需求获取 | 13 |
实验五 软件研发团队组建 | 4 |
实验六 团队项目评审与团队项目选题报告 | 7 |
实验七 团队作业3—团队项目的原型设计与开发 | 8 |
实验八 团队作业4—基于原型的团队项目需求调研与分析 | 16 |
实验九 团队作业5—团队项目需求改进与系统设计 | 12 |
实验十 团队作业6—团队项目系统设计改进与详细设计 | 11 |
实验十一 团队作业7—团队项目设计完善&编码测试 | 25 |
实验十二 实验十二 团队作业8—团队项目用户验收评审 | 10 |
总花费时间 | 128 |
每周平均花费时间 | 10.67 |
3、哪一次作业让你印象最深刻?为什么?
答:印象最深的是实验七,因为实验七第一次知道原来有一个工具可以把我们自己想象出的工程完整的、没有任何歧义的展示出来,不用敲代码,不用搭建数据库,任何的工作都可以省略,很开心,开心完了以后对原型开发又有了新的思考:这样可以极大程度上避免的工程师和用户之间产生的二义性,工程师交付,客户就能试运行,马上感知到不如意或者需求表达不清楚的地方,工程师收到客户反馈,可以在成本很小的范围内进行二次修改,直至用户满意,可以为后期节省很多的工作。
4、学习和使用的新软件;
答:visio、问卷星、leangoo
5、学习和使用的新工具;
答:process on、墨刀、mockplus、石墨文档、mockplus
6、学习和掌握的新语言、新平台;
答:博客园、GitHub、中国大学MOOC、安卓
7、学习和掌握的新方法;
答:快速原型方法、白盒测试与黑盒测试、面向对象设计方法
8、其他方面的提升。
答:编程能力、文档撰写能力、逻辑分析能力,任务规划能力、矛盾调停能力、团队协作的能力等都有了很大的提升。
三、你认为目前的课程有哪些问题,你有什么更好的建议:
1、你认为本门课程需要在哪里进行改进,具体措施有哪些,包括:时间进度安排,项目难度等均可;
答:本课程是一直领着做下来的,不难发现老师们设置的任务安排是合理的,极个别不合理的安排也在助教或者邹欣等老师的建议下及时的进行了调整,可以看出老师们确实是很认真的在为我们思考,但是其实整个过程下来自己也发现有一些时间的进度安排没有考虑到学生的其他方面,比如要考教师资格证、英语等级证等这类考试的时候,大家的心思很大程度上已经被占用了,即使强迫自己去做任务也只是去完成任务本身,收获不大,这个时候就特别希望老师能宽泛几日,让我们考完试以后再去做作业,项目难度适中,基本都能跟上,整体下来还是比较好的一次体验,因为基本上每次理论课学的新知识我们马上就会用到,加速了记忆力和理解力。
2、你认为助教/老师哪里做的不足,哪里限制太多等;
答:感觉助教/老师们都很尽心,没有不足,很感谢每个老师。
3、你认为每次项目的评分标准存在哪些问题,你认为的合理评分准则是怎样的(个人/结对/团队算三个)
答:评分标准没有问题,但是个人感觉在执行的时候由于每个老师不同的理解力、状态、偏好等多种影响可能会导致评分的时候有细微差异;还有一点是有些团队的博客代码大部分是拷贝过来的,但是博客上体现不出来,所以评分的时候其实对于被抄袭的同学是不公平的。
4、在结对项目中你是否真正体会到了结对的好处,是否真正严格进行了结对编程,双方的工作量是否相同;
答:结对编程中体会到了结对编程的好处,也严格的进行了结对编程,任务分下去,每个人只需要负责自己需要负责的那一部分即可,能够腾出更多的时间去完善自己的负责的那一部分。在结对编程的时候,双方的工作量是不一样的。
5、你的团队项目是否成功,如果重来一次你是否还会选择这个团队,为什么成功/失败;
答:我的团队项目是成功的,项目顺利地实现了预期效果,但是其实有一点小问题,当时我们团队有一个两点,可惜由于人数(我们团队只有三人)的限制和技术的不过硬导致没有完全实现出来,有点可惜。如果重来的一次的话,我只会选择这个团队的某些成员,找合适的人选,因为想要尝试和不同的人相处合作,以便于自己今后的团队项目管理与发展。
6、总结一下你们团队在做项目时大家的时间安排情况。
答:团队每一个成员都有其具体分工的一部分,比如文档类,图表类,实地考察走访类等,每个人的时间由于任务的需求会有所不同,但基本上整体下来大家都差不多。
7、对下一届软工课实践教学的建议,或者对于开学初的你,对于大一的你,对于开学初的老师,你有什么想建议和告知的呢?对于后来人的期许。
答:其实一直觉得这门可应该在大二第一学期,这样子就可以申报学校的创新创业项目,每一次任务不仅有老师监督更有学校督导组分中期、后期检查,质量有了更进一步的保证,学校对于各类项目也有资金支持,800到几万不等,每个人每次项目结项,至少能得到一个校级奖,有些优秀的也可以到省上或者直接去北京比赛,也是一个很不错的福利。其实作为学院的副主席之一,我主管的就是科技部和学习部,也曾找辅导员、书记以及教务处老师浅谈过,但由于这件事牵扯太广,又要重新安排调课等事项所以最后也没成功,所以对后人的期许是:还得再去烦书记、张老师,争取调课,好处多多。其次这一门课真的涵盖的知识范围很广,不想死的太惨,建议学好基础,这门课也真的很重要,所以,请好好学习,不要放松警惕。
四、你还有什么想说得话。
首先虽然觉得这些话很俗但还是要说:很感谢每一位助教老师以及代老师对我们的帮助,让我们少走路很多弯路,谢谢你们,也很感谢我的团队的每一个人,是你们一起陪着我学习了很多新知识,熬了很多夜,奔溃了无数次,虽然过程笑笑闹闹,但是还是很感谢你们,也谢谢每一个给过我帮助的人,配合过我们调研的人,不管是熟识还是陌生人,都给了我们这个团队最大的善意,谢谢你们;其次,想要谈谈我的收获,很少能在这么紧张的时间里去做出一个完整的项目,还是经过了这种最正规要求下的完整,各类文档,燃尽图,表格,计划等应有尽有,不再是那个只会拿到任务就莽莽撞撞去敲代码的我了,很欣喜自己的成长,也很感恩培养了这些习惯的老师,使我切实体会到软件工程规范化的做法所带来的好处,不用面临一上手就写代码,最后又全篇进行修改这样的尴尬局面。