Kanban no desenvolvimento ágil de software by Dilbert.

Fonte: Universitários de POA

WORKSHOP - SCRUM

Olá, gostaria de convidá-lo a participar de um evento que vamos ministrar referente a SCRUM.

O treinamento tem como principal propósito, introduzir os profissionais ao mundo dos métodos ágeis e prepará-los para a curva de aprendizado que envolve esse meio. Entender porque os métodos ágeis têm recebido tanto destaque nos últimos anos, e como aplicar de forma prática a teoria em ação.

Durante o curso, os participantes irão entender de forma simples e direta como uma framework pode transformar os resultados de uma empresa, além de aprender como aplicar SCRUM em diversos tipos de projetos independente da segmentação e área de negócio.

Por fim, com este treinamento o aluno terá uma clara percepção da essência dos métodos ágeis: seus valores e princípios.

Inscreva-se: Clique aqui

Papéis no SCRUM.

No Scrum existem 3 papéis principais:

Product Owner

Comumente o cliente ou o gerente de um projeto maior. As suas principais responsabilidades são definir as funcionalidades, os prazos, estabelecer as prioridades de entrega, ajustar prioridades e funcionalidades e, por fim, aceitar o produto entregue.

Scrum Master

Responsável pela aplicação do Scrum na equipe. Remove obstáculos à conclusão dos trabalhos, controla o bom andamento das atividades e acompanha a aplicação das funcionalidades e a qualidade do que está sendo produzido. Atua como ponto de contato entre a equipe, os clientes e a gerência do projeto.

Equipe

Geralmente entre 5 a 10 membros. Inclui perfis multidisciplinares e auto-gerenciáveis (desenvolvedores, designers, testadores, analistas, arquitetos), que atuam em tempo integral no sprint.

O pontapé inicial para a definição de um sprint é o seu planejamento. Itens como capacidade de equipe, o backlog, tecnologia atual e funcionalidades são levadas em consideração por toda a equipe.

Nesse processo, é gerada a priorização do backlog e o plano, as diretrizes de como a equipe irá chegar ao seu objetivo final. O principal artefato gerado por essa etapa é o sprint backlog. Já formatado e com as devidas priorizações, responsáveis, tempos e datas de entrega.

Com o sprint backlog gerado, a equipe já pode começar a trabalhar nos produtos. Diariamente e feita uma reunião informal (preferencialmente com todos de pé) de cerca de 15 a 20 minutos, onde a equipe pode colocar ao Scrum Master os obstáculos que encontraram para a conclusão de suas atividades do dia anterior.

É importante salientar que essa reunião não deve servir para discussão de funcionalidades ou problemas alheios às atividades do dia anterior em si, para não perder sua essência e foco.

O gerenciamento de cada sprint é feito pelos próprios membros da equipe. Qualquer membro dela pode modificar, incluir ou eliminar tarefas e cada um fica responsável por escolher quais tarefas irá executar e atualizar diariamente as horas gastas e a estimativa de horas restantes para conclusão das atividades.

Ao final do sprint é celebrada uma reunião de revisão, onde a equipe apresenta os resulatados obtidos durante o sprint. Nessa reunião, que é informal e sem grandes apresentações, todo o time participa e discute os progressos e os problemas encontrados, onde pode-se planejar de forma mais efetiva para atingir os resultados do próximo sprint.

Fonte: http://webinsider.uol.com.br

Quer aprender mais sobre o tema? Clique aqui

Como lidar com a ausência (indisponibilidade) do Product Owner

Uma questão bastante abordada e discutida quando pensamos em projetos que utilizam do SCRUM como ferramenta de processo, é a ausência (indisponibilidade) do Product Owner. Se levarmos em consideração que PO é o "cara" que melhor conhece o produto, que tem clara a prioridade do que deve ser feito, é a pessoa que demanda as necessidades do negócio, considero natural que esta "entidade" não seja tão acessível quanto pregamos no SCRUM.

Como resolver esta questão?

Abaixo uma matéria escrita por Paulo Rebelo  no site  INFOQ explana um pouco mais sobre o assunto.

Como lidar com a ausência de um Product Owner efetivo

O papel do Product Owner tem grande importância no Scrum, mas muitos dos profissionais que assumem esse papel não possuem o tempo necessário para acompanhar a equipe, não tendo disponibilidade sequer para a evolução do produto da forma que merece. Neste artigo, são exploradas alternativas para tornar mais efetivo o papel do Product Owner. 

Papel e responsabilidades

Em Scrum, lembrando, temos três papéis bem claros: ScrumMaster, Product Owner e membro da Equipe (ou do Time). Nosso foco é no Product Owner, que possui basicamente as seguintes responsabilidades:

• Conceber o produto, escrevendo suas histórias e funcionalidades gerais;
• Priorizar as histórias de mais alto valor;
• Estar disponível para a equipe, ajudando-a a entender os requisitos;
• Aprovar as histórias realizadas pela equipe;
• Definir as necessidades dos usuários;
• Garantir o retorno de investimento para cada funcionalidade entregue;
• Possibilitar que seja feito o mais simples possível, mantendo a funcionalidade necessária.

A efetiva contribuiçāo do Product Owner (PO), como se vê, é um fator chave para o sucesso do projeto. Mas será que os POs possuem a dedicação exigida para a entrega de um produto? Da mesma forma que a equipe e o ScrumMaster, o PO também precisa ter o foco necessário, sendo este um valor importante do Scrum.

É importante que o PO participe das reuniões diárias, e sua presença é obrigatória em Reviews e Plannings (lembrando que Review é a reunião de apresentação do que foi realizado pelo time, e Planning é a reunião de planejamento do que será feito em um determinado ciclo de entrega). 

Recomenda-se ainda que o PO esteja disponível para a equipe, para lidar com eventuais dúvidas e sugestões. Além disso, na reunião de Product Grooming, contamos com o PO para trazer as respostas e os direcionamentos necessários.

No entanto, isso frequentemente não é o que acontece na prática, pois muitos dos Product Owners são extremamente ocupados, não possuindo o tempo para dedicação à equipe e principalmente ao produto. Muitos dos eleitos para a função de PO cuidam de outras atividades, outros produtos, até mesmo gerenciam outras equipes, dentre varias responsabilidades adicionais. Esse acúmulo de funções pode ser enormemente prejudicial para todos os envolvidos no projeto. 

Alternativas

Como lidar com essa situação? Em muitos casos, o que se pode fazer é tratar o PO atribulado como um Business Owner, delegando as tarefas do PO de fato, com o foco no desenvolvimento do produto e na equipe. Saber delegar e confiar no profissional para o qual está passando essa responsabilidade traz retorno para o próprio Business Owner. O PO precisa se conscientizar (ou ser conscientizado) de que não é possível "encaixar" mais um papel em seu dia-a-dia. Deve-se ainda reforçar que esta é uma responsabilidade básica para o Scrum.

É neste último ponto que talvez esteja o problema: será que a implantação do Scrum nas empresas fica realmente clara e transparente para todos? Às vezes, "transformamos" o atual Gerente de Projetos em ScrumMaster, treinamos o time de desenvolvimento em técnicas ágeis, mas e o Product Owner? Não bastaria apenas treinar aquele que hoje responde pelo produto, pois é ele mesmo quem deveria exercer essa função?

Querendo ou não, a denominação de PO do Scrum é confundida por muitos, talvez pela tradução literal da palavra ("dono do produto"). Mas, o fato é que a escolha do PO pode ser decisivo para o sucesso de um projeto. Imagine um PO sem capacidade de determinar o retorno de investimento do seu produto; ou que não saiba o que gera mais valor.

Existem implantações de Scrum, nas quais já participei, em que existia um grupo de Product Owners e um Chief Product Owner (recomendo a leitura do artigo de Roman Pichler que trata do papel de Chief Product Owner). O Chief Product Owner é um profissional responsável por treinar, colaborar e conduzir os Product Owners. Na minha experiência, o modelo funcionou bem, pois os CPOs eram focados na função e por existir essa comunidade, compartilhavam muitas experiências. Os Product Owners faziam a interface com a área de negócio e o dono real do produto era considerado o Business Owner (leia mais sobre o conceito de Business Owner no artigo de Dean Leffingwell).

Outra opção para garantir uma boa condução do produto é a alocação de um analista de negócio. Esta pessoa faz o detalhamento dos épicos, temas e histórias; fica ao lado do time e responde às dúvidas de negócio, viabilizando a geração de valor para o produto, entre outras funções. Mas novamente aqui podemos cair em uma armadilha: o analista não é um Product Owner de fato, e muitas vezes requisitaria certo tempo do verdadeiro Product Owner. Isso porque não teria a mesma autonomia para priorizar ou aceitar as histórias, por exemplo.

O Problema da indisponibilidade

A falta de tempo do PO tende a se tornar um círculo vicioso, que na maioria das vezes acaba sobrecarregando o ScrumMaster. Se o PO não cumpre com a sua função como deveria, o ScrumMaster é quem acaba assumindo grande parte da responsabilidade. Não é raro encontrar um ScrumMaster refinando uma história para o time ou até mesmo criando-a. 

Dito isso, algumas questões vêm à tona: será que foram dadas as condições necessárias para o PO realizar efetivamente o seu trabalho; ou seja, não deveria o PO ser um Business Owner, e permanecer em um papel com menos responsabilidades? Para isso acontecer, no entanto, precisaria ele contratar um PO e delegar essa função, ou deixar a resolução do impasse a cargo de quem implantou o Scrum? 

A Implantação do Scrum nas Empresas 

Toda a culpa parece ficar por conta do Scrum, o que não é verdade. Apesar de ser um framework baseado em princípios simples, o Scrum detém complexidade significativa e sua implantação em empresas exige cuidado e atenção a detalhes. Se a implantação não ocorrer de forma bem planejada, novos problemas surgirão e a impressão do Scrum ficará comprometida. 

Os papéis e as responsabilidades de cada um devem ficar muito claros, não pode haver sobreposição de tarefas (por exemplo, um PO deve se dedicar a essa função). Além disso, treinamentos são necessários para todos, inclusive para os profissionais nas demais funções, que, de uma forma ou de outra, serão afetados pela implantação. E, talvez o mais importante, é a transformação cultural da empresa, e o aprendizado e a adaptação dos profissionais que a compõem.

Conclusões

O papel de Product Owner no Scrum é complexo, envolvendo múltiplas tarefas e responsabilidades. É preciso ter foco no produto a ser entregue e tempo de dedicação. Portanto, a escolha do Product Owner é de vital importância para todos os envolvidos. É o Product Owner quem direciona o produto. Mas se não tem o tempo necessário, e não for possível fazer mudanças na empresa para que o tenha, será melhor considerá-lo como Business Owner e contratar um Product Owner que realize essa função.

Fonte: http://www.infoq.com/br/articles/product-owner-efetivo

Métodos ágeis - JIRA como uma ferramenta de gerenciamento de projetos.

Diferente do modelo tradicional para o controle de projetos, a metodologia ágil exige uma evolução tecnológica das aplicações e ferramentas para o gerenciamento de projetos. Um dos melhores exemplos com o qual atuo é o JIRA - Atlassian.

JIRA é altamente customizável, possuindo inúmeros recursos que ajudam em um projeto de gerenciamento de requisitos.

JIRA para Gerentes de Projeto
 Gerencie todos os seus projetos
 Gerencie muitos componentes em um único local
 Controle as atividades de sua equipe
 Monitore progressos em seus projetos
 Acesso on-line seguro

Gerenciar projetos e componentes
 Rastreie todos os seus projetos
 Gerencie sua lista de to-dos
 Número ilimitado de tarefas e sub-tarefas
 Descrições
 Arquivar anexos
 Mecanismo individual de workflow para: departamento, projeto e tipo de tarefa
 Customização de workflows

Controle as atividades de sua equipe
 Relatórios de monitoramento de tempo
 Road maps
 Painéis com atualizações de status
 Exportação de relatório de dados para Microsoft Word e Excel
 Exportação de relatório de dados como XML e RSS

Monitorar o progresso de seus projetos
 Dashboard para atualizações de status rápido
 Gráficos e relatórios sobre o seu dashboard pessoal
 Relatórios enviados automaticamente
 Atualizações por e-mail

Acesso on-line seguro
 Regimes de segurança granular
 Gerenciamento de segurança em nível empresarial

Time Tracking
 Definir uma estimativa para cada tarefa
 Log de tempo gasto em cada tarefa
 Registro de acompanhamento de tempo para cada fase do projeto
 Acompanhar tarefas de risco em um projeto
 Definir feeds RSS em tarefas de risco

Controle de atividades do projeto

Agilizar tarefas de gerenciamento de projeto
 Mostra a estrutura de hierarquia de issues
 Fornece avançados planners para Gerentes de Projetos
 Gerencie issues de risco em um projeto
 Integre JIRA com MS Project

Link hierarquias entre issues

Gerenciamento de risco/Gerenciamento de Projeto Ágil
 Definição de responsável por drag and drop
 Estimativa de Issue
 Planejamento da Iteração
 Gráfico Burndown
 Relatório sobre o estado da iteração

Vale ressaltar que cada gerente de projeto tem seu estilo e meio de gestão... as aplicações, ferramentas e controles são todos direcionados conforme seu maior conforto e meio de condução.

Em parceria com a ECORE, minha intenção desse post não é "vender" a aplicação, e sim disseminar o conhecimento sobre uma solução completa para a gestão de projetos, não nos limitando apenas ao velho e bom MS Project.

Fonte: http://blog.ecore.com.br