个人作业——华为软件开发云案例分析

目录

• 调研&评测
• 分析
• 建议和规划
• 名词解释

调研&评测

评测

上手体验

一打开网页的上手体验就是，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也非常重要（表示很喜欢华为云web端的UI。）

采访：

分析

使用此软件的大部分功能，估计这个项目做到这个程度大约需要多少时间（团队人数6人左右，计算机大学毕业生，并有专业UI 支持）。 分析这个软件目前的优劣（和类似软件相比），并推理出团队在软件工程方面可以提高的一个重要部分（具体建议）。

构建之法中给出的实际时间花费主要取决于两个因素—对某件事的估计时间X，以及他做过类似开发工作的次数N。

没有过这麽大项目开发经验的我来估计项目时间，感觉非常难。（计算机大学毕业生？估计都没有很大的项目开发经验？）估计时间：6个月吧。。考虑到里面有非常多的功能，而且我对这些功能的具体实现没有很好的概念。就只能凭感觉估计了。如果有些功能我知道应该怎么实现，应该会比较好估计。

• 根据理解和体验，画出整个软件所有功能逻辑框图，根据重要度标识出各模块的重要度、完成度、出发点及效果；
  

• 针对不同的维度评分，对用户体验方面、UI界面美观度、核心功能，分别打分。
  满分10分。

建议和规划

• 如果你是项目经理，如何提高从而在竞争中胜出？
• 目前市场上有什么样的产品了？
• 你要设计什么样的功能？
• 为何要做这个功能，而不是其他功能？
• 为什么用户会用你的产品/功能？
• 你的创新在哪里？可以用 NABCD 分析。
• 如果你来领导这个团队，会有什么不一样？
• 如果你的团队有5个人, 4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？
• 描述你的团队在16 周期间每周都要做什么，才能在第16周如期发布软件，大小里程碑绩点设定。
• 项目发布后，有没有考虑过项目该怎么部署才能满足需求。依据下图（某校教务处系统的部署）作为参考，分析16周后你所完成的项目上线需要哪些配套设备(服务器、带宽、数据库需求数量与配置) 。

名词解释

在使用华为云时，有些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来实现。
  他们之间的关系可以用下面的两张图来表示：
  
  参考链接敏捷估算/计划中几个概念间的关系