实战解析----总序
我和大多数程序员一样，经历了从一个学生到单位合格程序员的一个转变时期。不过我还算幸运，4年的编码生涯后可以有机会经历系统分析设计、项目管理、过程改进等方面的工作，我这个英语菜鸟也居然能到国外去学习，也真是要感谢那些曾经帮助过我的同事和老上级了。
没有从事编码五年后看到了国外一些大家虽然年纪比我大，但也还是在坚持编写代码，并且我发现人过三十后，经历的事情多一些，写出的代码也相对成熟点了。加上进行过程改进的几年终于有时间可以思考，所以就在2004年6月选择了C#作为总结的语言。后来在这里有认识了"孙策"和"双鱼座"等一直坚持在技术一线的优秀人才，看来编码我还真的要靠边站，希望读者多多看看他们的技术总结。
这个分析的项目是在98年底完成的，参加前我只会FoxPro For Dos ,单位人手不够，就硬把我推进去了，居然要用NT,第一次接触！碰到好多基本的知识要求如：队列、信号互斥、命名管道、socket把我给折腾了半年，幸好当时有个科大的同事C有些经验，是他给了我一些启发。
我的解析分六部分：
1 开篇
概要阐述了我这些年的开发管理心得，当然很多观点你一定很熟悉，软件开发的大原则个人觉得最后感觉都很相似。当然也有本人的一些特别体会，如想方设法把客户拉进项目组;自适应团队;始终保持目标;为提速做好准备等以前都有较深的感触。
2 项目的目的和需求概括
任何一个项目的需求开发都是至关重要的，文中通过丰田公司的所谓"看板"的方式将需求直观、简洁地呈现到客户、领导、项目经理、开发员、测试员等一切项目干系人面前。
3 我想到的设计
要想在项目后期不要出现处处都是“关键路径”的局面出现，一要靠项目管理，二要靠项目的技术架构，这通常是项目经理和技术总工为主进行的。
本文的设计已经不是当年的方式，毕竟思想进化了，工具也“锋利”了。
没有从事编码五年后看到了国外一些大家虽然年纪比我大，但也还是在坚持编写代码，并且我发现人过三十后，经历的事情多一些，写出的代码也相对成熟点了。加上进行过程改进的几年终于有时间可以思考，所以就在2004年6月选择了C#作为总结的语言。后来在这里有认识了"孙策"和"双鱼座"等一直坚持在技术一线的优秀人才，看来编码我还真的要靠边站，希望读者多多看看他们的技术总结。
这个分析的项目是在98年底完成的，参加前我只会FoxPro For Dos ,单位人手不够，就硬把我推进去了，居然要用NT,第一次接触！碰到好多基本的知识要求如：队列、信号互斥、命名管道、socket把我给折腾了半年，幸好当时有个科大的同事C有些经验，是他给了我一些启发。
我的解析分六部分：
1 开篇
概要阐述了我这些年的开发管理心得，当然很多观点你一定很熟悉，软件开发的大原则个人觉得最后感觉都很相似。当然也有本人的一些特别体会，如想方设法把客户拉进项目组;自适应团队;始终保持目标;为提速做好准备等以前都有较深的感触。
2 项目的目的和需求概括
任何一个项目的需求开发都是至关重要的，文中通过丰田公司的所谓"看板"的方式将需求直观、简洁地呈现到客户、领导、项目经理、开发员、测试员等一切项目干系人面前。
3 我想到的设计
要想在项目后期不要出现处处都是“关键路径”的局面出现，一要靠项目管理，二要靠项目的技术架构，这通常是项目经理和技术总工为主进行的。
本文的设计已经不是当年的方式，毕竟思想进化了，工具也“锋利”了。
4 关键技术储备
一个软件不管功能多强，性能上不去用户都是不会用的，所以在迭代开发中，首先要提出高风险的技术问题，尤其要验证和测试系统今后的性能承受能力。
文中概要地给大家示范了一下该过程。
5 主体实现和界面示意
主体核心的实现部份，世界上好多事情都是遵守二八原则，核心的其实还挺简单，但是确实系统的生命所在，看看原文相信会有体会。文中也大致模拟了一个商业软件应该具备怎样的界面作了一个简单示例。
6 点评与总结
对本次解析做一些总结，也对中国的IT现状发了一点牢骚。
再次概括了我对技术、项目管理、和过程改进的体会：
温伯格大师曾说：“技术(本身)毫无价值”----转送给迷惑的程序员
艾森豪威尔上将曾说："计划本身什么都不是，而编制计划的过程就是一切"----转送彷徨的项目经理
齐白石大师曾说：“学我者生；似我者死”----转送给委屈的过程改进者
看我的代码，基本没有什么新技术可以学到，但愿大家能借鉴我的一点经验总结就挺高兴的了。
最后希望在这个园子里能结交更多的朋友。
alex 12-2
