个人作业4——alpha阶段个人小结

一、个人总结

在alpha 结束之后， 每位同学写一篇个人博客， 总结自己的alpha 过程；

请用自我评价表：http://www.cnblogs.com/xinz/p/3852177.html 有比较才会有进步。

alpha 过程

自我评价：

第一部分评价：

第二部分评价：

之前写过统计代码量的小工具，刚好拿过来用，如下是后端的代码统计结果，600左右,前端的大概有400行的代码，加起来1000行代码左右

个人技能自评表：

---

二、回答问题

我们在课程开始之初，曾经要求大家针对软件工程提出问题：
个人阅读作业2，那么在经过alpha阶段，大家是否对软件工程有了一定的了解？请结合自己提出的问题进行回答

当初提的问题博客链接：http://www.cnblogs.com/lyq063/p/8576167.html（我只想问：我当初提的是什么鬼畜的问题。。。表示到现在也没有理解透）

问题一：

1.2软件工程是什么当中提出：

软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。

当初：不理解什么是系统的、有序的、可量化的方法...

我现在的回答：拿我们做的小项目来说，我们做的是记账小程序系统，最核心的是记账功能和查看明细功能，还有一些其他的。我们会把功能细分，任务细分，有计划地管理项目，所以说是有序的。我们会预估工作过量，工作量是有限的，所以说是可量化的。

问题二：

2.3个人开发流程的表2-4下面一段话中提到：

显然，从学生到职业程序员，并不是更加没完没了地写程序--花在写代码上的时间反而少了许多

当初：认为的是书上的说法不对，认为职业的程序员编码还是占用很大一部分的时间
我现在的回答：经历了alpha阶段，模拟了软件开发的过程，编码行数才1000左右，与预期的有差距，以为是一直敲代码，结果我们在设计和需求分析上面花的时间比较多，尤其在界面的设计和数据库的设计方面，反反复复，改了好几遍才满意。看来书上说的是有道理的！

问题三：

7.4 MSF过程模型当中提到：

MSF过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的，它把瀑布模型中增量迭代的长处结合起来了

当初：不理解增量迭代的长处
我现在的回答：瀑布模型把软件开发过程划分成若干阶段，每个阶段的任务相对独立，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度。每个阶段必须完成规定的文档，在每个阶段结束前完成文档审查,及早改正错误，是一种不断迭代的过程

---

三、再提问题

同时，大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。
在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文。列出一些事例或资料，支持你的提问 。说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？
一个模板可以是这样：我看了这一段文字 （引用文字），有这个问题 （提出问题）。 我查了资料，有这些说法（引用说法），根据我的实践，我得到这些经验（描述自己的经验）。 但是我还是不太懂，我的困惑是（说明困惑）。【或者】我反对作者的观点（提出作者的观点，自己的观点，以及理由）。
【附加题】：请将问题提交至豆瓣：https://book.douban.com/subject/27069503/， 并在博客中给出链接，在豆瓣页面的最下方 “读书笔记” 那里发言， 《构建之法》的作者会亲自答复问题

• 问题一：

在书上第六章敏捷冲刺提到冲刺阶段要求我们每天都要开一个站立会议，报告各自的情况。但是我认为我们平时都还要上课，并不属于真正的开发人员，他们只有做项目这件事，而我们只是模拟这个过程，真的要遵守这个规则吗？如果遇到一整天满课，晚上还要补作业，没有其他时间做项目，那还有必要开站立会议吗？所以我认为这个敏捷冲刺14天对学生而言太苛刻了点

• 问题二：

在书上7.2.4各司其职，对项目共同负责中提到：每个角色在其职范围内的失败都会导致整个项目的失败，而且各个角色的工作都是相互渗透、相互依赖的。

但是我认为，角色的能力都不相同，如果存在成员不能独立负责某一模块的情况，那么就需要其他成员协助完成。而这个成员可能也有自己的模块要完成，这种特殊的成员我们勉强称之为“全栈”或者项目的总负责人员，那么按照书上的说法，不管是哪个地方出来纰漏，他都需要负责吗？如果是这样，会不会太累了点呢？

• 问题三：

在书上第九章详细介绍了项目经理，提到：

软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面的事情但也很重要，我们叫他们项目经理

但是实际情况是：大家会误认为应当选择开发能力比较强一点的做PM，也就是说PM要做“全职保姆”，啥都要做一点，担起全部的责任，结果是PM更累一点。我认为和书上的描述不相符合，如果PM不需要写代码，测试代码，但至少应该会了解要怎么写，是否可行。比如像我们的微信小程序，我们要实现记账提醒的功能，而因为小程序的特殊性，无法像公众号一样在不打开的情况下还能提醒，那么如果这些技术上的问题，PM不了解的情况下就容易导致方向偏离，这样真的好吗？

• 问题四：

在书中第八章提到软件的计划和估计时可以参考前人的经验，用快速原型法——用一年各个先锋去探路
但是我们在需求分析阶段时候就要求我们估计工作量。如果在团队的成员都不了解项目的情况下，又如何预估工作量呢？而我们不能派几个代表说：“你去探探路，做个小型的demo，然后告诉我们简不简单或者难不难”。其次，在不了解成员能力的情况下，在始料未及的困难出现时，我们无法提前预估工作量。如果开始时随意地估计，最后发现有一定的差距，那么这个预估的意义又何在呢？

• 问题五：

在书上第十四章软件质量的成本中，作者认为还要加上流程分析改进、投资改进等。流程分析要求团队成员分析各个阶段的优缺点，并提出改进意见，那么这个属于事后诸葛亮分析的部分，和成本的关系是啥？我不太理解。投资改进这个可以有，如果时间上成本花费得太多，可以开发、定制、购买、完善用于软件开发和软甲管理的工具。这个有道理，毕竟很多时候有钱可以解决问题 哈哈