Muitos profissionais falam sobre método ágil de desenvolvimento, mas, o que isso significa?

 

O método ágil de desenvolvimento de software, que na realidade pode ser aplicado em vários outros processos e não somente na área de tecnologia da informação, é um conjunto de métodos e processos que facilitam a interação entre clientes e desenvolvedores, possibilitando uma maior eficiência e ganho de produtividade.

O método ágil tem por princípios, garantir a satisfação do cliente, entregando de forma eficiente e contínua, produtos funcionais, antecipando prazos e estimulando a cooperação diária entre o cliente, o desenvolvedor e outros colaboradores (stakeholders).

Os projetos criados no processo ágil, valorizam as interações, ou seja, a cooperação entre os indivíduos, mais do que as ferramentas, ou mesmo, os processos utilizados. Nesta metodologia de trabalho, um produto funcional e que atenda aos requisitos do cliente se sobrepõe as necessidades de documentação. O produto é entregue em etapas e cada etapa acompanhada de perto pelo cliente.O design do produto preza pela qualidade e excelência técnica, que visam responder às mudanças de forma rápida, sempre em colaboração com o cliente.

puzzle_pieces_house_teamwork_1600_clr

Startup Sorocaba: Você sabe o que é desenvolvimento ágil?

 

Para um processo de desenvolvimento ágil, é importante que a empresa tenha uma cultura que apoie o processo, fazendo com que os colaboradores se sintam motivados e confiantes. É importante ainda, manter uma equipe pequena, porém, competente, com facilidade de comunicação entre seus membros. A cultura empresarial pode ser uma das principais barreiras para a implantação do processo ágil, porém uma vez superadas, as vantagens do desenvolvimento ágil em relação ao modelo de desenvolvimento em cascata (baseado no planejamento) farão as mudanças culturais valerem a pena.

É importante ressaltar que o método ágil de desenvolvimento, se não for bem gerenciado, pode acabar gerando uma indisciplina no desenvolvimento, já que visa atender todos os requisitos do cliente, criando códigos funcionais, porém, desorganizados e lentos.

Uma das metodologias mais usuais é conhecida como “Scrum”, que, apesar do nome assustador, Scrum não é uma linguagem de programação, nem um novo seriado de TV. É um processo de planejamento e desenvolvimento de software, ou produto de forma ágil.  É um conceito recente aplicado à criação e projeto com foco na solução e nos resultados.

Quando comecei a programar, na década de 80, fazíamos os fluxogramas que eram, na verdade, diagramas de blocos representativos da programação estruturada onde cada comando era equivalente a um símbolo bastante específico.

Depois, aprendi a usar o UML e seus diagramas de caso de uso, de classes, diagrama de sequência, de objetos, de instalação e outros. Estes diagramas ajudavam a projetar um programa orientado a objetos.

A programação orientada a objetos revolucionou a forma de desenvolver código e para quem veio da programação estruturada, era uma forma muito mais simples de realizar o projeto de um software. Mas seus diagramas e excesso de planejamento tornam o desenvolvimento lento e muitas vezes o cliente não tem ou não compreende este fator.

Existem vários processos de criação iterativa e incremental para desenvolvimento de software ágil, como a prototipagem (onde são criados protótipos do código para o cliente e após definir as especificações, cria-se o produto real), processo em espiral (onde se agregam funções ao projeto e as especificações são implementadas).

O Scrum é o nome dado a um processo ágil onde o mais importante são os resultados e funcionalidade e não manuais complexos. E a participação de todos, desenvolvedores e clientes (product owner) é fundamental.

Muitas vezes, o cliente pode alterar a necessidade ou especificações do produto. Cabe ao Scrum Master manter a equipe direcionada da forma correta e assegurar as práticas do Scrum.

O desenvolvimento Scrum, começa ouvindo o cliente através de “histórias dos processos” que o sistema realizará. Isso irá gerar o product backlog (funcionalidades do sistema). Os processos do sistema são divididos em sprints, que são unidades básicas daquilo que será criado.

Cada sprint começa com uma reunião (Sprint Planning) que irá definir as tarefas daquela unidade, sempre seguido por reuniões de revisão ou retrospectiva. Em cada sprint a equipe (Scrum team) cria algo funcional e perceptível pelo product owner, dentro de um prazo estabelecido e gera um “feedback”.

Muitas empresas de desenvolvimento de software estão adotando o processo Scrum, pois seus resultados têm se mostrados mais vantajosos que os processos similares.  Se você leitor é um desenvolvedor e esta é a primeira vez que ouve sobre o assunto, segue abaixo alguns links para mais informações:

 

Manifesto ágil

 

Using na Agile Software Process with OffShore Development

 

O guia do Scrum: Um PDF sobre método Scrum

 

O site do Scrum (em Inglês).

 

Vídeos da Universidade Scrum

 


E você, o que pensa sobre o assunto? Gostou do artigo? Compartilhe conosco sua opinião. Não gostou? Acha que podemos melhorar? Então nos ajude a aprimorar nosso trabalho.

Siga o Startup Sorocaba no Facebook e cadastre-se para receber nossa newsletter e para ser informado sobre todas as novidades.

Compartilhe:

Por que é necessário usar métricas?

“Métricas de software nos possibilitam realizar uma das atividades mais fundamentais do processo de gerenciamento de projetos que é o planejamento. A partir deste, passamos a identificar a quantidade de esforço, o custo e as atividades que serão necessárias para a realização do projeto.” – Wikipédia

 

Talvez no início da sua empresa você deve pensar que a utilização de métricas é completamente desnecessária, mas conforme você for obtendo e analisando estes valores perceberá a sua importância principalmente por proporcionar um entendimento maior em relação ao cliente.

 

Quando se trata de qualidade, o próprio livro Lean Startup do Eric Ries é um pouco contraditório. Apesar do autor dizer que não é possível medir a qualidade de um produto inovador já que não se conhece o padrão do mercado que ele será inserido (já que é um mercado inovador), outras vezes ele ressalta como a qualidade é importante.

 

Por mais que não se conheça o padrão de mercado, as métricas podem ajudar a entender o que está acontecendo no seu produto. Por isso, é através delas que será possível definir o padrão de qualidade inicialmente desconhecido, o qual é possível seguir conforme o produto for crescendo.

 

Como já foi mostrado anteriormente, na pesquisa sobre processo de desenvolvimento em startups, problemas relacionados a prazos, gerenciamento de bugs, dificuldade com o desenvolvimento de uma nova funcionalidade, entre outros, podem ser facilmente identificados com o uso de métricas. E, a partir daí adotar práticas que ajudem a melhorar esses números.

O “CHUTÔMETRO”

  

Vamos a um exemplo simples: programadores que atuam de forma independente através de consultoria! Como que eles estimam o seu tempo para desenvolver determinado software? É muito comum usarem uma técnica robusta mais conhecida como “chutômetro“! Muitas vezes a prática pode até levar a perfeição, então é muito comum depois de um tempo usando essa “técnica” e desenvolvendo sempre os mesmos tipos de software que a precisão em relação ao tempo aumente. Mas antes de virar um expert em “chutômetro”, quantas vezes um projeto será entregue atrasado?

Os atrasos são péssimos, mas a entrega antes do prazo também pode ter suas pegadinhas. Principalmente em relação ao valor cobrado pelas horas trabalhadas, além da possibilidade do cliente querer sempre as coisas antes do prazo.

Esse tipo de problema não acontece somente quando se trata de consultoria, para as startups isso pode ser mais um fator que influenciará o seu sucesso. Muitas vezes o atraso pode representar a perda do “time to market” ou até a possibilidade de aparecer alguma solução semelhante a sua no mercado de forma mais rápida.

 

O GQM

Definir métricas pode ser um pouco complicado, mas para ajudá-los é possível usar uma técnica muito simples, o GQM – Goal Question Metrics! É uma técnica muito semelhante ao mind map, mas com foco em métricas.

 

 

 

 

Para utiliza-lo é muito simples basta apenas: 

1) Identificar um objetivo (Goal),

2) Fazer perguntas (questions) em relação ao objetivo levantado em 1,

3) Definir as métricas (metrics) com base nas perguntas feitas no item 2. 

Desta forma, através do objetivo (o que você quer medir), é possível levantar hipóteses sobre o que deve ser medido que te induzam a definir as métricas. Lembre-se sempre de ser bem específico no objetivo para chegar ao resultado esperado. Veja exemplo abaixo:

 

 

 

No início pode parecer difícil, mas o importante é começar aos poucos! Comece com objetivos pequenos tais como: “Medir problemas encontrados por clientes após release do software”, e a partir desse objetivo crie perguntas que te ajudem a desenvolver um raciocínio para chegar até o objetivo. Por exemplo: como medir a quantidade de bugs encontrados pelo cliente? ou até, como medir a quantidade de clientes que deixam de usar a minha solução devido aos bugs encontrados? A partir dessas perguntas é possível estabelecer algumas métricas: número de bugs encontrados durante desenvolvimento X número de bugs encontrados em produção, número de bugs encontrados pelos clientes X número de clientes, dentre outras.

Não confuda métricas com medidas! As métricas são definidas pela relação de duas ou mais medidas, ou seja, para obter uma métrica você precisa comparar dois valores (medidas). Por isso as métricas te dão mais informações do que as medidas, e uma dica muito boa é sempre olhar as métricas em relação ao tempo. Desta forma é fácil identificar se os resultados estão melhorando ou não.

COMECE PELO MAIS SIMPLES E ESTABELEÇA METAS

Então comece com esses mapeamentos menores para ir ampliando aos poucos! Devo lembra-los também que não adianta nada ter os números se você não utilizá-los de forma adequada! Utilize-os para elaborar metas tais como: aumentar qualidade do produto final, a cobertura e qualidade dos testes, qualidade do código desenvolvido, dentre outras metas.

  

Apesar de um pouco complicada, espero que façam bom uso da dica dada neste post. Ela é importantíssima para te ajudar a elevar a qualidade final do seu produto, e do seu desenvolvimento. Mas lembrem-se sempre de começar do que considera mais fácil: comece a entender os valores que a sua empresa já consegue mapear, para depois aprimorá-los com o tempo.

Além dos exemplos dados neste post, essa técnica também pode ser utilizada para definir os famosos salto de fé e motor de crescimento do Lean Startup 

 


E você, o que pensa sobre o assunto? Gostou do artigo? Compartilhe conosco sua opinião. Não gostou? Acha que podemos melhorar? Então nos ajude a aprimorar nosso trabalho.

Siga o Startup Sorocaba no Facebook e cadastre-se para receber nossa newsletter e para ser informado sobre todas as novidades.

Compartilhe:

Alguns de vocês já devem ter visto e respondido a nossa pesquisa para entender as dificuldades que as startups encontram com a engenharia de software. Hoje então vamos mostrar alguns resultados que obtivemos com esta pesquisa! E se você ainda não respondeu, nos ajude acessando a pesquisa aqui.

Sempre ouvimos que o sucesso de uma startup está diretamente ligada ao plano de negócios e aceitação de mercado. Muitas vezes esquecemos de outros fatores que também podem afetá-la diretamente tais como: falta de experiência da equipe, qualidade do produto, velocidade de desenvolvimento, dificuldade na inserção de novos requisitos no projeto, dentre outros.  Por isso hoje vamos mostrar alguns dados obtidos com a pesquisa que estamos realizando. Essa é uma pesquisa informal e foi respondida por startups do Brasil inteiro.

Pesquisa-adicionar-funcionalidade-nova-startup-2

 

Ao perguntarmos: “Ao adicionar uma funcionalidade nova ao software, qual o grau de dificuldade encontrado?”, com as respostas é possível perceber que mais de 50% (63%) respondeu dificuldade 3 e 4! Ou seja, eles encontram uma certa dificuldade em alterar o software desenvolvido, em fazê-lo crescer aumentando seu escopo. Tomando por base que a maioria das Startups começa com um MVP (não sabe o que é MVP? Veja no nosso Dicionário de Startups), imagina que em cada ciclo de desenvolvimento a dificuldade encontrada pode ser 3 ou 4. Tomando por base que o Lean Startup foi criado para evitar o desperdício do tempo, o quão “lean” será esse desenvolvimento? Quanto tempo e código serão desperdiçados? E o “time-to-market” como fica? Além disso, será que o software deve ser todo re-feito para absorver uma nova funcionalidade?

Outro dado da pesquisa que dá suporte ao que falamos anteriormente é em relação a quantas versões são lançadas até que o software esteja estável o suficiente para liberação para o cliente. Esse dado é complicado de ser analisado separadamente já que ele está diretamente ligado a quantidade de bugs encontrados após o release de uma versão. Mas de qualquer forma é importante ressaltar que 44% disse liberar de 3 a 5 versões, e 26% mais do que 5 versões. Ou seja, 70% trabalham no mínimo em 3 versões de software até liberá-la para o cliente. O motivo de ser difícil analisar este dado isoladamente deve-se ao fato de algumas startups alegarem ter apenas 1 versão de software  e não é possível identificarmos com este dado a quantidade de bugs que são liberados com esta única versão. Estimamos que no mínimo 2 versões devem ser trabalhadas antes de liberá-la para o cliente, já que no mínimo é necessário realizar uma bateria de testes normais e outra de testes de regressão (em breve falaremos mais sobre os tipos de testes).

 

Pesquisa-versoes-software-startup

Por fim, vamos falar de prazos e impacto nos clientes:

  prazo-impacto-desenvolvimento-de-software-cliente-startup

É possível perceber na figura acima que ao falarmos de prazo e impacto, apenas 23% controlam os prazos e que são cumpridos de acordo com o planejado. Do restante, 31% não trabalha com eles e 46% atrasam um ou mais dias. Muitas pessoas pensam que startups não precisam trabalhar com prazos já que estão descobrindo uma oportunidade de mercado, porém muitas vezes essa oportunidade está numa janela de tempo e que se desperdiçada também pode ser um fator para o insucesso de uma startup.

Por exemplo, com a copa e as olimpíadas vindo para o Brasil muitos enxergaram oportunidades de negócios, mas nem todos conseguiram ficar prontos para aproveitá-la. Vide exemplo do HelloUniverse que se trata de “um serviço eletrônico com tradutores de várias línguas à disposição, numa central para qual basta ligar e pedir ajuda de  alguém para traduzir qualquer coisa'”, cujo o lançamento foi apenas 2 semanas após o início da copa (veja mais detalhes  aqui). Eles perderam uma oportunidade de lançar o produto antes da copa e já ter adeptos do mundo inteiro, agora resta somente esperar as olimpíadas.

E, ao falar de impacto no cliente, quando falamos de “early adopters” (veja também no nosso dicionário) fica mais fácil controlar o impacto dos problemas encontrados no produto. Porém, quando pensamos em escala como medir esse impacto? Como saber se um cliente deixou de usar a sua ferramenta por causa das dificuldades encontradas ao utilizá-la podendo ser por bugs pequenos ou até problemas de UX (também no dicionário)? Quantos aplicativos você mesmo já não baixou e deixou de utilizá-lo devido a dificuldade  ou por te deixarem na mão? De qualquer forma, 43% das startups que responderam a pesquisa disseram que possuem um impacto alto ou extremo, além de 9% que não fazem nem ideia e 6% que marcaram “outros”. Como controlar esse impacto? Como medí-lo e entender como ele pode ser reduzido? Além disso, quando falamos em sistemas embarcados esses números podem aumentar consideravelmente, principalmente em relação ao prejuízo gerado a uma startup.

Para essas e todas as perguntas feitas neste post existem boas práticas de engenharia de software que resolvem os problemas aqui listados. Práticas desenvolvidas baseadas em experiências do passado por um desenvolvimento desorganizado, será que estamos vivendo um ciclo vicioso?

E o seu processo? Será que ele é realmente Lean?

Lembrem-se sempre que Lean e Agile não são sinônimos de bagunça e desorganização. E se você quer melhorar a forma de desenvolver na sua startup, continue acompanhando os nossos posts que daremos muitas dicas de como aplicar práticas de forma que não engesse o seu desenvolvimento e que ele continue ágil e ainda mais lean!

Veja todas as respostas da pesquisa em: Processo de desenvolvimento em Startups


E você, o que pensa sobre o assunto? Gostou do artigo? Compartilhe conosco sua opinião. Não gostou? Acha que podemos melhorar? Então nos ajude a aprimorar nosso trabalho.

Siga o Startup Sorocaba no Facebook e cadastre-se para receber nossa newsletter e para ser informado sobre todas as novidades.

Compartilhe:

Gostaríamos de entender o processo de desenvolvimento de software em Startups, por isso construímos o formulário abaixo e pedimos por favor que preencham. Quando finalizarmos a pesquisa publicaremos os resultados obtidos aqui no Startup Sorocaba.

Este formulário foi criado para que possamos conhecer mais sobre o processo de desenvolvimento e propormos uma metodologia de fácil aplicação que contenha as melhores práticas das metodologias tradicionais existentes, Lean Startup e Customer Development. Esta metodologia visa ajudar na evolução do projeto eliminando os obstáculos encontrados durante seu desenvolvimento.

Compartilhe:

Juntamente com o GBG (Google Business Group) Sorocaba o SS lança seu primeiro desafio!! Seus participantes deverão desenvolver soluções para resolver problemas encontrados na cidade de Sorocaba e região.

O primeiro problema escolhido foi: Como engajar a população de Sorocaba para consumir mais cultura?

Este desafio terá um mês de duração e o resultado final deve ser um MVP validado. Durante este período rolarão eventos online para acompanhamento, conversa com possíveis clientes e esclarecimento de dúvidas. Além disso, acontecerão algumas dinâmicas compostas por desafios que deverão ser concluídos para aumentar a pontuação da equipe.

As duas equipes com mais pontos farão o pitch final no dia 07/11 para uma banca formada por pessoas que sofrem com o problema abordado (seus clientes) e agentes da cultura. 

Com essa iniciativa o Startup Sorocaba e o GBG querem fomentar o espírito de empreendedorismo através da solução de problemas reais, conexão de pessoas e apoio com ferramentas e direcionamento para os empreendedores.

O prazo para inscrição é 25/09! Você pode se inscrever sozinho* ou com uma equipe de até 5 pessoas.

*Aqueles que se inscreverem sozinhos serão direcionados para a formação de uma equipe.

Está esperando o quê? Inscreva-se aqui. Leia o Manual com o FAQ do Desafio Startup Sorocaba.

#desafioStartupSorocaba #desafioCulturalSS #1DSS

gbg_SS

Compartilhe:

Você alguma vez já ouviu falar sobre desenvolvimento iterativo e incremental? Esse tipo de desenvolvimento remete as metodologias ágeis como Scrum e XP, e também metodologias mais tradicionais como o RUP.

Muitos conhecem o modelo de desenvolvimento waterfall (cascata) por terem estudado durante a faculdade ou por trabalharem numa empresa que ainda o utilize. Outros, trabalham com metodologias ágeis, e logo associam a agilidade devido a falta de documentação e não conhecem o modelo de desenvolvimento por trás dela: iterativo e incremental.

Hoje em dia o waterfall é considerado ultrapassado já que nele o software passa completo de etapa em etapa. Desta forma, seguindo um modelo básico de desenvolvimento que seria: requisitos, desenvolvimento, testes e implantação, em cada uma dessas etapas o sistema é planejado por completo: na fase de requisitos todas as funcionalidades devem ser levantadas, no desenvolvimento implementadas para depois então seguir para testes e implantação. O grande problema nisso é a que se uma falha acontece numa fase inicial, ela é replicada e ampliada em todas as outras. 

Além disso, numa startup por exemplo, a aplicação desenvolvida só estaria pronta para ser liberada para o cliente validar ao final do desenvolvimento. Ou seja, depois de muito tempo de trabalho somente no final é possível verificar se o que foi produzido realmente atende as necessidades do cliente. E, caso não atenda, todo o trabalho desenvolvido e tempo gasto serão “jogados fora”. 

Modelo-cascata-startup-sorocaba

Diferente do waterfall, no desenvolvimento iterativo e incremental o software é dividido em iterações que incrementam o software a cada nova rodada. Este modelo consiste na repetição do processo básico: “requisitos – desenvolvimento – testes – implantação” várias vezes com entregas pequenas do software. Além disso, o importante é saber que cada iteração deve entregar uma parte funcional do software para que ele possa passar por todas as etapas desde a elaboração dos requerimentos até implantação.

Iterativo-Incremental-startup

Esta forma de desenvolvimento é muito eficiente para uma Startup já que a cada incremento é possível gerar uma versão funcional do software para o cliente, obtendo feedbacks constantes e mais rápidos.  Além dessa vantagem, outra consiste em evitar o gargalo final na hora da realização dos testes e a sua maior flexibilidade em relação mudanças. As alterações que podem ocorrer num projeto se tornam mais fáceis de lidar já que muitas vezes são necessárias somente pequenas alterações no planejamento, ou então mudanças pontuais que não afetarão o produto inteiro. Isso tudo te força a pensar durante o planejamento nos pontos mais importantes que deverão ser validados primeiro com o cliente (durante o MVP, por exemplo),  priorizando-os para obter um feedback antecipado do seu produto. 

Se você não sabe nem por onde começar a desenvolver desta forma, abaixo estão 5 passos para te ajudar:

1- Levante as principais funcionalidades do produto, sem detalhá-las

É importante saber tudo o que será desenvolvido para que seja feito um planejamento do todo dividindo cada etapa em iterações. Muitas vezes com o feedback dos clientes o planejamento pode se modificar por completo, ou então, apenas alguns detalhes. Porém não se esqueça de ter essa visão sobre onde quer chegar e planejar. Este planejamento te ajudará a estabelecer melhor o caminho a seguir e,  principalmente, a definir o MVP. 

2- Quebre as funcionalidades em grupos de entrega

Após identificá-las é necessário entender o que deve ser desenvolvido primeiro (MVP) para testar a sua hipótese inicial e as etapas seguintes. Lembre-se sempre que cada iteração deve fornecer um produto executável. Nesta etapa é possível também levar em consideração a arquitetura e lógica de funcionamento do software, para facilitar o desenvolvimento em cada etapa diminuindo as chances de retrabalho.

3- Identifique a prioridade e Complexidade

Este passo é opcional, mas pode ajudar na hora do planejamento, principalmente quando inserir novos items para serem desenvolvidos. Para cada requisito determine sua prioridade (de acordo com o feedback do cliente) para ser desenvolvido e a complexidade para desenvolvê-lo. Itens com prioridade baixa e complexidade alta devem ser descartados do planejamento já que consumirão grande parte do seu tempo e não trarão benefícios aos seus clientes. 

4- Monte um planejamento de entregas

Com base nos passos anteriores monte um planejamento de entrega de cada iteração, mas não se esqueça de incluir um período para integração dos produtos liberados em cada iteração. Já que algumas vezes podem ser necessários o desenvolvimento de interfaces de comunicação entre eles. 

Neste passo também é importante linkar as alterações com as versões do software. Isso garante que se após uma alteração ocorrer algum problema grava com o software, seja possível mapear o que foi alterado de uma versão para a outra, além de poder resgatar o que estava funcionando anteriormente. Lembrando sempre que gerenciamento de versão é algo fundamental para quem está desenvolvendo softwares comerciais.

5- Siga o seu fluxo de desenvolvimento para cada iteração

Lembre-se sempre que não é porque o desenvolvimento é ágil que ele precisa ser bagunçado. Por isso tente sempre seguir o fluxo básico: requisitos > desenvolvimento > testes > implantação para não se perder no meio do caminho durante o desenvolvimento. Com o tempo e feedbacks de clientes aparecerão novos requisitos e saber como lidar com eles: qual deve ser desenvolvido primeiro ou descartado pode ajudar muito no sucesso da sua startup.


E você, o que pensa sobre o assunto? Gostou do artigo? Compartilhe conosco sua opinião. Não gostou? Acha que podemos melhorar? Então nos ajude a aprimorar nosso trabalho.

Siga o Startup Sorocaba no Facebook e cadastre-se para receber nossa newsletter e para ser informado sobre todas as novidades.
Compartilhe:

Quando falamos em teste de software é muito comum pensarmos apenas em rotinas de verificação simples do software desenvolvido, na qual os próprios desenvolvedores fazem testes rápidos para ver se determinada funcionalidade mais difícil está funcionando como deveria.

 Também é  muito comum as pessoas confundirem o real significado da etapa de validação no ciclo de desenvolvimento: “testes são feitos somente para eliminar falhas”. Os testes com certeza auxiliam na remoção das falhas por serem uma forma de identificá-las, mas o seu real objetivo é de apontar o maior número de falhas possível, comprovando o que NÃO está funcionando.

Um dos maiores problemas em relação a este tema é como saber se todos os erros foram encontrados se não se sabe quantos existem? Por isso é necessário entender o nível de qualidade aceito pelo seu cliente para que possa ser replicado em todos os seus releases de software.

É importante ter sempre em mente que testar não é somente seguir um “passo-a-passo” bem detalhado verificando o resultado esperado. Antes disso é importante que uma pessoa planeje como serão feitos os testes e como o software deverá ser testado para então serem desenvolvidas rotinas com ações e resultados esperados no qual qualquer pessoa possa seguir e anotar os resultados obtidos, inclusive um computador!

Nessas horas deve vir a dúvida “se é tão complicado, devo ter alguém especializado trabalhando aqui comigo?” A resposta a esta pergunta é sim! Mas como a maioria das empresas pequenas e Startups não têm dinheiro disponível para sair contratando diversas pessoas, a nossa dica de hoje é: comece a escrever as suas rotinas de teste!

 

Muitas pessoas costumam realizar testes de software sem nenhum planejamento e nem sequer anotar as rotinas que serão testadas e como elas serão testadas. Mas a partir de agora todas as vezes que for testar um software, vocês vão escrever a rotina que será testada! Não precisa ser com muitos detalhes, é necessário somente iniciar um mapeamento para conseguir obter os dados necessários para medir a sua qualidade. Então, comece com esse passo pequeno, para iniciar o entendimento de quais são os pontos falhos para depois poder focar num planejamento melhor. Além disso, com o tempo é possível perceber que muitas das rotinas de testes já criadas anteriormente poderão ser re-utilizadas em novos releases de software.

 

Por isso não se esqueça das dicas fundamentais:

 

DEFINA UM OBJETIVO DE TESTE  

Ao criar seus testes não esqueça de formalizar seu objetivo deixando-o claro e bem específico para o teste que estará desenvolvendo. Ao fazer esse planejamento pense: o que eu quero comprovar com esse teste? Quais métricas me ajudam a chegar a este resultado? Como utilizar essas métricas? Não se esqueça de especificar também a funcionalidade que será testada e principalmente o que será testado como por exemplo: “Verificar se a entrada de dados no campo nome aceita caracteres especiais”.

 

 

 

ESCREVA AÇÕES PARA ALCANÇAR OS RESULTADOS ESPERADOS

 Após definir o objetivo você pode escrever passo a passo para que o responsável pelo teste siga para chegar até a rotina desejada ou então apenas descrever a ação necessária para produzir o seu resultado esperado. Esta segunda opção é mais rápida e fácil de desenvolver, e a primeira visa facilitar a execução de testes por pessoas que não conhecem a ferramenta.

Essas dicas, podem ser aplicadas também na validação do seu produto e na execução de testes com seus clientes. Essa abordagem é muito simples e te ajuda a organizar o seu raciocínio. Seu ponto principal é deixar bem claro onde se quer chegar: qual o seu objetivo? Ao validar a sua ideia também é importante saber o objetivo da sua ferramenta e a partir dele, e definir métricas assim como é feito com teste de software. As métricas serão suas aliadas em todos os momentos no desenvolvimento da sua Startup. Elas ajudam na tomada de decisão, e a responder perguntas como: “devo pivotar ou continuar”.

Não sabe o que é pivotar? Não tem nem ideia de como definir uma métrica? Continue acompanhando o Startup Sorocaba que nós te ajudaremos!


E você, o que pensa sobre o assunto? Gostou do artigo? Compartilhe conosco sua opinião. Não gostou? Acha que podemos melhorar? Então nos ajude a aprimorar nosso trabalho.

Siga o Startup Sorocaba no Facebook e cadastre-se para receber nossa newsletter e para ser informado sobre todas as novidades.

Compartilhe:

Alguma vez você já parou para se perguntar: O que é qualidade?? Não estou falando somente de qualidade de software, mas qualidade em geral. Nessas horas você pode estar pensando: “que pergunta mais idiota! É óbvio que qualidade é aquilo que é bom!!”. Porém, se você parar um pouco para pensar, quando conversamos com outras pessoas podemos perceber que nem sempre o que é bom para elas, também é bom para a gente.

 

Não precisamos fazer muito esforço para pensarmos num exemplo onde isso é claramente percebido: na famosa disputa entre iPhone e Samsung Galaxy. O que pode também te levar a pensar: “não vou nem perder o meu tempo, é óbvio que o Galaxy é mil vezes melhor que o iPhone já que no Galaxy eu consigo fazer inúmeras coisas que o iPhone me bloqueia.” Ou então, “o iPhone dá de mil no Galaxy já começando pelo seu design e qualidade de imagem e fotos e, além disso, ele não trava o tempo todo!” Enfim, existem características que te levarão a concluir o que você prefere, o que você acha que é melhor, ou seja, o que tem mais qualidade para você!

iphone5-galaxy-s3

 

Para piorar, no mundo da tecnologia, falando mais especificamente de software, as opções são inúmeras o que dificulta mais ainda a escolha do cliente. Mas o que os novos empreendedores, donos de empresas pequenas e StartUps não param para pensar é que muitas vezes os clientes escolhem o que é menos pior para eles. Afinal, quantas vezes não ouvimos alguém comentando que comprou um determinado produto que tem diversas funcionalidades por causa de apenas uma que atendia a sua necessidade?!

Mas por quê ao invés de fornecermos o “menos pior” não focamos no melhor? Ao invés de focarmos em várias funcionalidades diferentes, não gastamos nossos recursos naquelas que realmente rendem alguma coisa? E como fazer isso?

 

Como vocês podem ver medir a qualidade de algum produto não é uma tarefa fácil já que é um conceito muito subjetivo, mas tentarei ajudar com algumas dicas de como você pode começar a percebê-la utilizando números, ou seja, métricas. E para isso, fui obrigada a recorrer ao meu TCC no qual uma frase se destacou: “Tratando-se de qualidade existem três aspectos fundamentais que devem ser levados em consideração: as pessoas, tecnologia e gerenciamento.”

 

Esta frase isoladamente pode não fazer muito sentido, mas vou focar nos três aspectos e tentar traduzi-los de uma forma mais prática para que você possa utilizá-la no seu dia-a-dia. Começando pelo primeiro item e acredito que o mais difícil: pessoas. Quando leio pessoas nesta frase, leio clientes. E quando penso em clientes, a logo associo a  “Requisitos de Software“! Posteriormente farei mais um post exclusivo dando mais dicas práticas de como utilizá-los.

Já a tecnologia faz referência a ferramentas e recursos tecnológicos que você irá utilizar para auxiliar durante todo o seu desenvolvimento: desde o computador até, por exemplo, uma ferramenta de gerenciamento de requisitos gratuita, além da tecnologia em si que está sendo desenvolvida. Também farei um post dando dicas de quais ferramentas você pode utilizar para melhorar a sua gestão de qualidade. E, por fim, gerenciamento!  O gerenciamento vem através da definição de métricas de acompanhamento e como utilizá-las para aumentar a qualidade de seu produto já que não adianta apenas medir os valores sem utilizá-los.

 

Trazendo um pouco mais para o mundo Startup: o Lean Startup fala bastante sobre evitar o desperdício de dinheiro, tempo de trabalho e recursos! E por isso nele é pregado o constante feedback dos clientes, afinal, são eles que podem te dizer o que mais gostaram ou detestaram no produto! É possível perceber então, que a qualidade está diretamente ligada às necessidades do usuário! Ela é totalmente relativa e você deve sempre se perguntar e entender até que ponto o seu cliente consegue lidar com os problemas encontrados no software?

métricas-digitais

 

Outro ponto fundamental tanto para a Engenharia de Software tradicional como para o Lean Startup são as métricas! São elas que irão te direcionar e dar base para a tomada de decisão: devo pivotar ou continuar? É com elas que você tem as informações necessárias para medir o aprendizado obtido durante um ciclo de desenvolvimento avaliando o impacto gerado nos seus clientes. Entendeu? Não?! Calma! Em outros posts nós iremos ajudá-los a entender melhor sobre o mundo de desenvolvimento de software em Startups!

Assine a nossa newsletter para ficar por dentro das novidades!!


E você, o que pensa sobre o assunto? Gostou do artigo? Compartilhe conosco sua opinião. Não gostou? Acha que podemos melhorar? Então nos ajude a aprimorar nosso trabalho.

Siga o Startup Sorocaba no Facebook e cadastre-se para receber nossa newsletter e para ser informado sobre todas as novidades.

Compartilhe:

Pensando em diversos assuntos que poderia abordar aqui resolvi começar do inicio: Requisitos!!!! Muitos sabem o que são, mas nem todos entendem sua importância, a grande maioria acha perda de tempo. Mas neste post vou tentar explicar um pouco sobre sua importância com o intuito de convencê-los de que não é perda de tempo.

Geralmente, quando começamos a desenvolver um software idealizamos como ele deveria ser de acordo com as nossas expectativas e logo começamos a desenvolvê-lo, mas será que fazer desta forma traz somente benefícios? Bom, vamos entender primeiro o que é um requisito de software: de forma prática não é nada mais nada menos do que entender as necessidades do cliente e traduzí-las para um sistema, ou seja, para o software.

Não vou entrar muito nos detalhes de como desenvolver um requisito, até porque com uma simples busca no google você consegue descobrir como começar a utilizá-los. Quero apenas convencê-los de sua importância e a diferença que ele poderá trazer para o seu produto final. Mas de qualquer forma aqui está um link que você pode acessar para obter mais detalhes: Engenharia de Requisitos. Neste link você vai encontrar uma explicação mais detalhada sobre Engenharia de Requisitos mostrando seus conceitos, como utilizá-los, etc. Mas lembre-se todo processo deve ser adequado para a sua empresa, então comece com um passo menor: entendendo o que são requisitos e a escrevê-los de uma forma que vá te ajudar, com o tempo vocês irão evoluindo para algo mais robusto que necessitará de um processo mais complexo.

Voltando a importância dos requisitos vocês devem estar pensando “legal, mas por quê devo utilizá-los?”. Como eu havia dito anteriormente os requisitos são a tradução das necessidades do cliente para a descrição de um sistema que você pode desenvolver. Desta forma, ao entendermos a necessidade dos nossos futuros e/ou atuais clientes as chances de acertar no produto final aumenta, evitando com que tenhamos que fazer um re-trabalho quando começarmos a interagir melhor com nossos clientes.

Quantas versões de software você já teve que desenvolver até conseguir atrair o maior número possível de pessoas interessadas? Este tempo gasto em re-trabalho poderia facilmente ser usado para elaboração de  uma funcionalidade nova para o seu sistema ou até uma nova ferramenta para atingir um público diferente.

É comum ao desenvolvermos um software não nos incluirmos no público alvo, em algumas situações isso realmente não acontece. A melhor abordagem para levantar requisitos de uma Startup é conversar primeiro com o seu público alvo! Porém nem sempre é fácil de fazê-lo, e muitas vezes o cliente para começar a conversar precisa ter algum protótipo para entender do que se trata. Para esses casos,  ao desenvolvermos alguma coisa nova podemos pensar: essa necessidade que observamos foi para suprir problemas que enfrentamos no dia-a-dia? Neste caso, que tal juntar todos envolvidos no desenvolvimento e fazer um brainstorming das funcionalidades que a ferramenta deverá ter? Começar a escrevê-las e depois detalhar para requisitos de sistema?

Agora você pode pensar “ah, eu faço isso de cabeça, não preciso escrever!”. O que eu posso te dizer é que escrever os requisitos irá te ajudar posteriormente no final do processo, onde alguém irá realizar testes com base nesses requisitos, afinal o papel dos testes é assegurar que o produto final terá qualidade o suficiente para seu cliente. Além disso, também irá te ajudar no gerenciamento conforme a sua empresa for crescendo e seu quadro de funcionários aumentar!

Se você acha que qualidade é apenas um software livre de bugs (o que não existe) e que com apenas alguns testes aleatórios conseguirei garantir 100% da qualidade do software desenvolvido, nos próximos posts falarei um pouco sobre o que é qualidade e o papel do time de testes e SQA dentro da engenharia de software. Mas já para dar uma introdução ao assunto você já pensou o que é qualidade para você? Quais produtos você considera bons e a razão de os preferir? Então pense e comente com outras pessoas, você perceberá que qualidade é algo muito mais subjetivo do que objetivo. E como medí-la? Tentarei dar dicas para poder te auxiliar, mas pode ter certeza que a dica de hoje é uma das mais importantes.

São muitos os desafios encontrados por empreendedores no momento de montar uma Startup, mas utilizando algumas técnicas de engenharia de software (calma, até Lean Startup é um processo :)) alguns desses desafios podem ser amenizados e o fluxo de trabalho ficar muito mais simples, prático e eficiente!

Lembrem-se sempre que até Metodologias Ágeis constituem num processo de desenvolvimento! E a forma que você irá incorporar as melhores práticas desses processos na sua Startup deve ser de acordo com suas necessidades! Algumas coisas podem não ter sentido nenhum em utilizá-las, porém outras são fundamentais para o sucesso do seu produto! E requisitos é uma dessas coisas essenciais para o desenvolvimento do seu projeto!


E você, o que pensa sobre o assunto? Gostou do artigo? Compartilhe conosco sua opinião. Não gostou? Acha que podemos melhorar? Então nos ajude a aprimorar nosso trabalho.

Siga o Startup Sorocaba no Facebook e cadastre-se para receber nossa newsletter e para ser informado sobre todas as novidades.

Compartilhe: