sexta-feira, 21 de novembro de 2008

Implementando Cartões de Historias Priorizados pelo Product Owner

Uma das técnicas de se garantir o retorno de Investimento do cliente é implementar Itens de Backlog priorizados pelo cliente. Esta ação também permite com que os riscos de cancelamento do projeto fiquem diminuídos, pois o cliente passa a receber em primeiro lugar o que ele considera importante.

Mas nem sempre o item priorizado pelo Product Owner é na visão da equipe de TI o primeiro a ser implementado. Este conflito de interesses pode ser um problema para o Scrum Máster, mas eu sempre faço a observação:

Engenharia de Software é diferente de Engenharia Civil.


Se o cliente deseja um Item de Backlog que não possui os seus predecessores construídos não tem problema para o mundo virtual, nos em TI podemos criar estes predecessores de maneira que eles possam atender o Item de Backlog que o cliente deseja.

Vamos a um exemplo, o cliente considera em um sistema de venda de livros pela internet os comentários existentes a um livro mais importante que o cadastro de livro, isto é, ele deseja ver primeiro como será a solução dos comentários de um livro e após esta solução trabalhar com o cadastro do livro.

Este é um apenas um exemplo e é neste exemplo é que vamos mostrar como fazer a solução utilizando TDD e a implementação do item priorizado pelo cliente.

[Exemplo 4] – [Cartão de Historia]

Como um cliente, quero ter os comentários referentes aos livros consultados, para que eu possa saber a opinião de quem já leu

[Testes] - Template: [ação] [resultado] [objeto]

Mostrar comentário realizado para livro
Mostrar mais de um comentário realizado para o livro
Mostrar inexistência de comentário para um livro
Visualizar marcador de mais comentários que o valor maximo permitido para visualização para o livro


[1]
Temos que criar os models de livro e comentários. O livro não é a prioridade, mas para podermos realizar o item de backlog ele se faz necessário.

ruby script/generate model livro

exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/livro.rb
create test/unit/livro_test.rb
create test/fixtures/livros.yml
exists db/migrate
create db/migrate/002_create_livros.rb

ruby script/generate model comentario

exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/comentario.rb
create test/unit/comentario_test.rb
create test/fixtures/comentarios.yml
exists db/migrate
create db/migrate/003_create_comentarios.rb

[2]
O próximo passo é criarmos os registros necessários para atender os nossos testes, para que isso seja possível devemos alimentar as estruturas de Fixtures

Lembrando os nossos testes....

1) Mostrar comentário realizado para livro
2) Mostrar mais de um comentário realizado para o livro
3) Mostrar inexistência de comentário para um livro
4) Visualizar marcador de mais comentários que o valor maximo permitido para visualização para o livro

Livros.yml

one:
id: 1
nome: Ruby OnRails

two:
id: 2
nome: Java

three:
id: 3
nome: Lean Solutions

four:
id: 4
nome: Livro sem comentario

Comentários.yml

one:
id: 1
livro_id: 1
comentario: xxxxx xxxxx

two:
id: 2
livro_id: 2
comentario: xxxxx xxxxx

three:
id: 3
livro_id: 2
comentario: yyyyy xxxxx

four:
id: 4
livro_id: 3
comentario: xxxx1 xxxxx

five:
id: 5
livro_id: 3
comentario: xxxx2 xxxxx

six:
id: 6
livro_id: 3
comentario: xxxx3 xxxxx

seven:
id: 7
livro_id: 3
comentario: xxxx4 xxxxx

eight:
id: 8
livro_id: 3
comentario: xxxx5 xxxxx

nine:
id: 9
livro_id: 3
comentario: xxxx6 xxxxx

ten:
id: 10
livro_id: 3
comentario: xxxx7 xxxxx


[3]
Massa de dados X Testes

1) Mostrar comentário realizado para livro

Para atender esta necessidade foi criado os registros necessários para o cadastro de livros

2) Mostrar mais de um comentário realizado para o livro

Para atender esta necessidade foi criado os registros necessários para que um livro tenha apenas um comentário, não tenha comentário e que tenha uma quantidade grandes de comentários

3) Mostrar inexistência de comentário para um livro

Para atender esta necessidade foi criado um registro de livro que não vai ter comentários

4) Visualizar marcador de mais comentários que o valor maximo permitido para visualização para o livro

Para atender esta necessidade foi criado uma quantidade de comentários para um livro, porem não temos em nenhum lugar a informação que determina o valor maximo permitido de visualização. Nos podemos resolver este item de parametrização por uma estrutura de cadastros de parâmetros ou por uma constante. Vamos manter o foco no problema que é os comentários dos livros e não um Cartão de Historia que trate de Parametrização e criarmos uma constante.

Em momento adequado esta constante é retirada e passamos a implementar o Cartão de Historia referente a Parametrização.

[4]
Podemos observar que a massa de dados necessária para a implementação dos testes nos ajudou a criamos um modelo de dados e um modelo de objetos.

[5]
Vamos criar a estrutura de testes do model de comentário

#Mostrar comentário realizado para livro
def test_mostra_comentario
assert true
end

#Mostrar mais de um comentário realizado para o livro
def test_mostra_varios_comentarios
assert true
end

#Mostrar inexistência de comentário para um livro
def test_livro_sem_comentario
assert true
end

#Visualizar marcador de mais comentários que o valor maximo permitido para visualização para o livro
def test_visualiza_marcador_comentario
assert true
end

[6]
Agora passamos a implementar o model para que os testes sejam atendidos

“Não vamos colocar aqui no post o model implementado, não é o objetivo do post.”


[7]
Podemos observar que o item de backlog priorizado pelo cliente foi possível de ser implementado, para esta implementação foi necessário atacarmos predecessores, como o cadastro do livro e a parametrização da quantidade de comentários a serem mostrados.

Mas devemos gastar energia apenas na implementação do nosso foco, “Comentários em Livros” e não nos predecessores. Os predecessores devem ser implementados ate o limite do atendimento do Item de Backlog que é nosso foco.

Nos sabemos que teremos que refazer partes do código dos itens predecessores quando for a vez deles de ser priorizado pelo cliente, mas com esta técnica nos estamos atacando o que é importante para o cliente e ao mesmo tempo realizando analise de sistemas para identificar requisitos correlacionados ao requisitos que estamos trabalhando.

Estes requisitos correlacionados vão sendo evoluídos com a implementação do nosso foco e implementados de maneira mais consistente no momento que o cliente deseja.


Este post foi longo, abraços a todos,


Abu

Nenhum comentário: