Scrum (overview)

Há algum tempo o companheiro “Fernando Zambroti” dividiu sua sapiência com alguns pobres mortais (como o esvrevente deste pequeno blog) sobre este assunto: SCRUM (não sei a causa do nome, me parece que veio de alguma modalidade esportiva … mas, isso não importa!)

Como esse termo é a “bola da vez” em quando se fala de metodologia de desenvolvimento de aplicações (ou ALM, como indica a vertente deste canal!)

Em linhas gerais, quase ´por tópicos’ este post pretende registrar o que foi aprendido com o Fernando nessa ocasião…

O  que conhecemos de modelo de gerenciamento de projetos?

Quase todos os modelos se assemelham em maior ou menor grau ao Modelo Waterfall (cascata) e as principais notícias de projetos de software são variações de:

 

  • Problemas nas estimativas (justificam o atraso do projeto!?)
  • Prazos não cumpridos com justificativas de que os “prazos são apertados ou insuficientes” – o que remete ao item anterior!?
  • Mudança de escopo (as necessidades mudam com o decorrer do projeto…)
  • Equipe sempre acredita que vai dar tempo (essa é a pior das crenças!)
  • Mas… o Aviso de que não vai dar tempo normalmente ocorre no último dia, quando não no último minuto antes da previsão de entrega)
  • Cada integrante tem responsabilidade com a “sua parte” – (sempre sobra para alguém!)
  • Teoricamente tem outras pessoas olhando para as demais tarefas – (retórica? ou prática?)

Em resumo, o que se têm é a sequência fatídica (death’s fall!?)

Planejamento

Desenvolvimento

Entrega (onde o problema aparece!)

 

O que é vivenciado em projetos de software?

 

  • O Processo de desenvolvimento de software normalmente tem uma complexidade muito elevada;
  • A forma de execução das atividades é fortemente dependente do executor pois exigem atividades racionais;

Desenvolvimento de Software não é “commodity”

O que isso significa?

Construir uma aplicação não é  tão “simples” como construir uma Casa.

Quase todas as Engenharias nasceram de processos empíricos (experimentação, tentativa + erro), e a Engenharia de Software também segue este padrão.

Acontece que, as demais engenharias (e digo agora especificamente a Engenharia Civil) acompanha a humanidade desde que os nossos ancestrais biológicos sairam das cavernas e começaram a construir suas residências. O tempo de maturidade de uma Engenharia Civil, por exemplo, a coloca na posição de “commodity” dada à sua maturidade e a sua curva de evolução (que hoje depende mais de novos materiais e suas técnicas de aplicação do que da Engenharia propriamente dita!).

A Engenharia De Software, por sua vez, tem no máximo uns 50 anos de existência. Se colocarmos as existências das duas Engenharias citadas numa proporção de linha de tempo na escala de duração de um jogo de futebol A Engenharia Civil surgiu logo após o apito inicial do jogo equanto a Engenharia de software surgiu apenas alguns milisegundos antes do juiz apitar o fim da partida!

Ou seja, o principal problema a ser resolvido pela EngSW é a Gestão de

  1. Processos empíricos que normalmente são …
  2. Complexos, caóticos, ou com muita incerteza. E que demandam
  3. Atividades ciclicas com durações variáveis agregadas às
  4. Dificuldades em estimativa de tempo.

Como o Modelo SCRUM pretende endereçar isso?

A Visão SCRUM é direcionada à Gestão de Processos Empíricos onde são fixados alguns parâmetros tais como:

 

  • Parametros de contexto
  • PRAZO (fixado, mas não é o prazo final do projeto) – é o que veremos a seguir com o nome “SPRINT”.
  • ESFORÇO
  • EQUIPE (ESTRUTURA)
  • Parametros de saída
  • Objetivo
  • Critério de avaliação
  • Parametro de entrada fixo
  • Backlog. (lista das atividades)
  • Prioridades.
  • Estimativa.

Para isso, o alicerce da metologia SCRUM é a tática do JACK (ou do Napoleão, como quiserem!) “Dividir para conquistar”. O projeto inteiro passa a ser divididos em entregas parciais em espaços de tempo fixos e recorrentes onde, em cada intereação (ou SPRINT) é a plicado o …

Modelo  PDCA

Planejamento (PLAN)

Sprint planning

Fazer (DO)

SPRINT

Verificar (Check)

Sprint Review

Agir (Act)

Sprint Restrospective

 

 

 

O foco nas entregas parciais, totalmente funcionais nos sprints é o que permite realizar as entregas de maior valor agregado para o cliente, conforme as prioridades determinadas por ele.

 

Palavra de ordem : gerenciamento da expectativa! 

Em síntese:

  • As necessidades de negócio geram o Backlog.
  • 80% do valor de negócio está em aproximadamente 20% das atividades
    • Isso significa Priorizar as atividades que são mais importantes.
  • O Escopo completo é dividido em escopos menores que caibam nos SPRINTS sendo que
  • Os escopos por sprint são minimalistas
    • e a Decisão técnica fica ao encargo da equipe.
  • Os riscos podem ser minimizados através da definição de:

 

                    • Critérios de aceite.
                    • Premissas
                    • Experiência de equipe

 

  • Refactoring (possível para o próximo sprint)

 

 

 

 

 

SCRUM FRAMEWORK

PAPEIS: (não confundir com CARGO!)

  • Product owner

    PO

    É o cara (não é o cliente)  é o que está do lado do cliente.

    Faz o levantamento dos requisitos, montar o backlog, é o equivalente ao analista de negócios.

    Características dos produtos

    Gerenciar o backlog e priorizar.

    Responsável pelo “ACEITE” do entregável da equipe.

    Faz a análise do ROI (Revenue of Investiment)  para cada item do backlog.

    Responsável pela Entrega

    Scrum Master

    SM

    É o cara da equipe cuja principal responsabilidade  é fazer com que a metodologia esteja sendo aplicada no projeto

    Atualização de quadro

    Impedimentos (remoção dos …)

    Execução das reuniões (condução)

    Team

    T

    Equipe de trabalho. – normalmente 7 pessoas em média (+- 2). De 5 a 9 pessoas. Um número excessivo de pessoas pode tornar o processo improdutivo. Não existem papeis pré definidos. A liderança normalmente é suscitada naturalmente. (MERITOCRACIA).

 

Não existe nenhuma entidade regulamentadora que define  os padrões scrum. (e essa é a melhor parte!)

 

Quais são os eventos (ou cerimônias) que ocorrem em um SPRINT?

Sprint Planning

  • estimativa(P1)
  • planejamento (P2)

Início do sprint

Todos participam.

PO olha o backlog e prioriza.

A equipe estima o prazo (P1) – estimativa de complexidade – o que é mais importante e o que é mais fácil para desenvolver (menor complexidade).

Na reunião de planejamento (P2) os itens de backlog estão priorizados e com a complexidade definida. Nesta reunião ocorre o comprometimento com a entrega no sprint atual.

Neste caso, a equipe elenca os artefatos que serão entregues no fim do sprint e define o OBJETIVO do sprint que não representa necessariamente  o total das entregas realizadas.

–> Objetivo é norteado por necessidades de negócio.

 

Sprint Review

Fim do sprint

A equipe faz a entrega para o PO que formaliza o Aceite, faz a devolução de itens ao backlog (Product Backlog) e reprioriza o BackLog.

A equipe pode ser reformulada (se necessário)

Sprint Retrospective

Fim do sprint

Parecido com o “Lessons Learned” do PMBoK

Daily Scrum Meeting

diário

Checkpoint diário rápido de acompanhamento. Normalmente conduzida pelo SM com a equipe e o PO.

 

ARTEFATOS:

Product backlog

 

Necessidades de negócio a serem atendidas (ao longo de todo o projeto)

Sprint backlog

 

Tarefas (relacionadas a cada product backlog)

Burndown charts

 

Relatório de acompanhamento do Projeto.

 

E quanto à ESPECIFICAÇÃO?

O conjunto de detalhes está embutido no entendimento das funcionalidades, que são mapeadas através dos “User stories”.

  • Pode haver um conjunto de tarefas inerentes à um user histories.
  • As user hstories podem ser quebradas em user stories mais específicas
  • (a história original morre, neste caso)
  • O Product backlog é o conjunto de user stories.
  • Product Backlog Item = user story

 

Uma boa história deve ser…

  • Independente
  • Negociável
  • Valorizável
  • Estimável
  • Pequeno
  • Testável

Assim, o SCRUM endereça o desenvolvimento de software com base em 2 princípios fundamentais para conseguir o sucesso no desenvolvimento de software:

  • Planejamento Estratégico
  • Trata do “negócio” para a empresa
  • Planejamento Tático
  • O que será feito para que o planejamento estratégico seja efetivado (realizado)

Mas… e sobre as estimativas?

Há uma técnica de definição de complexidade utilizada para as estimativas, com base em  valores de uma “série de fibonacci” (o que é, no SCRUM chamado de story points) mas isso vai demandar um post específico para este assunto.

Parece que eu já vi esse filme (será um remake?)

Provavelmente você, meu caro leitor, deve ter identificado alguns elementos comuns da metodologia SCRUM com o que se chama “Extreme Programming”, Agile, … e isso não é mera coincidência. O cerne principal dessa metodologia é justamente a mola mestra denominada “Desenvolvimento Interativo”.

Como levantar requisitos, na prática

 

 

o Problema…

Imagine um sistema de matrícula escolar de alunos da 1ª série do ensino médio. (e é isso tudo o que o cliente diz!)

… aí você respira fundo, toma um gole de água e começa a sua SAGA rumo à definição do escopo..

Solução

Para obtenção dos requisitos necessários algumas perguntas pertinentes são as seguintes:

  1. Quais são as expectativas de uso do sistema?
  2. Qual o objetivo?
  3. Quais demandas de negócio este sistema visa melhorar/resolver? (isto é… Qual é a DOR de negócios sentida  na escola e qual a visão de solução que o cliente já tem…) ?
  4. Quais são as informações necessárias para a realização da matrícula?
  5. Haverá carga de documentos (Xerox, digitalização dos documentos, etc) para anexar ao processo?
  6. O sistema deverá ter acesso pela internet, intranet ou pela estação (Cliente) da secretária da escola?
  7. Quais são os processos de matrícula para os alunos oriundos da mesma escola?
  8. E quais os processos para alunos oriundos de outras escolas?
  9. Haverá algum processo automático de distribuição dos alunos nas salas de aula?
  10. Haverá algum processo de aprovação de uma matrícula requisitada através do sistema?
  11. Quais são os elementos de infra estrutura disponíveis (ou desejados) para hospedagem do sistema? Servidores, softwares, licenças disponíveis, sistema operacional?
  12. Qual o número de alunos da escola, taxa de crescimento de alunos por ano (ou por sazonalidade de matrícula), qual o volume de alunos e informações agregadas se deseja que o sistema suporte?
  13. Pretende-se estender o sistema de matrícula para um sistema acadêmico completo? Quais são os sistemas que existem na escola atualmente? Haverá necessidade de integração com algum sistema de controle educacional do governo? (prefeitura, estado)
  14. Que tipos de informações se deseja extrair do sistema (quais os tipos de relatórios desejados)

Esses são exemplos direcionados à uma requisição de sistema para controle de matrículas… que podem gerar um conjunto de requisitos (funcionais ou não)…

Requisitos Funcionais (exemplo)

O sistema será uma aplicação Web disponível na internet através do site http://www.secretariaescolar.com.br e deverá prover as seguintes funcionalidades:

  • Cadastro de alunos com base no seguinte conjunto de informações:
    • Nome
    • Nome dos pais
    • Informações pessoais: Data de nascimento, RG, CPF, Endereço
    • Escola de origem
    • Ano de conclusão do Ensino Fundamental
    • Imagem dos documentos de matrícula (histórico escolar, RG, CPF, etc)
  • Com base no cadastro, o sistema deverá permitir a realização do controle de matrícula com base no seguinte fluxo:
    • O aluno preenche o cadastro no site supra citado. Ao fim do cadastro, o aluno deverá ser conduzido a uma tela com o conteúdo dos termos de contrato da escola e sinalizar sua aceitação (que deverá ser condicionante para a continuidade do processo;
    • Ao aceitar os termos, o aluno é conduzido a um formulário de solicitação de matrícula onde deverá preencher os dados relativos à sua condição escolar atual;
    • Após atela de cadastro, o aluno deverá realizar o upload da digitalização de seus documentos (para efeitos de controle de crescimento de massa de dados, cada imagem não deverá ultrapassar a 100kb e estar na extensão JPEG):
      • Histórico escolar
      • RG
      • CPF
    • Findo o upload dos arquivos, o aluno receberá um número de protocolo e uma agenda de data de limite para contato da escola.
  • Todas as matrículas submetidas serão encaminhadas à secretária que deverá registrar (via sistema) a leitura e o deferimento dos protocolos.
  • Após o deferimento dos protocolos, o status da matrícula passa a “Aprovado”.
  • O sistema deverá conter a consulta ao status do processo através do número de protocolo informado ao usuário no ato de matrícula.
    • Os status possíveis são:
      • Em análise;
      • Deferido;
      • Indeferido.
  • Entre as consultas disponíveis ao usuário da Secretaria estão:
    • Matrículas Aprovadas;
    • Matrículas Rejeitadas (indeferidas)/motivo
    • Protocolos pendentes de aprovação;
  • Apenas a extração dos relatórios e operações específicas da secretaria será realizada sob controle de login/senha.

Requisitos Não-Funcionais

Entre os requisitos não funcionais mapeados estão os seguintes:

  • O site deverá ser construído com o uso da tecnologia ASP.NET 2.0;
  • O SGBD a ser utilizado para a manutenção das informações do site deverá ser o SQL SERVER 2008 EXPRESS;
  • As consultas do site não deverão ultrapassar o limite de 5s (considerando a experiência do usuário final);
  • O sistema deverá ser hospedado em um único servidor (tanto para aplicação quanto para dados).

Por fim, o escopo

 

o escopo é formado pelo desenvolvimento dos Requisitos Funcionais com base nos requisitos Não Funcionais.

 

SE houver algo que você (ou a sua empresa) não saiba fazer ou não queira fazer (ou algo que o cliente não queira pagar para ter) você elenca como “Requisito INVERSO”

 

Simples, não é?

Onde começa o ciclo de vida de uma aplicação…

Há mais ou menos 2 anos (um pouco mais ou um pouco menos…) eu ‘rompi’ a película que divide os “DEV-MAN” dos “BIZ-MAN”…

Comecei a atuar no “lado negro da força” (segundo os Dev que se acham Jedis! [sic]) … como Arquiteto de soluções focado em “Pré vendas de serviços”.

O maior desafio, no meu caso, foi ampliar a visão puramente técnica, cheia de restrições disso, restrições daquilo e o que é pior: A arrogância técnica de que a solução deve ser a mais “PERFEITA” com todas as novas tecnologias, boas práticas, patterns complicadérrimos… isso sem contar de que o código feito pelos outros é sempre uma “porcaria”… então eu pego e FAÇO TUDO DE NOVO, DO MEU JEITO e PONTO FINAL. [humpf] [sic] (acredite! estou falando de mim mesmo!)

ACONTECE que, por trás de um novo projeto tem sempre um “gerente comercial” cansado!

O ciclo de vendas de uma solução (projeto de software, como é o meu caso) é normalmente muito longo (não é como vender caixinhas, acreditem!)

O que faz um Pré-vendas? Especialmente um Pré Vendas que trabalha essencialmente com “Custom Development” ?

RESP: (de um técnico) …” ah.. fica aí fazendo ppt, usando o Word, usando o Visio pra fazer uns desenhinhos… nem lembra mais como usa o visual stúdio. fica enrrolando por ae, fazendo visitinha em cliente… pararí parará… “

Na verdade, toda essa introdução é para chamar a atenção para um assunto pouco discutido sobre ALM:

Quando começa a ‘vida de uma aplicação’ ?

Para uma empresa que VIVE de desenvolvimento de aplicações, o ciclo de vida começa BEM ANTES do “Deal”.

Na prática, mesmo para empresas que tem um time de desenvolvimento interno (empresas cujo o Core Business não seja desenvolvimento), o ciclo de vida de uma aplicação começa em uma oportunidade (ou demanda) que vira uma proposta que é negociada em termos de esfoço e prazo (custo/preço) em função das capacidades (ou funcionalidades/requisitos).

Isso me remete a algo que ouvi há mais de dois anos (quando estava no programa ‘Green badge’ lá na Microsoft):

    • You can’t propose without a price.
    • You can’t price without an estimate.
    • You can’t estimate without a plan.
    • You can’t plan without a work breakdown structure (WBS).
    • Therefore, you need a WBS to write a Proposal/SOW.

A elaboração de uma proposta é um trabalho de análise, que normalmente é feito com o menor tempo possível e com a melhor qualidade possível) para minimizar o ‘custo da venda’.

Considerando que a análise e o projeto de um sistema de informações devem ser conduzidos de forma sistêmica a fim de produzir uma especificação coerente e adequada às necessidades de negócio em específico na solução de um problema computacional (processo) bem delimitado (escopo) há de se considerar que o início desta tarefa é dado pela objetivação do sistema, ou seja, responder à seguinte questão: Por quê? Qual o motivo de existência do sistema? Qual o seu propósito? Quais são os ganhos em se criar o sistema?

A responsabilidade de obter a resposta para esta primeira indagação é do requisitante (quem precisa do sistema!). Isso normalmente é feito através da figura do “PATROCINADOR”, ou no termo inglês normalmente usado no mercado, SPONSOR.

Seguindo o conceito suscitado pelo termo (objetivo) esta declaração deve ser concisa e capaz de explicar a razão de existência do sistema em um único parágrafo.

O Objetivo do sistema deve nortear as demais fases da análise, projeto, desenvolvimento e estabilização de um sistema de informações.

A prática de mercado mostra que a falta de atenção a este item é o principal motivo de frustrações dos projetos de software posto que, isso provoca desvios enormes entre o que foi solicitado e o que foi entregue (com atraso, diga-se de passagem) ao solicitante.

Com os objetivos definidos, refina-se a análise determinando o seu contexto de aplicabilidade. O contexto deve informar ao analista quais são os macro-fluxos de entrada (input) e saída (output) necessários ao sistema em projeto.

É nesta fase que o analista poderá “sentir o cheiro da confusão”, ou seja, intuir sobre os riscos inerentes ao projeto ao definir as entidades externas (outros sistemas a serem integrados, usuários) que servirão de provedores ou consumidores dos dados desse sistema bem como seus canais de comunicação.

Pode-se , a partir do contexto, refinar a análise dos escopos menores determinando-se os eventos e suas expectativas de resultados mediante um conjunto especificado de entradas.

O conjunto de refinamentos sucessivos a partir da listagem dos eventos do sistema transpassam a fronteira da análise essencial para a análise comportamental do sistema onde devem ser detalhados (sucessivamente) seus componentes (estruturas de dados) e as formas de interação desses componentes (fluxos de processamento).

Para este fim, o analista se vale de técnicas, normalmente diagramais, como a criação dos diagramas de Entidade e Relacionamento (ERD), diagramas de fluxo de dados, Normalização de dados, especificações modulares, diagramas arquiteturais, etc.

Comparativamente, temos que este processo de análise essencial e comportamental, também conhecida como estratégia TOP-DOWN, é similar a um “vôo de águia” em situação de ataque.

Tal abordagem é ainda muito utilizada no mercado de desenvolvimento de software (ainda que de forma oficiosa ou habitual) e é, normalmente, encoberta na execução de análises Orientadas a objetos (com UML).

Normalmente divide-se um grande sistema em pequenas partes  para que os objetivos, ao se compor essas peças do “quebra-cabeças” num sistema completo que atenda aos objetivos propostos.

Esse ciclo todo é o que compreende a “PREPARAÇÂO” da proposta. A Proposta pode então, através de um ‘gerente comercial’ virar finalmente um DEAL, ou um CONTRATO…

E o que é necessário para ‘fazer uma aplicação nascer’ ?

A “Gestação” de uma aplicação, por assim dizer, é uma boa metáfora para o “Processo de venda”

A concepção se dá pelo encontro da “NECESSIDADE” (Business needs) com a “PROPOSTA” (que entre milhões de propostas, somente uma delas vira um DEAL”).

Para que a “Necessidade” encontre a sua “Proposta” ideal há todo um conjunto de condições que têm de ser satisfeitas.

Uma das coisas que tenho percebido nesses últimos anos é que uma proposta tem maiores chances de virar um “deal” se houver a conjunção de 3 fatores (atitudinais) inerentes (ou trabalhados) ao Arquiteto de soluções, a saber:

  • Alinhamento de negócios: basicamente, o arquiteto de soluções deve pensar como o CEO e CFO (orientar a solução para as necessidades do negócio com o menor custo possível)
  • Visão em perspectiva: A mesma “Dor” do cliente pode ser “sentida” de diversas formas diferentes pelos seus pares. Conseguir o máximo de informações possível de como “a falta ou deficiência de um sistema” dói nos diversos envolvidos é um fator decisivo para o  sucesso na conversão de propostas em um “contrato”
  • Comunicação: FALAR A LÍNGUA (ou o mesmo idioma) do cliente (e de todos os envolvidos do lado do cliente). Parece óbvio mas, de tão óbvio, não prestamos atenção (falando como técnico, mesmo!) nesse detalhe. (Hoje mesmo eu cometi esse tipo de gafe durante uma apresentação de proposta num cliente…)

De forma esquemática, a “concepção” de uma solução acontece a partir do cenário ilustrado abaixo:

image

Quando a proposta vira DEAL, ela (a proposta) é o documento formal que deve servir de base para gerar os requisitos, especificações detalhadas, workitens, product backlog, etc… que precisam ser gerenciados para que a solução planejada (e orçada) seja construída como foi proposto, no prazo em que foi proposto e com o custo (preço, na visão do cliente!) que foi proposto.

… o resultado disso é o que dá subsídio para a etapa seguinte  que culmina com o “trabalho de parto”  da aplicação.

MSIO – Infrastructure Optimization : Linhas gerais

O processo MSIO tem como objetivo mapear a maturidade em tecnologia de informação (TI) a fim de que esta seja utilizada para suportar e fomentar negócios em uma empresa.

O mapeamento é realizado a partir de três modelos:

  • Core Infrastructure: onde são mapeadas a maturidade das competências de infra estrutura. Tem como objetivo otimizar os recursos de infra estrutura disponíveis. Entre as competências desse modelo estão:
    • Gerência de identidade e acessos;
    • Gerência de Servidores, dispositivos e estações de trabalho;
    • Segurança e rede;
    • Proteção e recuperação de dados.
  • Business Productivity: onde são mapeadas a maturidade das competências de negócios. Tem como objetivo otimizar os processos de trabalho com base na tecnologia. Entre as competências desse modelo estão:
    • Comunicação unificada;
    • Colaboração;
    • Gerência de Conteúdo;
    • Buscas / Pesquisa;
    • Business Intelligence;
  • Application Plataform: onde são mapeadas a maturidade das competências da plataforma de aplicações. Tem como objetivo otimizar o planejamento e desenvolvimento e manutenção das aplicações usadas para suporte ao negócio. Entre as competências desse modelo estão:
    • Experiência do usuário;
    • Business Intelligence;
    • SOA (Services Oriented Architecture – Arquitetura orientada a serviços) e processos de negócios;
    • Gerenciamento de dados;
    • Desenvolvimento;

Em cada um dos modelos, as competências são classificadas em quatro estágios:

  • Básico: Onde a competência tem características reativas, com baixo ou nenhum planejamento e direcionada a resolução contínua de problemas. Neste estágio, a competência colabora para que o modelo seja um “gerador de custo”.
  • Padronizado: Neste estágio, a competência tem características reativas, orientada à requisições e uma incipiente gestão de mudanças.
  • Racionalizada: Neste estágio a competência tem características proativas e orientadas à Qualidade. Neste caso, a competência colabora para que o modelo seja “gerador de lucro” ou “fomentador de negócios”;
  • Dinâmico: Neste estágio, a competência tem características proativas, orientadas à qualidade, agilidade com redução/otimização de custos e melhoria contínua.

clip_image001

Figura 1 – Sumário do processo MSIO

 

Maiores informações : http://www.microsoftio.com