个人软件过程 1

    提到软件过程,大家首先会想到"传统的瀑布模型",当然,这个通常作为反面例子,来衬托各家的过程如何实用、先进。然后是CMMI、Rup这些重量级的软件过程，然后是Xp、Scrum这类敏捷过程。嗯，无论是哪一种软件过程，一般公司有实施过的，程序员常常会联想到两个字：痛苦。
    是的，痛苦。漫长的培训、没有必要最后也没人看的文档，当然即使是XP的捉对编程也会令一些人感到私人空间收到侵犯，而单元测试这种一部分人寻找快乐的方法，也往往会让另一部分人感到繁琐。

    通常叫嚣要建立良好的软件过程的人，是公司里的技术权威，或者准权威。通常这种叫嚣的结果，是所有人的无奈，和叫嚣者最后的颓败。
    所以姑且不论大公司，我所见过的中小企业，即使通过CMM几级认证之类的，往往也是挂羊头卖狗肉。为认证而认证，真正的软件过程仍然是稀烂到不能再稀烂的程度。今天想起来应该这样，强调一阵子，明天想起来应该那样，再强调一阵子。强调来强调去，随着人员频繁的进出，最后往往是我们每天在努力，然后我们每天都很稀烂。

    这也许和中国人的特质有关，工作如何令人快乐？良好的过程如何长期保持？
    西方人的经验未必有多少借鉴意义。
    很简单，在西方，程序员是高薪行业，也是能工作到退休的行业。而在中国，程序员多数是以民工状态生存的，同时是一碗青春饭。西方尚学尚能，中国唯尚官，在南为橘，在北为枳，大体就是这个道理。哦，那些每月拿到数万元高薪的家伙，没有说你，一边去吧，这里讲的东西不适合你。

    我长期挣扎在一群程序员中间，维持一间十来人的小型公司多年，慢慢实践的结果，觉得对中国人，必须有针对中国人的软件过程。这不是民族主义，我也不愤青；这也不是独树一帜，我采纳的也都是各类软件过程中一般的实践。针对和地球主流不同的人群，中国程序员，当然要有和主流不一样的方法。
    首要的原则，是简单，次要的原则，是坚持。当然，不简单的东西若要坚持，往往也是天方夜谭。

    我想，多数有一定年头的程序员面临的问题，往往是需求怎么采集、怎样将需求划分为开发任务、如何设计数据库、如何做类设计、怎样保证质量、怎样管理源代码和项目资料、怎样监控进度、怎样权衡进度和工作量的关系、如何判断哪些程序员贡献度最大、怎样积累开发知识、团队整体水平很差的时候怎么办？
    我最后形成的方法，或者是开发习惯，基本上一一对应的解决这些问题。

    从方法论来说，我们必须先知道为什么这样做，才会这么做。因此，有几项基本的立论：
    1、每个人都是懒惰的，勤快是因为有所图：比如需要赚钱养活自己、担心丢失工作、在团队中担心没有面子、希望将来能够赚更多钱，这些都是能够勤快点常见理由。
    2、中国是没有高手的：嗯，看看操作系统、数据库、开发环境、主要的优秀产品、最强的公司，这些是不是在中国，看结果就知道。
    3、人的能力是有差异的：虽然整体是中国软件处于地球上的食物链低端，但具体的个体之间还是有强有弱的。
    4、每个人都喜欢听到夸奖的话，不喜欢被批评。
    5、模仿是最好的学习方法：这个，我们知道英语折磨了很多大学生，学习十年后不会说话的比比皆是，却很少听说哪个小孩因为智商问题学不会说汉语，虽然汉语看起来似乎更难一些。
    6、最重要的：如果人的劳动不能带来有尊严的生活，不要指望任何方法可以让这个人为你拼命工作。这一点是所谓软件过程能够实施的前提，假设你准备开一间黑心工厂，或者你准备利用廉价到甚至难以应付生存的劳动力赚钱，任何所谓的管理、架构之类的药物都不用吃，注定没有效果的。
   
     所谓最简化的软件过程，大体上从这么六点出发。在公司层面来说，公司的技术负责人、项目经理可能需要真正实用、可操作性强、可持续的团队项目管理方法；在程序员个人层面来说，形成良好的工作习惯，让自己更有效率乃至今后逐步胜任团队的管理，这些知识也是必须掌握的。
     所以，这里会是一本薄薄的书，从现在开始我会结合一个实际项目，“彻底完成”其中的数据导入功能，逐步的讲解，自己个人的编程习惯、团队协作最简易的方式，包括采集和记录需求、规划用户体验、列出开发任务、估算所需时间、类设计、数据库设计、管理bug、版本控制、知识库等各方面。
     也希望牢记一个原则，你做的软件产品，只要多按一个键，意味着客户永远不会用，这种简单性，既对软件产品的用户来说是必需的，对程序员而言也是这样：多一分复杂，就不要指望每个人都守规矩。