Conheça a Informant          RSS

Posts Tagged: metodologia ágil


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.


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!


29
Oct 13

Software ágil os 7 princípios do desenvolvimento – Princípio 01

softwareHoje damos inicio a uma série de posts sobre os princípios do desenvolvimento ágil de software. Tendo como maior benefício a flexibilidade durante as etapas de execução do projeto, a metodologia vem ganhando cada vez mais espaço entre os desenvolvedores.

O método surgiu quando especialistas reuniram, em um manifesto publicado em 2001, uma série de princípios comuns ao desenvolvimento ágil. As principais características são o foco em pessoas e suas interações ao longo do projeto, a colaboração contínua do cliente e as respostas rápidas para as mudanças ocorridas.

Uma das filosofias do desenvolvimento ágil é o Lean Thinking, que é a eliminação de todo o trabalho desnecessário durante o projeto, por meio de esforços reduzidos no menor tempo possível e, ainda assim, realizando entregas de valor e com a máxima qualidade para o cliente.

Dentro da filosofia do Lean Thinking, hoje vamos abordar o primeiro princípio do desenvolvimento ágil de software, que é a eliminação de desperdícios.

Princípio 1 – Eliminar desperdícios

No desenvolvimento de softwares, desperdício é tudo aquilo que, embora esteja no projeto, não agrega qualquer valor ao produto final ou para o cliente. Esses desperdícios podem ser facilmente identificáveis pela equipe, mas muitas vezes não são tão nítidos, consumindo tempo e recursos preciosos.

A própria essência da metodologia ágil pressupõe alguns desperdícios ao longo do percurso. Isto porque o desenvolvimento é feito com mudanças e aprendizados a cada ciclo, fazendo com que algumas tarefas não sejam aproveitadas.

No entanto, quanto menor o desperdício, maior será o retorno do projeto para o desenvolvedor e o cliente. Por isso, é fundamental saber qual seu principal causador para que possa ser minimizado:

Trabalho incompleto

Toda tarefa iniciada que não é finalizada poderá gerar desperdícios mais adiante. O excesso de documentação no início do projeto, por exemplo, pode gerar desperdícios por se tornar rapidamente obsoleta. Quando os requisitos são detalhados e especificados excessivamente e muito antes do desenvolvimento, eles podem perder sua credibilidade e jamais serem efetivamente consultados.

Outras fontes que geram trabalhos incompletos e desperdícios posteriormente são os códigos não testados, não sincronizados e não documentados.

Excesso de funcionalidades

Alguns projetos de desenvolvimento de software podem trazer funcionalidades desnecessárias que também serão desperdiçadas.

Isso pode acontecer quando o cliente especifica uma necessidade que não se concretiza ou quando o desenvolvedor inclui uma aplicação não descrita apenas para melhorar o produto final ou evitar inclusões mais adiante. Outro cenário possível é quando cliente e desenvolvedor incluem uma funcionalidade em comum acordo e só percebem que era supérflua posteriormente.

Reaprendizado

O aprendizado é um processo importante que ocorre em todas as etapas do processo de desenvolvimento de um software, especialmente na metodologia ágil. O problema é quando esse aprendizado não é absorvido e a equipe precisa reaprender algo que já havia sido apresentado anteriormente.

Esse desperdício pode ocorrer, por exemplo, quando desenvolvedores fazem correções no código e não registram a solução encontrada para utilização posterior. Códigos mal escritos e documentados também costumam causar o reaprendizado, pois nessas situações o comportamento e objetivo das aplicações não ficam claros.

Entregas

A hora de passar o bastão para outro profissional da equipe continuar uma tarefa é um terreno fértil para os ruídos de comunicação e, consequentemente, o surgimento de desperdícios. Nesse momento, as informações passadas podem não ser suficientes ou então difíceis de serem descritas por email e outros documentos.

Para resolver esses problemas, é fundamental que o projeto conte com uma documentação simples e enxuta e, além disso, estimule o uso da comunicação face a face, a realização de chamadas de vídeo ou áudio e a organização de reuniões.

Atrasos e espera

Qualquer atraso na entrega de uma das etapas do desenvolvimento do software pode gerar aumentos consideráveis de custo e prazo, gerando desperdícios ao longo do processo.

Uma armadilha comum é quando os fluxos de aprovação e revisão são morosos, criando obstáculos e acumulando tarefas para o restante do projeto. Uma equipe em standby aguardando aprovações ou outras entregas pode gerar os maiores desperdícios no desenvolvimento de um programa.

Falhas

Evitar falhas é fundamental para minimizar desperdícios. Em vez de procurar e corrigi-las no código, o melhor a ser fazer é utilizar o tempo disponível do projeto para prevenir os erros.

A utilização de metodologias de design de softwares orientadas a testes é primordial para que os códigos tenham a qualidade esperada por seus clientes e não gerem perdas ao longo do projeto.

Sua equipe já trabalha com desenvolvimento ágil? Fique ligado, no próximo post apresentaremos o segundo princípio, a ampliação do aprendizado. Até lá!


28
Aug 10

Metodologia Ágil de Desenvolvimento: além dos sprints e post-its

Nesta última quinta-feira a Informant, representada pelo Eduardo Kruger, participou da semana da computação na Sociesc.

Kruger além de compartilhar um pouco da sua experiência com metodologias ágeis de desenvolvimento, comentou sobre o que estamos fazendo aqui na Informant e quais serão os nossos próximos passos em termos de metodologia.

Confira a palestra na Integra:


25
Aug 10

Informant apoia semana da computação da Sociesc

Metdologia Ágil de Desenvolvimento: além dos sprints e post-its: Este será o tema da palestra ministrada pelo Informmant Eduardo Kruger, que irá compartilhar um pouco da sua experiência com desenvolvimento ágil de software.

Outro objetivo da palestra é demonstrar o que estamos fazendo aqui na Informant e quais serão nossos próximos passos em termos de metodologia.

A palestra acontecerá no dia 26/08 na Sociesc em Joinville às 19:00.  A Sociedade Educacional de Santa Catarina-SOCIESC é uma instituição educacional, cultural e tecnológica, presente em Joinville, Blumenau, São Bento do Sul, Balneário Camboriú, Florianópolis, em SC, e Curitiba no PR. Atua no ensino fundamental, fundamental bilíngue, médio, técnico, graduação, pós-graduação lato sensu e stricto sensu, (especializações em MBA e mestrados reconhecidos pela CAPES) cursos de extensão e capacitação empresarial, também atua na modalidade do ensino  a distância.

Para saber mais detalhes sobre o evento acesse:  Semana da Computação Sociesc