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

目录

调研&评测

评测

上手体验

一打开网页的上手体验就是,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来实现。
    他们之间的关系可以用下面的两张图来表示:

    参考链接敏捷估算/计划中几个概念间的关系

posted @ 2017-12-02 18:55  tyfu  阅读(2097)  评论(2编辑  收藏  举报