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

Implantando Reuniões Diárias

Oi pessoal,


Em minhas caminhadas nesta estrada de desenvolvimento de software, eu tenho me deparado constantemente com a dificuldade de implantar processos em empresas ou em equipes.

Um dos itens que mais me chamou a atenção na ação de implantação de processos é a dificuldade inicial das pessoas em identificar em que parte do processo elas estão inseridas, e quais processos estavam antes e quais processos serão executados depois de sua atividade.

Para resolver este problema de visualidade eu estou criando fichas para que mostre o processo inteiro, o item do processo que a pessoa esta inserida e a tarefas que ela deve executar.

Este material esta sendo utilizado junto com o Jogo do Scrum, pois o treinamento das equipes esta sendo realizado com ele. Também esta sendo utilizado a figura do processo completo, mas a figura do processo completo é uma imagem padrão da comunidade, para que as equipes com o passar do tempo aprendam a utilizar o processo desenhado em sua forma original.


Abraços a todos,

Abu

Palavras de Ken Schwaber

Palavras de Ken Schwaber escritas no forum "scrumdevelopment"


The belief that a nine women can have a baby in one month. Martin Fowler's statement is "scaling Agile is the last thing you should do."

Agile 2008 Conference, Toronto, August 4-8, 2008

Agile 2008 Conference, Toronto, August 4-8, 2008
CALL FOR PARTICIPATION: LEARNING AND EDUCATION STAGE

SUBMISSIONS WANTED!

What are effective ways to teach and learn Agile practices?

The Learning and Education stage is for industry practitioners and academics to present new ideas in learning and teaching Agile. We invite you to share where you think training and education needs to go in 2008/2009. We are looking for innovation in training, classes that use new techniques, and training that convinces skeptics. Agile drives change in an organization's structure and how work gets executed. Lean shows us where we can make improvements and focuses management effort on the right things. How are you bringing these ideas home with your students?

We invite submissions that address any aspect of teaching and/or learning Agile and Lean practices. Example topics of interest include:

- Agile Training for Teams, creating the team dynamic
- Lean and Agile - integrated learning approaches
- Teaching XP practices to managers (Pairing, TDD) for understanding, collaboration, buy-in
- The Lean and Agile Manager
- Agile Coaching beyond Scrum
- Product Owners and Return on Investment
- Using Agile in the Classroom
- Techniques and Tools to Support Agile Learning
- Using Games to Teach Agile Practices
- Learning to deal with Change
- Speed to market, cycle time, and innovation

We are interested in all aspects of teaching and learning pertaining to any Agile method or practice.

How to submit:

Learning and Education stage submissions may be in the form of experience reports, tutorials, panel discussions, or workshops.

The submitted proposals are reviewed soon after submission in an open review process, and the authors have the opportunity to view all feedback and make updates to their submission prior to close of submissions on February 25.

We advise that submissions be as close to their final form to be presented as possible. This will give the reviewers the best understanding of your presentation.


Presentations should be submitted to: http://submissions.agile2008.org/ Simply set up an account.
You may collaborate on making the conference better by reviewing other conference submissions with this same account.

Note: Academic Educational Research papers should be submitted to the Research Stage for the traditional peer review process.


About Agile 2008

Agile 2008 is the premier conference on the latest thinking in Agile, the fastest growing productivity movement in IT today. Agile 2008 brings together over 1500 executives, managers, software development practitioners, researchers from labs and academia.
We Look Forward To Your Participation!
Sign up today. http://submissions.agile2008.org/

Learning and Education Stage
Brian Hanks, Producer
Robin Dymond, Assistant Producer



--
Robin Dymond
VP, Managing Partner
Innovel, LLC
www.innovel.net
cell: (804) 239-4329

Scrum na Empresa IEA / Knowtec

Oi Pessoal,


É com muita satisfação que apresento as fotos do treinamento de Scrum realizado na empresa IEA / Knowtec (http://www.knowtec.com.br/ - http://www.iea.org.br/). Quero agradecer aos colegas de trabalho que tiveram paciência por ficar 6 horas me escutando, bem como a empresa por permitir esta oportunidade de fala sobre desenvolvimento ágil dentro de suas instalações.

Aos leitores do site que ainda não sabem, eu inicie minhas atividades na empresa Knowtec no dia 07/01/2008.

Abraços a todos,


Abu