确定分工

1. 上次的《需求规格说明书》初稿的不足之处。

2. 讨论制定团队的编码规范，讨论之前和讨论之后，队员阅读《构建之法》第四章内容，并讨论总结。将代码规范和编码原则发布在随笔上，并说说你们这么选择的理由。

《构建之法》第四章讲的是两个人的合作、结对编程。结对编程往往只需花费大约一半的时间就能编写出质量更高的代码。以下是分别对这三个方面的分析与理解：

• 编程规范
  《构建之法》中的编程规范主要包括代码规范、代码风格规范和代码设计规范。此处规范的标准是简明易懂、能让其他程序员更好地理解和维护。对于编程规范的重要性，相信很多人都深有体会，平时上网找参考代码或者是跟别人合作做一些编程作业，最怕就是对方的代码不规范，看起来费时又揪心。其实别说是其他人，如果我们没有一个规范的编程习惯，我们自己回头看自己以前写的代码，恐怕也是很难看懂的。因此在给函数或者类取名的时候要严谨，不能写一些没意义的名称；在一些代码后面可以加些注释来说明此行代码的作用。

• 代码审核
  为什么要注重代码审核？是因为不相信程序员的能力吗？明显不是的，再有能力有经验的程序员也会有出错的时候，这时候若没有严格的代码审核流程，错误往往就会被忽略，直到产品交到用户手上使用错误才逐渐暴露出来，从而造成不可挽回的损失。而代码审核又有自我审核、同伴审核和团队审核几种形式，其作用都是不一样的，自我审核一般能检查一些由于疏忽而产生的错误，同伴审核能以与程序员本人不一样的思维来看代码，从而能发现一些程序员本人考虑不到的问题，而团队审核则往往是站在项目总体的角度分析该代码，从而检查改代码是否能实现了本来要求的功能需求。

• 结对编程
  无论是乔布斯与乔纳森，还是比尔盖茨与保罗艾伦，我们看到了太多的结对模范，他们的成功都离不开彼此。一个人的能力是有限的，在奋斗的路上我们往往需要一个志同道合的人和你一起努力；一个人的思想也是局限的，我们很多时候还需要一面镜子，在镜子中的人对比，发现自身的优点与不足，镜子中的人有时候可以是自己，但更多的时候会是你的搭档。无论是作为一名志同道合的合作伙伴，还是忠实无条件的支持者，还是在我们犯错时及时指正的引路者，你的搭档都是难得而珍贵的。所以我觉得，重视结对编程，有百利而无一害。

3. 通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图。

4. 进行项目的后端架构设计，要与需求规格说明书中的界面原型设计相对应。

5. 确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：

• 利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能，在博客中叙述并给出相应的WBS图。

• 在团队管理软件中（比如Github的Issue，Leangoo等）将各个叶子结点的功能加入，并确定每个子功能的工作量，在博客中给出分配后的截图。值得注意的是，与学习技术相关的任务也需要考虑在工作量中，开发需要检验产出，学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。
• 给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList，并在最后给出燃尽图。

6. 描述组员在上述任务中的分工和工作量比例。

7. 附录

• 燃尽图