O Propósito do Guia SCRUM - XVII

Reunião de Planejamento da Sprint    

49. Quando ocorre o planejamento do trabalho que será realizado na Sprint?

• Na reunião de planejamento da Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum.

50. O que é a reunião de planejamento da Sprint?

• É uma time-box de 8 horas para uma Sprint de um mês de duração. Para Sprints menores, este evento deve ser proporcionalmente menor. Por exemplo, uma Sprint de duas semanas terá uma reunião de planejamento de Sprint de quatro horas.

51. Como é desenvolvida a reunião de planejamento da Sprint?

• Ela consiste em duas partes, cada uma sendo uma time-box de metade do tempo de duração da reunião de planejamento da Sprint.

52. Quais as questões são respondidas durante a reunião de planejamento da Sprint?

• O que será entregue como resultado do incremento da próxima Sprint?
• Como o trabalho necessário para entregar o incremento será realizado?

53. Qual o planejamento para a primeira parte da reunião? O que será Pronto nesta Sprint?

• Na primeira parte da reunião a Equipe de Desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidas durante a Sprint. O Product Owner apresenta os itens de Backlog do Produto ordenados para a Equipe de Desenvolvimento e todo o Time Scrum colabora com o entendimento do trabalho da Sprint.

54. Quais os resultados da primeira parte da reunião de planejamento da Sprint?

• O mais recente incremento do produto.
• A capacidade projetada da Equipe de Desenvolvimento durante a Sprint.
• Desempenho passado da Equipe de Desenvolvimento.
• O número de itens selecionados do Backlog do Produto para a Sprint é o único trabalho da Equipe de Desenvolvimento. Somente a Equipe de Desenvolvimento pode avaliar o que pode ser completado ao longo da próxima Sprint.

Após a Equipe de Desenvolvimento prever os itens de Backlog do Produto que irá entregar na Sprint, o Time Scrum determina a meta da Sprint. A meta da Sprint é um objetivo que será conhecido dentro da Sprint através da implementação do Backlog do Produto, fornecendo orientação do porque a Equipe de Desenvolvimento está trabalhando no incremento.

55. Quais os resultados da segunda parte da reunião de planejamento?

• Tendo selecionado o trabalho da Sprint, a Equipe de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”. Os itens de Backlog do Produto selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de Backlog da Sprint.

A Equipe de Desenvolvimento frequentemente inicia o desenho do sistema e do trabalho necessário para converter o Backlog do Produto em um incremento utilizável do produto. O trabalho pode ser de vários tamanhos ou esforços. Contudo, o trabalho suficiente é planejado durante a reunião de planejamento da Sprint pela Equipe de Desenvolvimento prever o que esta acredita que poderá fazer durante a próxima Sprint. Com o trabalho planejado pela Equipe de Desenvolvimento para os primeiros dias da Sprint, este é decomposto em unidades de um dia de duração ou menos até o final desta reunião. A Equipe de Desenvolvimento se auto-organiza para realizar por todo o trabalho do Backlog da Sprint, tanto durante a reunião de planejamento da Sprint quanto no que for necessário durante a Sprint.

O Product Owner pode estar presente durante a segunda parte da reunião de planejamento da Sprint, para clarificar os itens do Backlog do Produto selecionados e para ajudar nas decisões conflituosas de troca. Se a Equipe de Desenvolvimento determina que tem excesso ou falta de trabalho, os itens do Backlog da Sprint pode ser renegociados com o Product Owner. A Equipe de Desenvolvimento também pode convidar outras pessoas para participar desta reunião de forma a fornecer opinião técnica ou de domínios específicos.

No final da reunião de planejamento da Sprint, a Equipe de Desenvolvimento deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar como equipe auto-organizada para completar o objetivo da Sprint e criar um incremento previsto.

Objetivo ou meta da Sprint

56. Por que estabelecer uma meta ou objetivo para a Sprint?

• O objetivo da Sprint dá a Equipe de Desenvolvimento alguma flexibilidade em relação às funcionalidades a serem implementadas dentro da Sprint.

Conforme a Equipe de Desenvolvimento trabalha, ela mantém o objetivo em mente, e no caminho de buscar satisfazer o objetivo da Sprint, ela implementa a funcionalidade e a tecnologia. Caso o trabalho acabe por ser diferente do esperado pela Equipe de Desenvolvimento, então eles colaboram com o Product Owner para negociar o escopo do Backlog da Sprint dentro da Sprint.

O objetivo da Sprint pode ser um marco contido no propósito maior no roteiro do produto.



Grande Abraço,
Gilberto Ribeiro.

Métrica de Software - XVII

As 14 Características Gerais e seus Graus de Influência. 

Glossário:

• Batch ou arquivo de lote (também conhecidos por .bat)
• É um arquivo de computador utilizado para automatizar tarefas. É regularmente confundido com o modo de processamento de dados no qual os mesmos são processados em grupos, ou lotes, através de uma rotina agendada. O batch neste caso, nada mais é um conjunto de comandos rodados sequencialmente.
• Stand Alone , ou stand-alone (literalmente "ficam em pé por si só") os programas completamente auto-suficientes: para seu funcionamento não necessitam de um software auxiliar, como um interpretador, sob o qual terão de ser executados.
• Protocolo de Comunicação
• Na ciência da computação, um protocolo é uma convenção ou padrão que controla e possibilita uma conexão, comunicação ou transferência de dados entre dois sistemas computacionais. De maneira simples, um protocolo pode ser definido como "as regras que governam" a sintaxe, semântica e sincronização da comunicação. Os protocolos podem ser implementados pelo hardware, software ou por uma combinação dos dois.

Grande Abraço,
Gilberto Ribeiro.

Gestão de Projetos - XVII

Ciclo de vida e organização do projeto

Os projetos e seu gerenciamento são executados em um ambiente mais amplo que o do projeto propriamente dito. A compreensão desse contexto mais amplo ajuda a garantir que o trabalho seja conduzido em alinhamento aos objetivos da empresa e gerenciado de acordo com as metodologias e práticas estabelecidas pela organização. Este capítulo descreve a estrutura básica de um projeto, bem como outras considerações importantes, incluindo como os mesmos impactam o trabalho operacional em andamento, a influência das partes interessadas além da equipe de projeto imediata, e como a estrutura organizacional afeta o modo como a equipe é formada e como o projeto é gerenciado e executado. As principais seções discutidas aqui são:

2.1 O Ciclo de vida do projeto — Resumo

2.2 Projeto versus trabalho operacional

2.3 Partes interessadas

2.4 Influências organizacionais no gerenciamento de projetos

Grande Abraço,

Gilberto Ribeiro.

Fábrica de Software - XVII

As técnicas usadas em projetos integrados são:

Uso de especialistas

Quando o projeto envolve novidade para a empresa e pela equipe do projeto, é importante contar com o aconselhamento externo para fins de estimativas de prazo.

Técnicas Delphi

Pode produzir estimativas adequadas na ausência de conhecimento externo. Ela prega uma abordagem de brainstorming, em que cada membro da equipe do projeto fornece sua melhor estimativa a respeito da duração de uma atividade. Os resultados individuais são tabulados e sua frequência é calculada; a média e a dispersão são também calculadas.

Os resultados fora da média são discutidos para saber a razão dessa variação. Então é feita outra rodada de estimativas em função das observações dos indivíduos que estavam fora da média. Os resultados são novamente “plotados” e as variações são discutidas. Parte-se então para a terceira rodada para se chegar a uma estimativa final.

Uma variação dessa técnica é empregar especialistas e confrontar os resultados da equipe do projeto a fim de aprimorar a estimativa.

Técnica dos três pontos

Parte do pressuposto que a duração da atividade é aleatória, mesmo considerando condições exatamente iguais de projeto. Para tanto, reúne-se a equipe do projeto e solicita-se que cada indivíduo faça três estimativas acerca da duração da atividade; uma otimista, outra pessimista e a outra mais provável. A pessimista é dada se tudo correr errado. A mais provável é gerada com base na experiência individual dos membros da equipe.

Esse método emprega a seguinte fórmula para a determinação da duração da atividade:

E (estimativa de duração) = EO + 4EM + EP/6, sendo:

EO = estimativa otimista;

EM = estimativa mais provável;

EP = estimativa pessimista;

Técnica Delphi ampliada

É a combinação da técnica Delphi com a técnica de três pontos. Ao invés de um estimativa, os membros da equipe fazem três estimativas. São feitas médias para as três estimativas que são aplicadas na fórmula anterior.

PERT (Program Evaluation and Review Technique)

Essa técnica foi desenvolvida pela empresa de consultoria Booz-Hallen and Hamilton para a Marinha dos Estado Unidos da América. O método é uma técnica de redes e consiste em um conjunto de processos, técnicas para planejamento, programação e controle de um empreendimento ou operação, ou projeto.

Estimativas de Custos

A estimativa de custo é o processo de desenvolver uma estimativa aproximada dos custos dos recursos necessários para completar o projeto. Para tanto, é necessário quantificar em valores monetários o orçamento de recursos do projeto, assim como definir alternativas de custo se houver restrições orçamentárias colocadas para a equipe do projeto.

A estimativa de custo vai ser usada quando da elaboração do Orçamento de Custo do Projeto, quando é feita a apropriação dos custos estimados a cada uma das atividades requeridas para elaboração de um “pacote de trabalho” (elemento de menor nível de um WBS). A estimativa de custo depende da estimativa de prazo e recurso.

Grande Abraço,

Gilberto Ribeiro.

Engenharia de Software - XVII

Relacionamento entre métricas internas e externas

Quando os requisitos de qualidade do produto de software são definidos, as características ou subcaracterísticas de qualidade do produto de software que contribuem com os requisitos de qualidade são listadas. Então, as métricas externas apropriadas e os limites aceitáveis são especificados para quantificar os critérios de qualidade que validam se o software atende às necessidades do usuário. Os atributos de qualidade interna do software são então definidos e especificados, com o objetivo de atingir a qualidade externa e a qualidade em uso requeridas e contemplá-las no produto durante seu desenvolvimento. Métricas internas apropriadas e limites aceitáveis são especificados para quantificar os atributos de qualidade interna, de modo que eles possam ser utilizados para verificar se os produtos intermediários atendem às especificações de qualidade interna durante o desenvolvimento.

Recomenda-se que as métricas internas utilizadas tenham uma relação tão forte quanto possível com as métricas externas selecionadas, de modo que possam ser utilizadas para prever os valores de métricas externas. Entretanto, em geral, é difícil projetar um modelo teórico rigoroso que estabeleça um relacionamento forte entre métricas internas e externas.

Grande Abraço,
Gilberto Ribeiro.

Perfil Profissional - XVII

Segunda Fase - Criação do Diagrama de Implementação

Criação do Diagrama de Implantação

É um artefato UML que define todos os detalhes relacionados à implantação do sistema.

Produto de Entrada
Modelo VIII - Lista de Requisitos.
Modelo XII - Documento de Arquitetura.
Produtos de saída
Modelo de design atualizado.

Grande Abraço,
Gilberto Ribeiro.

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.

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.