Framework do Scrum (Balsamiq Mockups)

Oi pessoal,

Eu desenhei o Framework do Scrum com um software muito divertido chamado Balsamiq Mockups (http://www.balsamiq.com/products/mockups)


Abraço a todos,

Abu

Curso Potencializando Scrum com o Product Owner

Potencializando Scrum com o Product Owner

Scrum é um processo de gerenciamento de projetos ágeis, onde uma das suas principais características é a entrega de produtos em períodos de tempo pré-estabelecidos, nunca inferiores há uma semana ou superiores há trinta dias. As entregas periódicas de funcionalidades desenvolvidas e prontas para serem utilizadas ao “Dono do Produto”, chamado em Scrum de Product Owner permite identificarmos se estamos no caminho certo ou não no nosso projeto, onde a melhor maneira de comprovar se o software atende às necessidades é fazer com que o Product Owner o utilize, apontando as qualidades e o que falta ser aperfeiçoado.

O Product Owner no processo Scrum possui responsabilidades durante todo o ciclo de vida do projeto e uma das suas atribuições é participar ativamente no projeto junto com a equipe de desenvolvimento. Está participação ativa do Product Owner no projeto é um dos segredos do sucesso do Scrum. Também faz parte das atribuições do Product Owner a definição de funcionalidades do produto, decisão quanto às datas de lançamento de conteúdo e ajuste de funcionalidades.

O que você vai aprender:

Como escrever e manter um Product Backlog
Técnicas de Priorização de Product Backlog
Como utilizar a velocidade da equipe de desenvolvimento do projeto para prever as datas de entregas de funcionalidades do projeto
Leitura de gráficos de acompanhamento da execução do projeto
Dinâmicas que permitem o aprendizado do conteúdo

Agenda
1 - Scrum
O que é Scrum?
Papeis e Responsabilidades

2 - Visão do Projeto

3 - Escrevendo e Gerenciando Product Backlog
Adicionando e removendo requisitos
Escrevendo Histórias de Usuários
Organizando requisitos

4 - Sprints
Entregas potenciais
Mudanças durante a Sprint
Ritmo de trabalho sustentável
Cancelando uma Sprint

5 - Estimativas
Estimando o tamanho do trabalho
Planning Poker

6 - Escalando o Product Owner
Gerenciando demandas por clientes
Gerenciando demandas por produto
Construindo um único Product Backlog

7 - Priorização
ROI – Retorno de Investimento
Análise de Kano
Theme Screening e Scoring
Relative Weighting
MoSCoW

8 - Planejamento de Versões
Definindo escopo por versão
Definindo data de entrega de versão

9 - Acompanhamento de Projetos
Burndown charts (Execução do projeto)
Task boards (Execução de tarefas)

Publico Alvo
Product Owners, Gerentes de Produtos, Gerentes de Projetos, Analistas de Negócio, ScrumMasters, Executivos de TI/Projetos, Stakeholders

Detalhes
Data: 26 e 27 de março (08h00 às 18h00)

Carga horária: 16 horas

Local: Recife Praia Hotel

Valor: R$ 650,00 (R$ 500,00 inscrições até o dia12/03).

Instrutor: Nelson Abu (http://blogdoabu.blogspot.com/)

Mais informações: Clique Aqui!

--
Atenciosamente,
Alexsandro Marques, CSPO
www.alexsandromarques.wordpress.com

Diagrama de Casos de Uso

Definição
Guedes [1] define que: “O diagrama de caso de uso por meio de uma linguagem simples, demonstra o comportamento externo do sistema, procurando apresentar o sistema através de uma perspectiva do usuário, demonstrando as funções e serviços oferecidos e quais usuários poderão utilizar cada serviço. Este diagrama é, dentre todos os diagramas de UML, o mais abstrato, flexível e informal, sendo utilizado principalmente no início da modelagem do sistema, embora venha a ser consultado e possivelmente modificado durante todo o processo de engenharia e sirva de base para a modelagem de outros diagramas.”.



Exemplo
Atores


Casos de Uso


Cenários
Exemplo retirado do livro de Raul Sidnei Wazlawick [2] página 66.

Caso de Uso: Emprestar Fitas

Fluxo Principal
1.O cliente chega ao balcão com as fitas que deseja alocar;
2.O cliente informa o seu nome e entrega as fitas ao funcionário;
3.O funcionário registra o nome do cliente e inicia a alocação;
4.O funcionário registra cada uma das fitas;
5.O funcionário finaliza a locação, devolve as fitas ao cliente e lhe informa a data de devolução e o valor total da locação.
6.O cliente deixa a locadora com as fitas.

Tratamento de Exceções
3a – O cliente não possui cadastro.
3a1 – O cliente deve informar seus dados para cadastro.
3a2 – O funcionário registra o cadastro.
3a3 – Retorna ao fluxo principal no passo 3.

Exercício
•Crie o ator de fornecedor
•Identifique pelo menos três casos de uso de um fornecedor

Dicas
O diagrama de caso de uso é como uma peça de teatro, onde nós temos os atores que fazem parte da peça de teatro que são os mesmo atores do caso de uso. Os casos de uso são os itens, papéis que um ator tem que representar e a forma de como vai ser representado é o cenário de execução do caso de uso.
Na peça de teatro do chapeuzinho vermelho podemos dizer que o lobo mal, a chapeuzinho vermelho, a vovozinha, o caçador são os atores do nosso caso de uso.
As ações que o lobo mal tem que executar são os casos de uso, algumas dessas ações são: comer a vovozinha, falar com a chapeuzinho vermelho fingindo que é a vovozinha, morrer pelas mãos do caçador, etc.
A maneira de como o lobo mal vai comer a vovozinha é um exemplo de cenário, pois o cenário sempre tem que ser feito da mesma maneira, não podendo ter variações ou improvisos.

Bibliografia
[1] Guedes, Gilleanes T.A. UML 2 – Guia de Consulta Rápida – Segunda Edição. São Paulo: Novatec Editora Ltda, Novembro de 2005.
[2] Wazlawick, Raul Sidnei. Analise e projeto de sistemas de informação orientados a objetos. Rio de Janeiro: Elsevier, 2004.
[3] Fowler, Martin. UML essencial: um breve guia para a linguagem padrão de modelagem de objetos. Porto Alegre: Bookkman, 2005 – 3.ed.


Abraços,

Abu

Um Cartão de Classe (Cartão CRC)

Oi pessoal,

Segue um texto que eu utilizo no meu treinamento de Cartão CRC.


----- X -----

A única coisa que você precisa registrar em um cartão de classe quando você o define pela primeira vez é seu nome. Este é um pequeno, mas importante passo porque o nome que você dá a cada classe terá um efeito significativo no modo como as pessoas de negócios entenderão o funcionamento do modelo. O nome que você escolher deve transmitir clara e sucintamente, em termos de negócios e não técnicos, o que cada tipo de objeto representa no mundo real.


Figura 01 - Cartão de Classe

Definindo Responsabilidades
A primeira alternativa para definir objetos em termos de suas informações é defini-los de acordo com os papéis que desempenham no modelo. Esta é a essência de uma técnica conhecida como projeto dirigido por responsabilidade. Nesta abordagem, cada objeto é visto como uma entidade ativa dentro do modelo, executando responsabilidades específicas de modo a cumprir seu papel. Dependendo do objeto – como definido em sua classe – como ele usa variáveis na condução destas responsabilidades.

Uma boa maneira de quebrar antigos modos de pensar é encorajar os modeladores a personalizar objetos – pensar neles como seres vivos que são responsáveis por conduzir suas obrigações da maneira mais eficiente possível.

Devemos em primeiro lugar tentar distribuir as responsabilidades logicamente, no sentido de que você não deve pedir a um objeto que saiba ou faça algo fora de seu escopo normal. Por exemplo, seria razoável você esperar que um objeto Produto projete suas vendas futuras, mas não seria razoável fazê-lo projetar vendas de outros produtos.

O objeto Cliente deve ser responsável por saber o seu nome, endereço e informações para remessa, assim como por qualquer outra informação que possa ser solicitada por operações. Também decide que um Cliente deve saber seu saldo corrente e situação de pagamento de modo que a empresa possa ser cautelosa sobre uma possível extensão de crédito se um cliente estiver em débito.


Figura 02 - A Classe Cliente

Definindo Relacionamento
Cartões de Classe têm áreas para registrar informações sobre cada um dos três principais tipos de relacionamentos, como mostrado na figura a seguir. Para colaborações, coloque os nomes dos colaboradores – os objetos que são chamados para os serviços – na mesma linha das responsabilidades que eles apóiam. Para superclasse, simplesmente registre o nome da superclasse assim que ela for conhecida. Use o final do cartão para listar os componentes dos objetos compostos.


Figura 03 - Uma classe conhece seus relacionamentos


Figura 04 - Colaborações para determinar um preço total


Figura 05 - Esclarecendo itens de linha

Seguindo o cenário da Ordem de Venda
- Ordem de Venda, preencha o cabeçalho.
- Cliente, forneça endereço para envio (Ordem de Venda registra esta informação na área do cabeçalho).
- Ordem de Venda, adicione um item em linha (Ordem de Venda cria um novo Item em Linha e o adiciona a Itens de Linha).
- Item em Linha, aceite Produto (selecionado pelo usuário).
- Item em Linha, aceite quantidade (registrada pelo usuário).
- Produto, relate preço descontado pela quantidade.
- Ordem de Venda, preencha o rodapé.
- Cliente, relate seu desconto.
- Itens em Linha, preços totais estendidos (Ordem de Venda aplica desconto e adiciona frete).

Referencia Bibliográfica
Engenharia de Negócios com Tecnologia de Objetos
David A. Taylor


Abraço a todos,

Abu

Nível de Detalhamento de Requisitos

Estimativa – Precisão ou Aproximação?

Reflexão sobre Requisitos

O que é Escopo e Requisito?

Boa tarde pessoal,

Eu vou fazer uma definição simples e não formal, da diferença entre escopo e requisitos.



No exemplo das figuras dos carros, o escopo determina todos os produtos, serviços ou resultados que estamos entregando no nosso carro. No caso dos carros alguns itens que fazem parte do escopo são: portas, motor, rodas, bancos, etc...

Os requisitos determinam como vai ser a nossa porta, o nosso motor, os nossos bancos, a nossa cor de veiculo, etc.

É muito comum falarmos que o escopo mudou no projeto, mas a mudança de escopo é de fácil identificação. Um exemplo: O carro deve ter três rodas e não mais quatro rodas. Neste caso o escopo está determinando as fronteiras do nosso carro, os entregáveis que ele possui.

O que nos temos constantemente é a mudança de requisitos, onde o nosso cliente passa a ter uma visão mais critica do que ele realmente deseja com a execução do projeto e o recebimentos de produtos/serviços/resultados com requisitos implementados.

Mas agora vai a minha pergunta, quem desejar mandas as respostas por e-mail fique a vontade e quem desejar pode chamar para bate papo para debater sobre o meu questionamento.

Para podermos gerenciar o nosso projeto, para saber o quanto foi executado e quanto ainda falta ser executado, como devemos gerenciar o nosso projeto, por Escopo, Requisito ou qual a sua sugestão?

Abraço a todos,

Abu

FDD

Oi pessoal,

Segue uma imagem traduzida pelo Adail Muniz Retamal – www.heptagon.com.br



FDD: http://www.featuredrivendevelopment.com/

Fica a minha sugestão, não se prenda apenas a Scrum. Cada projeto tem as suas características e conhecer Open UP, XP, Lean, Kanban, Scrum, FDD, entre outros é muito importante, para que você encontre a melhor maneira de conduzir o desenvolvimento que o seu projeto exige.

[]s
Abu

Cartão de História – Invest

Oi pessoal, eu vou escrever sobre Cartões de História e a sua estruturação com conceito INVEST. Existe na web vários post sobre este assunto, também temos este assunto muito bem tratado no livro de Cartão de História de Mike Cohn (Eu recomendo a leitura deste livro).

INVEST é igual a:
Independent | Independente
Negotiable | Negociável
Valuable | Avaliável
Estimatable | Estimável
Sized Appropriately | Dimensionada apropriadamente
Testable | Testável

No processo de analise de sistemas, quando estamos levantando as informações referentes “ao que tem que ser feito” no sistema, estamos identificando os requisitos necessários para a completude do nosso projeto.

Estes requisitos identificados podem ter dentro de si, uma quantidade de outros requisitos implícitos. Também podemos ter requisitos pequenos, que já permite um entendimento e estimativa do mesmo.

Estas discrepâncias entre os requisitos podem ser normalizadas com a técnica de INVEST. Mas normalizar não é a única responsabilidade do INVEST, ele nos ajudar a entender melhor os requisitos, a realizar estimativas mais assertivas, definir critérios de aceite, definir o valor agregado do requisito ao negócio e priorizar o que realmente deve ser entregue ao nosso cliente.

Vamos agora utilizar o termo História. História é como vamos organizar o nosso requisito, onde ela permite identificar quem está realizando a ação, a funcionalidade desejada e o valor de negocio que se espera com a execução desta funcionalidade. O termo História vêm do convite que esta estrutura nos leva ao dialogo, o que permite o nosso trabalho de analise de sistemas.

Como um [usuário], gostaria de [funcionalidade] para [valor do negócio].

Quem? O que? Por que?

Independente

Devemos buscar a independência entre as Histórias, isto é, não termos correlação direta entre eles. Fica mais fácil realizar a estimativa focada a uma História do que realizar uma estimativa em um conjunto de Histórias. O nosso erro vai ser maior quando temos que estimar um grupo de Histórias correlacionadas.

Também fica difícil priorizarmos Histórias correlacionadas, um dos itens que fazem parte deste grupo de História necessariamente não tem que ser entregue junto com a História mais importante para o nosso cliente, mas como existe um acoplamento forte entre as Histórias, não temos (ou fica muito difícil) entregar apenas uma parte do que deve ser feito.

Um exemplo é forma de pagamento de uma compra. Podemos pagar com cartão de credito, boleto bancário, dinheiro, cheque, com uma composição de meios de pagamento (dinheiro + cheque) e assim por diante.

Está História esta muito grande e possui dentro dela varias outras Histórias. Podemos refinar colocando as Histórias assim:
Pagamento com Cartão de Credito
Pagamento com Dinheiro
Pagamento com Cheque
Pagamento em Boleto Bancário

Mas ainda temos uma quantidade grande de tipos de Cartão de Credito, vamos melhorar mais um pouco...
Pagamento com Cartão de Credito Visa
Pagamento com Cartão de Credito Master

Agora a História de pagamento de uma compra chegou no nível de independência. Eu posso priorizar qual a forma de pagamento mais importante para o meu cliente na minha próxima entrega de produto. Devemos repetir este processo de refinamento para as demais formas de pagamento que o nosso cliente deseja.

Negociável

Uma Historia no seu processo de entendimento (analise de sistemas) gera um conjunto de conversas, conversas são anotações que realizamos na História para saber “o que temos que fazer” para deixar a História aderente as necessidades do cliente.

Estás conversas anotadas geram software, isto é, funcionalidades necessárias a serem implementadas no nosso sistema. Mas nem todas as necessidades (funcionalidades) tem que ser realizadas ao mesmo tempo, permitindo uma negociação com o cliente, onde esta negociação determina o que vai ser entregue e o que pode ser realizado em outro momento do projeto.

Um exemplo é a nossa tela de login. A nossa tela tem que ter o campo para a entrada do username e a entrada da senha. Mas no processo de entendimento da História passamos a buscar a completude da História, com informações de quantas vezes o usuário pode tentar se logar no sistema, se existe uma funcionalidade de recuperar a senha, algum tipo de notificação por e-mail, mensagens de erro, dispositivos de ações, como um botão para confirmar o usuário e senha, e assim por diante.

Passamos a realizar o entendimento da História junto ao nosso cliente, anotamos todas as suas necessidades e expectativas, estas anotações vão ser transformadas em funcionalidades implementadas e passamos a negociar quais destas funcionalidades devem ser implementadas.

Valiosa

Histórias devem gerar valor ao cliente, uma boa técnica de buscarmos este valor é o próprio cliente escrevendo as suas Histórias. Nem sempre é possível o cliente escrever as suas próprias Histórias, não importando no momento o que leva a está impossibilidade.
Mas valor é visto nos olhos de quem paga para usar e devemos se necessário colocar óculos no cliente, para que ele possa enxergar o valor de retorno das Histórias que ele está solicitando.

É um processo demorado, mas o retorno vale a pena, ensinarmos nossos clientes a escrevem suas Histórias. Lembrando sempre que podemos ajudá-lo a escrever.

Estimável

Quando chegamos no ponto de realizar uma estimativa é importante que as nossas Histórias já estejam independentes e negociadas. Se eu não tenho mais dependência entre Histórias minha estimativa vai ser mais assertiva e sem as funcionalidades desnecessárias para a entrega facilita e melhora cada vez mais a estimativa.

Estamos estimando Histórias com suas funcionalidades que realmente agregam valor aos “Olhos” do nosso cliente.

Pequena

Não existe uma formula mágica para determinar o tamanho que as nossas Histórias devem ter, mas este tamanho se normaliza com o processo de levantamento de Historias e analise das mesmas.

Um tamanho determinado em um projeto, necessariamente não vai ser o mesmo em outro projeto.
Devemos tomar cuidado em não confundir Histórias com uma funcionalidade a ser implementada, um exemplo é uma mensagem de erro do sistema, que faz parte de uma História.

Testável

Uma boa técnica de descobrir como a nossa História deve se comportar é realizar testes de validação da História.

Conversas mais Testes de Aceitação fecham um ciclo de entendimento da História. Qualquer implementação a mais nesta História, que não foi identificada nas conversas ou testes não deveria ser realizada.

Exemplo:
[Cartão de História]
Como um cliente, quero que o sistema mostre o valor da postagem, para que eu possa saber quanto vai ser a taxa de entrega.

[Testes] - Template: [ação] [resultado] [objeto]
Mostrar valor da postagem de correio para vendas realizadas na mesma cidade
Mostrar valor da postagem de correio para vendas realizadas no mesmo estado
Mostrar valor da postagem de correio para vendas realizadas em estados diferentes
Mostrar valor da postagem de correio para vendas internacionais
Mostrar valor da postagem de correio para vendas isentas de taxa de entrega
Calcular valor da postagem de correio para cada produto existente no carrinho de compras
Mostrar mensagem de erro para cep´s inválidos
Mostrar mensagem de erro para cep´s vazio



Abraço a todos,

Abu

Cartão de História

Cartões de história é uma técnica de captura de requisitos de sistemas, esta técnica surgiu com a metodologia de desenvolvimento chamada de XP (extreme programming), porém podemos utilizar esta técnica com qualquer metodologia de desenvolvimento de sistemas ágeis.

Como “Cartões” têm o objetivo de capturar os requisitos, eles se concentram em “quem, o quê e porquê de um recurso, e não como”. Neste ponto ele é igual a varias técnicas de levantamento de requisitos, onde tentamos identificar o que tem que ser feito e não como será feito.

O cartão de história tem que ser escrito a partir de uma perspectiva do usuário. Desta maneira o cartão não deve possuir jargões técnicos ou informações de design, ou qualquer outra coisa que não seja informações de negócio. Um cartão deve ser escrito com a linguagem no negócio, para que seja compreendido por todos.

Exemplo de Cartão de Historia
Como um professor, eu gostaria de lançar as notas de meus alunos, para que os alunos possam saber como estão indo na minha matéria.

Como um aluno, eu gostaria de visualizar as minhas notas de modo que eu possa saber o meu desempenho nas disciplinas.

Observe que em ambos os casos estamos buscando um linguajar de negócio e buscando as necessidades do sistema (em nível de negócio – o que tem que ser feito), mas em nenhum dos exemplos entramos em uma linguagem técnica e nem falamos “como vamos fazer”.

Template de Cartão de Historia
Como um [usuário papel], quero [meta], para que eu possa [motivo].

A primeira vista podemos achar que a parte do [motivo] não é necessária, mas a utilização do [motivo] nos leva a um entendimento melhor do objetivo pelo qual o cartão é útil. Ele nos ajuda a entender melhor como o requisito funciona e nos da uma idéia melhor para outras características do sistema.

Em Scrum nós buscamos identificar os cartões no início do projeto, para que ele de origem ao “Procuct Backlog”. Com os cartões identificados podemos dar origem a priorização e a estimativa dos mesmos.

Uma vez os cartões priorizados para execução em uma Sprint eles devem ter os seus detalhes (tarefas) identificados. Não devemos identificar os detalhes de cartões que não fazem parte da Sprint, desta maneira evitamos o gasto de energia na Sprint corrente em trabalhos que fazem parte de outro momento temporal.

Organizando Cartões de Historia
Um cartão de história deveria ter pelo menos três itens: Informações do cartão, dados de conversa com o usuário e testes de validação do cartão.

Informações do cartão são: nome, descrição da história, um número de referencia, estimativa, etc.

Conversas são anotações (lembretes) da história e não uma especificação completa. Estas anotações servem de apoio para a obtenção de mais detalhes no momento de desenvolvimento, identificando como o software deve funcionar. Tudo que ajude a explicar a funcionalidade deve ser colocado como um item de conversa. É como um conjunto de palavras chaves, mas não tem a necessidade de ficar restrito a uma palavra, pode ser colocada (escrito) como uma frase.

Confirmação (Testes) são os casos de testes no verso do cartão. Os testes possibilitam o entendimento melhor do cartão, ajuda na busca de cenários que os usuários, desenvolvedores / analistas podem não ter pensado. Um cartão (requisito) tem que ser possível de ser testado.

Um cartão de história tem que possuir uma única responsabilidade, ter cartões de história com mais de uma responsabilidade dificulta o entendimento, a estimativa e a priorização. Cartões pequenos nos ajudam a realizar uma administração (gestão) do projeto.


Observe que o desenho que representa a frente do cartão tem os dados de identificação do cartão de história. Estes dados são: o numero (0001), o titulo (User Login), a história do cartão (As a [register user]...) e ainda dados das conversas com o usuário, onde temos um esboço de como deve funcionar a tela e anotações do comportamento esperado.

Na segunda imagem nós temos as informações dos testes (confirmação), mostrando os cenários possíveis e esperados pelo usuário.

Link de Referencia:
http://kw-agiledevelopment.blogspot.com/2008/01/user-stories-answers-on-postcard-please.html
http://kw-agiledevelopment.blogspot.com/2008/01/user-stories.html
http://kw-agiledevelopment.blogspot.com/2008/01/example-of-user-story.html

Abraço a todos,

Abu

GTT - Criando e Gerenciando Backlog + Kanban

Oi pessoal,

Foi realizado no sábado do dia 06 de fevereiro de 2010 na empresa GTT (http://www.gtt.com.br) o treinamento de Criação e Gerenciamento de Backlog e controle de execução do projeto utilizando Kanban.

O treinamento teve o foco de realizar um alinhamento dos conceitos com a pratica já utilizada na empresa. Parabéns a todos os participantes. O treinamento teve a participação dos profissionais da empresa nas mais diversas áreas, produção, engenharia, TI, vendas, etc. Foi muito proveitoso e a união das mais diversas áreas da empresa no treinamento permitiu uma troca muito rica de conhecimentos entre o instrutor e os participantes.

Fotos do Treinamento







Link's de post já realizados no Blog do Abu da empresa GTT

Combinando Técnicas de Ágil e PMBOK
Reunião de Definição de Produto na GTT
RFID x Cerveja x Geladeira x Empresa GTT
Fotos da Empresa Gtt
Abu e Empresa Gtt
Projeto GTT, em execução...
Cartão de Historia Quebrados em Tarefas

Abraços a todos,

Abu

Abu - Treinamentos e Coach

Quer fazer um Treinamento com o Abu?