Conheça a Informant          RSS

Posts Tagged: desenvolvimento


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!


25
Mar 14

As 12 práticas do XP – 2/3

XP

Hoje continuamos nossa série sobre as 12 práticas do Extreme Programming (XP) no blog da Informant! No primeiro post, abordamos as quatro primeiras técnicas da metodologia: jogo de planejamento, desenvolvimento orientado a testes, programação em pares e equipe.

Agora é hora de seguir em frente e falar sobre outras quatro práticas que fazem com que o XP seja um método de desenvolvimento de softwares extremamente adaptável a mudanças de cenário e possibilite entregas de qualidade com baixos custos. Confira:

Integração contínua

A quinta prática do Extreme Programming consiste em criar um sistema formal ou informal de comunicação por meio do qual todos os desenvolvedores possam ser informados sobre modificações realizadas no código por seus colegas.

Tendo em vista que o XP pressupõe ciclos pequenos de iteração e um ambiente com mudanças constantes, essa prática contribui para que os programadores estejam em integração contínua, se tornando capazes de fazer melhorias nas aplicações de forma mais informada e eficiente.

Melhoria do código

Essa prática do Extreme Programming significa que, durante o desenvolvimento do software, os programadores deverão reestruturar o código sempre que necessário, sem alterar seu comportamento externo, ou seja, a forma como se apresenta para o usuário.

Após uma aplicação passar em um teste, os desenvolvedores já podem refinar o código quando julgarem necessário, lembrando de não mudar a lógica por trás da funcionalidade para evitar problemas de leitura ou integração mais adiante.

Esse refinamento do código é feito para melhorar a leitura pelas máquinas, assim como reduzir a complexidade da programação, o que contribui para uma manutenção mais simples.

Simplicidade

O design simples de software, mais uma das práticas do XP, pressupõe que nenhuma linha de código será escrita caso não tenha um valor real para o sistema e seus usuários.

A máxima dessa prática é que o melhor design é o design funcional. Em um projeto típico que utiliza o método XP, o desenvolvimento deve passar pelos testes da forma mais simples possível, atender aos requisitos e não apresentar redundâncias.

Após escrever uma linha de código, o programador deve sempre se perguntar se existe alguma forma mais simples e fácil de descrever o mesmo procedimento. Caso exista, ele deverá refiná-lo.

Entregas pequenas

A última prática do Extreme Programming que abordaremos no post de hoje é também uma das mais importantes: as entregas pequenas.

Por meio de pequenos ciclos de iteração, os projetos de software dentro do método XP sempre apresentarão entregas menores e constantes, sendo cada uma delas com funcionalidades bem específicas.

Essa prática é uma das grandes diferenças do Extreme Programming quando comparado a programas desenvolvidos em métodos mais tradicionais, em que o cliente, de forma geral, só entra em contato com o software quando um grande número de aplicações já foram finalizadas e entregues.

As entregas pequenas garantem maior agilidade ao processo de desenvolvimento, permitindo que o usuário utilize o sistema logo no início, estimulando a colaboração e os ajustes no código em uma fase mais adequada do projeto.

Nó próximo post, mostraremos a terceira, e última parte sobre XP. Não perca!


24
Mar 14

As 12 práticas do Extreme Programming – 1/3

 

extreme programming

O Extreme Programming (XP) é um dos métodos ágeis de desenvolvimento de software que tem ganhado cada vez mais atenção de programadores em todo o mundo em função de sua alta capacidade de adaptação a mudanças nos requisitos e as entregas de qualidade, tudo isso com times pequenos e baixos custos.

 O motivo para tantas vantagens é, basicamente, a adoção de 12 práticas pelos desenvolvedores durante o projeto.

A partir de hoje, vamos publicar em nosso blog uma série de três posts sobre o XP. Na primeira postagem, vamos falar sobre as quatro primeiras práticas do método. Acompanhe!

 Jogo do planejamento

Essa prática se refere à organização de reuniões periódicas, que ocorrem a cada ciclo de iteração, para guiar a equipe até a entrega final. Essa abordagem evita um planejamento extenso e rígido no início do projeto, permitindo que cliente e programadores estejam mais confortáveis para fazer possíveis correções de rota durante o desenvolvimento.

Nos encontros, é realizado o planejamento das próximas entregas, definindo-se quais aplicações deverão ser finalizadas e quando serão entregues. Além disso, os desenvolvedores listam as tarefas que precisão executar para conseguir finalizar o trabalho a cada ciclo.

Esse jogo com rodadas de planejamento permite que o cliente defina de forma sucinta o requisito de cada uma das aplicações, atribuindo prioridades a cada uma delas. Além disso, a prática facilita a estimativa de custos e o gerenciamento do projeto como um todo.

 Desenvolvimento orientado a testes

A segunda prática do XP pressupõe que o código seja testado constantemente, enquanto está sendo escrito, e não somente após o término do desenvolvimento. O processo a ser seguido é: escrever o teste, desenvolver um código mínimo suficiente para passar no teste e depois terminá-lo com os ajustes necessários.

A adoção dessa prática faz com que o software seja desenvolvido de forma mais limpa e organizada, pois as partes desnecessárias do código podem ser descartadas a cada iteração e não somente no fim do projeto.

 Programação em pares

A programação em pares se refere à estratégia de alocar dois desenvolvedores para trabalhar em uma mesma aplicação, ao mesmo tempo e em uma só máquina. Dessa forma, um dos profissionais fica responsável por escrever o código, enquanto o outro assume o papel de observador, revendo cada linha à medida que o trabalho vai sendo desenvolvido.

A expectativa é que cada um dos programadores concentre seus esforços em aspectos diferentes da funcionalidade, permitindo o desenvolvimento de um código de qualidade, menos propenso a falhas e com um custo total mais baixo que métodos mais tradicionais. Nessa prática, os papéis exercidos pelos desenvolvedores também são trocados frequentemente.

 Equipe

A última prática que abordaremos hoje em nossa série estabelece que, no Extreme Programming, todos os profissionais envolvidos no projeto sejam parte integrante do time, favorecendo uma maior integração entre cliente, gestores e desenvolvedores.

Nessa abordagem, o consumidor não se restringe apenas ao papel de contratante, mas atua como o usuário do sistema interessado em sua usabilidade, fazendo-se disponível a qualquer momento para solucionar dúvidas em relação ao desenvolvimento do software.

No XP, um membro qualquer do projeto pode assumir mais de um papel ao longo do desenvolvimento, o que estimula a colaboração e o trabalho em equipe.

 

Você já adota o XP na sua rotina profissional? Se interessou pelo assunto? Fique ligado, no próximo post, traremos a segunda parte desta série!

 


10
Mar 14

Quais são as novas linguagens de programação que você deveria aprender?

A maioria dos desenvolvedores de software no mercado está habituada à utilização das linguagens de programação mais tradicionais, como Java e C. No entanto, nos últimos anos, muitos profissionais já vêm se atentando para a importância de aprender novas linguagens e se tornarem programadores poliglotas.

Ao explorar diversas linguagens de programação, os desenvolvedores podem encontrar novas formas de solucionar problemas nos códigos, ampliar o leque de conhecimento sobre o desenvolvimento de software e aproveitar mais oportunidades no mercado de trabalho.

Por isto, separamos três novas linguagems, pra se ficar de olho e começar a aprender. Veja nossa lista:

Harlan

A Harlan é uma linguagem de programação que tem como principal objetivo simplificar o desenvolvimento de aplicativos que são executados na unidade de processamento gráfico (GPU). Ao contrário do que muitos pensam, a GPU não serve apenas para processar imagens, mas é capaz de fazer determinados tipos de cálculo com grande eficiência.

As GPUs possuem a capacidade de guardar múltiplos cálculos de forma simultânea (os chamados threads) enquanto os CPUs só fazem um por vez. O contraponto é que as GPUs fazem essa tarefa de forma lenta, tendo sua utilização até então restrita ao processamento gráfico.

O Harlam visa tirar proveito da capacidade de processamento simultâneo da GPU de forma mais ágil. Realizando várias tarefas ao mesmo tempo, o potencial do hardware aumenta substancialmente. Essa característica pode transformar computadores simples em processadores extremamente robustos.

A linguagem de programação Harlan tem sua sintaxe em Scheme, que é considerada a origem de todas as linguagens utilizadas em larga escala nos dias de hoje.

Julia

A linguagem de programação Julia, disponível para Windows, OS X e Ubuntu, foi concebida com a ambiciosa missão de reunir todas as virtudes das demais linguagens em um só lugar. Julia atende aos requisitos da computação numérica e científica de alta performance, apesar de já estar sendo utilizada para outros propósitos.

Lançada em 2012, a linguagem permite a compilação de programas de forma mais ágil, evitando a necessidade de conversão para códigos como Java ou C. A Julia possui virtudes como velocidade, dinamismo, notações matemáticas familiares e funcionais, entre outras vantagens.

A linguagem também permite que, ao desenvolver um sistema, o programador utilize o recurso do paralelismo, ou seja, dividir um problema em várias partes e distribuí-los entre vários computadores, contribuindo para uma análise de dados mais ágil e eficiente.

Os usos mais comuns são na programação de sistemas para a web e uso técnico que requer alta performance, como em pesquisas científicas. Apesar disso, a linguagem não é recomendada para o desenvolvimento de aplicativos de desktop ou sistemas operacionais.

Go

A Go, também chamada de GoLang, é a linguagem de programação da Google. Lançada em 2009, como open source, a Go foi adotada em grandes projetos recentemente, inclusive pela própria Google, e passou a receber mais atenção do mercado e dos desenvolvedores.

A linguagem pode servir como alternativa para outras já populares, como Ruby e Java. Seus principais benefícios são performance otimizada do software, uso eficiente da memória, qualidade dos códigos e a facilidade de utilização pelos programadores.

Inicialmente, o Google lançou a linguagem para uso no desenvolvimento de  sistemas. No entanto, sua ampla utilização pela comunidade de desenvolvedores fez com que a linguagem pasasse a ser utilizada para vários outros propósitos.

Você já possui familiaridade com estas linguagens? Há alguma outra nova linguagem que quer acrescentar à lista? Deixe seu comentário!

 


10
Jan 14

Criar o seu próprio CRM, vale a pena?

As vantagens que um CRM pode proporcionar à uma organização vão desde o relacionamento mais próximo com seus clientes, até o desenvolvimento de estratégias eficazes de vendas, marketing e atendimento.

No entanto, algumas empresas que optam por usar a ferramenta ainda encontram dificuldades para escolher a opção mais adequada à sua realidade. É melhor desenvolver um CRM próprio ou contratar um software pronto disponível no mercado?

A decisão depende de características específicas de cada empresa e o uso que a equipe irá fazer do sistema. Uma escolha acertada pode significar menos falhas e maior produtividade. Além das necessidades imediatas, também é preciso se preocupar com o longo prazo e as possibilidades de expansão das operações e dos negócios.

Saiba identificar se a criação de um CRM próprio vale à pena.

Personalização

O principal benefício do desenvolvimento de um CRM próprio é que a empresa pode definir exatamente como as funcionalidades do sistema deverão se comportar para atender às necessidades do negócio.

Quando a organização possui demandas muito especificas para o CRM, implantar uma ferramenta própria é a melhor opção. Isso coloca à disposição da empresa as aplicações ideais para ela. Alguns softwares disponíveis no mercado também oferecem opções de customização para os clientes, mas essa flexibilidade não se compara a de um CRM desenvolvido internamente.

Controle

Muitas empresas fazem questão de ter controle absoluto sobre as ferramentas que utilizam e a autonomia para modificá-las sempre que necessário. Com um CRM próprio, o cliente se torna o proprietário do produto. Isso lhe permite fazer alterações no código quando for pertinente, sem precisar aguardar por atualizações periódicas do fornecedor.

Suporte

Para desenvolver um CRM customizado, será necessário contratar uma equipe de TI ou um fornecedor especializado. Além de entregar o produto final, esses profissionais também serão responsáveis por oferecer o suporte e atendimento.

Dessa forma, ao invés de precisar lidar com centrais de atendimento padrão de grandes fornecedores, a sua empresa irá contar com o apoio de um parceiro próximo, que está mais propenso a entender as especificidades do seu negócio.

Além disso, a equipe que presta o suporte pode ter acompanhado o desenvolvimento do software. Isso faz com que os profissionais entendam os problemas do sistema de forma rápida, precisando de menos tempo para solucioná-los.

Economia

Um CRM de prateleira pode trazer muitas ferramentas desnecessárias para a realidade da sua empresa. Isso faz com que seu uso seja mais complexo, pois o sistema terá mais telas e campos de preenchimento na navegação.

Quando o CRM é projetado para sua organização, todas as aplicações e funcionalidades terão um motivo para estarem ali. Isso evita gastos desnecessários e organiza a interface para o usuário.

Integração

As informações sobre os clientes que compõem um CRM podem ter origem em sistemas e documentos espalhados por diversos setores da empresa.

Um software próprio também traz a vantagem de unificar os bancos de dados com informações dos consumidores. Durante o desenvolvimento do programa, a empresa irá prever o sistema com as diversas fontes de informações, reduzindo problemas de integração.

Produtividade

O CRM próprio também pode atender de forma customizada à maneira como os funcionários se organizam no trabalho. Tarefas mais comuns ficam em locais de fácil acesso. Informações importantes estarão disponíveis somente para quem precisa acessá-las, sem que seja preciso pedir por autorizações. Esse tipo de organização confere agilidade para o negócio.

Pontos de atenção

Apesar das vantagens acima, desenvolver um CRM próprio pode não ser a solução ideal para qualquer organização.

A empresa interessada na solução deve estar ciente do tempo e esforço necessários para a implantação. A importância de manter a ferramenta sempre atualizada para que ela realmente traga os benefícios esperados também é um ponto que requer muita atenção.