De um modo geral, é melhor fazer todas as partes funcionais ou obter a interface do usuário funcionando primeiro - ou uma mistura das duas?

46

Em geral, é melhor criar todas as partes funcionais ou fazer com que a interface do usuário funcione primeiro - ou uma mistura das duas?

Supondo que você esteja trabalhando em algo grande, é prática geralmente aceita fazer com que todos os blobs de coleta de dados funcionais funcionem antes de qualquer interface do usuário, fazer com que toda a interface trabalhe uma peça de cada vez ou algo no meio?

Todos nós sabemos como dividir o trabalho em partes gerenciáveis, mas a questão é, em última análise, se a UI está incluída em partes gerenciáveis, suponho.

Para o caso do exemplo, considere um aplicativo GUI com uma janela raiz, mas com mais de uma dúzia de guias em vários docks para separar diferentes componentes de dados. Cada guia individual possui um conjunto relativamente complexo de partes móveis por trás de uma perspectiva de unidades funcionais.

A aplicação de exemplo nesta questão em particular é aqui com o software de acompanhamento blog e o produto comercial original .

    
por RobotHumans 27.07.2014 / 15:13
fonte

9 respostas

84

Existe uma concepção geral entre muitos usuários de negócios e clientes que, quando parece completa, está quase concluída. Como você provavelmente sabe, isso está longe de ser verdade. Pode-se ter uma boa aparência, mas sem backend e alguns usuários acham que fazê-la parecer legal é 80% do trabalho, e não 20% ( ou os outros 80% ).

Inúmeros desenvolvedores podem contar histórias de terror sobre isso - fazer uma maquete das páginas feitas no Microsoft Word usando capturas de tela de alguma outra ferramenta, e o cliente dizendo "então, você quase fez isso?"

Você precisa estimulá-lo para que todas as partes sejam concluídas quando isso for feito. Tentar fazer todo o backend primeiro e depois todo o front end levará o usuário final a pensar que você não está fazendo nada e perguntando por que você está sendo pago quando não há nada para mostrar. Por outro lado, o front end primeiro e você encontrará o usuário final fazendo alterações e consumindo todo o nosso tempo.

O pior caso com um 'primeiro e o outro' é quando você chega à outra parte, descobre que ele não se encaixa no design.

Assim, construa os dois. Mostre o progresso no front end, faça o back-end funcionar com o que você está construindo. Em muitos casos, é uma boa ideia fornecer versões incrementais e certificar-se de que você está fazendo o que o cliente deseja (isso se torna Agile). Indo muito longe com 'avanços visíveis' pode prejudicar o relacionamento com o cliente (isso é para ambos casos de 'tudo parece feito cedo' e 'nada é feito até o final' - é difícil para o cliente para ver o framework sendo escrito ou os testes de unidade ou sanitização de dados como progresso).

Joel escreveu sobre isso em O Segredo do Iceberg, Revelado :

Important Corollary Two. If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.

People who aren't programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think "oh, gosh, how much harder could it be to make it actually work?"

The big risk here is that if you mock up the UI first, presumably so you can get some conversations going with the customer, then everybody's going to think you're almost done. And then when you spend the next year working "under the covers," so to speak, nobody will really see what you're doing and they'll think it's nothing.

Isso é novamente reiterado na postagem do blog Não faça a demonstração tem este gráfico útil:

Noteaquiqueasduasopçõesgeralmenterefletemo'gettheuidone'(eentãoaexpectativaéquevocêseráfeitoembreve)e'façaobackendpronto'(eentãooclienteestápreocupadocomafaltadoprazo)).

How'done'somethinglooksshouldmatchhow'done'somethingis.

Everysoftwaredeveloperhasexperiencedthismanytimesintheircareer.Butdesktoppublishingtoolsleadtothesameheadachefortechwriters--ifyoushowsomeonearoughdraftthat'sperfectlyfontedandformatted,theyseeitasmoredonethanyou'dlike.Weneedamatchbetweenwhereweareandwhereothersperceiveweare.

Esteartigotambémtrazumpontoimportantesobreotipodefeedbackquevocêobtémcomdiferentesníveisdeconveniênciadainterfacedousuário.Sevocêtemalgoqueparececompleto,émaisprovávelquevocêrecebacomentáriossobre"você pode alterar a fonte" do que "esse layout não funciona - há muitas guias".

Para aqueles que estão brigando com isso no mundo do Java Swing, há uma aparência chamado Guardanapo que faz com que a interface do usuário não pareça completa (mesmo que seja).

Achaveaquiéfazercomqueelanãosejafeita.TeraUIparececompletaéumsinalparamuitosusuáriosdenegóciosqueoaplicativoestácompleto(mesmoquesejamapenasalgumaspáginasestáticassemqualquerlógicaportrásdeleoualgoconstruídoemumconstrutordeinterface).

Outrasleituras(elinksdoartigo):

por 27.07.2014 / 15:43
fonte
27

Depende: Você precisa de um feedback apertado em torno de sua parte mais importante da funcionalidade

Se o núcleo do que você faz, a parte arriscada e assustadora, é algum mecanismo interno, então faça a parte central funcionar no console ou através do teste de unidade. Por exemplo, um analisador de protocolo não precisa de uma interface do usuário para saber se está funcionando corretamente.

Se a sua coisa legal envolve alguma interatividade - interatividade, você precisa estar constantemente solucionando problemas, jogando fora e redescobrindo -, então uma abordagem de UI-first é crucial. Por exemplo, quero criar um aplicativo para permitir que as pessoas interajam com uma visualização de dados. A coisa mais importante que preciso descobrir é se a visualização é significativa, então provavelmente descartarei meia dúzia de abordagens antes de me decidir por uma. Eu farei tudo isso antes de escrever um único teste unitário.

Há uma área cinzenta entre a qual você decide a melhor combinação para melhor interagir e validar seu código (testes automatizados? UI para experimentação?). Eu pessoalmente fiz os dois extremos e tudo mais, e decidir o lugar certo para estar nesse espectro é uma das coisas mais difíceis que eu tenho que decidir e é 100% dependente do tipo de coisa que estou construindo.

    
por 27.07.2014 / 15:42
fonte
7

Em um ambiente Ágil, você pode ouvir discussões sobre "esqueletos ambulantes" ou "fatias verticais finas". A ideia é que, uma vez que o software de trabalho é o que é importante para o usuário, você constrói o software em uma peça de moda trabalhando por peça.

No aplicativo de exemplo mencionado, você iniciaria com a janela e talvez com uma guia e faria tudo funcionar de frente para trás de alguma forma. Então, ao longo do tempo, você adicionaria funcionalidade e, portanto, guias de acordo com cada caso, fazendo com que cada recurso funcionasse conforme você o construía. Isso faz parte do que as frequentes demonstrações de clientes oferecem: uma chance de mostrar algo novo e obter feedback instantaneamente.

Em resumo, sim, o trabalho da interface do usuário é absolutamente parte integrante de uma unidade de trabalho funcional, se você tiver uma interface do usuário.

Comece com algo pequeno que funcione e repita a funcionalidade para entregar um software completo.

    
por 27.07.2014 / 21:53
fonte
3

Eu recomendaria fazer uma mistura de funcionalidade e interface do usuário (e obter feedback ou testar a experiência o mais rápido possível).

BTW, não é da maneira que a maioria dos softwares GUI é desenvolvida? Procure por exemplo no navegador Firefox : de uma versão para outra, a funcionalidade e a interface do usuário evoluíram.

    
por 27.07.2014 / 15:42
fonte
2

Em grandes aplicações (baseadas na web em PHP) em que trabalho, tento colocar as classes e métodos em primeiro lugar, que retornam valores fictícios . Isso é para estabelecer um pseudo-contrato que os outros desenvolvedores possam usar para implementar a interface do usuário.

Uma vantagem secundária desse método é que podemos aprimorar o contrato / interface conforme os requisitos da interface do usuário mudam (e eles sempre mudam), mesmo antes de todo o código ser gravado e entregue.

    
por 27.07.2014 / 19:50
fonte
1

O que eu costumo fazer é começar com uma IU de baixa qualidade : algo que simplesmente despeja os dados variáveis na tela. Sem fontes, sem alinhamento, nada realmente gráfico por um longo tempo. Apenas "Bem-vindo usuário x" e botões chamados "carregar pic" etc. O que é bom sobre isso é que você vai descobrir se algo no back-end está quebrado.

À medida que o desenvolvimento avança, você pode descobrir mais coisas que precisam continuar, ou menos. Mas em algum momento, você decidirá que o backend está próximo da conclusão. Agora você tem uma interface do usuário que contém todos os anexos necessários e pode gastar muito tempo fazendo todo o material gráfico.

Cuidado, porém, não é infalível. Você precisa de um pouco de previsão para ver certos problemas decorrentes. Por exemplo, você pode precisar pesquisar componentes da interface do usuário para exibir os dados de uma maneira sensata.

    
por 28.07.2014 / 12:30
fonte
0

Se você usa um bom marco e um sistema de acompanhamento de problemas, é possível evitar alguns desses problemas, pois, de relance, o gerenciamento pode ver o quanto você está sendo produtivo. Eles poderão ver que você está 80% concluído no back-end e que a interface do usuário é o próximo marco; eles poderão ver que você tem um conjunto de tarefas de interface do usuário e de back-end para concluir um marco de recurso específico. Mas tudo começa com os requisitos do projeto, e a resposta de Doug T levanta alguns pontos positivos sobre esse aspecto de projetar um sistema.

    
por 28.07.2014 / 10:19
fonte
0

Pense no ponto de vista de seus usuários / clientes. Um sistema de software é uma coleção de recursos que dá valor a esses usuários / clientes. É claro que cada um desses recursos tem e interface do usuário, um backend e algumas outras coisas.

Construa seu sistema sempre recurso por recurso e tente dividir em recursos muito pequenos. Desta forma, você está sempre perto de ter algo mais para entregar aos seus clientes, lembre-se que o desenvolvimento de software não é sobre construir a versão 1.0 é sobre ir para a versão 1.0.1 para o 1.0.2 e assim por diante ...

    
por 28.07.2014 / 18:33
fonte
0

Depende. Quão bem definidos são os seus requisitos? Quanto do sistema está voltado para a interface do usuário?

Da minha experiência, a maioria dos clientes não sabe o que eles querem até ver algo na frente deles. Por isso, normalmente forneço algumas estruturas de fios dos principais aspectos da interface do usuário ou forneço a maioria da interface do usuário (sem funcionar). Isso permite que o cliente mude de ideia sobre os recursos / funções sem muito impacto, pois o design do banco de dados e a estrutura do código ainda estão apenas na fase de projeto - é fácil alterar o design. São ordens de grandezas mais fáceis / mais rápidas para alterar o design no início do projeto, mais tarde.

O Agile afirma que você também deve trabalhar nos itens mais difíceis e nos itens mais importantes primeiro. Falha rápida . Assim, uma vez que o cliente tenha visto a IU, eu me concentro na criação de componentes pequenos que sejam totalmente funcionais, falando sobre o mais importante e mais difícil de implementar primeiro, para que você saiba o mais rápido possível se tiver problemas.

Depois, você tem seus sprints e tem uma comunicação constante com o cliente, desenvolvendo tanto a interface do usuário quanto os aspectos funcionais em algum momento.

    
por 29.07.2014 / 06:10
fonte