首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >使用不完全分析、延迟后端和无API启动前端开发

使用不完全分析、延迟后端和无API启动前端开发
EN

Software Engineering用户
提问于 2019-02-06 20:39:56
回答 1查看 150关注 0票数 -1

首先给出一些背景信息,我的任务是指导实习生为特定的业务需求创建UI:

  • 已经有4个月用于分析、创建业务用例和一些上下文图,以及BPMN图,但分析尚未完成。
  • 预计API将已经定义,并将提供更多的细节。但由于意外情况,情况并非如此。
  • 后端本身也不可用。

实习生下周开始。但是,直到今天,我才了解到这一分析,似乎有些东西仍然太模糊或不完整。有人建议,已经开始与实习生的UI。可能是先做了几个模型。并通过与分析人员、业务人员、关键用户和操作人员交谈来进行我们自己的分析。

从这一点上,我们可能可以创建某种原型。甚至可能定义一个API的外观建议。但我们错过了一些拼图,所以我担心这会在我们的脸上爆炸……

我怎样才能确保这对实习生、他的论文和公司都有好处?我们怎样才能防止随后的大规模返工呢?我们有大约50天的时间花在这上面。你的建议是什么?你会怎么处理这个问题?这种工作方式有什么问题?

EN

回答 1

Software Engineering用户

回答已采纳

发布于 2019-02-07 07:52:53

形势的

分析

首先,我衷心祝贺您认真对待您的指导,并预先思考如何充分利用这种困难的情况!这就是现实生活:实习承诺是基于假设做出的,计划不像预期的那样起作用,而这些计划的延迟会给其他人带来延迟。

这里有一些非常积极的因素:

  • 首先,实习生将在前端UI上工作,这至少在一定程度上与后端分离,并且还需要执行som UX设计工作。
  • 然后,您似乎可以直接访问业务分析师、关键用户和操作员。这就是你的实习生需要了解的用户,他们的需求和他们的期望,并从一个坚实的基础为UX设计。事实上,IMHO是一个更好的开端,它是直接基于某些分析开发的一个更好的开端(在这种分析中,用户的生命常常会丢失一些)。

还有一个非常糟糕的因素。在您的背景下,我看到了一个非常面向瀑布的项目生命周期:首先制定计划,然后编写完整的分析,然后每个人都开始根据分析编写代码,最后每个人都希望它能一起工作并进行广泛的测试。然后用户看到产品并注意到他或她的需求被误解了。

因此,这次实习是一个机会,可以以不同的方式对待事物,并为一种更动态、更灵活的方法提供一个概念证明,从这个UI开始。

Recomendations

首先,向实习生介绍你的公司。让他非正式地会见你提到的不同的利益相关者,给他或她一些时间来阅读和理解现有的分析。然后与分析师进行第一次交易

  • 第一副产品:实习生得到了一般的上下文,但是分析师也从一个天真的无关读者那里得到了关于歧义的第一个反馈。

下一步,让实习生做一些线框(纸,或适当的工具),在那里,他或她可以设计用户的旅程,而不是太多的细节。让他(她)向商业专家和关键用户直面这些最初的想法。在第一次向分析师汇报用户的反应之后。

  • 第二个方面--产品:连接到用户社区,并从用户的角度对需求进行集体思考。

然后实习生可以从一些原型开始,用虚拟函数来模拟与后端的交互(但是有预定义的答案)。让我们做一些研讨会,向用户展示并获得更多反馈,并可能开始制定更多关于交互的细节(字段的位置、下拉列表、按钮、错误消息,.)。

  • 第三个结果:一个原型,其中后端函数看起来像一个潜在的API。但这是一种可以提炼的活产品,而不是一种被丢弃的原型。

然后是时候回到分析师那里,开始讨论API的细节,并在提议的API和预期的后端函数之间进行映射(这可以聚合几个API交互)。

  • 最重要的产品:您现在已经启动了一个迭代精化过程,在这个过程中,API设计和后端开发在精神上与前端连接在一起,每个人都会被激励去取得进展,向用户展示进步。

提示:预见到关键用户的定期演示,并邀请分析师。这将为您的新的自下而上的敏捷过程设定步调。

票数 3
EN
页面原文内容由Software Engineering提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://softwareengineering.stackexchange.com/questions/386782

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档