O Propósito do Guia SCRUM - XI

Eventos Scrum

• Reunião de Planejamento da Sprint.

• Reunião diária.

 

• Reunião de Revisão da Sprint.

 

• Retrospectiva da Sprint.

44. Qual a principal característica dos eventos Scrum?

• Eventos time-boxed, onde todo evento tem uma duração máxima.

45. Qual objetivo dos eventos time-boxed?

• Garantir que uma quantidade adequada de tempo seja gasta no planejamento sem permitir perdas no processo de planejamento.

Além da Sprint, que é um container para outros eventos, cada evento no Scrum é uma oportunidade de inspecionar e adaptar.

Estes eventos são especificamente projetados para permitir uma transparência e inspeção criteriosa.

Atenção: A não inclusão de qualquer um dos eventos resultará na redução da transparência e da perda de oportunidade para inspecionar e adaptar.

Grande Abraço,
Gilberto Ribeiro.

Requisitos - XV

Testes

Os testes se dividem em 5 tipos :

• Teste de bancada
• Teste de qualidade
• Teste de Stress
• Teste de Segurança
• Homologação

Destes 3 tipos apenas o teste de bancada é realizado em ambiente de desenvolvimento, em geral pelo próprio analista conforme comentado anteriormente. Os demais testes são realizados em um ambiente denominado ambiente de qualidade.

Ambiente de Qualidade 

O ambiente de qualidade é um ambiente o mais similar possível ao ambiente de produção da empresa. Este ambiente é utilizado para a realização de testes de qualidade na aplicação.

Raramente, porém, é possível ter um ambiente de qualidade realmente idêntico ao de produção. Cabe à equipe de suporte juntamente com o analista/arquiteto do sistema realizar um relatório de riscos relativo a passagem da aplicação para produção, ou seja, o risco de mesmo depois dos testes em qualidade a passagem para produção não funcionar devido a diferença entre qualidade e produção.

Montagem do ambiente de qualidade

A montagem do ambiente de qualidade é, de fato, um teste : Testa-se o passo-a-passo de instalação do sistema, garantindo que o processo de instalação funcionará quando for executado em ambiente de produção.

Teste de Qualidade

• O teste de qualidade é, de todos, o teste mais detalhado do sistema. É realizado por testers, profissionais especializados na realização de testes da aplicação.
• Os testers podem fazer uso do plano de testes criado pelo analista, mas não se prendem a ele. O objetivo principal dos testers é fazer o que é chamado de monkey test : Fazer exatamente o contrário do que a aplicação pede em cada tela e verificar como a aplicação reage. Desta forma obtém-se a garantia de que a aplicação funcionará mesmo perante os piores tipos de usuário existentes.
• Os testers em geral são desenvolvedores, mas não precisam ser tão especializados como os próprios desenvolvedores do projeto. Em alguns casos podem ser outra equipe de desenvolvimento da própria empresa, mas não devem ser os mesmos desenvolvedores do projeto, pois por mais que tentem os desenvolvedores do projeto sempre fazem testes para fazer a aplicação funcionar, ao contrário de testers que devem fazer a aplicação dar erro
• Há um trabalho circular entre os testers e o processo de codificação. Os testers devem gerar um relatório de volta para o processo de codificação, gerando uma reimplantação da aplicação em qualidade e novo teste até o momento em que os testers não identifiquem nenhum erro

Teste de Stress

• O teste de stress tem por objetivo testar a aplicação em condições de uso muito maciço, verificando como o hardware e o software respondem em ambiente simulado.
• O teste envolve tanto o analista/arquiteto, responsável por especificar a simulação de teste, como a equipe de banco, responsável pela análise da resposta do servidor de banco ao teste como a equipe de suporte, responsável pela análise da resposta do hardware e do sistema operacional. 

Teste de Segurança

• Em geral é realizado por uma equipe externa de hackers contratados especialmente para testar a segurança do sistema, este teste tem se tornado comum nas atuais arquiteturas de desenvolvimento para web.

Homologação 

É o teste realizado pelos usuários finais, que podem ou não seguir o plano de testes preparado pelo analista

• O processo de homologação pode gerar um trabalho circular com a etapa de codificação, assim como ocorreu com o teste de qualidade, mas é mais improvável que o processo de homologação encontre muitas falhas no sistema
• O usuário vai, como sempre, pedir modificações no sistema. Porém o analista deve ser cuidadoso de direcionar as modificações solicitadas pelo usuário para a próxima versão do sistema.
• Ao final da homologação o usuário dá sua aprovação final para o sistema 

Implantação

Não existe uma regra específica para o processo de implantação, mas o analista, a equipe de suporte e a de banco de dados devem estar em conjunto solucionando os seguintes problemas.

• Treinamento para os usuários
• Trabalho em paralelo com aplicações existentes quando necessário
• Migração de dados de bancos de dados existentes quando necessário

Observe que tanto o analista, como a equipe de suporte e a equipe de banco de dados devem ter trabalhado deste o término da etapa de análise no planejamento do processo de implantação. Desta forma o trabalho neste etapa torna-se bem planejado e organizado, menos sujeito a falhas.

Grande Abraço,
Gilberto Ribeiro.

Engenharia de Software - XIV

Métricas de software

Atributos Externos e Internos

Constata-se que os níveis de certos atributos internos influenciam os níveis de alguns atributos externos, de modo que há tanto um aspecto externo quanto um aspecto interno na maioria das características. Por exemplo, a confiabilidade pode ser medida, externamente, observando-se o número de falhas, num dado período de tempo de execução, durante um experimento de uso do software e, internamente, inspecionando as especificações detalhadas e o código-fonte para avaliar o nível de tolerância a falhas. Os atributos internos são tidos como indicadores dos atributos externos.

Um atributo interno pode influenciar uma ou mais características e uma característica pode ser influenciada por mais de um atributo (ver figura A.1). Neste modelo, todos os atributos de qualidade do produto de software são classificados numa estrutura hierárquica, em árvore, de características e subcaracterísticas. O nível mais alto desta estrutura consiste em características de qualidade e o nível mais baixo consiste em atributos de qualidade de software. A hierarquia não é perfeita, pois alguns atributos podem contribuir para mais de uma subcaracterística.

Fonte: NBR ISO/IEC 9126.

Subcaracterísticas podem ser medidas por métricas internas ou por métricas externas.

A correlação entre atributos internos e medidas externas nunca é perfeita e o efeito que um dado atributo interno tem sobre uma medida externa associada será determinado pela experiência e dependerá do contexto específico no qual o software será usado.

Do mesmo modo, propriedades externas (tais como: adequação, acurácia, tolerância a falhas ou comportamento em relação ao tempo) influenciarão a qualidade observada. Uma falha na qualidade em uso (por exemplo, o usuário não consegue terminar uma tarefa) pode ser relacionada a atributos de qualidade externa (por exemplo, adequação ou operabilidade) e a atributos internos associados que precisam ser modificados.

Grande Abraço,
Gilberto Ribeiro.

Fábrica de Software - XIV

Planejamento da Implantação

O planejamento da implantação da Fábrica deve seguir alguns passos e gerar um Plano do Projeto. A entrada principal para o planejamento da implementação da Fábrica de Software é constituída por suas especificações técnicas e pela estratégia de desenvolvimento.

O planejamento do projeto deve considerar os seguintes passos:

1. Definição do WBS do projeto.
2. Definição das atividades para geração de cada produto previsto para ser entregue pelo projeto (exemplo: instalação dos servidores, procedimento documentado de controle de qualidade etc.).
3. Definição sobre precedência entre as atividades.
4. Estimativa de prazos e recursos.
5. Estimativas de custo.
6. Elaboração do plano da qualidade.
7. Elaboração do plano organizacional.
8. Elaboração do plano de aquisição de recursos.
9. Elaboração do plano de riscos.
10. Elaboração do plano de comunicação.
11. Elaboração do cronograma do projeto.
12. Elaboração do orçamento de custo do projeto.
13. Elaboração dos critérios de controle do cronograma, custo e escopo.
14. Consolidação do Plano do Projeto.

WBS do projeto da Fábrica de Software 

O WBS do projeto define os entregáveis do projeto.

Um projeto de Fábrica de Software geralmente tem os seguintes entregáveis:

• Instalações Físicas
• Imobiliário

• Projeto de Rede
• Servidores
• Softwares
• Cabeamento
• Dispositivo de Rede

• Ferramentas do Processo de Construção
• Processo de Gestão do Projeto
• Ferramentas do Processo de Gestão do Projeto
• Processo de Gestão da Operação
• Ferramentas do Processo de Gestão da Operação
• Processo de Suporte
• Ferramenta de Processo de Suporte
• Processo de Gestão Estratégica
• Ferramentas de Processo de Gestão estratégica

 

• Organização Funcional
• Organização Matricial
• Organização Projetizada
• Organização Composta

• Gestão de Demanda
• Gestão de Desempenho
• Gestão do Projeto
• Gestão Financeira 

 

• Processos e Ferramentas de Comunicação
• Processos e Ferramentas de Gestão de Projeto
• Processos e Ferramentas de Gestão de Operação
• Processos e Ferramentas de Suporte
• Processos e Ferramentas de Processos Estratégicos

• Plano da Garantia da Qualidade
• Relatórios da Garantia da Qualidade

• Plano do Projeto
• Controle do Cronograma
• Controle do Custo
• Controle da Qualidade
• Controle do Escopo

Grande Abraço,
Gilberto Ribeiro.

Gestão de Projetos - XIV

Papel de um gerente de projetos

O gerente de projetos é a pessoa designada pela organização executora para atingir os objetivos do projeto. O papel de um gerente de projetos é diferente de um gerente funcional ou gerente de operações. 

Normalmente, o gerente funcional está concentrado em proporcionar a supervisão de gerenciamento de uma área administrativa e os gerentes de operações são responsáveis por um aspecto do negócio principal.

Dependendo da estrutura organizacional, um gerente de projetos pode se reportar a um gerente funcional. Em outros casos, um gerente de projetos pode ser um dos vários gerentes de projetos que se reporta a um gerente de portfólios ou de programas que é, em última instância, o responsável pelos projetos no âmbito da empresa. Nesse tipo de estrutura, o gerente de projetos trabalha estreitamente com o gerente de portfólios ou de programas para atingir os objetivos do projeto e garantir que o plano do mesmo esteja alinhado com o plano do programa central.

Muitas das ferramentas e técnicas de gerenciamento de projetos são específicas ao gerenciamento de projetos. No entanto, compreender e aplicar o conhecimento, as ferramentas e as técnicas reconhecidas como boas práticas não é suficiente para um gerenciamento eficaz.

Além de todas as habilidades da área específica e das proficiências ou competências de gerenciamento geral exigidas , o gerenciamento de projetos eficaz requer que o gerente tenha as seguintes três características :

.1 Conhecimento.

Refere-se ao que o gerente de projetos sabe sobre gerenciamento de projetos.

.2 Desempenho.

Refere-se ao que o gerente de projetos é capaz de realizar enquanto aplica seu conhecimento em gerenciamento de projetos.

.3 Pessoal.

Refere-se ao comportamento do gerente na execução do projeto ou de atividade relacionada. A efetividade pessoal abrange atitudes, principais características de personalidade e liderança; a capacidade de orientar a equipe do projeto ao mesmo tempo em que atinge objetivos e equilibra as restrições do mesmo.

Grande Abraço,

Gilberto Ribeiro.

Métrica de Software - XIV

Generalização, Subtipos e Supertipos.

A relação entre um elemento mais geral – o pai – e um elemento mais específico que agrega informações adicionais e é totalmente consistente com o primeiro elemento – o filho – é chamado de Generalização. 

 

Grande Abraço,

Gilberto Ribeiro.

SCRUM - Implantação XIV

Os Valores do SCRUM

Os valores do Scrum têm como base a transparência, a inspeção e a adaptação.

 

O valor transparência exige que todos os envolvidos no projeto conheçam os aspectos significativos do processo e do projeto. A visibilidade é fundamental para comunicação da equipe, colocando todos na mesma página. A clareza nas informações possibilita que todos tenham o mesmo entendimento, pois todos envolvidos tem que falar a mesma linguagem independente de para quem a pergunta foi formulada, a resposta tem que ser a mesma.

O valor inspeção garante o bom andamento do projeto e viabiliza a adaptação, o terceiro valor do Scrum. Os processos, as práticas e atividades devem ser inspecionadas constantemente para mantermos o projeto dentro do planejado nas Sprints, detectando os desvios o mais cedo o possível. A inspeção também garante que o sistema atenderá os requisitos do negócio, garantindo assim a qualidade do sistema.

O valor adaptação garante as correções dos desvios ao longo do ciclo de vida do desenvolvimento da Sprint, e serve como lição aprendida nas reuniões de retrospectivas do Scrum, evitando que erros detectados nas Sprints anteriores ocorram novamente ao longo do ciclo de vida das demais Sprints. Fazem parte do valor Adaptação quatro eventos formais que são utilizados para inspeção e adaptação:

• Reunião de planejamento da Sprint.
• Reunião diária
• Revisão da Sprint
• Retrospectiva da Sprint

A Adaptação depende da Inspeção e a Inspeção depende da Transparência.

Grande Abraço,
Gilberto Ribeiro.