学习进度总结（一）

  今天开始一天一篇总结

  前几天看了Android的视频教程，有点儿一口吃个胖子的感觉。学习了很多的知识但是都没有学精，跟着教程，我大概知道了一个项目需要哪些东西。比如图片当道res目录下还学到了运用布局管理器来布置页面。就像一个棋盘，棋盘的网格就是布局管理器，棋子就是组件。我也跟着教程创建了手指拖动图标的实例，下一步计划学习登陆页面。开始着手寒假留的那个记账本。

  阅读日记

  人月神话讲的

• 对于软件项目进度的估算往往会根据项目的紧急程度而得出过于乐观的结果，这一方面是因为所有的编程人员都是乐观主义者，我们往往会认为“这次肯定能运行”或者是“我已经找出了最后一个bug”，另一方面则来源于市场的压力，这种情况在国内环境更甚。我们对于进度估算的第一个错误假设就是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。而这个假设往往是一厢情愿的，对于创造性工作来说，创造者常常是在实现过程中，才发现在构思设计时候的不完整性和不一致性，从而反馈到的构思设计上，处理这种问题的时间和复杂程度会随着项目的结构以及任务的大小而呈现非线性增加的关系。所以对于大型软件项目来说，“一切都将运作良好”就是一件概率非常小的事情了。
• 在软件项目中我们往往用人月这个指标在衡量项目的工作量。但是人月这个指标实际上是一个危险的带有欺骗性的神话。它暗示着人员数量和时间是可以互相替换的。只有在将任务分解给参与人员后他们之间不需要互相交流的情况下，人数和时间才是可以互换的。在实际软件项目中，只要项目具有一定规模，不论是设计、开发、测试、部署各个阶段都会有分解任务给不同人员，而且这些阶段本身也属于一种任务的分解，在不同人员间分解任务就不可避免的引发额外的沟通成本——培训和相互沟通。因为软件开发本质上是一项系统工作——错综复杂的关系下的一种实践，沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。简单来说就是，3个人要干3个月的事情不是说安排9个人就能1个月干完了。而且，在进度落后的项目中增加人手的做法，往往只会使进度更加落后。这就是去除了神话色彩的人月。