标签：
1、 问题解决 http://www.cnblogs.com/someonefighting/p/4830605.html
1） 现代计算机技术发展日新月异，很多情况是我们很难预知软件的具体定位，从而做出迅速的方案设计，那么在这种情况下“走一步看一步”是不是也不失为一种好的软件开发方法？
虽然准确的定位一个软件的需求和功能具体实现细节是困难的，但是对于接口等等架构的设计一定要最先进行，否则会把大量的时间花在重构上。
我还有一个明显的技术理解错误就是”写代码“是比较简单的活动。复杂的是软件架构，只要架构设计好后写代码是程序员的事儿，这是一个明显错误的价值观，认为写代码的人都是廉价的，不具有任何的设计和创造新。一个简单的PPT、WORD文档中的架构图是不能表示架构的。用Craig larman大师的话讲，在整个软件生命周期的活动中，复杂的是编写代码，而代码才是架构，所以说架构的就是代码。你原本理解的架构才是真正难的地方其实也就是代码才是真正难的地方，不可浮于表面，这样才能更加的接地气才能真正的有价值。
在编写代码的过程中往往出现很多意外的问题，经过思考才发现是设计的漏洞。只有将问题带到架构的位置，用架构的视角设计方案，然后亲自把这个方案带到代码”前线“落实下去，这才是设计的意义。
软件开发是一项设计活动而不是建筑活动，软件是会不断变化的，而建筑一旦敲定是不会改变的。
2） 书中认为软件开发最好的状态是不耽误程序员正常的家庭生活，但是现实生活中往往相反，书中的这种观点是否具有可行性，是否太过理想化？
软件开发不轻松，但并非都似想象的那般辛苦：众所周知，软件开发是很辛苦的工作，想到软件开发就能想到加班熬夜，这让很多在大学时代对软件行业充满憧憬的人望而却步。整天对着电脑，除了写程序就是吃饭睡觉，经常要加班到深夜，没有周六周日，有时还要出差到外地去做封闭式开发或者维护，长时间不能跟家人或女友见面，社交关系简单，与自己共度时间最长的是同事，没有时间和同学朋友聚会。这些确实是一些软件软件公司的现状，但不是全部。有些IT企业对员工还是很人性化的，并不要求每天加班，同样周末也可以休息，有良好的企业文化，简单的 人际关系，多数员工都能公平的竞争，有平等的机遇。当然，有时为快速推出产品，先对手一步抢占市场，适度加班开发也是正常的，但这是阶段性的，不是长期状态。其实有些时候为了自己喜欢的行业和职位，在能够承受的范围内适当多付出些是值得的，而且迟早会有回报的，毕竟我们从事什么行业都要靠辛勤和汗水换来自己的成就，软件行业亦是如此。
3） 书中认为不应当给队员施加过大的压力，这样会造成积极性下降，但是我认为事实上，软件开发的初期由于经验不足和其他的多方面原因，压力过大是一种正常的状态。只有经历这一阶段，软件开发才会平稳高效的进行？
软件开发进度监督是指在项目进行过程中，协调用户需求和软件开发的关系，监控软件开发任务的执行情况，给开发人员和管理层提供反映软件过程质量的信息和数据，提高项目透明度，从而保证项目按照计划实施，实现预期目标。
所选的软件开发进度监督人员应具备3方面基本素质：具有较强的工作责任感和良好的沟通能力;熟悉业务管理流程，掌握软件开发流程、开发规范以及相关标准;具有软件开发项目的建设和管理经验，掌握项目管理知识。
监督人员除了监督职责外，还应该协调小组成员对软件进度及时调整。为确保项目按时、按量、按质完成，PM必须控制任务和跟踪里程碑。按照软件项目的开发规律，将软件开发过程分为几个重要阶段，对这几个阶段的关键事件设立里程碑进行跟踪管理。
项目进度管理可以选择很多方式完成：制定项目里程碑管理运行表;定期举行项目状态会议，由软件开发方报告进度和问题，用户方提出意见;比较各项任务的实际开始日期与计划开始日期是否吻合;确定正式的项目里程碑是否在预期完成。
这样可以高效有序的进行进度管理。
4） 《快速软件开发》明确指出鲁莽编程的不可取，但是并没有提出一个具体可行的方式，都是在进行理论？
鲁莽式编程会造成设计的不统一，无法控制适应变更的代码的速度和次数。变更是无法避免的，你的代码无法面对这些复杂的变化，因为你的代码不是设计出来的而是堆出来的。最后你的项目质量也无法很好的保证。
5） “糟糕的计划”和“不清楚的合同”，关于计划和合同是否高效往往需要时间和实践的检验，很难在行动之前作出判断？
软件开发需要不时地于需求进行沟通，然后逐步完善功能，因为这种现象是正常的。
2、 新产生的问题
1） 协调开发团队之间的对接问题：”牵一发而动全身“导致小修改的连锁效应好的解决方法？
2） 由于团队中每个成员的能力不同，进度难以一致？
3、 温故而知新
说到软件开发就不得不提及调试，在这点上我对”软件工程的瀑布, 大泥球, 教堂，集市，和银弹“这篇文章的印象最深刻。
一度狭隘的以为编程能力就是指数据结构和算法，只有在ACM的时候才有用武之地，经过这一阶段的团队项目开发我才真正地意识到，编程能力已经成为了构建程序框架不可或缺的能力，他不仅决定了程序的正确性和鲁棒性，还决定了其可扩展性，一言以蔽之就是决定了代码的生死存亡，编程能力强就意味着程序中大泥球的数量很小甚至没有。
曾经写过一个目标追踪的项目，程序的框架设计和编写同时进行，最后一股脑的才开始测试，由于类的设计交错冗余，功能或独立或重复，还有功能没有覆盖上的，再加上函数的正确性没有进行单元化覆盖测试，执行的结果也时对时错，不断地调试修改程序导致“泥球”越滚越大，不仅在调试上花费了大量的时间精力，而且写出来的程序可扩展性很差，仅仅是添加个接口都需要改动很多代码。
经过了上次“血的教训”，在进行软件工程团队项目开发的阶段，我都会首先确定需求，预留接口，在编写代码的时候始终保证单元功能的正确性，虽然程序中还是有很多需要改进的”大泥球“，但我会端正对“大泥球”的态度，努力提高自己的编程能力，培养良好的编程习惯。
4、 总结
1) 软件开发个人体会：
1. 软件领域中的知识在于积累。
2. 做软件开发，就类似算数学题和世界杯足球赛一样：重在结果，而不在乎过程。
3. 软件服务于人类，软件是在解决一些生活中的问题和错误，问题决定解决方案。
2) 在开发中遇到问题应该怎么去解决？
1. 不明白就多问，不要自已一直去琢磨，多关注前沿技术动态。
2. 一个问题如果30分钟还没有解决就应该考虑是不是问问别人,有效的管理开发的进度。
3. 一个问题在没有用过3种以上的方法解决过就不要去问别人。
4.解决问题思路是关键： 相信问题总归有解决的办法，就算连技术上都没法实现的问题，相信通过良好的沟通终究也会有解决的方法。
5. 解决问题的前提是：理解用户的需求，多和用户、队员沟通，及时反馈信息进入实现。
3） 怎么样才能提高自身的能力？
1. 进步的方式—— 理论结合实践
2. 不要怕出错，不怕遇到错误，有错误就有挑战，这样才可以进步，但不要犯相同的错误。
4） 怎么样才能做好软件开发？
1. 首先要明白解决的问题是什么，理解问题，其次再决定怎么解决这个问题，即用户需求
2. 碰到很复杂的问题，对问题简单化，细化到能够实现为止
3.小组、组员之间相互协调，统一实现细节，确保每个成员都对软件的运行机制烂熟于心，只有真正彻底的了解了项目的业务需求，我们才能做真的做好这个项目
4. 出了问题，我们要先分析问题，然后知道引起问题的原因，最后并想出问题的解决办法
5） 文档的重要性
搭建一个开发环境，配置几台服务器，划分一下模块，分工，我们就可以Coding了，一直到项目结束了，也没有完整的设计文档，更没有完整的测试文档，虽然这样的确是很快的完成了Coding工作，感觉上好像节省了好多成本和开发时间，但后期的维护和Bug 就是经常出现的事。
小项目没有文档关系不大，但如果遇到一个大项目的时候，那这样的开发方式就很有问题很危险的。如果大项目没有文档： 首先维护就很麻烦，也很乱，写的代码，过几天都不知道它是完成什么功能的了，其次系统的稳定性和可靠性也让人怀疑，扩展性也会很差。
标签：
原文地址：http://www.cnblogs.com/someonefighting/p/5118306.html
