【week2】 构建之法 读后感及问题

   上一次读后感涵盖前五章的内容包括个人技术,结对合作,小组项目等。本周作业的燃尽图以及站立会议是关于《构建之法》第六章的内容,所以关于这一章的读后感涵盖在上两篇博客中。

第七章 MSF

      介绍MSF(微软解决方案框架),他有自己的九条思想框架,总结起来就是勤于客户交流,保证个人价值的同时要注意与团队共进退,相信合作的力量,在保持敏捷的同时将作品价值最大化。还有重要的一点就是总结前人经验,并且把自己的经验与他人分享,利用这些经验避免一些错误,这在团队合作中尤为重要。

第九章:项目经理

     项目经理分为两种Project Manager和Program Manager。前者负责开发和测试以外的所有事,管事也管人。后者与大家平等的完成软件的功能只管事。本章主要介绍的ProgramManager是微软首先提出的,要具备观察分析能力,并且要有一定的专业知识,要对整个团队起到推进的作用,要有预测及处理风险的能力。综上我觉得PM一定要有一定的敲代码的能力,还会巧妙地处理技术人员以及上层领导的关系,对风险比较机敏。这确实是一向很艰巨的任务。

第十章:典型用户和场景

     这一章让我明白了不是所有的人都是我所研发的软件的用户,要十分明确的定义谁是我们的用户。关于用例我一直觉得是软件测试的关键,但是本书说是需求分析的工具,想想也是这样的。要针对用户的需求,进行用例分析,能分析出我们需要开发的功能,每次完成一个用例,逐步完善需求。

第八章,第十一章,第十二章,第十三章 第十五章:

      这几章记录的是软件开发的流程。需求分析阶段提出NABCD是进行创新开发的一个很好地办法,有想法开始实施之前先问自己这五个问题,是否符合用户的需求?怎么做?这么做对于团队或用户有什么好处?进入市场有什么竞争力可以pk掉对手?产品研发成功之后如何让用户大规模使用?

      软件设计就是对上一阶段分析出的用户的问题进行抽象,形成文档,做出一些形象的图,比如流程图、实体关系图等。

      关于用户体验我一直很注重这个,因为我作为很多产品的用户,真的希望研发人员能对自己的作品负责,真正从用户的角度出发。公户之庞大使让用户有良好的体验变成一个很困难的事情,值得深入研究,也不是书中教几个方法就能彻底解决的,还要在以后慢慢深入研究。还有我想说的是邹老师在举例子的时候确实很风趣。

     软件测试,方法分为两类:黑盒测试和白盒测试。我的理解就是,黑盒就是看不见代码如何构成,而白盒就是能看见具体的代码,根据代码完成测试。

     软件发布前还会存在一些问题,这个时候十分考验团队的耐压能力,但是要记住优秀的软件公司也会发布有缺陷的软件。软件发布前要对项目做总结与回顾。

第十四章:质量保证

    即使对待自己的作业也要负责任,何况是要上线的软件,但是做到"好"、"快"、"便宜"确实不容易。QA和Testing我觉得区别就在与,测试是在发布前,为实现软件预期应该实现的功能而做的完善工作。而质量保障既包括软件测试,也包括“售后活动”。上线后根据反馈也要对软件进行一些完善,“事后诸葛亮”会议也很重要。

第十六章 IT行业的创新

     说到创新,确实是我们中国应试教育下的一个悲哀,对于计算机行业,我觉得,首先还是明确用户的需求,才能从基本的需求出发,搞出创新。创新者从来都是面对诸多压力的,面对创新的技术,大众接受的曲线也是很久之后才到高峰。看过这章之后我才知道,原来创新也招数,也有时机,在工作中,创新也要注重这些。

第十七章 人 绩效职业道德

    正如站立会议的要点,只允许猪讲话,不允许鸡讲话,因为“猪”是将全身心投入到整个项目,注入的更多也更了解,涉及切身利益,能做到真心负责。对于绩效,代码量多少不能代表什么,真正解决客户的问题的才是有用的,高效的。

读过本书之后的五个问题:

1.关于敏捷,书中说了我理解的就是介绍了敏捷就是“没有既定的计划与文档,马上写代码,随时发牢骚”,但是开发也是需要有一定的流程的,是否敏捷就是分阶段的瀑布?

2.书中的每章末尾的引用出处,我看了一些很有意思,但是一点点敲网址实在是麻烦,或许单独列出来每章的链接是个好主意?

3.我大学同学,还从事计算机专业的女生大多去做了软件测试岗位,不知道老师是如何看待女程序员的?是不是还是女生比较适合做测试?

4.全书所说的所有过程都十分的完备,但是对于一些小型公司,或者说就是只有几个人的小项目组,要进行这么完备的开发过程是不是有点太过于复杂,怎么平衡?

5.关于萝卜和白菜的问题,我自己是比较倾向白菜的,不知道老师怎么看?

原文地址:https://www.cnblogs.com/yumiaomiao/p/5869740.html