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