软件项目经验总结

如何让所有的涉众目标一致
1，文档：
因为一个工程，所有的涉众不是同时介入的。这就导致了
对于工程的认识就不同。而要帮助后加入的成员很快的进入角色，
就必须有提纲性的文档作为引导。并且所有的描述语言都是所能够
领会的，比如uml就是一个很好的选择。
2，授课：
严肃的说不是授课，而是交流经验。广开言论，而后达成共识。
3，明确的核心骨架和规范
高层业务用例，高层测试用例，核心类构成，主要流程。这些都决定了
系统的主脉络。

如何让团队成员保持激情
1，阶段性的成果
   让每个员工感受到阶段性的成果，是大家心血的结晶，而且是大家
   辛苦努力的结果。不是停留于语言上，而是让每个人真切的感受到
   确实是这样。并且对结果都是有十足的信心。
2，挑战性的工作
   在单调的工作中，寻找挑战性，寻找亮点。让每个人在团队中体现出
   个性，让每个人感受到她是不可获缺的。
3，时刻的进步
   对每个成员进行合理的规划，在工作的同时，提高每个人在自己领域的进步
   尽可能的和她的职业规划一致。时刻感受到她在进步。
4，实时的支持和鼓励
   风险和困难到处都是，此时，要有强有力的支持和鼓励以及帮助。要尽可能的
   寻找资源来帮助她，而不是将压力全部推给她。
5，成果的喜悦和物质的关怀
   我们成果了，职业生涯画了很好的一笔，精神享受的同时，将大家的打车费，加班费
   ，奖金等立刻兑现。走去high吧 哥们。

如何让团队有凝聚力和自由的交流空间
1，成果分享
   在体现个人价值的同时，成果是大家分享的。当然 给予分享的人，她的个人魅力的提升就是一种收获。
   将这种价值观贯穿整个团队。鼓励大家分享。
2，有个安静的交流环境和小黑板
   如果有coffe更好不过。这里是灵感的来源地，解决问题的天堂。
3，有价值的培训和交流
   不说为项目做准备，就是提高个人能力和交流彼此思想。此时我们抛开目前的项目。

如何使用模式
这里将不对具体的模式进行大量的描述，只是总结自己的经验，谈谈自己的浅论。
1，项目管理模式
    项目管理模式使得常规的管理问题处理起来变的简单，如果这个团队是新组建的团队，
将会使开头的事情有条理的进行，管理者将只是关注异常的发生，应对那些比较难处理
的困难，不为其他事务所劳累，以使得偏离方向，使一切陷入泥潭。
    我的总结是 牢牢的抓住主线，旁支末节套用模式去处理，不必去创新，好的模式已经潜
    在的包含了处理风险的方法，要做的就是发现并使用它。当然，用了和用的好差别是很大
    的，常规的判断和经验的积累是提高的最快方式。
2，业务模式
    领域模型的概念提出很久了，虽然做了很多的领域，自己仍然没有对此进行深入的研究和
    探索。业务模式更多的体现于用户权限控制，日志处理等通用模式和一些行业特有模式（
    如：电信计费模式，网管报警模式，电力设备运行模式等等）。对于业务模式我的意见还是
    知识库的方式，没有银弹。尽可能的收集和提取业务模式（以易懂的描述手段进行编写），以专业
    的模式名以大家熟知的方式进行索引归类。方便大家查询，业务模式是帮助大家理解新的业务需求，
    并不是套用和借用。
3，构架模式
    用成熟的，如mvc.借助一些成熟的framework，中间件等。
    因为产品的特殊性，没有成熟的模式匹配，建议大量采用层模式，使得问题处理起来简单一些。 
4，设计模式
    设计模式是为了设计师之间的讨论。我严格的批判以代码分析模式的学习方法，因为我们大家都是
    从代码时期慢慢的转入专业的设计队伍的，所以难免看到模式的时候想到的是如何用某种代码实现
    这个模式，引入大家进入了一个误区。可以尝试，不看任何模式代码的实现，先看模式，想想以前的
    系统，那些场景适合某些模式的使用或者扩展。懂模式，而后用模式，然后进行设计，再去实现它。
5，代码模式（通用组件）
    封装好用的组件是很困难的，将代码模式转化为组件更是难上加难。像我们这些二把刀子，可能做出
    的组件还不如不做组件。所以，对于代码模式，为了便于操作和使用，我建议：
    第一步：封装一些常用的工具类，如：字符串比较，日期比较等等。使得最常规的一些实现通用稳定适用。
    第二步：根据具体产品功能需求，进行针对性的组件封装，功能最好单一简单。
    第三步：组件群的设计，为了实现复杂功能，将简单的组件进行群化。