体验当‘项目经理’的日子 4---项目开展方式的确定

   分好模块后有两种分配任务的方案可以选择。第一种是将五个大模块分给5组人（不是一开始那种分组方式）， 五组人同时开发各自的模块。第二种方案是将五个大模块再细分成一个个的小功能， 比如更新用户详细信息， 发布一份简历或职位等。由需求分析小组给每个小功能写一份任务书，然后安排其他的人来代码实现一份份的任务书。在这个问题上没怎么纠结， 因为老师他帮我们选了第二种， 说现在有不少公司都是这样运作项目的（ 不知道是不是真的， 哪位大侠愿意在这个问题上指点一下？我有点不太相信老师的话...）。
    好吧， 没经验的听有经验的。  于是确定以任务书的方式开展项目。在确定这一点后， 我们碰到了项目开展后的第一个难题： 任务书该怎么写？
    先说说我对任务书的理解。首先，任务书要具有很高的可执行性， 让人看完任务书后能直接用代码实现。 没有其次 。 为具有很高的执行性， 任务书里应该要包含以下几个部分的内容：1. 功能描述， 这个肯定是必须的， 不用多说；2. 页面和服务器之间要传递什么参数，各个参数的意义是什么， 参数的类型， 若是表单选项，对表单的填写有什么要求， 如能否为空、长度要求、格式要求等， 最好给出一个能直接在Java代码中使用的变量名，以减少命名混乱；3. 实现功能的业务处理逻辑， 涉及到哪些类（action， service， dao）， 要调用哪些方法，最后跳转到哪个页面等。 简而言之， 任务书有点类似于使用说明书， 能够让不怎么会的人在按照说明一步步操作后也能得到正确的结果。

    然后给出一个示例（只有核心部分），以个人用户登录功能为例。
        功能描述:
        从登录页面(***.jsp)通过post方法发送personalUserLogin. action请求传入用户名(email)和密码, 实现用户登录功能。
         用户名或密码为空时不允许提交.
        当用户名表单项失去焦点时验证是否存在此用户, 此验证不通过时也不允许提交. 
 
     传递的参数: 
        邮箱,email, String,  不能为空，而且要通过是用户存在性验证.
        密码, password, String , 不能为空.      
 
    需要的类和方法:
        Action: PersonalUserLoginAction
            checkEmail(): 当用户名表单项失去焦点后向此action发送Ajax请求，调用IPersonalUserDao.findPersonalUserByEmail(String email)验证是否存在此用户 : 若方法返回的personalUser为空, , 则往页面传递true(通过json) ,表示存在此用户;  若不为空, 则传递false,  表示不存在此用户.
            login(): 表单提交后，检查用户密码是否正确, 验证是否存在此用户. 登录成功, 返回”success”, 跳转到***.jsp,  失败则返回***.jsp。
  

    写完这个示例后，我拿去给老师看了一下， 回答是板块还算齐全， 但内容还可以再详细些。（没办法， 又是只有没经验的服从有经验的。）

    这些要求注定写任务书比写代码的难度更大（也更折腾人），所以写任务书的人的水平一定要很好才行，而班上技术拔尖的几个人都分在核心组或担任其他组的组长。 于是我又做出如下安排：每名需求分析组成员都配备一名核心组成员， 前者负责分析业务需求和功能描述， 后者分析业务实现的逻辑。第二天要用到的任务书须在头天晚上提交到SVN， 由我审阅通过后第二天再下发。 另外，在下发具体任务书之前， 分析出各自负责的模块要使用的dao和实体类， 为dao建好接口， 加上文档注释。 对剩下的组员的安排是：继续完成登录注册功能， 然后完成dao接口的实现。
    等这两项完成后， 任务书也该出来一批了， 于是又可以去代码实现任务书。（时间较紧迫， 安排不得不紧凑些。）

    项目的进度控制，即确定在何时之前要完成哪项功能，肯定也是不能少的， 有相应的计划， 但不在博客上叙述了。

    计划制定到这个份上， 若能如愿实现， 完成这个项目肯定是没有问题的。可天下哪有这么多顺心如意的事。 今天是10号， 项目开展刚好一星期。在这一星期中主出现了三个方面的问题， 它们严重影响到了项目进度。接下来的几篇文章会集中对这些问题的分析总结上。 先透露一下是哪三个相关的方面：一些令人头疼的团队成员， SVN使用和文件目录混乱。