sexta-feira, 10 de maio de 2013

SCRUM - Implantação II

Dando continuidade aos artigos anteriores, neste post começo com um caso real de consultoria na implantação do framework ágil Scrum em uma Fábrica de Software.

Fundamentando o Conhecimento

A empresa participante da consultoria utilizava o modelo de gestão proposto pelo PMI e o modelo de desenvolvimento de sistema em Cascata, incompatível com sua velocidade comercial, gerando diversos problemas pelo curto espaço de tempo entre a realização da elicitação dos requisitos e a entrega do produto, dada a velocidade, competitividade do mercado e as exigências do cliente.

Durante a consultoria levei em consideração o perfil da empresa, identificando todos os processos internos apoiado na certificação já existente – ISO 9001, que já contemplava as fases de concepção, planejamento, implementação, estabilização e entrega. Apesar da certificação identifiquei também o desconhecimento e resistência em fazer uso do processo existente na empresa, causada por vícios culturais na organização.

A proposta e adoção das boas práticas do framework Scrum na gestão de projetos de desenvolvimento de sistemas proporcionou a melhoria na qualidade dos processos e gestão do ciclo de vida do produto na organização, contribuindo para diminuição do retrabalho, aumentando a produtividade, racionalizando o uso dos recursos e contabilizando ativos para Fábrica de Software. Mas vou contar essa história ao longo dos textos, objetivando compartilhar conhecimento com a comunidade de TI.

Quanto prestamos uma consultoria, devemos levar em consideração diversos fatores que permeiam um organização, pois trata-se de um organismo vivo e que reponde aos estímulos de forma positiva ou negativa, dependendo da nossa abordagem profissional.

A dinâmica do mercado, a necessidade de melhoria no modelo de gestão e dos processos de engenharia de software, o aumento da complexidade dos sistemas, que no passado não demandavam tanta inteligência, as regras de negócio, o mapeamento sofisticado de processos e o conhecimento específico sobre o domínio do negócio, motivou a mudança no modelo de gestão e reavaliação dos processos de Engenharia de Software, resultando na proposta e implantação do framework Scrum na Fábrica de Software.

A empresa em questão fazia uso do modelo de gestão proposto pelo PMI - Project Management Institute e do modelo tradicional de desenvolvimento de software Waterfall[1] (Cascata). Os modelos em uso exigiam um esforço muito grande da equipe de desenvolvimento, em especial dos analistas de requisito, pois a falta de um especialista no negócio dificultava o entendimento do domínio necessário para elaboração da proposta comercial. Para os clientes eram conceitos triviais, pois faziam parte do seu dia-a-dia, mas para os analistas de requisito não eram de fácil entendimento, visto que assim como a socialização com os jargões da profissão levavam tempo considerável, o que dificultava a especificação do projeto do sistema, sem contar com o retrabalho dos analistas de sistema e arquitetos que só participavam do processo após a definição do escopo do projeto e aceite da proposta pelo cliente, precisando validar o escopo com os fornecedores de requisitos antes de iniciar o projeto, passando a impressão de falta de comunicação interna e desorganização.

Limitei a princípio, o escopo da consultoria, ao modelo de gestão de projetos e ao processo de desenvolvimento dos sistemas praticados na empresa, com base na complexidade dos projetos desenvolvidos. Existia a necessidade de desburocratizar os processos de gestão, melhorar os processos de desenvolvimento dos sistemas fazendo uso das boas práticas de Engenharia de Software, e  de envolver um especialista no negócio durante o ciclo de vida dos projetos, tornando o processo de gestão e de desenvolvimento compatível com a velocidade comercial da empresa e com o negócio do cliente.
Observei também, no processo existente, uma grande queda de braços. De um lado o cliente querendo colocar o máximo de funcionalidade possível e do outro a empresa desenvolvedora, tentando limitar o escopo para elaboração de uma proposta comercial, com o menor esforço para a equipe de desenvolvimento.

Como implantar um modelo de gestão enxuto e ágil, garantindo prazos, custos e qualidade nos projetos de desenvolvimento de software? Ao longo dos artigos esta pergunta será respondida.

Grande Abraço,
Gilberto Ribeiro.



[1] O modelo Waterfall é um modelo de desenvolvimento de software sequencial no qual o desenvolvimento é visto como um fluir constante (como uma cascata) através das fases de análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software. A origem do termo cascata é frequentemente citado como sendo um artigo publicado em1970 por W. W. Royce; fonte: http://pt.wikipedia.org/wiki/Modelo_em_cascata.

Perfil Profissional - II

Dando continuidade ao post sobre Perfil Profissional, os diagramas abaixo demonstram as interações dos  profissionais com processo de Engenharia de Sistemas e suas responsabilidade.

Interação I



Interação II


Interação III


Interação IV


Interação V


Com base no processo de engenharia de software, no próximo post, montarei a base de cada perfil que participa do processo.

Grande Abraço,
Gilberto Ribeiro.

Métrica de Software - II

APF - Análise de Ponto de Função

Conceito básico: é a visão do usuário, baseada nos requisitos funcionais do sistema.

Base para análise:
  • Análise de Requisitos
  • Estimativa
Contagem:

Para estabelecermos a contagem de Ponto de Função é fundamental estabelecermos a fronteira entre o sistema que está sendo medido e o mundo exterior. (usuário, outros sistemas...).

Especificar a fronteira baseado na perspectiva de negócio (onde acaba um sistema e onde começa o outro)

Processo da Contagem APF
  • Definir o propósito da contagem para nortear todo o processo.
  • Reunir toda documentação disponível.
  • Determinar o Escopo e a Fronteira da Contagem, identificando os requisitos funcionais do usuário.
Passo a passo da contagem
  1. Identificar o propósito da contagem.
  2. Identificar o tipo de contagem com base no objetivo. (projeto de desenvolvimento, projeto de melhoria ou aplicação pronta).
  3. Determinar o escopo da contagem, com base no objetivo e tipo de contagem.
  4. Determinar a fronteira de cada aplicação contida no escopo da contagem com base na visão do usuário não levando em consideração a técnica.
  5. Medir função de dados (ALI e AIE).
  6. Medir funções de Transações (EE, SE, CE).
  7. Calcular o tamanho funcional.
  8. Documentar e Reportar.
 
Glossário
  • ALI - Arquivo Lógico Interno
  • AIE - Arquivo de Interface Externa
  • EE - Entrada Externa
  • SE - Saída Externa
  • CE - Consulta Externa
Grande Abraço,
Gilberto Ribeiro.

O Propósito do Guia SCRUM - II


O modelo tradicional presa pela especificação detalhada dos requisitos, com objetivo de:
  • Planejar e desenhar a solução.
    • A questão é: será que tudo o que foi especificado atende às necessidades do cliente?
    • O próprio cliente seria capaz de descrever tudo o que deseja?

O abordagem do modelo tradicional é o BRUF - Big Requirements Up Front.
  • Mas esta técnica tem um agravante, porque o cliente não terá poderá mudar o escopo após a contratação, a tendência é que ele inclua o máximo de funcionalidades, até algumas funcionalidades raramente utilizadas, elevando o custo do projeto.
  • Esta abordagem é interessante quando conhecemos os requisitos.

No modelo tradicional criamos:
  • Um plano de projeto incipiente o que impactará no ciclo de vida.
  • Estimativas relativamente precisas para o projeto.
  • Controle de mudanças preventivamente.
  • Métrica em termos de valor agregado durante o ciclo de vida.

Em contrapartida, para implantarmos o framework SCRUM precisamos conversar mais e escrever menos.

Ações que devemos adotar para nos tornamos ágeis:
  • Conversar mais e escrever menos.
  • Escrever somente aquilo que realmente é necessário para o desenvolvimento do sistema.
  • Demonstrar o software constantemente aos usuários e obter feedbacks de forma contínua.
  • Ter a consciência que os requisitos mudam ao longo do tempo e que os usuários só sabem o que realmente querem quando usam o software.
  • Aprender progressivamente sobre o sistema.
  • Ajustar os itens a serem desenvolvidos, a medida que aprendemos o domínio do negócio.
  • Estar preparado e aceitar as mudanças de forma natural.
  • Ações preventivas contra as mudanças não devem ser realizadas.

Grande Abraço,
Gilberto Ribeiro.

Engenharia de Software - II

Até os anos 80, no Brasil, o processo de desenvolvimento de software caracterizou-se como um processo artesanal. O foco era no fechamento do negócio, precisávamos ganhar dinheiro e programar, custe o que custar. E o cliente? E o retorno do investimento? E o diferencial competitivo no mercado? Pois esta pode ser uma das razões que justificaram o investimento no sistema, na automação.

Este cenário começa a mudar com o surgimento do conceito de FÁBRICA de SOFTWARE. Pois é, o que a grande maioria encara como novidade, surgiu em meados da década de 80 e só foi colocado em pratica em 1993 no mercado paulista.

Antes, conceitos como gerenciamento de projetos e melhoria continua (qualidade), não eram vistos como necessários. Com a inserção no mercado internacional, as normas de qualidade passaram a ser adotadas, possibilitando a prestação de serviço em um mercado globalizado.

Quando me perguntam qual a metodologia que eu uso no processo de desenvolvimento de software, eu respondo com outra pergunta: Você conhece as normas da ABNT?

Abordaremos os seguintes temas:

Primeira parte: 
  • Normas ABNT
Segunda parte:
  • Fábrica de Software
Terceira parte:
  • Formação da Equipe
  • Análise de Requisitos: Quem participa do processo e quais os artefatos gerados?
  • Arquitetura de software: Quem participa do processo  e quais os artefatos gerados?
  • Análise do Sistema: Quem participa do processo  e quais os artefatos gerados?
  • Teste de Software: Quem participa do processo  e quais os artefatos gerados?
Quarta parte:
  • Métrica: APF – Análise de Ponto de Função
Quinta parte:
  • Gerenciamento de projetos segundo PMI
  • SCRUM
  • XP

Grande Abraço,
Gilberto Ribeiro.

Fábrica de Software - II


O conceito de FABRICA DE SOFTWARE surgiu em 1980 e foi aplicado em escala comercial em 1993, em São Paulo.

Pasmem mas no período de 1960 a 1990, a área de software, não era vista como uma operação que necessitava de gerenciamento, melhoramento contínuo, com a responsabilidade de dar retorno para a empresa. A globalização foi a grande responsável pela transformação do senário que perdurou por três décadas.

Influenciado pelo novo conceito de Fábrica, e com os resultados positivos, surge o conceito de “Outsourcing de Sistema”, que é, ou pelo menos deveria ser, uma operação de desenvolvimento e manutenção de software terceirizada com alguns atributos de uma operação fabril.

Da abrangência do termo Fábrica de Software, derivam conceitos que são partes integrantes da totalidade, como o SPL – Software Product Line, cujo objetivo é criar uma manufatura de software aos moldes de uma linha de montagem de automóveis, o que vem a resolver a questão da Fábrica de Componentes. Começamos aqui a dissecar o sistema, cuja complexidade se resume no termo Fábrica de Software. Este conceito tende a disseminação à medida que as novas plataformas de ambientes distribuídos forem generalizadas e novas ferramentas de apoio ao desenvolvimento surjam também com o passar do tempo.

Grande Abraço,
Gilberto Ribeiro

Gestão de Projetos - II


Neste primeiro post sobre gestão de projetos farei uma introdução ao gerenciamento de projetos e alguns conceitos, tendo como base o PMI.  

Segundo o PMI, um projeto é um empreendimento temporário com o intuito de criar um produto ou serviço único, com começo e fim bem definidos e suas principais características são: 
  • Tempo - começo e fim bem definido. 
  • Unicidade - algo que nunca foi feito, pode até ser semelhante. 
  • Objetivos - pré-definidos. 
  • Atividades - interdependentes.
  •  Execução - etapas incrementais específicas.
  •  Recurso - áreas multidisciplinares. 
  • Restrições - escopo, custo e prazos.Incertezas.


PROJETOS


  • Criação de um produto ou serviço (como por exemplo, uma consultoria).
  • Desenvolvimento de um software.
  • A implantação de sistemas de gestão.
  • A implantação de processos de gestão, tais como ITIL, MPS.BR, CMMI, 9001.
  • Redução de custos operacionais.
  • Um novo modelo de carro de corrida.

... entre outros...



Qualquer empreendimento com tempo definido, único, com objetivos planejados, atividades interdependentes, realizado em etapas incrementais, com escopo, custo e prazo, podemos chamá-lo de PROJETO.



Atenção: Projeto é diferente de Plano de Negócio.

OPERAÇÃO



Atende necessidades administrativas ou operacionais em uma organização.

  • Reuniões.
  • Relatórios.
  • Transportar mercadorias.
  • Contabilidade.
  • Financeiro.
  • Manutenção de veículos.


Operação contínua não é um projeto, mas existem semelhanças entre os projetos e as operações, pois ambos são executados por pessoas, possuem restrições de recursos, são planejados, executados e controlados, existe um propósito bem definido e com atividades inter-relacionadas.


GERENCIAMENTO DE PROJETOS



Segundo o PMI, é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender as suas requisitos.




De forma sistemática a gestão de projetos contribui para a realização de um trabalho, envolvendo atividades de coordenação, organização e controle, para atingir os objetivos do projeto dentro do tempo, custo e desempenho esperado.



Programa, Portfólio e Subprojeto.




Definindo Programa



Programa é o conjunto de projetos inter-relacionados e podem compartilhar os mesmos recursos, gerenciados de forma coordenada a fim de obter benefícios estratégicos para a empresa, que de forma isolada não teriam sucesso.




Definindo Portfólio

Portfólio é um conjunto de programas ou projetos, não precisam estar diretamente relacionados ou ter interdependência, como acontece em um programa.





Definindo Subprojetos

Subprojetos são unidades de trabalho independentes, que podem ser distribuídos dentro da própria empresa ou terceirizados levando em consideração as especializações tecnológicas, requisitos de habilidades dos recursos ou fases do projeto.




Grupos de processo definidos pelo PMI



Iniciação  -  Planejamento  -  Execução  -  Monitoramento e Controle  -  Encerramento

 



A Tríplice Restrição 



Podemos considerar como restrições chaves em um projeto o escopo, o tempo e o custo. O PMBOK ainda inclui recursos e riscos.




Balanceamento dos Elementos



Envolve as expectativas dos clientes com os objetivos do negócio, refletindo as restrições e seu controle, adicionado qualidade, recursos e riscos. A mudança de uma das variáveis resulta em mudança nas outras.



Um projeto bem planejado facilita o seu gerenciamento, tornando-o ágil, melhorando a sua qualidade durante o ciclo de vida, reduz a gestão de riscos, aumenta o controle gerencial, melhora a comunicação, facilita a relação com o cliente, reduz custos evitando o retrabalho, aproveitando melhor os recursos do projeto, aumenta as margens de lucro e a confiança da equipe. 


No próximo post abordarei os seguintes assuntos:

O papel do gerente de projeto, suas principais responsabilidades e competência.
Grande Abraço,
Gilberto Ribeiro.