点击下载此游戏
这个游戏展示了基本的图形处理（镂空、叠加、切割、变色、不同格式读取）、碰撞、动画、按键处理、声音播放，内部技术包括内存处理、异步处理、时间逻辑、触发类、数组逻辑、类库编译、外部API调用等，当然这些看不见，要看代码。主要使用工具：Visual C# 2008 Express程序编写、3DMax9角色制作、Photoshop资源制作。
既然是搞项目管理的，这个小游戏也按照一个项目来做的，那么就按整个项目以项目管理的知识体系来说，由于非正式，一些量化的方面仅做概念处理，另外提一句，项目没有按照原定完成。
一、启动阶段
项目目标：一个新颖的小游戏，以此巩固C#学习成果，试验图形处理
组织团队：就一个人，管理、执行等工作有一个人完成，职权表——免
项目方案：初步方案，主角是一个失事的飞行员，要躲开残骸顺利跳伞降落，敌人是飞机残骸被击中生命减少直到死亡，增益道具同残骸一起随机产生，主角获得增益道具补生命，减益道具包括大量损血、减慢、反向操作三种，残骸和道具的路线随风向改变，风向有标识，界面包含场景、主角、敌人、道具、生命值显示、风向标、高度值，主角在高度到达一定数值完成游戏过关，共8关，难度体现在风向变化时间、敌人飞行速度、增减益道具数量，小单机无网络，无复杂AI，无双人对决，策划案——免
可行研究：游戏方式较为新颖——可行。巩固C#学习成果——难度不大，可行。试验图形处理——有图片就可以处理了，主要检验于动态图形处理方法。目标用户主要是自己和朋友，因此项目干系人较少，另外此作品可展示自身能力，一些潜在干系人需要分析，考虑潜在干系人需求，发布的文档要写的好。
评估项目：基本上通过前期的准备，C#的编码能力已经初步具备，完成此游戏难度应不大，时间应在2天之内完成，潜在风险包括技术难度过高、软件无法使用、个人突发事件、档案丢失、需求变更、项目延期，这些问题的应对方案就免了，反正就我一个人嘛。评估结果是，按照二八原则，可以认定实现项目目标的80%左右是可以的，也没有财务支出，影响到的仅是个人时间和并行事务，排好计划就可以了。
项目决策：一个人的项目说明会……免了
二、规划阶段
可用时间计划：星期五6个小时、星期六4小时、星期日6小时、星期一14小时，共20小时
项目范围管理：项目范围按照项目方案实施，工作包分解分成编码和设计两个部分，由于仅有两天时间，就没有花大力气做工作包分解。
项目时间计划：网络图如下
细致的计划就不写了，计划安排星期五完成图形类和基本界面设计，星期六完成全部的界面设计和资源制作，星期日编写角色代码和逻辑架构，星期一完成剩下除了发布和专稿以外工作。给自己的缓冲时间为星期二一天，毕竟星期三还要上课。
资源管理计划：就一个人，无非是吃饭花点钱，需求一台电脑，编码和设计环境，看样子不少什么
质量管理计划：考虑到特殊情况，这里就没有写太多，关键看计划的实施质量怎么样。
风险管理计划：参考前面
沟通管理计划：一个人有啥沟通呢
三、项目实施
项目过程控制、范围控制、进度控制、费用控制、质量控制、风险控制就不一一列举，此项目虽小但是确为一个很全面的项目，具体说说实施过程。
项目的过程控制较为顺利，基本上按照计划进度在进行，在前期和后期都遇到一些技术难题，这些难题通过搜索查询的方式解决，但对最终的测试时间有一定影响，因此，网络图中K项工作被推到星期二进行（注意，K项的推迟并不是指单项移开，按照网络图以K为前置任务的任务都将被推迟）。
最不好的是范围控制，按照原定的项目需求，应有增益道具、生命条、高度指示，这个是没有的，因时间问题而去除，如果按照项目管理的变更计划，我应对此部分负责提出理由并通过批准。在这里出现了项目范围蔓延的状况，不是少东西了，为什么还蔓延，原来的项目方案中没有过关过程，这部分逻辑没有想到，而且界面设计也没有考虑过关之后的结果，如果按照一个好的项目标准评判，因为在项目进展到快结束的时候才发现少了这么多，可以说完全不对，也没有什么补救措施，只好减少功能只有一关，而且是无限玩下去。
范围变更使得质量控制就有所制约，这里虽没有质量控制，但是实际上还是影响到了，到了一半还要减少功能，质量控制该怎么办，到底按什么标准来控制？
四、项目收尾
收尾检查：范围未实现的是增益道具、生命条、高度指示、过关逻辑、失败逻辑都没有做，其中包含了编码和设计两个部分，如果做评判，游戏的逻辑层面仅完成不到60%的功能需求，整个项目来说，已经80%以上。
时间进度比原来推迟约4个小时，加上2两个小时的发布整理超过6个小时，超出是项目时间计划6/(6+20) = 23%，时间进度控制很失败，原因来自需求不全面，评估偏差。
项目收获，此次项目收获大量C#编码实践，并且学习到很多的新知识，项目的学习目标完成的不错。
文档已经保存，并且编目加版本号，以便于随时查询和使用里面的实现方法。
这个项目虽然短小，但是却也暴露了很多问题，要想管理一个项目确实非常难，那么，项目的总结报告就算在晚上睡觉前，这是一个不错的主意。
本文转自nowpaper 51CTO博客，原文链接:http://blog.51cto.com/nowpaper/712613
