Workshop de Product Owner na Knowtec / IEA

Oi pessoal,


Segue a relação de fotos do workshop para Product Owners realizado dentro das empresas IEA / Knowtec.
Neste workshop foi apresentado o papel do Product Owner, as suas responsabilidades e, principalmente, os seus desafios.
A sala ficou cheia!
Podemos dizer, com toda certeza, que nós (Equipe de TI) somos privilegiados, pela quantidade de Product Owners atuando ativamente em nossos projetos e pela alta qualidade desses profissionais.

Abraços a todos,


Abu

Modelagem Ágil

Oi pessoal,


Em vários textos de desenvolvimento ágil sempre encontramos referencias a não gastar muito tempo criando documentos “bonitinhos” para modelagem do sistema, onde estes textos sempre falam de arquiteturas feitas em guardanapo, papel de pão, ou qualquer outro tipo de forma de representação e armazenamento de uma informação.

Aqui nesta postagem do Blog eu estou seguindo as orientações dos nossos GURUS, onde em uma reunião entre todos os integrantes da equipe de desenvolvimento (porquinhos) nos encontramos uma arquitetura simples para o projeto.

Esta arquitetura já foi idealizada para poder ser expandida e receber no futuro alguns recursos que no momento não estamos utilizando, como por exemplo o conceito de DOMINIO e JPA (tecnologia Java).

O mais importante foi que não gastamos um tempo elevado modelando e definindo em ferramentas gráficas e sim o papel, que permitiu uma técnica rápida de desenho e remodelagem do desenho, conforme a equipe amadurecia as idéias de como a arquitetura iria resolver o problema de negocio.

Também não foi idealizado uma arquitetura ideal, onde nos montamos uma arquitetura mais simples, para podermos dar inicio ao projeto e podermos evoluir a arquitetura conforme o amadurecimento do projeto. Desta maneira não gastamos um tempo excessivo com funcionalidades e necessidades que ainda não sabemos se serão necessárias.

Neste exercício o grande beneficio foi a integração da equipe no processo de definição da arquitetura do sistema, a visibilidade dos desenvolvedores do que foi definido e principalmente o comprometimento com a entrega, onde nos estamos atendendo com a nossa arquitetura as necessidades do produto, sem colocarmos gordurinhas Tecnológicas desnecessárias para o projeto.

Eu gosto muito de uma frase do livro Caindo na Real: “Crie uma grande aplicação e depois se preocupe com o que fazer quando ela se tornar animalmente bem-sucedida”.

Mas a nossa modelagem não vai ficar assim no papel, com o tempo oportuno ela será colocada em nosso WIKI do projeto, por intermédio de fotos, onde poderemos ate mesmo acompanhar o seu amadurecimento pela seqüência de fotos da evolução da arquitetura.

Se for necessário, isto é, realmente agregar valor ao produto ela será colocada em uma ferramenta de modelagem de UML.


Abraço a todos,


Abu



1 - Estrutura de Paginas (Templates)




2 - Funcionamento da Camada de View e o Controlador de Tela



3 - Modelo MVC





4 - Foto do Quadro Inteiro


5 - Tem que ser feito TDD TDD TDD TDD hahahahahaha

Definindo o Tamanho do Item de Backlog

Oi pessoal,


Este parte do processo é uma das mais difíceis, pois ela quebra o paradigma de pensarmos em “tempo” de termino da tarefa, ou “duração” da tarefa e passamos a utilizar o TAMANHO da tarefa como referencia de estimativa.

O primeiro passo é olhar os Itens de Backlog do inicio do projeto, montando uma visão de escopo e identificar o item que tem o menor tamanho, para que ele receba o valor de 2 pontos.

O próximo passo é analisarmos os demais Itens do Backlog e comparar o tamanho dele com o item de referencia (o de 2 pontos). Desta maneira cada Item de Backlog passa a receber o seu tamanho sempre em correlação ao item identificado com 2 pontos.

Este trabalho é feito com a equipe e o Product Owner, onde a equipe fica com a responsabilidade de identificar o tamanho da tarefa e o dono do produto fica responsável de tirar as duvidas em relação a tarefa que esta sendo estimada.

A ficha adicionada ao blog tem o objetivo de orientar a execução da tarefa.

Vamos analisar esta ficha e identificar o seu resultado, ate o momento as fichas de Reunião Diárias e de Planejamento da Sprint estão funcionando bem.

Abraços a todos,


Abu

Implantando Planejamento do Sprint

Oi pessoal,

Trago para vocês mais uma ficha de auxilio a implantação do processo do Scrum. Nesta ficha representamos os itens de atenção de uma preparação de Sprint.
A continuidade desde tipo de metodologia de implantação do processo vem dos bons resultados alcançados com a ficha de “Reuniões Diárias”, já colocadas no blog.

Eu tenho observado que na primeira vez que se executa um item do processo ele não saí a contento, mesmo com a utilização da ficha. Porem após a execução do item do processo junto com a correção dos pontos errados, o erro tem diminuído de maneira significativa.

Abraços a todos,


Abu

Certificado Scrum Master do ABU

Oi pessoal,

Eu recebi o Certificado Scrum Máster emitido pela ScrumAlliance (http://www.scrumalliance.org/).


Abraço a todos,

Abu

Nosso amigo e parceiro Product Owner

Chamados de analista de negocio, cliente, dono do produto, entre outras definições é o que nos chamamos em Scrum de Product Owner.

Em Scrum, “Product Owner Role” é a pessoa que representa o interesse do cliente.

Nesta responsabilidade ele tem a responsabilidade de priorizar o “Backlog” e de atender a equipe de desenvolvimento do projeto.

Esta pessoa deve estar disponível à equipe em qualquer momento, mas especialmente durante a reunião de planejamento do Sprint e a reunião da revisão do Sprint.

Não vou entrar nas técnicas de idealização de um produto, ate mesmo porque me falta experiência nesta área. Mas independente da maneira que o produto foi idealizado pelo Product Owner é a responsabilidade dele fazer com que o TIME que vai desenvolver o produto entenda todos os itens, isto, itens de backlog.

O Product Owner tem que determinar a abrangência do escopo do projeto, garantir que o entendimento deste escopo seja realizado, que este escopo seja entregue.

Ele deve realizar a priorização dos itens de backlog, para que o TIME possa entregar produtos seguindo este priorização. Num projeto nem sempre pode ser entregue vários itens ao mesmo tempo e neste caso se podemos ter apenas o item A ou B, o Product Owner que determina o que vai ser entregue primeiro, A ou B.

O Product Owner tem que determinar o que faz parte de uma versão usável para o cliente, isto é, um release. Neste caso ele determina quais itens de backlog deve ser implementados para que um conjunto de código possa ser definido como uma “release”

As datas de liberação de “releases” também são determinas pelo Product Owner, pois é ele que sabe quando estas datas são importantes para o cliente.

Podemos determinar que os desafios de um “Product Owner” são:

1 – Resistir a tentação de controlar a equipe. As equipes são auto-organizadas e nem sempre a organização das equipes vão ser da maneira que o “Product Owner” gostaria.
2 – Resistir a tentação de adicionar mais funcionalidades a um Sprint já iniciado.
3 – Fazer escolhas das tarefas que devem ser executadas em uma reunião de planejamento do Sprint.

E as responsabilidades do Product Owner são:

1 - Definir as funcionalidades do produto
2 – Decide datas de lançamento de conteúdo
3 – Responsável pela rentabilidade (ROI)
4 – Prioriza funcionalidades de acordo com o valor de mercado
5 – Ajustar funcionalidades e prioridades
6 – Aceitar ou rejeita o resultado dos trabalhos

Abraços a todos,

Abu

Classificação de Itens de Backlog

Oi pessoal,


Olhe que fantástico a classificação de priorização de requisitos que eu recebi de um colega:

(1) Tem que ser feito na primeira versão
(2) Seria bom se fosse realizado, mas pode ser retirado
(3) Realizar se houver tempo
(4) Versões futuras


Estes itens fazem exatamente a mesma coisa que a nossa classificação com Must, Should, Could e Want.

O incrível é que o produto veio com estas classificações, mostrando o comprometimento da equipe de negócios com o recebimento de um produto dentro do prazo, custos e qualidade que ele julgam importante.

A equipe de produto realmente esta realizando umas das atribuições do Product Owner, que é garantir o ROI (Retorno de Investimento).


Abraços a todos

Abu