DESAFIOS NA CONTRATAÇÃO DE SERVIÇOS DE DESENVOLVIMENTO DE SOFTWARE UTILIZANDO MÉTODOS ÁGEIS CARLOS EDUARDO VAZQUEZ 13/10/2015 FATTO CONSULTORIA E SISTEMAS
ORIENTAÇÕES INICIAIS 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:
MISSÃO 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. DIRECIONAMENTO ESTRATÉGICO COM: 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
FORMAÇÃO PROFISSIONAL 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) Preparação para o Exame CFPS 96 horas (EAD e presencial) Medição e Estimativa de Software com o Método COSMIC 16 horas (Presencial) Oficina de Contagem de Pontos de Função Sessões de 8 ~ 40 horas Engenharia de Requisitos de Software 24 horas Oficina de Requisitos Sessões de 8 ~ 40 horas Estimativa de Projetos de Software com o COCOMOII 16 horas Introdução ao Gerenciamento de Projetos 16 horas Gestão de Riscos em Projetos 16 horas 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
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?
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
FÁBRICA DE SOFTWARE Fábrica de Projetos (ampliada) Fábrica de Projetos de Software Fábrica de Projetos Físicos Arquitetura de Solução Projeto Conceitual Especificação Lógica Projeto Detalhado Construção e Teste Unitário Teste Integrado Teste de Aceitação Fábrica de Projetos Físicos Iniciação Desenvolvimento Transição 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
Á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
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
O GERENCIAMENTO DO ESCOPO E REMUNERAÇÃO: Posso usar Pontos de Função para remunerar meu fornecedor? Pontos de função existem para que: Por que existe Pontos de Função? 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? 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... 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 Outra coisa bem diferente... falhas no levantamento e organização dos requisitos que implicam em pseudomudanç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? 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? A lógica é totalmente diferente! O exemplo do alcance menor que o da fábrica de projetos 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? 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? 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? Elementos do modelo de negócio
O GERENCIAMENTO DO ESCOPO E REMUNERAÇÃO: Posso usar Pontos de Função para remunerar meu fornecedor? 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? Modelo de valor agregado
O GERENCIAMENTO DO ESCOPO E REMUNERAÇÃO: Posso usar Pontos de Função para remunerar meu fornecedor? Plano de iteração
O GERENCIAMENTO DO ESCOPO E REMUNERAÇÃO: Posso usar Pontos de Função para remunerar meu fornecedor? Plano de iteração
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
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)
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).
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
PROCESSO
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
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
PESQUISA!
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-deriscos-como-lidar-com-as-incertezas-doprojeto/register