项目开始的第一周 3.9--3.16

  一直以来有个习惯，可做可不做的事情一般不做，必须作但又不喜欢的事情用效率去做，喜欢做的事情一定要做到最好，比如足球，比如书法，比如winning 11.所以出现了我们小组的文化，“既然选择了要软件，而又不愿大众化，那我们把一个简单的东西做到极致，然后成为我们的绝招"————题记

  团队名：Lemon Tree

  团队成员：许凯，杨晓丽，张怡，谢力励，杜书宇

3.9   
  决定参加比赛一个月（2.6-3.6）

      大家都做了不少准备，自学了软件项目管理，面向对象解决方案，.net，软件过程管理。比如本人：本来的假期的日子--吃饭，睡觉，娱乐三条线路被自然而然的打乱。取而代之每天都会很早醒来，读读《古文观止》， 想想这一天的计划,然后95%的执行，还有5%的时间会不知不觉流逝——因为这样那样的原因而中断，等重新敲打键盘的时候又是从头理思路。。。老是出现这种情况，进而开始思考解决方案。良久，在其中只弄清楚了一个道理，要处变不惊，就要善于应对各种突如其来的，甚至艰巨的情况——事情有时发生会惊涛骇浪，但只有训练有素的心才能做到平静无波。

        这使我想到我们团队在过程进行的可能遇到的问题：1.因为是第一次配合，如何最大限度的使我们组成员发挥自己最擅长的特点，优势互补——核心问题，资源的最大化；2.在不影响学习的情况下，把我们的在线词典在规定的时间内，拿出一份与众不同的系统——目标问题，实现我们的计划；3.我们学习的技术有多少有用，还要哪些——技术问题；4.其他组的进程和方案——知己知彼。

        怎样的解决方案才能使我们组遇到这些困惑时从容面对——这是个问题。

   
3.10

确定我们团队进程中的风格，即进程方案.

• 需求驱动。因为我们团队期待把项目从设计到实施完美的解决，而需求驱动通常最适用于精心设计的系统，所以成为了我们的首选。需求驱动的特征：严格关注系统外部可见的行为，即系统功能点；每次决策从需求出发。一般遵循以下过程:

             1.列举出所有系统功能；

               2.为其中的每一个线程设计组件。

 3.实现每一个组件。存在问题：由于定义很明确——很多并行结构，对应这每个主要的系统功能，导致了变更的困难性。而我们的需求可能因为新想法而更改，随着需求的变化，项目很容易失去平衡——解决方案：随着进程的进展，对于构架需要改动的分支进行修改或者引入新特性来减少实际重用的数量，再局部优化。

•  构架驱动。既然系统要求可度量性，可扩展性，可移植性和可重用性，不如直接使用柔性很好的构架驱动，并且可很好的适应我们的变化。此开发模式的特征是把重心放在创建一个满足所有已知确定需求的框架上，而且框架具有足够的柔性以适应那些未知的或不太明确的需求。一般遵循以下过程：

1.通过实际场景集合确定系统所预期的行为；

2.实现这些场景构架；

3.演进该构架，根据需求进行中以便适应为被发现的新需求。

• 日程驱动。 由于首次做在线型的系统，考虑到了进程的不确定性而提出此驱动。该驱动的特点是进程的紧迫性。因为过分关注微进程导致最后完整性失衡，即部分功能不能实现——最好的准备，最坏的打算。

三种不同提案，等待开会决定。

3.11

      假期和川大土木的高中同学讨论建筑和软件的共通性——

       如果开发商（我们）想建造一所房子，和建筑师进行讨论是很重要的，因为他们可以帮组我们在时间和预算允许的条件下就满足我的客户需要的产品（房子）达成共识。设计蓝图对双方都很重要，它有助于更为正式.精确地表达我们的意图。为了完成这个计划，所有技术熟悉的木工，电工，水管工和油漆匠都需要使用电动工具和卷尺。他们需要经常观察施工现场并请监察人员单独评估工作，以确保工程和原来的想法一致且符合标准。然后，对我们最重要的最终的还是建成的房子本身——其他任何事情都是次要的，只是在获得最终产品的过程中的必然经历的步骤。

       这和我们软件开发过程很相似。好的软件开发组织绝不会忽视它的主要任务：有效地开发，交付和维护软件产品以使最终用户满意，满足所有已经提出的或者可以想象到的需求。 确保这一目标的分析，设计，实现，质量保证和编写文档等活动才是最重要的，其他任何事情——所有会议，在白板上进行的讨论，测试等——都是完成系统的过程，是次要的。

所以我们团队的行动方案为：把所有的重心和精力放在系统实际的需求和我们的创新点上，而不是理论的东西。最后的目的不是看我们说了多少，开了几次会，而是做了多少——“房子”能满足服务人群么？能让我们和用户都满意么？

 3.12

第一次见面会议

确定我们团队的原则：

• 掌握知识固然重要，运用知识更为关键。
• 过程控制固然重要，完善的团队合作关系，良好的个人工作状态更为关键.。
• 任何的创新来自于对现实的深入分析，没有商业价值分析和流程分析的创新只是空想。

3.13

西游记与团队组件

         为了完成西天取经任务，组成取经团队，成员有唐僧、孙悟空、猪八戒、沙和尚。其中唐僧是项目经理，孙悟空是技术核心，猪八戒和沙和尚是普通团员。这个团队的高层领导是观音。
         团队的组成很有意思，唐僧作为项目经理，有很坚韧的品性和极高的原则性，不达目的不罢休，又有很得上司支持和赏识（直接得到唐太宗的任命，既给袈裟，又给 金碗；又得到以观音为首的各路神仙的广泛支持和帮助）。沙和尚言语不多，任劳任怨，承担了项目中挑担这种粗笨无聊的工作。猪八戒这个成员，看起来好吃懒 做，贪财好色，又不肯干活，最多牵牵马，好像留在团队里没有什么用处，其实他的存在还是有很大用处的，因为他性格开朗，能够接受任何批评而毫无负担压力， 在项目组中承担了润滑油的作用。最关键的还是孙悟空，由于孙悟空是这个取经团队里的核心，但是他的性格极为放荡，回想他那大闹天空的历史，恐怕作为普通人来说没有人会让这种人呆在团队 里，但是取经项目要想成功实在缺不了这个人，只好采用些手腕来收复他。
         这些手段是，首先把他给弄得很惨（压在五指山下500年，整天喝铜汁铁水）；在他绝望的时候，又让项目经理去解救他于水火之中以使他心存感激；当然光收买人心是不够的，还要给他许诺美好的愿景（取完经后高升为正牌仙人）；当然最主要的是为了让项目经理可以直接控制好他，给他戴个紧箍，不听话就念咒惩罚他。孙悟空毕竟是牛人，承担了取经项目中的赶妖除魔的绝大多数重要任务，虽然是个难于管束的主，不能只用手段来约束他。
        此时猪八戒的作用就出来了，在孙悟空苦恼的时候，上司不能得罪，沙和尚这种老实人又不好伤害，只好通过戏弄猪八戒来排除心 中的郁闷，反正猪八戒是个乐天派，任何的指责都不会放在心上。
        在取经的项目实施的过程中，除了自己的艰辛劳动外，这个团队非常善于利用外部的资源，只要有问题搞不定，马上向领导汇报（主要是直接领导观音），或者通过各种关系，找来各路神仙帮忙（从哪咤到如来佛），以搞定各种难题。
         西游记里特别强调得到高层支持的重要性，有没有靠山真的很不同，君不见象白骨精这种没有靠山的妖魔都会死得很惨。
        上面这则来源于网上的故事，告诉我们团队组建对于项目成败的关键作用，人尽其职，物尽其用。在我们的组队过程中给了我们很多启示。幸运的是我们的运气不错，昨晚开会了解到小组里既有了拥有各种必要技能的成员，大家的性格互补，都有着极强的团队责任感和乐观向上的精神——这或许就是成功的前兆吧！
         今后的Blog中我们会一一的来介绍我们团队的每一个成员，相信我们的组合一定会勇往直前，争取胜利的！

 3.14

        第一次参加这种正规的比赛，自然会有无限憧憬，但心里难免又有点忐忑。当朋友把我介绍入队时，我最先想到的是我能给这个团队带来什么。因为我知道能跟一帮这么优秀的人一起合作，不管最后结局如何，我都可以向他们学到不少知识，这一点是毋庸置疑的。也正是这样，我才会去考虑能给我们的团队带来什么价值。

       说来也惭愧，学了一堆所谓管理与技术结合的课程，却从来没有真正去实践过。学过系统开发构建方面的内容，只学到了SOA之类的名词，其内涵于我来说却显虚无飘渺；学过项目管理，可最终也只是停留在画画甘特图之类的，始终没有领会到项目管理的精髓。

       以前所学之虚浮，让我在面对真正有挑战性的任务时充满压力，但也激起我挑战的欲望。前面要走的路还很长。大家一起加油！

3.15

        和队友一起对在线词典大赛的命题思索，感触良多。

        需求是软件开发的起点，更是开发成败的关键。我们一拿到题目不禁产生了如下疑问：没有一个真实的，可以调查、访问、咨询的客户，不能与之讨论、协商以明确需求，我们的设计和开发会不会就是一场游戏一场梦呢？如果仅仅是虚幻的南柯一梦，那么大赛是否能够真正地考量出参赛者的架构设计能力呢？没有详尽的需求，这是我们面临最大的挑战。

        解决方案——我们决定通过自己的调查报告来处理需求。具体细节如下：

• 把客户分为两部分：软件学院和云大其他学院.软件学院：项目计划第一步，面向IT及有关学院的专业在线词典。其他学院：项目愿景——通过本学院的实践经验，进而为其他专业提供在线词典。
• “任何的创新来自于对现实的深入分析，没有商业价值分析和流程分析的创新只是空想。”——我们组的共识——我们的服务和业务模型分析的第一手资料。
• 通过调查报告确定我们组创新的出发点。