Conheça a Informant          RSS

Metodologia


30
May 14

Um computador, dois programadores. Conheça o pair programming!

Set icons for business, communication, web

Trabalhar em equipe é sem dúvida a melhor maneira de se executar qualquer tipo de tarefa, principalmente quando essa tarefa exige dos profissionais um grande conhecimento técnico no assunto, como é a indústria de fabricação de software.

Para ir além do trabalho em equipe estudiosos de metodologias ágeis de desenvolvimento criaram o pair programming. Do inglês, pair programming significa programação pareada e envolve dois programadores trabalhando na mesma máquina para se alcançar um resultado superior no código. Um dos programadores é o “driver”, que escreve o código, enquanto o outro é o “observador” que revisa cada linha em busca de erros.

Enquanto o observa, o segundo programador também pode ajudar na estratégia de desenvolvimento, apontando o melhor caminho que o código deve tomar. Pair programming já vem sendo utilizada por muitas empresas ao redor do mundo e nos próximos parágrafos você irá entender como você pode tirar proveito dela. Confira:

Vantagens de pair programming

Um código de qualidade é apenas uma das vantagens apresentadas por pair programming. Algumas pesquisas apontam que programadores pareados gastam 15% mais de tempo do que programadores individuais para escrever o mesmo código. Por outro lado, o resultado costuma ter 15% menos erros, reduzindo assim o custo de manutenção e correções ao longo do tempo de vida do software.

Também é comum que o pair programming incentive um aprendizado entre os desenvolvedores e ajude a reforçar a comunicação na equipe. Pair programming permite que os membros do time compartilhem seus problemas e soluções entre eles, incrementando a troca de informações.

Por fim, segundo pesquisa de IEEE, 96% dos programadores preferem trabalhar em dupla do que individualmente, demonstrando que esse tipo de programação acaba sendo mais vantajosa para o profissional.

Como funciona o pair programming

O pair programming pode ser dividido em quatro combinações: expert-expert, quando se busca a mais alta produtividade e excelente resultados; expert-novato, para que haja a oportunidade de se criar um vínculo de mentoria; novato-novato, ainda que a produtividade e a qualidade sejam baixas, é uma maneira de se treinar novos programadores; e remota, quando a pair programming ocorre através de editores de texto em tempo real com os programadores em locais separados.

Em geral, a modalidade expert-expert costuma não ser boa para que se descubra novas formas de se resolver os problemas, já que esse tipo de programador não está aberto a tentar novos caminhos. Se o objetivo for inovar, o pareamento do tipo expert-novato se encaixa melhor na estratégia da empresa.

Quando adotar

Para muitas empresas, adotar o pair programming pode significar uma quebra nas metodologias de trabalho. Isso pode gerar atrito entre desenvolvedores e prejudicar o andamento de projetos. Dessa forma, a migração para o pair programming precisa ser feita de maneira cautelosa.

Por outro lado, toda empresa que deseja aumentar sua produtividade e qualidade das entregas deve considerar o uso de pair programming, principalmente se o time de desenvolvedores possuir profissionais mais experientes.

Encontrar a melhor estratégia pode exigir testes, reuniões e paciência dos gestores, mas o resultado final pode surpreender mesmo os programadores mais céticos. Dúvidas? Vamos conversar nos comentários abaixo!


20
May 14

Entenda de vez o papel do Product Owner no SCRUM

Informant07.05Creditar o sucesso ou o fracasso de um projeto apenas à uma pessoa pode parecer errado, ou então conveniente, mas é algo comum em equipes que utilizam scrum no desenvolvimento dos seus projetos. Isso acontece por conta de uma figura fundamental: o product owner.

O sentimento de “posse” que toma conta de muitos POs é causado por conta do poder que ele exerce sobre as decisões importantes do projeto. Ao não perceber que ele deve servir como elo entre o cliente – ou usário final – e o time, acaba colocando em risco todo o desempenho do software, gerando ferramentas inúteis e desperdiçando tempo e recursos. Para entender o papel do product owner, suas atribuições, acertos e erros, acompanhe os tópicos a seguir:

Quem é o product owner

O product owner é responsável por gerenciar o backlog do projeto. Ainda que ele tenha ajuda de outros membros do time, como arquitetos, desenvolvedores, analistas de negócio, entre outros, a decisão final precisa ser tomada por ele. Da mesma forma, nenhuma alteração ao escopo do projeto deve ser tomada sem a presença e o consentimento do product owner. É claro que isso não significa que suas decisões não possam ser questionadas, apenas que todas elas devem ser compartilhadas com ele.

O product owner pode ser o próprio cliente, mas o mais indicado é que seja alguém do próprio time com um visão global do projeto, que entenda tanto do negócio do cliente, quanto do desenvolvimento e dos processos da empresa.

O que faz e o que deveria fazer o product owner

Segundo os guias de scrum, é papel do product owner registrar e ordenar com clareza os itens de backlog do projeto, garantir que todos do time estejam cientes e entendam os itens do backlog, garantir o valor do trabalho da equipe e, por fim, perceber se o MVP está entregando o valor esperado pelo cliente e comandar as melhorias contínuas em ciclos interativos.

Mais do que isso, o product owner deve perceber que ele tem um papel duplo para o sucesso do projeto: ao mesmo tempo que acompanha o cliente através da construção do software, também mantém o time trabalhando em prol das entregas. Em resumo, 50% do tempo de um product owner deve ser gasto para entender o negócio do cliente enquanto os outros 50% devem ser gastos passando esse conhecimento para o restante do time.

O que não fazer como product owner

O papel de conectar clientes e time pode fazer com que o product owner não saiba lidar com tanto poder, se isolando em meio a tomadas de decisão. Em geral, esse comportamento é fatal para o projeto.

O ideal em projetos que possuam um product owner destacado é que se faça reuniões semanais entre cliente e equipe desenvolvimento. Ainda que haja um líder, a tendência é que a tomada de decisões seja um fardo dividido entre todos. Um indicativo dessa mudança acontece quando o product owner deixar de falar no singular – eu – e passa a utilizar o plural – nós. Ainda que pareça algo banal, é fundamental que o PO entenda que todos vencem ou falham juntos.

Você é um product owner? Trabalha para um? Conte sua experiência para nós nos comentários abaixo.


19
May 14

O que são user personas?

Um dos fatores mais importantes para o projeto –e desenvolvimento- de um software bem sucedido é o entendimento do seu usuário. Sem uma compreensão correta de quem são as pessoas que vão interagir com ele, suas dificuldades e necessidades, é praticamente impossível desenhar soluções para elas. Hoje vamos mostrar uma ferramenta que é incrivelmente útil para isto, as user personas. Veja só!

Personagens fictícios e reais ao mesmo tempo

Uma persona é a representação de um grupo de pessoas condensada em um personagem, com nome, rosto e história. Ela é uma maneira de humanizar os dados demográficos que a pesquisa de usuário trazem.

Quando fazemos (ou analisamos) pesquisas sobre usuários, encontramos informações sobre sua idade, classe social, formação e determinados hábitos, de acordo com o foco daquele levantamento específico. Já estabelecemos que o bom entendimento destes dados é fundamental no desenvolvimento, certo?

O problema é que é muito difícil para as pessoas decodificar os números, percentuais e percentuais levantados pelas pesquisas em informação realmente relevante para o produto que está sendo desenvolvido. Nós, como seres humanos, simplesmente não somos feitos para isto. É aí que a user persona mostra o seu enorme valor!

Humanizar a relação é o segredo para o bom entendimento

A criação da persona dá a estes números um nome, uma cara e uma história. Os dados apresentados são os mesmos, mas uma vez transformados em personagem, fica muito mais fácil entender e extrair informação útil deles.

Com o uso de personas, uma sequência de dados como: “Sexo masculino; superior completo; 20-30 anos; área de saúde; (…)” é transformada em uma verdadeira narrativa. Por exemplo: “João, 25 anos, médico. Tem o objetivo de se tornar cirurgião. É solteiro, tem pouco tempo para se dedicar ao lazer e estudos, devido à rotina pesada no hospital”.

Conseguem perceber como é muito mais fácil lidar com esta pessoa fictícia do que com os dados puros? Entretanto, para que a técnica traga bons resultados, é importante notar que…

Personas não são um exercício de imaginação!

Durante a criação das personas é fundamental se ater aos dados. A sua elaboração é muito mais uma atividade de análise e entendimento do que uma de criação. É uma grande tentação para o desenvolvedor imaginar o seu usuário final e incorporar esta percepção na persona que orientará a criação. Este é um erro terrível.

Por trás da escolha de um nome, rosto e história para a persona, a atividade principal relacionada à sua elaboração ainda é a pesquisa do usuário. Observar o seu comportamento, realizar entrevistas e testes continua sendo a melhor maneira de obter os dados que vão ser usados para orientar o desenvolvimento do seu software. Mas certamente a comunicação e uso destes dados através de um personagem, em vez de tabelas e gráficos, facilitará muito as conversas e aprendizados no time.

Você tem experiências com a utilização de user personas? Como foram os seus resultados? Não se esqueça de comentar! Para saber mais sobre esta, e outras ferramentas úteis no desenvolvimento de software, é só ficar ligado no blog da Informant!


16
May 14

Uma introdução ao Behavior-Driven Development (BDD)

girl typing

Um dos problemas mais corriqueiros de todo desenvolvedor é conseguir explicar para leigos como seu trabalho funciona. Isso, aliado à velocidade com que os serviços se multiplicam pela internet, criaram uma falsa impressão de que os softwares são fáceis se serem feitos. Ainda mais quando estão na web.

Este fato se torna um problema quando o desenvolvedor precisa interagir com clientes e usuários em busca de uma melhor solução para algum projeto. De fato, incluir esse tipo de colaboração pode ajudar a desenvolvedor ferramentas melhores, mas também trazer uma série de dores de cabeça para os programadores.

Neste sentido, há algumas décadas, criou-se uma metodologia de desenvolvimento guiada por testes, onde uma aplicação era feita, testada e melhorada. Apesar de útil, a metodologia não estava de acordo com o desenvolvimento ágil, já que aumentava o número de interações e tornava o processo mais lento.

Com esses problemas em mente, em 2003, Dan North criou a Behavior Driven Development (BDD), que significa desenvolvimento guiado por comportamento e é adotada atualmente como uma técnica de desenvolvimento ágil. Nela, a colaboração entre os diversos agentes que serão impactados pelo software é largamente encorajada. Assim, todos participam do desenvolvimento desde o primeiro dia do projeto.

Como o BDD funciona

A BDD foca na criação de código através das interações entre desenvolvedores e usuários através de um processo denominado outside-in development, que significa desenvolvimento de fora para dentro. Na prática, a ideia é criar exemplos que descrevam o comportamento do software para que esteja seja avaliado pelos seus utilizadores.

Ao guiar o desenvolvimento do software através da metodologia de BDD é fundamental que os gestores do projeto esclareçam as responsabilidades de cada um e permitam que a construção da ferramenta seja questionada. Também é indicado que sejam usados mock-ups para simular módulos do sistema antes que esses sejam escritos.

O uso destes testes deve servir para criar a oportunidade de feedbacks rápidos antes do início do desenvolvimento. As vantagens da metodologias são muitas, desde econômicas (ao se permitir testes é mais provável que o software se encaixe na necessidade do cliente); até de usabilidade e eficiência da ferramenta.

A vantagem do Outside-in Development

O BDD deixa claro que o desenvolvimento do software deve ser feito a partir da interface que terá contato com o usuário final. Ou seja, o software é desenvolvido da parte externa para a interna, daí o nome outside-in develoment.

BDD é uma metodologia focada nos benefícios que a aplicação trará para o negócio e a única maneira disso ser percebido é implementando a interface e a entregando para que os usuários finais façam suas próprias considerações. Essas opiniões, quando avaliadas pelos desenvolvedores, devem guiar a construção do código. Alie isso à participação de um profissional do setor de qualidade da empresa, ajudando a criar os requisitos mínimos da ferramenta, e as chances do investimento ser bem aplicado disparam.

Conhecer metodologias de desenvolvimento ágil como BDD farão sua empresa muito mais eficiente e a qualidade das suas entregas muito maior.

Precisa de ajuda para agilizar o desenvolvimento do seu software? Fale com a Informant!


09
May 14

Conheça a metodologia da Informant! Etapa 4

Chegamos ao fim da série de quatro posts sobre a metodologia de desenvolvimento de softwares da Informant. Durante a série, conseguimos expor como nosso time trabalha com o objetivo de construir uma ferramenta capaz de entregar a solução para o problema do cliente, dentro de prazo e custo saudável, utilizando o que há de mais pioneiro em tecnologia, design e planejamento.

Mas antes de terminar, vamos tratar de um ponto que é o principal desejo de todo empreendedor quando cria sua empresa: vê-la crescer e atrair cada vez mais usuários. Mesmo que esse estágio não pareça trabalho para uma fábrica de software, aqui na Informant temos a convicção de que podemos ser parceiros dos nossos clientes durante toda a vida útil do software. Assim, criamos uma metodologia que melhora a ferramenta e dá a ela combustível para avançar sempre em frente. Então, para encerrar, conheça os três pontos fundamentais para o crescimento:

Computação em nuvem

Atualmente quando um software é planejado através de metodologias ágeis e design thinking, ele também é pensado para estar disponível o máximo de tempo possível. Por estar disponível, é preciso entender que não significa apenas estar num servidor hospedado na nuvem – ao invés de servidores locais e seus emaranhados de cabos azuis – mas ser acessível a todos.

Quando um cliente está decidindo pela sua empresa ele não precisa o que você está fazendo para manter seu site no ar. Na verdade, ele quer poder acessar o sistema através do seu computador, mas também de um smartphone ou tablet com acesso móvel. Isso significa que sua ferramenta precisa estar disponível para todos a todo momento para que você possa atrair mais clientes e continuar crescendo.

Análise de engajamento

Mesmo com toda essa tração não significa que seu software seja perfeito. Ao longo do caminho é provável que novos clientes, com problemas diferentes, sugiram melhorias e incrementos. À medida que esses pedidos se tornam constantes é seu dever implementá-los. Não apenas para satisfazer os novos clientes e atrair mais, mas também para se posicionar um passo à frente da concorrência.

Implementar melhorias no software em busca de mais crescimento é um processo infinito. Ou seja, a empresa precisa monitorar e melhorar constantemente para manter-se na liderança. Um dos grandes erros das empresas que vão à falência é considerar a inovação algo desnecessário por estarem há muito tempo na frente. Muitas vezes, essa lentidão servirá de sinal para o seu concorrente lançar algo melhor e mais moderno.

Para que isso não aconteça e para que você possa construir um software alinhado com os objetivos da sua empresa, sem estourar prazos e orçamentos, procure nosso time e vamos colocar em prática tudo que tratamos nessa série de posts. Nossa metodologia funciona não apenas para novas ferramentas, mas para empresas que procuram melhorar seus processos através de um avanço tecnológico. Através da análise do problema, desenvolvimento da solução, métricas, engajamento e um total apoio ao cliente do início ao fim do processo.

Mais alguma dúvida? Vamos continuar o assunto nos comentários abaixo. Participe!


26
Apr 14

Conheça a metologia da Informant! Etapa 3

Metodologia Informant

No terceiro post da série sobre a metodologia de desenvolvimento de software que utilizamos na Informant vamos nos aprofundar na importância do acompanhamento das métricas e de como elas nos guiarão na busca de uma ferramenta muito mais completa e funcional.

Ao longo dos últimos dois posts,  falamos sobre como, em parceira com o cliente, conseguimos identificar o problema do usuário e, baseado nele, projetar um software que entregue a melhor solução dentro do orçamento e prevendo um retorno sobre o investimento. Através de metodologias de design thinking, user experience e desenvolvimento ágil, os sistemas que criamos surpreendem pela rapidez com que são lançados e pela confiabilidade de uso.

Para chegar neste ponto precisamos passar pela terceira etapa do processo com sucesso. Sem boas métricas, análises e acompanhamentos, corremos o risco de construir uma ferramenta pouco útil para o cliente, se transformando em prejuízo para a empresa. Assim, nos próximos parágrafos iremos explicar como as métricas são fundamentais para o desenvolvimento de software. Acompanhe:

A diferença entre métricas e feedbacks

Quando um software é lançado, mesmo em sua fase beta, conseguimos colher um grande volume de dados. Através de ferramentas de análise é possível medir todas as interações do usuário sem afetar a navegação ou a experiência de uso.

Por outro lado, é preciso diferenciar o que é métrica e o que é feedback nesse processo. Métricas são resultados vindos de uma grande porção de interações e servem para dar uma visão geral sobre o desempenho do software. Já feedbacks são gerados por usuários reais e são relevantes para correções pontuais, como uma funcionalidade que não esteja funcionando corretamente.

Ambos são importantes para as melhorias na ferramenta, mas devem fazer parte de estratégias diferentes. Métricas são mais fáceis de serem conseguidas; já feedbacks precisam ser incentivados.

Quais métricas são relevantes?

No meio de tanta informação é preciso saber separar o que é importante medir do que deve ser ignorado. Isso serve tanto para métricas, quanto para feedbacks dos usuários. Se seguirmos todas as métricas podemos cair na tentação de corrigir todos os aspectos do software, perdendo o foco do que realmente interessa: entregar uma solução simples, que resolva o problema do cliente.

Assim, é fundamental estabelecer uma métrica central para o software. Esta pode ser o número de cálculos que ele fará, ou a taxa de conversão de novos usuários. A partir disso é que as melhorias são decididas. Em relação aos feedbacks, não se deve fazer todas as correções e melhorias que os usuários solicitarem, apenas aquelas que se tornarem recorrentes. Ou seja, se algo está incomodando, mais de um usuários irá reclamar. Dessa forma, não perca tempo criando backlogs de reclamações, você saberá exatamente o que precisa ser melhorado no software.

Aprendendo e melhorando

A partir das métricas e feedbacks recebidos, as melhorias são listadas e implementadas. Com um pouco de tração já é possível lançar melhores versões do software em busca de mais usuários. Quando você chegar neste estágio seu software já estará pronto para escalar e se tornar lucrativo, mas isso não significa que nosso trabalho terminou! No próximo post falaremos sobre como a Informant pode te oferecer o combustível que falta para seu software decolar.

Continue acompanhando a série e deixe seu comentário abaixo! Até lá!