fatto consultoria e sistemasfattocs.com/files/pt/apresentacoes/desenvolvimento-agil-10-2015... · o...
Post on 11-Nov-2018
217 Views
Preview:
TRANSCRIPT
FATTO CONSULTORIA E SISTEMAS
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
DESAFIOS NA CONTRATAÇÃO DE SERVIÇOS DE
DESENVOLVIMENTO DE SOFTWARE UTILIZANDO
MÉTODOS ÁGEIS
CARLOS EDUARDO VAZQUEZ
13/10/2015
Dê preferência ao uso de uma conexão de banda larga
O evento não fará uso do vídeo (webcam), somente slides e áudio
Se necessário, ajuste o idioma da sala na barra de ferramentas superior
O evento terá ~45 min. de apresentação e ~15 min. finais para perguntas
Você pode mandar suas perguntas pelo chat ao longo da apresentação
A apresentação será gravada e o vídeo publicado posteriormente
Para aqueles que possuem certificação PMP, o evento vale 1 PDU
Acompanhe-nos nas redes sociais:
ORIENTAÇÕES INICIAIS
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
MISSÃO
Estimativas e Medição de Projetos de Software
Implantação da Análise de Pontos de Função (IFPUG, NESMA , COSMIC)
Auditoria de Medições de Projetos de Software Medidos com APF
Benchmarking e Análises de produtividade
Avaliação para Melhoria dos Processos de Software
Engenharia de Requisitos
Planejamento e avaliação do desempenho (Escopo, Esforço, custo, prazo, qualidade)
Construção e Monitoramento de Contratos de Software baseados em Resultados
Integração do Desenvolvimento Ágil com a Governança Corporativa de TI usando
Métricas Funcionais
DIRECIONAMENTO ESTRATÉGICO COM:
Apoiar nossos clientes a estabelecer modelos de negócios em que eles tenham o
controle e trazer visibilidade do desempenho para a gestão de seus processos de
software.
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Engenharia de Requisitos de
Software
24 horas
Estimativa de Projetos de
Software com o COCOMOII
16 horas
Oficina de Contagem
de Pontos de Função
Sessões de 8 ~ 40 horas
Gestão de Riscos em Projetos
16 horas
Oficina de Requisitos
Sessões de 8 ~ 40 horas
Introdução ao Gerenciamento de
Projetos
16 horas
Medição e Estimativa de Software
com o Método COSMIC
16 horas (Presencial)
Preparação para
o Exame CFPS
96 horas (EAD e presencial)
APF: Fundamentos,
Benefícios e Implantação
8 horas (EAD e presencial)
Capacitação em APF:
Medição e
Estimativa de Software
16 horas (EAD e presencial)
Workshop APF:
Metodologia
e Práticas de Medição
16 horas (Presencial)
FORMAÇÃO PROFISSIONAL
O livro mais vendido de APF no país foi escrito por nós
Formou ~25% de especialistas certificados pelo IFPUG no Brasil
Representante do Scope Project Sizing Software
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
INTRODUÇÃO
Qualquer contração do desenvolvimento de software que busque eficiência e
transparência deve buscar seguir alguns princípios que permitam a manutenção desses
objetivos na governança corporativa.
Resumidamente são eles:
Gerenciar o contrato pela medição dos resultados entregues comparados às metas
operacionais e objetivos táticos junto às contratadas (não será por supervisão do
esforço; não se contrata mão-de-obra, contrata-se o desenvolvimento);
Diminuir o potencial de novos riscos para todas as partes ao não exigir o
estabelecimento de premissas no início do contrato como, por exemplo velocidade
média alvo para o projeto;
Privilegiar a definição de referências locais para planejar, avaliar e melhorar o
desempenho ao longo do contrato;
Utilizar referências globais para posicionar o desempenho realizado e as metas
definidas para o contrato.
Alinhar os interesses de todas as partes para a obtenção de maiores níveis de
produtividade, qualidade e tempestividade
Considerando os princípios do desenvolvimento ágil e o modelo de fábrica de software,
alcançar esses objetivos é viável? Onde se posiciona o objetivo da eficácia nesse
cenário?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
WELCOME POTATO
Antes de se discutir um tema, devemos tomais cuidado com o que se deseja
dizer com as palavras ou expressões; no caso, “desenvolvimento ágil” e
“fábrica de software”
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Fábrica de Projetos (ampliada)
Fábrica de Projetos de Software
Fábrica de Projetos Físicos
Fábrica de Projetos
Físicos
FÁBRICA DE SOFTWARE
Fábrica de software tem diferentes abrangências de atuação e um modelo de negócio para
contratação o desenvolvimento ágil deve considerar qual a abrangência contratada
Arquitetura de Solução
Projeto Conceitual
Especificação Lógica
Projeto Detalhado
Construção e Teste Unitário
Teste Integrado
Teste de Aceitação
Iniciação Desenvolvimento
Transição
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
ÁGIL
É comum o uso deste termo como uma antítese do desenvolvimento usando processos de desenvolvimento estabelecidos como, por exemplo, o Processo Unificado ou RUP
De certa forma isso é válido
A maneira como se institucionalizaram esses processos no contexto da contratação do desenvolvimento de sistema os transformou, em termos práticos, em uma metodologia em cascata
Inclui os pontos fracos de um processo iterativo e incremental sem os respectivos benefícios
Processos extremamente e desnecessariamente lentos e cuja antítese não deixa de necessariamente buscar agilidade
O desenvolvimento ágil é muito mais que essa antítese!
Ele considera - principalmente - pessoas relacionadas à negócios e desenvolvedores trabalhando em conjunto e diariamente, durante todo o curso do projeto
Prioriza a EFETIVIDADE como a resultado de ir rápido para a direção certa; não apenas ir rápido
Para efeitos desse trabalho, vamos usar a terminologia do SCRUM como metodologia de gerência de projeto para exemplificar as propostas apresentadas
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
VIÁVEL?
O que se observa na prática do mercado é o uso muito restrito na contratação de desenvolvimento
“ágil” como descrito anteriormente
Se busca um sócio no sentido ele buscar o Retorno sobre o Investimento (a EFETIVIDADE);
contudo, sem um contrato de risco onde o valor remunerado seja uma função desse ROI.
O desenvolvimento do tema, à seguir, observa esse enfoque pragmático
É plenamente possível o uso de um modelo de fábrica de software
Desde que haja uma estratégia de metrificação compatível com as responsabilidades que são
transferidas para a contratada
Sob pena de se instalar a ineficiência e a opacidade nas contratações se não houver o
alinhamento entre o modelo de negócio associado à contratação ágil e a sua metrificação
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Por que existe Pontos de Função?
Pontos de função existem para que:
Seja possível medir software (ou aproximar o seu tamanho) mesmo quando há decisões de
projeto ainda pendentes ou mesmo quando se conhece apenas o domínio do problema e
os requisitos da solução em alto nível
Haja uma medição do tamanho associado ao software independente de decisões sob a
responsabilidade do desenvolvedor e, com isso, impedir que o mesmo “fabrique"
artificialmente elementos de projeto mensuráveis com o propósito especificamente de inflar a
medição (e a sua remuneração) sem vínculo com a melhor solução para o problema
Os responsáveis pela governança corporativa planejem e monitorem o desempenho em
projetos de escopo aberto, atendendo aos requisitos de transparência do mundo moderno,
sem necessidade de microgerenciamento. Com isso, tornando viáveis projetos ao redor de
indivíduos motivados e oferecer um ambiente no qual não é necessário confiar ou desconfiar
que farão seu trabalho
O GERENCIAMENTO DO ESCOPO E
REMUNERAÇÃO: Posso usar Pontos de Função para
remunerar meu fornecedor?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Como usar Pontos de Função?
O uso de pontos de função deve estar inserido em um modelo de negócio compatível com as
responsabilidades atribuídas à fábrica de software
Fugir a essa regra básica provoca efeitos desastrosos
Exemplo: O objeto de atuação da fábrica de software é aquele associado à Fábrica de Projetos,
então não se deve medir:
A primeira Sprint como um projeto de desenvolvimento e as demais como melhorias no
produto originalmente entregue.
Promover a medição nesses termos, cria uma tendência à ineficiência
Uma coisa... Outra coisa bem diferente...
O desenvolvimento ágil deve aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas
falhas no levantamento e organização dos requisitos que implicam em pseudo-mudanças como no cenário onde a produção dos requisitos é escopo da atuação de Fábrica de Projetos
O GERENCIAMENTO DO ESCOPO E
REMUNERAÇÃO: Posso usar Pontos de Função para
remunerar meu fornecedor?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Outra coisa...
Não houve mudança e houve falha dos responsáveis por desenvolver os requisitos a partir de
uma necessidade de negócio em
Resolver informações conflitantes
Aproveitar oportunidades de racionalização
Identificar tarefas total ou parcialmente transferidas para o software
Medir (e remunerar) os ajustes necessários a essas pseudo-mudanças promoveria que pouca
atenção fosse data às atividades analíticas necessárias aos três pontos citados
Quanto maior a incidência desses ajustes, maior seria a remuneração associada
O GERENCIAMENTO DO ESCOPO E
REMUNERAÇÃO: Posso usar Pontos de Função para
remunerar meu fornecedor?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
O exemplo do alcance menor que o da fábrica de projetos
A lógica é totalmente diferente!
Os responsáveis pelas atividades exemplificadas não estão na fábrica de software
Para aquela equipe, é indiferente uma mudança no negócio ou uma falha na engenharia de
requisitos
Essa fábrica de software apenas entra em cena quando essas atividades já estão concluídas e
materializadas em um Product Backlog. Portanto; o correto é medir cada Sprint como um
projeto à parte
Em ambos os casos...
Deve-se se considerar na metrificação que a entrega de uma funcionalidade não implica em
sua plena conclusão
Ao longo do projeto questões sobre o detalhamento de seu funcionamento e sobre a
experiência de usuário (User Experience - UX) vão sendo descobertas e implicam em
ajustes nos produtos de software
Uma proposta que a FATTO implementou em um de seus clientes foi o conceito de Nível
Maturidade na entrega de uma funcionalidade e o correspondente percentual de compleição
associado a ela
O GERENCIAMENTO DO ESCOPO E
REMUNERAÇÃO: Posso usar Pontos de Função para
remunerar meu fornecedor?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Requisitos para o modelo de negócio
Os requisitos para um modelo de negócio com base no uso da Análise de Pontos de Função na
contratação do desenvolvimento ágil são
Suportar escopo aberto e sua variabilidade ao longo da iniciativa
Considerar o nível de informação aumentando conforme os requisitos são “revelados”
Planejar e controlar o desempenho global (da iniciativa) sem entrar no mérito do
microgerenciamento ou supervisão no desenvolvimento
Refletir no esquema de metrificação as prioridades conforme são estabelecidas e atualizadas
Permitir comparar de maneira consistente o desempenho de cada iniciativa com outras
iniciativas
Dar visibilidade à administração (mesmo que não haja gerente de projetos) sobre o progresso,
identificando desvios que exijam atenção superior
Remunerar conforme o valor agregado (em nível tático), porque não se quer um sócio nos
resultados da iniciativa
O GERENCIAMENTO DO ESCOPO E
REMUNERAÇÃO: Posso usar Pontos de Função para
remunerar meu fornecedor?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Elementos do modelo de negócio
Os elementos para atender esses requisitos são 04:
Um modelo de valor agregado que descreve como traduzir os produtos entregues em termos
de um percentual total do desenvolvimento
Um plano de iteração que reflita em termos objetivos a evolução passada e a visão de futuro
em cada ciclo para o desenvolvimento do projeto como um todo
Um quadro resumo com a avaliação do plano de iteração contra o modelo de valor agregado
fornecendo o percentual concluído
A medição do desenvolvimento conforme a abrangência de uma fábrica de projetos ou não
O GERENCIAMENTO DO ESCOPO E
REMUNERAÇÃO: Posso usar Pontos de Função para
remunerar meu fornecedor?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Elementos do modelo de negócio
O GERENCIAMENTO DO ESCOPO E
REMUNERAÇÃO: Posso usar Pontos de Função para
remunerar meu fornecedor?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Medição do desenvolvimento conforme a abrangência
O GERENCIAMENTO DO ESCOPO E
REMUNERAÇÃO: Posso usar Pontos de Função para
remunerar meu fornecedor?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Modelo de valor agregado
O GERENCIAMENTO DO ESCOPO E
REMUNERAÇÃO: Posso usar Pontos de Função para
remunerar meu fornecedor?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Plano de iteração
O GERENCIAMENTO DO ESCOPO E
REMUNERAÇÃO: Posso usar Pontos de Função para
remunerar meu fornecedor?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
Plano de iteração
O GERENCIAMENTO DO ESCOPO E
REMUNERAÇÃO: Posso usar Pontos de Função para
remunerar meu fornecedor?
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
ROTATIVIDADE, RETENÇÃO DO
CONHECIMENTO E REFERENCIAS DE
QUALIDADE Processos ágeis promovem um ambiente sustentável
Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter
indefinidamente, passos constantes
Como conseguir isso considerando a rotatividade de mão de obra?
Pontos principais que levam a considerar a rotatividade de mão de obra:
A necessidade de independência de um fornecedor em particular o que leva a não
necessariamente mobilizar a mesma equipe em todo o desenvolvimento do produto; que pode
até ter mais de uma empresa atuando em diferente frentes
A responsabilidade pela gestão dos recursos humanos claramente no domínio do fornecedor e
além da influência direta da empresa que a contrata
Para o sucesso da contratação do desenvolvimento ágil
Ainda que a documentação se limite inicialmente a uma lista de requisitos que compõem o
Product Backlog. Ele, normalmente, tem a forma de histórias de usuários e evolui com a
eventual decomposição sucessiva de algumas delas pelo Splitting com cenários específicos e
mais rapidamente implementareis ou outros tipos de Product Backlog Items associados a
componentes arquiteturais. As regras de negócio devem ser descritas de forma legível pela
administração (ou melhor, por não desenvolvedores) mesmo que derivadas do código fonte
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
ROTATIVIDADE, RETENÇÃO DO
CONHECIMENTO E REFERENCIAS DE
QUALIDADE Outras políticas de qualidade
Isso deve ser objeto de uma política de qualidade; porém, não a única. Outros padrões de projeto
também necessários devem descrever
A arquitetura interna no projeto do produto
A interface e interação entre produto e usuários
As regras de codificação (incluindo o item abordando anteriormente sobre a retenção do
conhecimento)
O processo de gerência de ciclo de vida da aplicação (ALM)
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
ENTREGÁVEIS QUAIS E QUANTOS
Código fonte funcionando e que resolva as necessidades de negócio a cada 15 ou 30 dias
Principal produto que deve ser entregue na contratação do desenvolvimento ágil. Contudo, não
necessariamente o único. Um cenário adequado para a contratação de fábricas de programas
seria:
Códigos fonte e arquivos de configuração;
Roteiros de teste e automatização;
Evidências de teste unitário;
Testes técnicos para evidenciar requisitos não funcionais (itens a serem apontados);
Massa de dados para homologação;
Publicação em ambiente de homologação.
Esse é um cenário em que 43% do desenvolvimento é transferido para a contratada. Quanto se
trata da contratação de uma fábrica de projetos, então deve-se agregar a esses tipos de produtos:
Product Backlog atualizado com novas histórias do usuário ou por novos Product Backlog
Items resultantes da subdivisão de histórias do usuário em unidades menores que caibam em
um ciclo de desenvolvimento (Splitting).
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
ENTREGÁVEIS QUAIS E QUANTOS
Para o sucesso da contratação do desenvolvimento ágil
O desenvolvimento ter início com uma arquitetura viável e a resolução de elementos de maior
risco arquitetural. O desenvolvimento deve observar as regras estruturais definidas por ela e
pode identificar oportunidades de melhoria. Contudo, não se recomenda que a mesmo contrato
misture o desenvolvimento de software associado a elementos arquiteturais e ferramentas de
produtividade
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
PROCESSO
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
PROCESSO
No desenvolvimento, há três "tempos" que devem ser considerados:
O planejamento do Sprint
A retrospectiva do Sprint
A Release ou a cada três meses pelo menos, o que acontecer antes
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
PROCESSO
Não esqueça os Requisitos não Funcionais!
Por fim, mas não menos importante, é fundamental nivelar de antemão as expectativas quanto aos
requisitos não funcionais. Por exemplo, se nada for descrito nas histórias do usuário, considerar:
Tempo de resposta médio para transações interativas com o usuário humano pode durar até 5
segundos
Ciclo de processamento batch pode durar até 1 dia
Volumes a considerar:
• Meta crescimento 2015: 30%;
• Ambiente computacional – escalável, contudo, os produtos serão inspecionados
quanto ao melhor uso dos recursos
• Banco de dados atual 1TB
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
PESQUISA!
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
PRÓXIMO EVENTO
• Webinar:
Gestão de Riscos: como lidar com as incertezas do
Projeto?
• Data:
04 de Novembro de 2015 (quarta-feira)
• Horário:
20h
• Inscrição: https://fatto.clickwebinar.com/gestao-de-
riscos-como-lidar-com-as-incertezas-do-
projeto/register
© 2015 FATTO Consultoria e Sistemas | www.fattocs.com
top related