Como uma startup toma decisões de tecnologia? – Parte 2 – Desenvolvimento de software

Descubra como a área de Desenvolvimento de software se encaixa no processo de tomada de decisões de uma startup

Trabalhar em uma startup é como estar em um carro a 100km/h que nunca pode diminuir a velocidade ou parar, mas ainda ser necessário trocar as peças em movimento para que ele continue andando. E como fazer isso e ainda aumentar sua potência?

Essa é segunda parte da série ‘Como uma startup toma decisões?” Vamos falar sobre como nasce uma ideia em uma startup e como são tomadas as decisões. No artigo anterior, você viu como a área de Produtos se encaixa nesse processo; e no próximo, vai acompanhar a área de Qualidade. 

Nesse artigo, o foco é a área de Desenvolvimento de software. Vamos lá!

Ciclo de Desenvolvimento de Software

O ciclo de desenvolvimento de software varia de startup para startup. Há startups que possuem processos conhecidos como waterfall, tradicionais em startups que surgem a partir de grandes empresas ou empresas mais antigas, nas quais as/os profissionais responsáveis pelo desenvolvimento apenas recebem o design pronto. Na maioria, porém, a colaboração entre a área de Produto e Tecnologia começa durante a criação do produto ou feature.

Vamos falar focar nesse último modelo, que é o que vivemos na Arco Tech.

Onde começa o código?

Precisamos ter em mente que um produto é o resultado do trabalho de todas as partes envolvidas.

No modelo onde Tecnologia (Desenvolvimento de Software) começa a participar durante a criação do produto ou feature, o design chega ou como um wireframe ou já com os componentes pré-finalizados, assim como as regras de negócio e critérios de aceite do produto já escritos. As pessoas envolvidas no desenvolvimento de software irão fazer a análise técnica sobre a viabilidade de desenvolver a solução. Você deve conhecer essa etapa como Refining, Grooming (termo que caiu em desuso devido ao significado em inglês, associado a aliciamento infantil; vale cuidado para não utilizar) ou Technical Discovery, que é como chamamos aqui na Arco Tech.

Impossível falar de desenvolvimento de software sem falar de desenvolvimento ágil então aperte os cintos!

Etapas do Desenvolvimento

Etapa 1) Technical Discovery

Junto à área de Produto, a equipe de desenvolvimento de software irá fazer a análise da solução proposta. Alguns dos pontos mais comuns que são levantados nessa etapa são:

Impacto
Esse produto ou feature impacta em outros existentes? É necessário algum refactoring para que seja viável o desenvolvimento?

Dados
Quais dados são necessários? Existe API ou será necessário criar uma nova? Esses dados se relacionam com outros existentes? É necessária alguma alteração? Como esta alteração será requisitada e retornada? Qual estrutura deve ser retornada?

Segurança
Esses dados são sensíveis? Se sim, como será feita a autenticação? Quais camadas de segurança serão necessárias para garantir a segurança desses dados?

Recursos
Vamos precisar de recursos de serviços externos? Quais serão os custos? Alguma biblioteca open-source pode diminuir a complexidade do desenvolvimento? Caso afirmativo, por que devemos escolher essa biblioteca, o que ela resolve? Os componentes já existem ou é necessário desenvolvê-los? Imagens, ilustrações e demais recursos já estão organizados e disponíveis para uso?

Qualidade
Quais serão os testes necessários? Quais pontos deverão ser testados?

Tracking
Quais ferramentas são necessárias para fazer o acompanhamento? É possível adicionar um serviço de gerenciamento para essas ferramentas?

E tudo o que será necessário para o desenvolvimento do produto ou feature.

É importante fazer essa discussão com poucos termos técnicos ou, se não for possível, explicar o que cada termo significa para que a área de Produto possa colaborar e não apenas estar como ouvinte. 

Se todas as dúvidas foram sanadas e todas as partes envolvidas entenderam as regras de negócio, critérios de aceite e não há impedimentos como dependência de outras áreas que não puderam ser resolvidas nesse momento, então é hora de quebrar o produto em pequenas tarefas e organizar as entregas.

Etapa 2) Planning

Após o Technical Discovery, é a vez de organizar as tarefas para que a área de Tecnologia consiga desenvolver de forma organizada, deixar claro o andamento do desenvolvimento e claro, conter as emoções das demais pessoas envolvidas.

Fonte da imagem Srum.as

Grandes features são quebradas em pequenas tarefas ou mesma em etapas e as mais comuns são:

Milestones
Etapas de entrega do produto contendo todos os Epics.

Epics
Conjunto de Stories a serem desenvolvidas, contendo regras de negócio, critérios de aceite de produto, qualidade e segurança.

Stories
Tarefas a serem desenvolvidas contendo critérios de aceite técnicos, as definições de pronto ou Definition Of Done e relação entre outras tarefas.

Exemplo simples de quebra Epic e Story de uma nova feature. Imagem de Studos.com

Sprint
Termo muito falado dentro de startups, a sprint faz parte do modelo da metodologia Scrum. É o período durante o qual as Stories serão desenvolvidas.

Nessa etapa, o time de desenvolvimento, em conjunto com o/a Product Owner (pessoa responsável pelo produto nesse momento), irá analisar quais as Stories serão desenvolvidas e entregues nesse período. Para uma estimativa mais certeira, devem ser levados em consideração alguns quesitos:

• Esforço
• Complexidade
• E, não menos importante, compromissos com reuniões recorrentes ou outras atividades, e mesmo compromissos pessoais

Estimativa, o terror de desenvolvedores

Imagine o seguinte cenário: uma Story na qual o objetivo é formatar em HTML o conteúdo de 5 páginas institucionais, e outra, cujo objetivo é exibir informações que são retornadas de uma API.

A primeira Story é simples, mas ela pode demorar vários dias enquanto a outra, apesar de haver uma integração e, possivelmente, uma maior complexidade, pode levar algumas horas. Como estimar esses cenários sem cair na armadilha da tarefa fácil que pendura por dias e gerar frustrações no final de cada sprint?

Há diversos sistemas de pontuação, sendo o mais comum Fibonacci. Na Arco Tech, optamos por usar como referência uma tabela de Esforço e Complexidade.

Imagem de Agile Momentum

Uma tarefa complexa pode ter a mesma estimativa de uma tarefa fácil. A estimativa da Story deve também levar em consideração o entendimento sobre desenvolvimento que cada membro tem, e deve ser feita em conjunto. A pessoa mais experiente pode enxergar a tarefa de formatar o conteúdo em HTML como 5 enquanto a mais iniciante pode enxergar como 10. É importante que todos justifiquem suas pontuações e estejam confortáveis com as estimativas. Se alguém acha que é 10, e mesmo diante das explicações dos demais de porque é 5, não fique confortável, a pontuação deve ser 10.

Durante a sprint, há pequenas etapas pelas quais o desenvolvimento de uma Story passa. Isso também varia de startup para startup, mas o mais comum é haver:

Do
Story aguardando desenvolvimento.

Doing
Story em desenvolvimento.

Test
Story ainda em desenvolvimento, mas em conjunto com área de Qualidade (saiba mais sobre isso na terceira parte dessa série de artigos)

Done
Story finalizada. Lembra do Definition Of Done? O ideal é que atenda a todos os critérios estabelecidos para que a tarefa seja dada como finalizada, que pode ser desde o produto em ambiente de testes como também a disponibilização para o ambiente de produção.

Etapa 3) Entrega

O desenvolvimento de software não é preto no branco. Problemas VÃO acontecer.

Uma sprint pode falhar e isso é muito comum devido ao ambiente incerto que é o desenvolvimento de software dentro de uma startup. Uma Story pode ir e voltar algumas etapas diversas vezes; o código pode necessitar de uma alteração não prevista ou mesmo as prioridades podem mudar. Acontece.

Algumas startups que seguem o Scrum, possuem algumas cerimônias que revisitam fatos da sprint com o intuito de promover uma melhoria contínua como Review e Retrospective. Pode ser uma boa oportunidade de encontrar o que deu errado na entrega e propor soluções para que não aconteça novamente.

COLABORAÇÃO E COMUNICAÇÃO ENTRE ÁREAS

A falta de colaboração entre a área de desenvolvimento e demais áreas resulta em diversos conflitos, em um produto problemático e, consequentemente, em times que apontam dedos uns para os outros.

O trabalho de Tecnologia não é apenas escrever código. É colaborar com soluções que resultam em um produto inovador e de qualidade, sendo o código apenas um meio.

É importante ter em mente que, como profissional de desenvolvimento de software, você precisa, sempre, conversar com as áreas envolvidas no produto, entendendo os objetivos e valor que o produto entregará para o/a cliente final. Isso ajudará a encontrar inconsistências, a propor soluções e novas ideias em um desenvolvimento objetivo e de qualidade, evitando refactoring ou projetos que rapidamente viram legado, além de evitar foco nas coisas erradas, que resultam quase sempre em horas extras desnecessárias.

Ainda sobre comunicação e… FOGO NO PARQUINHO 🔥

Nesse artigo, passamos por praticamente todos os processos de metodologia ágil. Mas se você já leu sobre o assunto anteriormente, vai perceber que faltou uma cerimônia muito popular: a terrível e alerta de baixa colaboração e comunicação engessada e síncrona (em minha opinião pessoal, é claro), a Daily. Impossível concluir sobre comunicação sem levantar essa polêmica.

Como dito na primeira parte dessa série, uma startup está inserida em um cenário incerto, portanto, precisa ser flexível e responder a mudanças de maneira ágil, estando baseada em um ambiente de aprendizado rápido e constante.

A Daily é a cerimônia diária, que ocorre geralmente (para o terror das pessoas noturnas, como eu) nas primeiras horas do dia. Tem como objetivo entender o andamento da Sprint, apontar impedimentos ou dúvidas para que o/a Product Owner ou algum membro do time possa ajudar.

Em um time onde há uma excelente colaboração e comunicação, a Daily se torna desnecessária (e as pessoas noturnas podem sorrir novamente), pois os/as profissionais responsáveis pelo desenvolvimento estão em contato com as demais pessoas envolvidas durante todo o processo, solucionando impedimentos e dúvidas no momento em que elas ocorrem. E claro, todas as partes precisam estar acessíveis para que isso funcione, um orgulho que temos na Arco Tech.

Entender que a entrega é de toda a equipe e não um objetivo individual é importante para criar um ambiente colaborativo e proativo, evitando conflitos e tornando as áreas cúmplices uma das outras. Todas as partes saem ganhando.

Resumo

Como dito anteriormente, é muito difícil falar sobre desenvolvimento de software sem falar de metodologia ágil. Uma startup que queira entregar um produto rápido e de qualidade (ao menos, organizado, sem matar o time), poderá usar os clássicos processos do Scrum ou mesmo usar apenas o que faz sentido para aquele momento.

E, sem iludir você: pode acontecer de você entrar em uma startup onde não tem nada disso e o/a CEO te entregar um layout em um arquivo Word para que você desenvolva o famoso (e às vezes eterno) MVP ou Mínimo Produto Viável para validar a ideia. Isso faz parte do nascimento de uma startup e é um momento que exige poucos processos e rápido desenvolvimento. É onde também nasce os/as melhores profissionais. Apenas curta o momento! E se o produto der certo, você já sabe o mínimo que precisa para que o desenvolvimento de software aconteça de maneira organizada e saudável.

Lembre-se, desenvolvimento de software não é apenas sobre código ✌️

Este conteúdo faz parte da Sprint PrograMaria powered by Z-Tech | Mulheres em Startups.