最后一周总结

标签：菜鸟   sign   解决问题   日常   全面   关系   企业组织   有道   等级   

1） 回顾你的课程计划 （第一周的计划）， 你完成的程度如何？请列出具体数据和实际例子

　　在做第一周的计划时，我对自己的能力评估如下：

　　通过在ASE课程的学习过程中，我自己设想要提高的几个方面并没有全部锻炼到。在几次团队项目中，认为自己进步比较大的是编程的实现以及交流能力，

　　Programming: Implementation

　　在词频统计项目和对联小程序项目中，我负责了一些函数的底层实现工作以及前端页面的实现测试工作，编程能力得到了明显提高。尤其在和项目队友的合作中，学习到很多好的编程习惯。前端工作我以前比较陌生，这次能迅速熟悉前端语言并完成分派任务，一定程度上也提高了我的学习能力。我认为现在可以给自己的编程实现能力打4分。

　　Programming: Communication

　　ASE涉及到的编程工作大部分都是团队项目，所以我的交流能力有明显的进步。在和队友结对编程时，要尽量让自己的代码具有可读性，提前沟通好各自函数的的接口；有时更要互相迁就，通力合作把既定目标完成。在更大的团队里面时，我身为前端人员要虚心接受、仔细琢磨别人提出的意见；身为测试人员要学会更形象的描述bug，更耐心更讲策略地与开发人员交流。我认为现在可以给自己的交流能力打5分。

　　几次项目我也学到了不少个人代码管理的知识，可以给自己打3分。

　　其他的能力可能短时间内在这一门课上难以覆盖，希望以后可以通过组内的项目以及个人的努力尽快达到自己满意的水平。

2） 你在课程开始快速浏览了《构建之法》，提了 5 个问题， 请回顾那些问题， 自己回答它们。如果不能回答，为何软件工程课不能让你回答这些问题？

　　问题一：

那么，初级软件工程师如何成长呢？我认为有以下几种成长：

……

3.对通用的软件设计思想和软件工程思想的理解

      我对软件设计思想以及软件工程思想的概念并不是特别清楚，也不太明白怎样通过学习好的思想来提高自己。第5章“团队和流程”中提到的像瀑布模型、RUP等开发流程算不算是软件工程思想呢，第11章提到的分析设计方法算是软件设计思想吗？我读完后感觉不同的开发流程、设计方法适用的工程场景是不同的，最适合项目的流程似乎更符合“更好的思想”这个概念。那么通用一词又如何理解？如果是指放之四海而皆准的设计思想，我觉得似乎有点“银弹”倾向；如果是指大家常用的各类思想，不分场景和资源约束的比较两种思想的好坏，我觉得没什么意义。   而且我还觉得像Team Software Process这种开发原则也可以称之为思想，这种思想是需要我们遵守并且努力达成的目标。最后我对于怎么评价一个工程师有没有思想、境界的高与低仍然有所迷惑。

　　实践才是硬道理，同一个项目中在不同阶段可能有不同的人员配比，不同的开发需求，要根据实际情况在不同阶段选择合适的软件工程思想。掌握工业界常见的思想和软件设计方法，有利于PM的灵活运用。

　　问题二：

我觉得协会或是企业组织的执业资格考试一定程度上代表了行业对一个程序员的认同标准，那么这种考试是不是真正的反映了程序开发人员的基本素质呢，企业真的要求我们要有这种素质吗？除此之外，我还有别的途径可以准确地衡量自己的编程水平吗？

　　企业招员工，PM招程序员都是讲究效率的，因此很难有时间去全面的衡量一个程序员的水平。等级考试无疑是一个敲门砖，可以过滤到大多数不那么专业的程序员。作为IT行业的学生，我们要勤修内功，形成自己解决问题的一套方法，培养自己的学习能力，这些是我们立足IT领域的根本；同时我们也要兼修外功，有板有眼的招式、专业的表达能力有利于我们找到更多的机会和平台。

　　问题三：

阅读过爵士乐模式的特点，我感觉这种模式和敏捷流程的相似度几乎没有，不知道类似点在哪里。由于在网上没有搜索到应用这种模式的实例，我根据自己的理解谈谈对这两种模式的看法。从特点上来看，爵士乐演奏时没有谱子，而敏捷流程虽然讲究保持简明，但是仍然坚持 Product Backlog、Sprint Backlog、Sprint三步走的策略来更新迭代开发过程，是一种非常注重策略的流程；爵士乐没有现场指挥，成员们放飞天性，但敏捷流程是以有进取心的人为核心的团队，讲究自我管理，第六章6.3节也强调了一个好的Scrum Master对于项目成功的关键；爵士乐的模式，“架构师”吹出主题，其余人员各自发挥，最后”架构师“回应主题，而敏捷开发十分注重面对面的交流和工作进度的共享，讲究互相帮助，纪律性远超爵士乐模式。

　　我觉得老师的解释很有道理，从“心意相通”的角度上理解，爵士乐模式和敏捷流程的确颇为相似。无论是爵士乐的自由发挥，还是敏捷流程的简明思想，都要求大家对项目的目标以及实现的方法都十分清楚，彼此“心照不宣”。

　　问题四：

3.不同的团队模式如何影响团队绩效的评估？

　　在刚结束的团队项目中，alpha阶段和beta阶段我们小组内部通过投票对个人贡献度进行了评分。我认为这个方式很适合我们的项目，在项目里面，我们互相之间没有太大的利益冲突，合作关系远大于竞争，通过投票得出的结果可以比较真实的反应我们内心的想法。

3） 看看还有什么新的问题产生，请列出来

 　　问题四仍有疑问，在团队成员间利益冲突比较大情况下，如何更好地评估每个成员的贡献呢？如果由PM一言堂，会不会因为PM可能存在的偏见而引起成员不满呢？如果是由投票来解决，会不会出现功劳大的人反而被其他人集体“做掉”的情况呢？

4）你看了一些软件工程的文献， 你的团队也做了一两次 “事后诸葛亮”分析，  可以再去看一遍，现在有什么新的感想？ 

 　　事后诸葛亮分析不仅要提出问题，更重要的是反思不足，提出解决问题的方法。我们在alpha阶段提出的问题，会在beta阶段有所改善，这就是进步；同样地，出现的问题不去解决，问题会继续存在，甚至会成为真正棘手的问题。

5）对比一些技能评价表，你有什么提高？ 还有什么收获是不能用数字衡量的？

 　　提高的技能，在问题一中已经回答过了。其他收获：团队项目中，与队友合力做出一个满意的项目，在此期间获得的协作能力、沟通能力以及倾听能力很难用数字衡量，相信这些能力也会对我以后的研究工作有很大的帮助。

6）设想一年之后， 你到了你职业发展的下一个阶段（高年级， 读研，工作），回头看这门课， 你对于这门课的教学方法， 老师和助教的工作，和其他课程的衔接，有什么意见和建议？ 

 　　 软件工程应该是一门和工业界零距离的课，我认为在alpha和beta阶段review的时候，邹老师的团队以及诸位同学的mentor提出的意见都非常有启发性，往往切中要害。在团队项目的日常开发中，可不可以让真正的软件开发工程师参与到团队的例会或是事后诸葛亮会议当中呢？他们可以不参与实际工作，只提出问题。相信这样会让菜鸟团队更快的成长吧！

最后一周总结

标签：菜鸟   sign   解决问题   日常   全面   关系   企业组织   有道   等级   

原文地址：https://www.cnblogs.com/mouthful/p/10295688.html