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:

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:

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: