团队分工

组长博客 点这里！ 总结思考 设想和目标 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？ 弥补Powerpoint中模板转换存在的缺陷，完善PPT模板一键转换的功能。Powerpoint中模板转换功能能够将PPT转换成系统自带的模板，也能够通过浏览主题的方式将我们选定的模板导入转换，但是这两者存在着一定的缺陷，以致于用户不得不在之后手动矫正纠错，耗费了一定的时间。出于以上原因， 我们计划开发出PPT模板套用的自适应工具，来解决上述问题，提升PPT模板套用的简单性、正确性、完备性。 存在的缺陷 原PPT： ①只能转换一部分内容 ②元素错位 ③无法按照模板转换 导入模板： 转换后： 针对上述问题我们计划实现PPT一键转换的核心功能，并提供LOGO一键生成和PPT一键生成的附加功能，为用户提供更便捷和实用、能够减少工作量、节省时间的方式，去做出符合审美的PPT。 典型用户： 根据使用频繁度以及需要程度来看，典型用户会大学生及以上的学生群体以及工作人士（大约18岁至55岁），同时因为操作起来快捷方便，对于年龄小或者年龄过大的用户来说也是非常简单易上手和实用的。 从熟练程度来看，新手或经验少的人。 典型场景: 出于不同原因需要更换PPT模板时。 急需PPT、LOGO的情况。 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？

组长博客 点这里！ 总结思考 设想和目标 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？ 弥补Powerpoint中模板转换存在的缺陷，完善PPT模板一键转换的功能。Powerpoint中模板转换功能能够将PPT转换成系统自带的模板，也能够通过浏览主题的方式将我们选定的模板导入转换，但是这两者存在着一定的缺陷，以致于用户不得不在之后手动矫正纠错，耗费了一定的时间。出于以上原因， 我们计划开发出PPT模板套用的自适应工具，来解决上述问题，提升PPT模板套用的简单性、正确性、完备性。 存在的缺陷 原PPT： ①只能转换一部分内容 ②元素错位 ③无法按照模板转换 导入模板： 转换后： 针对上述问题我们计划实现PPT一键转换的核心功能，并提供LOGO一键生成和PPT一键生成的附加功能，为用户提供更便捷和实用、能够减少工作量、节省时间的方式，去做出符合审美的PPT。 典型用户： 根据使用频繁度以及需要程度来看，典型用户会大学生及以上的学生群体以及工作人士（大约18岁至55岁），同时因为操作起来快捷方便，对于年龄小或者年龄过大的用户来说也是非常简单易上手和实用的。 从熟练程度来看，新手或经验少的人。 典型场景: 出于不同原因需要更换PPT模板时。 急需PPT、LOGO的情况。 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？

这是敏捷开发一千零一问系列的第八篇。（ 之一 ， 之二 ， 之三 ， 问题总目录 ） 问题 在Team中，TeamLeader给人指定任务时，基本没有选择怎么办？（因为大家对别人的工作都不熟悉） 方案 步骤1： 如果团队已经习惯了沉闷地自己开发自己的工作，办公室里边总是静悄悄的，那么一个可行的起点，是Leader可以先与大家进行松结对，就是不断地指导有难题的人。 实际上当大家听到有人在交流的时候，就会侧耳听听，如果听到自己感兴趣的话题，也会积极参加。 步骤2： 下一步，可以主动喊某些人一起交流，比如“老张，过来帮忙看看小李这个问题”，这样交流的范围就逐渐扩大到3个人，而且老张-小李之间也建立了联系。 一个宽敞点的办公环境还是很有必要的，如果隔断林立，别说三个人，就是两个人挤进一个工位都有困难。 可惜这个问题很难在Team的层面解决，但是如果公司搬家、老板推广敏捷之类的机会来临，一定记得提一下。 步骤3： 从新招来的人入手，一点点形成师徒制度。 原来的团队大家分工习惯了，可能挺难评判谁比谁厉害的（即使完全跨职能，这个也很难，何况加上了工作分工），但是新招来的人很容易适应跟老员工一起工作。 首选那些工作能力超强的老员工，因为分工严重，公司内部没有人能帮他（有时候也没有人愿意），所以给他找个助手还是说的过去的，但是也要提前沟通好，这个徒弟可不是来打杂的，有要求其支持的权利

团队作业10——事后分析（Beta版本） 目录 一、设想与目标 二、计划 三、资源 四、变更管理 五、设计与实现 六、测试与发布 七、总结 八、图片和贡献分分配 一、设想和目标 1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？ 我们的软件要解决的问题是用户能够正常使用四则运算app，app可以出题，判断对错，显示结果，录入错题库的问题，同时在beta阶段加入注册登陆功能，设置简单版和复杂版。定义得也比较清楚，包括 出题，判断对错，显示结果，录入错题库 。 用户主要针对学生，老师，家长，场景主要是练习四则运算，做题。 2.是否有充足的时间来做计划? 时间上面还是不够充分，因为后期碰到了一些问题，一切都没有想象的那么顺利。 3.团队在计划阶段是如何解决同事们对于计划的不同意见的？ 小组通过微信，qq和电话等通讯工具一起协商讨论来解决意见冲突。 4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么? 用户量并没有达到预期，但是就有使用过的用户来说，功能（重要）是符合他们的要求的。离我们最初的梦想还是有一些距离的。 5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进? Beta阶段我们由于模拟器和设备等问题，等于把所有的内容全部重做了一遍。这样时间就会显得很不充分。如果可以重来我们会制定更细的任务清单

一 . 角色划分： PM : 顾育豪 Dev : 刘强、王洛书、陈睿翊、黄明源 Test :张梦达 二 . 关于评分，团队成员的各抒己见 刘强： 我思考的评分原则是： 1、不单纯根据代码量衡量组员分数，同时考虑到项目设计，博客管理，团队协调，代码测试等环节。 2、以组员所做实际贡献为基准评分 3、实际开发时间与开发难度综合考虑，效率兼顾 4、队员的团队能力（组员互评） 分数权重：PM:31%,Dev:37%,Test:32% 个人分数计算：基准分10分+贡献分。贡献分计算方式：60×（PM / DEV / Test权重）×（角色中贡献比例，百分制计算，小组讨论决定） 王洛书： 我认为一个好的团队分数分配制度要能调动所有同学参与团队项目的积极性。 因为是团队作战，同学们的编程能力不可能是一样的，如果完全按照编程贡献度给分，则会让一些同学在刚开始时就没有参与团队项目的热情。 我觉得在一开始的时候，组里应该根据个人意愿及团队需要进行明确的团队分工，并做到让每个人都认同和满意自己在团队中的角色定位和分工。（分工时要注意保证每个同学的分工中都有一定编程的任务量，锻炼编程能力；对写博客等任务的考虑也应放在细节分工的讨论范畴之内）。 每个人都有各自的特点，每个人的角色都有一定的不可替代性。在合理分工之后，理应认为大家的理论工作量是相等的。 我认为合理的给分方案是： 个人实际得分=个人总分/