Playbook da Divisio

Este é nosso passo-a-passo para o design, execução, e manutenção de soluções excepcionais de software customizados.

  • Fase 1

    Design

  • Fase 2

    Executar

  • Fase 3

    Manter

FASE 1

Design

  • Step 1
    Descoberta de Design
  • Step 2
    Descoberta Técnica
  • Step 3
    Design de Experiência Do Usuário
  • Step 4
    Design da Interface do Usuário
  • Step 5
    Prototipagem e Estimativas
DELIVERABLES

Design

Antes de podermos programar uma aplicação nova, ou adicionar funcionalidades para uma aplicação existente, precisamos fazer a etapa de design e prototipagem do que vai ser construído.

Esta seção descreve nosso processo de design e prototipagem, para que você saiba o que esperar.

PASSO 1

Descoberta de Design

A descoberta é um processo para estabelecer o escopo e objetivos do seu projeto, garantindo que todos estão na mesma página.

image

Reunião Inicial

O primeiro passo é uma reunião com nosso time de design e sua equipe. É natural que cada projeto comece num estágio diferente do processo, então, fazemos essa reunião para entender o que já foi feito no seu projeto e planejar um roteiro para desenhar as funcionalidades requeridas para sua aplicação.

Análise Competitiva

A seguir, vamos realizar uma análise competitiva para avaliar aplicações similares que foram construídas por competitores e determinar no que essas aplicações acertaram e no que erraram. Ao fazer isso nosso time consegue identificar oportunidade para você se destacar.

Personas de Usuários

Como uma etapa final, iremos definir e criar personas de usuários para ganhar entendimento dos diferentes tipos de usuários em potencial da aplicação. Iremos definir o que os motiva, quais são os objetivos que eles desejam alcançar quando estiverem usando o app. Este é uma etapa crucial para determinar a melhor experiência de usuário.

PASSO 2

Descoberta Técnica

Bem no início já realizamos um esforço para descoberta técnica seja para entender e documentar as tencologias de um projeto existente, ou para pesquisar e recomendar a melhor stack (conjunto de tecnologias) para seu projeto.

Esta etapa pode incluir a condução de uma revisão de código detalhada na sua aplicação existente, pesquisa de tecnologias para casos de uso específicos, revisão de documentação para integrações de terceiros e desenvolvimento de publicação e planejamento de operação de desenvolvimento.
PASSO 3

Experiência do Usuário

Nosso processo de Design UX garante que estamos resolvendo as necessidades do usuário de forma eficiente. Isso significa construir aplicações que são fáceis de entender.

Mapa de Funcionalidades

Para começar, criamos uma visão de alto nível das funcionalidades da sua aplicação (Mapa de Funcionalidades). Este é o ponto inicial para um um exame minucioso de como as telas vão interagir uma com as outras. Este documento é atualizado durante toda a vida do projeto.

Mapa de Features

Fluxo do Usuário

A seguir, construiremos os passos que o usuário vai percorrer parar atingir objetivos específicos no app (Fluxo do Usuário). Isso se torna especialmente importante quando lidamos com condicionais complexas em fluxos de interação. Ser capaz de visualizar o fluxo permite que clientes, designers e programadores compartilhem uma compreensão mútua de como as features vão funcionar e qual será o resultado final.

Fluxo do Usuário

Wireframes

Por fim, criaremos um conjunto de wireframes das telas principais da aplicação. Criar os wireframes permite que criemos o layout geral das telas sem ter que decidir imediatamente o conteúdo exato e imagens que serã usadas no design final. É muito para:

  • Prototipagem Rápida
  • Compreensão das Funcionalidades
  • Demonstração do Fluxo do Usuário
  • Garantia de uma Fundação Sólida
PASSO 4

Interface do Usuário

Uma vez que a Descoberta e Design UX estão completas, vamos então para o design visual, selecionando um conceito visual, então transformando este conceito num guia de estilo (Style Guide), e finalmente, vamos criar vários mockups de alta fidelidade de cada tela da sua aplicação.

Conceitos de Estilo

Conceitos de Estilo demonstram as diferentes opções para aparência e sensação da sua aplicação, inclusive de cores, fontes, etc. Avaliamos seus os produtos de seus competidores e determinamos como vamos diferenciar seu produto do deles, por fim, vamos criar duas ou três opções de conceitos de estilo para você escolher.

Guia de Estilo (Style Guide)

Nós utilizamos o conceito de estilo escolhido para criar um documento com as padronizações de cores, fontes, botões, cabeçalhos, estilos, tipografias e outros elementos que serão utilizados na aplicação inteira (Style Guide). Esta etapa garante um visual unificado, coerente em cada seção da sua aplicação, e também serve de referência para designers e programadores durante a execução do projeto.

Mockups de Alta Fidelidade

Estes mockups servem de representação visual perfeita (pixel por pixel) de como seu app vai ser. Este design incorpora a estrutura feitas nos Wireframes com os detalhes visuais estalecidos no Guia de Estilo. Os mockups também inclui materiais visuais como fonts, ilustrações e ícones.

Mockups de Alta Fidelidade
PASSO 5

Prototipagem e Estimativas

Uma vez que os mockups de alta fidelidade estão finalizados, nós subimos os arquivos para o Figma e criamos protótipos interativos, os quais utilizamos, por fim, para fazer uma proposta de desenvolvimento.

Protótipos Interativos de Alta Fidelidade

Protótipos interativso permitem que nosso time e o seu interaja com os protótipos e entenda como o app vai funcionar. Todos podem testar a aplicação antes mesmo dela ser desenvolvida, descobrir situações atípicas e melhorias que passariam desapercebidas, se não fosse por este processo. Pode ser uma grande ferramenta para conseguir aprovação orçamentária de desenvolvimento da aplicação, ou para pitch de investidores.

Estimativa de Desenvolvimento

Cada um dos passos feitos anteriormente no nosso processo de design faz com que todos se envolvam no projeto e permite que todos entendam completamente o que vai ser construído. Isso permite que criemos uma estimativa detalhada da estimativa de horas que serão necessárias para desenvolver o app, e o custo associado. Não é possível estimar com precisão o custo para desenvolver um projeto sem antes realizar a etapa de Design, e esta é a razão pela qual o processo de design é uma etapa indispensável.

Proposta de Desenvolvimento

A proposta de desenvolvimento descreve e custo proposto para desenvolver, o time de desenvolvimento e as estimativas.

PASSO 5

Entregáveis da Fase de Design

Estes são todos os materiais que você vai receber após concluir a Fase de Design - um extenso conjuto de entregáveis para encaminhar seu projeto para o sucesso.

  • Análise Competitiva
    upload_arrow
  • Mockups de Alta Fidadelide
    upload_arrow
  • Personas de Usuários
    upload_arrow
  • Protótipo Mobile
    upload_arrow
  • Mapa de Funcionalidades/Usuários
    upload_arrow
  • Protótipo Desktop
    upload_arrow
  • Wireframes
    upload_arrow
  • Estimativa de Execução
    upload_arrow
  • Conceito de Estilos
    upload_arrow
  • Proposta de Execução
    upload_arrow
FASE 2

Executar

  • Step 1
    Planejamento Pré-Desenvolvimento
  • Step 2
    Desenvolvimento Ativo
  • Step 3
    Lançamento

Execução

Este é o nossa forma metódica e científica de construir apps multi-plataforma, incluindo iOS, Android, e apps para web.

Esta seção descreve como nossa etapa de design está conectada com a fase de desenvolvimento e seus detalhes.

PASSO 1

Planejamento Pré-Desenvolvimento

Para garantir um processo de desenvolvimento efetivo e eficiente, começamos fazendo um planejamento de pré-desenvolvimento, definimos o time, o time de design entrega os materiais e conceitos para o time de desenvolvimento, estabelecemos as metas do projeto, criamos as estórias e planejamos as sprints.

Definição do Time

Cada projeto normalmente contém 5 profissionais: dois programadores senior, um gerente de projetos, um designer e um PO (product owner).

Entrega do Design para o Dev

Uma vez que o time está estabelecido, eles se encontram com o time original de design para uma reunião de entrega completa dos materiais e conceitos. Uma entrega detalhada garante que os programadores entendem completamente a aplicação e o que eles precisam construir.

Antes de começar o desenvolvimento, o time de desenvolvimento vai revisar todos os materiais criados na fase de Design, inclusive as pesquisas de mercado, personas de usuário, mapa de funcionalidades e usuários, guia de estilo, designs de alta fidelidade e os protótipos interativos.

O time de design também provê todas as imagens e ícones necessários nos formatos adequados, documentam qualquer interação ou fluxos que não podem ser demonstrados apropriadamente nos protótipos.

Essa entraga sistemática garante que os programadores tem tudo que precisam para iniciar rapidamente e eficientemente, sem nenhum bloqueio.

Metas (Milestones)

O gerente de projeto estabelece as metas (milestones) chaves para o projeto (ou publicação de versões). Ao invés de ter apena um prazo no final do projeto, nós temos diversas metas durante o projeto, sendo que cada meta inclui uma versão limitada do app, com um número limitado de funcionalidades funcionais para que você possa testar.

O objetivo é ter um conjunto de features operando diante do cliente o mais cedo possível no processo do desenvolvimento, para que possamos colher feedback e garantir que as funcionalidades cumprem as expectativas do cliente.

Metas

Estorias

Uma vez que as metas são estabelecidas e aprovadas, o gerente de projeto começa a criar as estórias. Estórias funcionam como ticket, que são designadas à programadores durante as sprints. As estórias descrevem o que o programador precisa construir. As estórias são criadas de acordo com os designs e os items individuais da estimativa original. Cada estória tem um número de horas para ser trabalhado, de acordo com as estimativas.

Para cada sprint, os programadores são designados à um número de tickets de forma que suas estimativas de horas combinadas sejam iguais ao número de horas da sprint. Isto permite que o gerente de projeto mensure a efitividade e eficiência de cada programador e a velocidade do projeto em si, em cada sprint.

Estórias

Planejamento das Sprints

Uma vez que as estórias forem criadas, elas são divididas em sprints de duas semanas. Planejamos o máximo de sprints possíveis no começo do projeto, entretanto, as primeiras sprints são planejadas com maiores detalhes e maior acurácia.

Após as estórias serem adicionadas à sprint elas são designadas para cada programador, de acordo com o número de horas disponíveis na sprint e o número de horas estimadas para cada estória.

PASSO 2

Desenvolvimento Ativo

Uma vez que o planejamento de pré-desenvolvimento está completo, nós começamos o desenvolvimento ativo, que inclui finalizar sprints de duas semanas e lançar versões do produto de acordo com as metas estalecidas do planejamento do projeto.

Execução da Sprint

Programadores são designados à uma série de estória para cada sprint de duas semanas. Cada estória é estimada com uma carga horária para ser finalizada, e então é combinaao com a horas disponíveis para aquela sprint. Cada estória inclui uma descrição do que será construído, links para os arquivos e documentos necessário, como por exemplo componentes e ícones, e também os termos de aceite para que uma tarefa seja aprovada (Acceptance Criteria).

Cobertura com Testes

Quando os programadores finalizam as estórias, eles constroem testes automatizados de unidade (unit tests) e testes de integração. A cobertura com testes é importante já que ela avisa os programadores quando algo dá errado quando um novo código é introduzido. Sem a cobertura de testes, cada vez que um novo código é adicionado a aplicação inteira precisará ser testada manualmente para determinar se o código novo gerou alguma falha no código antigo. Testar manualmente consome muito tempo, além de ser custoso e ineficiente.

Alguns programadores pulam a fase de testse no início para economizar tempo e programar mais rápido, mas esta forma é mais custosa no longo prazo. Todos os nossos apps são construídos com testes de ponta-a-ponta robustos desde o primeiro dia, o que economiza tempo e recursos no longo prazo.

Unit Testing

Os testes com Unit testing são a menor parte testável de uma aplicação para se validar que cada unidade do software está performando como o esperado.

Teste de Integração

O teste de integração é um tipo de teste que combina testes de unidade individuais e os testa em grupo. O objetivo desse teste é descobrir falhas na interação entre os testes de unidade integrados.

Integração Contínua

A integração contínua é uma técnica de desenvolvimento que obriga que programadores integram o seu código em repositório de código compartilhado várias vezes por dia, para que este código possa ser verificado utilizando um processo de build (construção) automatizado e executar as ferramentas de testes.

Controle de Qualidade

Uma vez que os programadores finalizam uma estória e constroem testes de unidade e integração, a estória está pronta para ser revisada pelo nosso Controle de Qualidade (QA). Se a estória for aprovada então ela é enviada para o gerente de projetos para uma revisão final. Se a submissão falhar no QA ela é retornada para que o programador possa revisá-la. O controle de qualidade verifica vários fatores, entre eles:

  • O código enviado está de acordo com os termos de aceitação descritos na descrição da tarefa ou da estória?
  • A interface do usuário é uma reprodução fiel dos designs?
  • O código está funcionando como o esperado em diversos tipos de dispositivos e navegadores?
  • O código está responsável para celular em um vasto número fatores?

Revisão de Código e Aprovação

Uma vez que a estória é aprovada pelo QA ela é enviada para o gerente de projetos que revê o código atual para garantir um alto nível de qualidade e testes, de forma final. Se tudo estiver ok, o gerente de projetos mescla o código com a branch principal (master), e a estória está completa.

A qualidade de tudo o código que escrevemos é avaliada de acordo com nossos princípios e padrões de qualidade. Na Divisio, nós escrevemos código limpo, ou seja:

Consciso

A forma mais fácil de manter um código limpo e entendível é ser consciso. Menos código significa menos complexidade, menor chance de erros (bugs), menos código para ser mantido. Mantemos o código limpo e enxuto.

Por humanos para humanos

Você pode ler código limpo como se estivesse lendo em inglês. As pastas devem ser estruturadas de acordo com as melhores práticas para cada linguagem/framework. Nome de arquivos, classes, funções/métodos, variáveis e parâmetros devem ser nomeados explicitamente de acordoc om o contexto e intenção.

Linting

Código deve ser sempre rodado com um linter automatizado. Se o seu projeto não está configurado para rodar CI ou com git hooks, você precisa fazer isso o quanto antes.

Auto-explicativo

Comentários no código deve ser guardados para situações que você não consegue explicar a intenção e a funcioalidade de um método ou classe somente pela nomeação e código limpo. Repare que isto deve acontecer apenas em raras situações. Você sempre pode refatorar e utilizar uma nomenclatura mais trabalhada para expressar contexto suficiente e intenção adequada no código.

Cobertura de Testes

Um conjunto de testes automatizados é prioridade para mesclar o código numa branch principal (master). Devem ser configurados o quanto antes, já que o projeto deve sermpre ter testes de ponta-a-ponta, testse de integração e testes de unidade, alcançando uma cobertura de 95% para cada projeto.

Retrospectiva

No final de cada sprint o time se reune para a retrospectiva da sprint, onde é determinado e discutido se a sprint foi finalizada dentro do prazo, se as estórias estavam propriamente estimadas, se durante o percurso houve algum imprevisto, bloqueadores ou desafios, se o projeto como um todo está dentro do planejamento e no progresso esperado.

O feedback de cada retrospectiva culmina no planejamento para a próxima sprint. Nós mensuramos a entrega de sprints de tempo-a-tempo para cada programador para garantir que os programadores estão entregando no prazo com consistência. Num evento raro em que um programador falha neste processo repetidamente, o gerente de projetos trabalha de perto para identificar e traçar um plano de melhora de performance, que então medido de acordo com o plano geral.

Retrospectiva

Publicação de Versões

As sprints são finalizadas, elas se agrudam em uma Versão de Publicação a qual inclui um número limitado de funcionalidades finalizadas e que estão prontas para o Teste de Aceitação do Usuário (UAT) que é feito pelo cliente. Clientes são capazes de testar a versão de lançamento e enviar feedback para o time de desenvolvimento.

Versão de Publicação
PASSO 3

Lançamento

Uma vez que todas as versões de publicação foram completas e aprovadas pelo cliente, e o app esteja aprovado para beta-testing, há um lançamento público ou interno.

FASE 3

Manutenção

  • Step 1
    Manutenção
  • Step 2
    Desenvolvimento Contínuo

Manutenção

Uma vez que a aplicação está publicada podemos oferecer suporte via um contrato de manutenção e/ou contrato de desenvolvimento contínuo.
MANUTENÇÃO

CONTRATO DE MANUTENÇÃO

Para aplicações com um planejamento limitado de desenvolvimento, um contrato de manutenção é suficiente para que o app continue a rodar corretamente. Contratos de manutenção cobrem o seguinte:

Monitoramento de Errors e Relatório de Bugs

Utilizamos diversas ferramentas de terceiros para monitoramenteo de errors e relatoria de bugs, entre elas: Eslint, CodeClimate, Sentry e Bugsnag. Estas ferramentas nos avisam quando algo errado acontece e também nos ajudam a otimizar a performance.

Atualização de Versões

Softwares com linguagem Open-Source são constantemente atualizados pela comunidade open-source. É importante manter as versões atualizadas, para garantir performance e segurança. Todos os nossos contratos de manutenção incluem, como requisito básico, atualização de versões..

Otimização de Performance

Para aplicações que gerenciam um grande volume de dados, usuários, manutenção e otimização constante na performance pode ser necessária. Isto pode incluir monitoramento e otimização de servidores, otimizações em geral, relatoria de quebras e respostas, entre outros.

Atualização de Integrações e Dependencias

Aplicações modernas são construídas com uma variedade de dependências de terceiros e API's, mas estas dependências podem mudar com o tempo. Por isso, uma importante parte do nosso contrato de manutenção, é atualizar as aplicações e garantir que elas constinuam integradas corretamente com dependências de terceiros.

MAINTAIN & IMPROVE

Ongoing Development

For clients who wish to continue adding features and making changes over time, an ongoing development agreement will be needed, in addition to a maintenance agreement. Ongoing development agreements include the following:

Roteiro de Produto (Roadmap)

Vamos trabalhar com seu time para criar um roteiro de produto robusto que descreve quais funcionalidades vão ser construídas, e quando. Esse processo ajuda a priorizar funcionalidades, planejar orçamentos, etc.

Desenvolvimento de Novas Features

Após novas features serem adicionadas para o roteiro de produto (Roadmap), vamos realizar um processo curto de design para demonstrar como as novas funcionalidades vão funcionar com a aplicação existente.

Desenvolvimento de Novas Features

Assim que o design está concluído, vamos estimar a quantidade de tempo necessária para desenvolver a funcionalidade, e então vamos adicioná-la na próxima sprint.

Como nós trabalhamos

Estas são as ferramentas e estratégias que utilizamos para entregar
a melhor experiência.

Colaboração

Criamos um canal no Slack para que todos do seu time e do nosso participem. Você tem direto acesso a qualquer um do nosso time, inclusive programadores. Realizamos reuniões diárias para revisão do que foi finalizado no dia anterior e o que será trabalhado naquele dia, procuramos e resolver qualquer potencial bloqueador. Fazemos uma atualização semanal com o cliente.

Gerenciamento de Projeto

Criamos Épicos, Estórias e Sprints utilizando o JIRA, uma ferramenta poderosa de gerenciamento de projeto que nos ajuda a visualizar o progresso de uma forma organizada e eficiente.

Relatório de Horas

Nós medimos e reportamos nossas horas cobradas com total transparência. Nosso time inteiro registra sua carga horária no Toggl (que mede até os segundos), e você só é cobrado pelo tempo que realmente estamos trabalhando no seu projeto. Não fazemos arredondamento de horas, e você tem visibilidade total em cada registro de hora.

Reunião com Clientes

Conduzimos reuniões semanais para cada semana do projeto. O objetivo desta reunião é para que o gerente de projeto atualize o cliente do andamento semanal do projeto, revisão de progresso da sprint, horas trabalhadas em comparação com as estimativas, orçamento, prazos e objetivos.

Vamos nos falar!

Gostaríamos muito de ouvir mais sobre seu projeto. Entre em contato com a gente abaixo para uma consultoria gratuita com nosso CEO. Projetos iniciam em R$50.000.

Tipo de Projeto

O que você deseja?

Como você nos conhece?