SCRUM - Implantação XV

Os Papeis do Scrum

Podemos identificar no Scrum três papeis bem definidos, o Dono do Produto ou PO – Product Owner, o Scrum Master e o Time de Desenvolvimento.

O Dono do Produto tem como função principal garantir o ROI - Return on Investment do produto, conhecendo as reais necessidades dos usuários e stakeholders. Dentre as suas habilidades podemos destacar a necessidade da visão estratégica e entendimento do que é valor para o cliente por ele representado, a capacidade de comunicação para conseguir trabalhar em conjunto com os stakeholders capturando as necessidades do cliente e usuários, a facilidade para estabelecer e comunicar a visão do produto para todos os envolvidos, autoridade para exercer suas responsabilidades, o comprometimento com o projeto, as habilidades de negociação, o bom relacionamento interpessoal e o conhecimento sobre o Scrum.

O Scrum Master deve ser um profundo conhecedor da metodologia, tendo domínio sobre suas regras, papéis, eventos e artefatos. Ele atua como mentor, auxiliando o Time de Desenvolvimento e o Dono do Produto a trabalhar melhor com o Scrum. É um facilitador, e deve também, possuir habilidades de comunicação e negociação, além de ter algum conhecimento técnico, saber blindar a equipe contra interferências externas e dar suporte para que o Time de Desenvolvimento seja funcional e produtivo.

O Time de Desenvolvimento, da mesma forma que o Scrum Master, precisa conhecer o framework Scrum, como as suas regras, papéis, cerimônias e artefatos, trabalhar sempre de forma colaborativa, atuando com transparência e sempre buscando entregar o máximo de valor ao negócio. Suas atividades devem estar pautadas pelo conceito de melhoria continua, trabalhando com qualidade e produtividade e principalmente, dado ao número reduzido de papeis, o time deve ser auto organizável.

Grande Abraço,
Gilberto Ribeiro.

Métrica de Software - XV

Entidades Associativas

As entidades que relacionam duas ou mais outras entidades entre si são chamadas de Entidades Associativas.

Grande Abraço,
Gilberto Ribeiro.

Fábrica de Software - XV

Definição das Atividades e Precedências

Com base no WBS definimos as atividades requeridas para a geração de cada fase ou produto. Por exemplo, as atividades básicas para elaboração do produto Plano de Capacitação deve ser elaborado e supervisionado pelos recursos seniores da empresa:

• Preparação do programa de treinamento
• Validação do programa
• Desenvolvimento do material de treinamento
• Validação do material de treinamento
• Programação do treinamento e sua logística
• Execução do treinamento
• Avaliação do treinamento

É necessário o estabelecimento de pontos de controle para a avaliação do progresso do projeto. Geralmente, são atividades de verificação e validação de produtos críticos para o sucesso do projeto. São produtos que estão no caminho crítico do projeto.

Grande Abraço,

Gilberto Ribeiro.

Engenharia de Software - XV

Métricas internas

Métricas internas podem ser aplicadas a um produto de software não executável, tais como uma especificação ou código fonte, respectivamente, durante o projeto e a codificação. Convém que, no desenvolvimento de um produto de software, os produtos intermediários sejam avaliados utilizando-se métricas internas, as quais medem propriedades intrínsecas, incluindo aquelas que podem ser derivadas de um comportamento simulado. O propósito básico destas métricas internas é assegurar que a qualidade externa e a qualidade em uso requerida sejam alcançadas; exemplos são encontrados na ISO/IEC 9126-3. Métricas internas oferecem a usuários, avaliadores, executores de teste e desenvolvedores os benefícios de poderem avaliar a qualidade do produto de software e considerar questões relativas à qualidade bem antes do produto de software se tornar executável.

Métricas internas medem atributos internos pela análise das propriedades estáticas dos produtos de software intermediários ou preparados para entrega. Da mesma forma, as métricas internas podem ser indicadoras de atributos externos.

As medições de métricas internas utilizam números ou frequências de elementos que compõem o software e que aparecem, por exemplo, em declarações de códigos-fonte, no gráfico de controle e nas representações de fluxo de dados e de transição de estados.

Grande Abraço,

Gilberto Ribeiro.

Gestão de Projetos - XV

Conjunto de conhecimentos em gerenciamento de projetos

O Guia PMBOK® é o padrão para gerenciar a maioria dos projetos na maior parte das vezes em vários tipos de setores da indústria. Descreve os processos, ferramentas e técnicas de gerenciamento de projetos usados até a obtenção de um resultado bem-sucedido.

Esse padrão é exclusivo ao campo de gerenciamento de projetos e tem relacionamento com outras disciplinas de gerenciamento de projetos, como gerenciamento de programas e gerenciamento de portfólios.

As normas de gerenciamento de projetos não abordam todos os detalhes de todos os tópicos.

Esse padrão limita-se a projetos individuais e aos processos de gerenciamento de projetos amplamente reconhecidos como boa prática. Outros padrões podem ser consultadas para a obtenção de informações adicionais sobre o contexto mais amplo no qual os projetos são realizados. O gerenciamento de programas é abordado em A Norma para Gerenciamento de Programas (The Standard for Program Management) e o gerenciamento de portfólios é abordado em A Norma para Gerenciamento de Portfólios (The Standard for Portfolio Management). O exame das capacidades do processo de gerenciamento de projetos de uma empresa é abordado em Modelo de Maturidade de Gerenciamento de Projetos Organizacionais (Organizational Project Management Maturity Model, OPM3®). 

Grande Abraço,

Gilberto Ribeiro.

O Propósito do Guia SCRUM - XII

A palavra SPRINT tem como tradução arrancada, corrida de velocidade, logo quando a escrevemos nos referindo ao termo, o correto é a SPRINT ou da SPRINT,  o mais importante é que ela é o principal evento do SCRUM.

46. 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.

47. 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.

48. 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.

49. Como podemos descrever 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.

50. 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.

Requisitos - XVI

Produção

A partir da implantação da aplicação entra em cena a equipe de produção, que algumas vezes é um subconjunto da equipe de suporte. Eis algumas tarefas da equipe de produção :

• Fornecer suporte ao uso da aplicação
• Inspecionar logs de eventos gerados pela aplicação identificando possíveis problemas em  produção
• Montar uma linha base de performance para a aplicação
• Conhecer as características da aplicação de forma a poder auxiliar a equipe de suporte no planejamento do remanejamento da aplicação em relação aos servidores da empresa.
• Apontar para a equipe de desenvolvimento problemas de performance na aplicação

Possíveis rupturas no processo

Mesmo muito bem organizado da forma como aqui foi descrita, podem ocorrer rupturas nesse processo de desenvolvimento que causarão problemas de custo e cronograma :

• Excesso de alterações na especificação durante a etapa de codificação
• Excesso de erros em homologação ou produção
• Dificuldade na comunicação entre o analista e os desenvolvedores
• Cronogramas imprecisos 

Excesso de alterações na especificação durante a codificação

Isso pode ser causado por uma inicial inexperiência de um analista. Deve-se registrar este fato como um índice qualitativo do processo de desenvolvimento e o analista deve utilizar cada ocorrência para aperfeiçoar-se, reduzindo este valor a cada projeto realizado.

Excesso de erros em homologação ou produção

Isso ocorre por inexperiência dos testers, responsáveis por identificar os erros da aplicação. Da mesma forma que o item anterior, isso deve ser registrado como um fator qualitativo do processo e os testers devem utilizar cada ocorrência para aperfeiçoar-se e reduzir este valor

Dificuldade na comunicação entre o analista e os desenvolvedores

Uma das rupturas mais críticas, quando o analista, por estar muito envolvido com o negócio, passa a ter dificuldade de se comunicar com o desenvolvedor e suas especificações se tornam mais distantes do ambiente físico da codificação.

Neste caso torna-se necessária a utilização de um arquiteto de sistemas como intermediário entre o analista e o desenvolvedor. Deve-se tomar muito cuidado na escolha de quem irá realizar esse papel, pois a pessoa deve ser capaz de utilizar a linguagem de negócio e traduzi-la para os desenvolvedores, tendo liberdade de requisitar alterações nas especificações quando estas estiverem por demais distantes do ambiente físico. Essa pessoa deve estar altamente atualizada para definir as melhores tecnologias para cada projeto.

Cronogramas imprecisos

Isso normalmente reflete uma inexperiência do analista na especificação do tempo para desenvolvimento. Neste ponto duas coisas devem ocorrer :

O analista deve usar as falhas de cronograma para aperfeiçoar-se em termos de calculo de duração de um projeto

Deve-se aperfeiçoar a aplicação da técnica de análise de pontos de função de forma a depender o mínimo possível do instinto do analista

Grande Abraço,

Gilberto Ribeiro.