目录
调研&评测
评测
上手体验
一打开网页的上手体验就是，UI挺不错的，我很喜欢这个风格。但是使用起来好像有点复杂，功能非常多，不仅有项目管理，还有仓库，测试，部署，发布等等一系列的功能。我同时体验了web和Android两个端。
功能评测
前一天在web端注册了账号，但是在Android端登录就遇到问题了。注册时虽然注册了用户名+手机号，但是我习惯用手机号登录，结果发现，使用手机号+密码无法登录成功，只能使用用户名+密码登录。
接下来登录成功后，看到默认头像想要修改，却发现不能点击-.-。
感觉Android端就是一个todollist。尝试建了几个项目。并且建立了几个task。
上面的第二张，你会发现，三个项目的内容混杂在一起了，缺少分类，会导致实际使用起来有点乱。即时有搜索，搜索功能也不完善。
Scrum项目中分为了Feature/Story/Task/Bug，但是新建却没有Task这个选项。
Android端的使用就到这里了。
接下来是web端。
web端
界面挺好看的，我很喜欢。
还是和安卓端一样的问题，
两个项目的backlog混在在一起了，表示很难受。虽然点击进入项目可以看到完整的任务分配，但是这块还是需要改进我觉得。
点击项目进入后，有许多的功能。一开始的看板，就有燃尽图，story的项目统计，不错。
一开始没有懂Feature/Story/Backlog这些的意思，建了一个项目规划
使用起来非常方便，还可以添加文档等。
还可以使用仓库，我尝试创建并且clone/push。
最后是将Android版本拿到web端进行兼容性测试，结果是
两个都发生了阻塞，并没有成功测试。没有明白为什么。
bug
在上面的功能评测已经有提及，最大的bug就是多个项目的backlog会混杂在一起，而不能有个归类。
还有一个比较难受的是，网页刷新特别慢，经常出现白屏的状况，有点难受。
你觉得为什么这个产品组的人没有发现这些bug?
表示不懂，讲道理有些bug产品组不可能发现不了的。。。
假设你们团队需要开发这套系统，需要注意哪些方面(架构、部署运维、微服务等)。
首先第一个是功能，需要满足用户用户的可能需求和潜在需求，这点华为云已经做到了，并且做的非常好。其次，考虑到用户量，在架构，部署运维方面也需要注意，当然，还有UI也非常重要。
采访
-
介绍采访对象的背景和需求（他们有没有用过这个APP或类似的APP，除了现有的功能还有别的需求么）
采访对象：15级计算机系正在进行软工实践同学
背景以及需求：以前有使用过github和teambition，以前在测试项目和服务器时选择了多个平台，希望可以方便一点。采访对象使用的是Android端。 -
让采访对象使用华为软件开发云（请上传照片证明用户的确正在使用，远程采访的同学请让别人帮忙照相）
-
描述用户使用这个产品的过程, 用户的问题解决了么？软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？
用户反馈一般，基本需求可以解决。
数据量：看板加上代码规范等数据量还是比较大的
界面：比较一般
功能：较为全面
准确度：还行
用户体验：加载速度较慢，ui不够吸引人（Android端） -
用户对产品有什么改进意见？
提升性能，美化app的ui界面
建议支持markdown -
结论
一般
分析
使用此软件的大部分功能，估计这个项目做到这个程度大约需要多少时间（团队人数6人左右，计算机大学毕业生，并有专业UI 支持）。 分析这个软件目前的优劣（和类似软件相比），并推理出团队在软件工程方面可以提高的一个重要部分（具体建议）。
估计时间
构建之法中给出的实际时间花费主要取决于两个因素—对某件事的估计时间X，以及他做过类似开发工作的次数N。
没有过这麽大项目开发经验的我来估计项目时间，感觉非常难。（计算机大学毕业生？估计都没有很大的项目开发经验？）估计时间：6个月吧。。考虑到里面有非常多的功能，而且我对这些功能的具体实现没有很好的概念。就只能凭感觉估计了。如果有些功能我知道应该怎么实现，应该会比较好估计。
优势
- 整合了极多的功能，非常方便用户在上面完成整个软件工程的开发。
劣势
- 也是由于整合极多的功能，导致整个软件在与同功能的软件相比，不够专精，有些功能就做不到和其他软件专门做一项功能来的突出。
团队在软件工程方面可以提高的一个重要部分
- 编码能力
- 团队协作能力
- 产品运维
- 测试能力
根据理解和体验，画出整个软件所有功能逻辑框图，根据重要度标识出各模块的重要度、完成度、出发点及效果；
针对不同的维度评分，对用户体验方面、UI界面美观度、核心功能，分别打分。
满分10分。
| 用户体验 | UI界面美观度 | 核心功能 |
|---|---|---|
| 8.0 | 9.0 | 8.5 |
建议和规划
-
如果你是项目经理，如何提高从而在竞争中胜出？
整个产品提供服务功能非常丰富，应该考虑把每个功能做的更好一些，并且再继续丰富功能。 -
目前市场上有什么样的产品了？
团队合作上面有teambition，leangoo，代码托管有github，码云。 -
你要设计什么样的功能？
增加文档功能（虽然目前已经可以写部分文档，但是可以是软件开发中的各种文档，包括需求说明书，接口文档，功能文档），并且可以自动生成文档。
测试部分增加接口测试功能。
提供给用户可选使用菜单，实现页面由用户定制化。 -
为何要做这个功能，而不是其他功能？
文档功能是对产品进一步完善，而提供可选菜单不会使用户觉得功能太多太复杂，只选择自己想要使用的功能，其他功能隐藏，并且可以随时添加使用功能。 -
为什么用户会用你的产品/功能？
使用自定义的app，会让极简主义的用户青睐，并且又能随时拓展。
对于想要在app上进行一体开发的用户，这个产品也完全能够提供。 -
你的创新在哪里？
将功能选择交由用户来使用，而我们提供一个丰富的服务功能。相比较其他产品，我们提供的功能多并且可选，极大方便用户。 -
如果你来领导这个团队，会有什么不一样？
把主要精力开发于web端和桌面端，实际上iOS/Android在软件工程开发中并不方便。 -
如果你的团队有5个人, 4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？
美工1人，开发4人。测试人员为5人（整个团队）。 -
描述你的团队在16 周期间每周都要做什么，才能在第16周如期发布软件，大小里程碑绩点设定。
-
|周数|任务|
|--|---|
|1|需求规格说明书|
|2|原型设计，数据库设计，架构设计|
|3-13|开发|
|14|测试&用户反馈|
|15-16|修改bug,根据反馈对app进行修改,最后发布| -
项目发布后，有没有考虑过项目该怎么部署才能满足需求。
由于项目提供功能性非常多，并且用户分布广泛，相比较教务处系统，数据库配置应该更强。教务处系统考虑到选课时的压力，估计不会超过10000+的并发，因此可以考虑分地区分布架构。
应用服务器配置:4核8G * 2
后端服务器配置:8核16G * 3
数据库服务器: SQL Server/ Oracle/MySqI 数量:3(读写分离2、备份1)
缓存数据库:Redis数量:3(主备)
网站安全性:WAF. DDOS . XSS,同时还需要考虑代码托管的安全性。
如果不够了，再考虑增加设备。
名词解释
在使用华为云时，有些Scrum名词的概念没有很清晰，下面做个记录。
-
Theme
Theme则是一组User Story(甚至是Epic Story)，这些User Story拥有共同的特征，为了更容易开发这些相关内容，通常会将这些User Story作为一组进行开发和管理。这组User Story就被称为Theme -
Epic Story
Epic Story的规模和复杂性，要大于User Story，它首先是一个大User Story。由于它非常大，无法或不容易进行估算，因此一般会分解成为更小的User Story，进行估算和开发。关于Epic和Feature，谁的复杂性更高，谁的规模更大，则还没有一个统一的说法，有的项目中，会定义Epic Story在Feature之下;而有的项目中则相反。因此在使用这个概念时，应该在项目中有一个明确的定义。无论Epic Story是在Feature之上还是之下，它与Feature同样是在Release Plan的层级，一般是通过一个或多个迭代才能完成。 -
Feature
Feature是可以为用户提供价值的东西，它代表一个产品可以做什么，或提供什么服务;是可以满足用户的需求，为客户服务，为用户带来真正的价值的成果物的特性。由一组动宾结构的句子表达，如一个超市的交易可以描述为： 扫描条形码， 显示单价， 计算总价， 计算税额。一个Feature是很难进行估算的，它需要被分解成一个个更小的单位，这就是下面的User Story，一个Feature可以分解成多个User Story，每个User Story不能单独被使用，而是一起构成一个Feature。 -
User Story
必须是清晰的，可以为客户增加价值，而且更重要的是能够被估算。因此User Story通常是进行估算的基本单位，通常使用Story Point来进行估算。User Story是在迭代的层级，一个User Story要在一个迭代内完成。 -
Task
项目中可以执行的工作单位，通常就是迭代计划中项目(如Sprint Backlog中的项目)。一个User Story一般会分解为一个或多个Task，通过这些Task来实现。
他们之间的关系可以用下面的两张图来表示：
参考链接敏捷估算/计划中几个概念间的关系