domingo, 23 de junho de 2013

Perfil Profissional - XVI

Primeira Fase - Escolha do Modelo de Arquitetura


Análise de Risco da arquitetura

Definir o modelo de arquitetura levando em consideração os custos e risco do projeto, elaborado estratégias de mitigação que reduza o impacto no projeto.

Produto de Entrada
Modelo VIII - Lista de Requisitos.

Produtos de saída
Modelo de arquitetura.
Protótipo de arquitetura.


Grande Abraço,
Gilberto Ribeiro.




Perfil Profissional - XV

Arquiteto de Sistema - Sugestão de Perfil

 
  
Relações no Processo
 

Grande Abraço,
Gilberto Ribeiro.

sexta-feira, 21 de junho de 2013

O Propósito do Guia SCRUM - XVI


Backlog do Produto

47. O que é o Backlog do Produto?
  • É uma lista ordenada de tudo aquilo que pode ser necessário no produto (não somente funcionalidades).
  • Qualquer coisa que precisa ser feita para o produto ou no produto deve estar no Backlog do Produto. 

  • É sempre uma lista das necessidades escrita na linguagem do negócio.
    • Não deve conter itens técnicos (ex.: a emissão de notas fiscais deve ser desenvolvida com uso de thresds)
  • Deve estar disponível para todos os interessados (aplicação do valor Transparência)
    • Possibilita a contribuição das partes interessadas.
  • Todos os envolvidos podem sugerir itens no Backlog do Produto, mas a decisão final é do Dono do Produto.
    • Em se tratando do Backlog do Produto, o Dono do Produto é o “porco” e todos os demais são “galinhas”.
  • Está em constante evolução.

48. Quem é o responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação?
  • O Product Owner.
 
Priorização dos itens do Backlog do Produto.
  • Valor do retorno de investimento
  • Dependências
  • Necessidades
  • Riscos
  • Outros fatores


Um dos pontos mais críticos do Backlog do Produto é como e quanto os seus itens precisam ser detalhados:
  • Cada item deve conter uma breve descrição, geralmente, de uma a duas linhas.
  • O nível de detalhe é definido pela Equipe Scrum e pode variar para cada item.
  • O Dono do Produto é o responsável por refinar os requisitos, ainda que possa contar com a ajuda do time de desenvolvimento para isso.
  • História de usuário, casos de uso e descrição textuais, são normalmente usados para o detalhamento.
  • Cada item precisa estar preparado, detalhado o suficiente para entrar em uma Sprint. 
  •  Os itens do backlog do Produto devem estar preparados para entrar em uma Sprint. Como Scrum Master, jamais deixe o Dono do Produto ir para um reunião de planejamento da Sprint sem ter itens preparados.
Grooming
  • A preparação e refinamento do Backlog do Produto é conhecido em inglês pelo termo Grooming.
  • O Dono do Produto é o responsável por realizar o Grooming do Backlog do Produto, mas pode contar com o apoio de toda a equipe para realizar isto.
  • Normalmente o Grooming é realizado por meio de uma reunião com toda a Equipe SRUM.
  • O objetivo desta reunião é ajudar o Dono do Produto a refinar e preparar os itens do Backlog do Produto para entrar em futuras Sprints.
  • Durante o Grooming, a equipe avalia a granularidade dos itens do Backlog e, se necessário, os quebra em itens menores.
  • Uma vez que itens do Backlog do Produto estejam claros o suficiente, o Time de Desenvolvimento pode estimar a complexidade de cada um.
  • O Grooming pode ser realizado a qualquer momento, sempre que houver necessidade.
  • O ideal é que o Time de Desenvolvimento reserve 10% do tempo da Sprint atual, para realizar o Grooming de itens que entrarão nas próximas três Sprints.
  • Lembre-se de um dos princípios do manifesto ágil:
  • Pessoas relacionadas à negócio e desenvolvimento devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

 O que não fizer parte no Backlog do Produto não será desenvolvido.
 
Grande Abraço,
Gilberto Ribeiro.

Perfil Profissional - XIV




Representação de Relacionamentos das Abstrações no Modelo de Domínio



Analisar e descobrir como os objetos relacionam-se entre si, documentando-os nos diagramas de classes.


Grande Abraço,
Gilberto Ribeiro.

quarta-feira, 19 de junho de 2013

Perfil Profissional - XIII




Definição de Diagrama de Atividade para os Casos de Uso

Mapear todas as atividades e etapas que devem ser executadas para que os casos de uso sejam executados como o esperado pelo cliente.



Produtos de Entrada
Modelo V - Documento de Visão.
Modelo VIII - Lista de Requisitos.
Modelo III - Plano de Projeto de Software.
Relatório sintético de caso de uso.

Produtos de Saída
Especificação de casos de uso.
Diagrama de Classes Atualizado.
Modelo de Análise Atualizado.

Atividades
Definir diagrama de atividades para todos os casos de uso, registrando-as nas especificações de casos de uso.
Refinar diagramas de classes e modelo de análise.

Grande Abraço, 
Gilberto Ribeiro.

O Propósito do Guia SCRUM - XV


Cancelamento da Sprint

43. Quem pode cancelar a uma Sprint?
  • Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob a influência das partes interessadas, da Equipe de Desenvolvimento ou do Scrum Master.

44. Quais as razões para o cancelamento da Sprint?
  • Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias.
  • Se o objetivo da Sprint se tornar obsoleto.
  • Se a organização mudar sua direção
  • Se as condições do mercado ou das tecnologias mudarem.
  • No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido.

44. O que acontece com o item de Backlog do Produto completo e “Pronto” quando a Sprint é cancelada?
  • O item é revisado e se uma parte do trabalho estiver potencialmente utilizável, tipicamente o Product Owner o aceita.

45. Os que acontece com os item do Backlog do Produto incompletos?
  • Todos os itens de Backlog do Produto incompletos são re-estimados e colocados de volta no Backlog do Produto.

46. Quais os resultados de um cancelamento de uma Sprint?
  • O cancelamento da Sprints consome recursos, já que todos tem que se reagrupar em outra reunião de planejamento da Sprint para iniciar outra Sprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns.

Grande Abraço,
Gilberto Ribeiro.

terça-feira, 18 de junho de 2013

O Propósito do Guia SCRUM - XIV


Sprint

38. Como podemos definir a Sprint?

Como o coração do Scrum, um time-box de um mês ou menos, durante o qual uma versão “Pronta”, versão incremental potencialmente utilizável do produto, é criada.

Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.

39. Qual o processo que compõe uma Sprint?

As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.

40. Durante a Sprint o que muda e o que não pode mudar?
  • Não são feitas mudanças que podem afetar o objetivo da Sprint;
  • A composição da Equipe de Desenvolvimento permanece constantes;
  • As metas de qualidade não diminuem; e,
  • O escopo pode ser elucidado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido.

41. Como podemos encarar uma Sprint?
  • Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês.
  • Como os projetos, as Sprints são utilizadas para realizar algo.
  • Cada Sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto.

42. Qual a duração de uma Sprint?
  • Sprints são limitadas a um mês corrido.

Quando o horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer. Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção a meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido.

Grande Abraço,
Gilberto Ribeiro.

Perfil Profissional - XII



Refinar os Diagramas de Casos de Uso

A partir de toda a informação obtida no processo de levantamento de requisitos e dos casos de uso de negócio do sistema, realizamos o refinamento dos casos de uso do sistema identificando todos os envolvidos.



Produtos de Entrada

Modelo V - Documento de Visão.
Modelo VIII - Lista de Requisitos.
Modelo III - Plano de Projeto de Software.
Protótipo.
Modelo VI - Glossário do Projeto.

Produtos de Saída

Relatório sintético de casos de uso atualizado.
Modelo de análise.
Especificação de casos de uso.
Glossário atualizado.

Atividades

Refinar diagramas de caso de uso.
Obter aprovação dos casos de uso junto ao cliente. 


Grande Abraço,
Gilberto Ribeiro.