Contratos ágeis medidos por Pontos de Função 1 Palestrante: Augusto Mariano Pinheiro, CCFL, CPRE-FL augusto.pinheiro@fattocs.com.br
2 FATTO Consultoria e Sistemas Missão: Ajudar nossos clientes no planejamento e avaliação de desempenho de processos de TI para alavancar o sucesso de seu negócio. Consultoria e Treinamento em Medição, Estimativas e Requisitos de Software: Análise de Pontos de Função (IFPUG, NESMA, COSMIC) Estimativas de projetos de software Engenharia de Requisitos Medição e auditoria em medição de software Análises de produtividade em projetos de software O livro mais vendido de APF no país foi escrito por nós Formou ~25% de especialistas certificados pelo IFPUG no Brasil
3 Objetivos desta apresentação Discutir a viabilidade da adoção de metodologias ágeis de desenvolvimento de software em suas contratações. Abordar os principais desafios na contratação de serviços de desenvolvimento e manutenção em regime de fábrica de software utilizando métodos ágeis
Agenda FATTO Consultoria e Sistemas - www.fattocs.com 4 Tópico I - Introdução Justificativas para a contratação Resultados Esperados Tópico II Comparação entre Práticas e Modelos Metodologias Tradicionais Comparação entre Práticas e Modelos Métodos Ágeis Tópico III Principais Desafios Integração do Time Documentação adequada Definição do Pronto Definição do Retrabalho Definição do "Elemento de Medição Elaborar modelo de Sustentação
5 Tópico I Introdução Justificativas para a contratação Resultados esperados
6 Justificativas para a Contratação A informatização das atividades organizacionais melhora condições de trabalho e apoia a tomada de decisão. Nesse sentido, a TI é estratégica para as áreas administrativa e operacional, desenvolvendo, mantendo e sustentando sistemas essenciais para a melhoria contínua da qualidade e eficiência dos serviços prestados pela organização. Em muitas organizações, há escassez de mão de obra especializada com condições de garantir a produção e a sustentação de sistemas, de modo que contratar torna-se condição indispensável para o atingimento das metas estabelecidas pela organização.
7 Resultados Esperados Garantir a manutenção e evolução dos sistemas em operação e construir novos Assegurar o pleno funcionamento de sistemas (sustentação) Dar a vazão esperada à demanda dos clientes (e no prazo esperado) Promover entregas de valor constantes, de forma controlada e automatizada Para alcançar estes resultados, É necessário escolher modelo de operação e metodologia adequados
8 Tópico II Comparação entre Práticas e Modelos Metodologias Tradicionais Comparação entre Práticas e Modelos Movimento Ágil e DevOps
9 Metodologias Tradicionais Clássica Espiral Baseada em Prototipação Processo Unificado
10 Comparativo das Práticas e Modelos Práticas Abordagem Tradicional Abordagem Ágil Processos Comunicação Aceitação da Mudança Entregas Preditivo. Atividades, tarefas e artefatos definidos. Há o incentivo à confecção de documentos, modelos, diagramas e especificações. É baseada em documentos formais. Exigem que o cliente saiba exatamente qual é o comportamento ideal do software a ser desenvolvido antes do início do projeto. Normalmente as entregas são feitas em ciclos longos. Adaptativo. Processos leves, baseados em valores e princípios. Há maior valorização da iteração direta entre os membros da equipe. Promove a integração dos envolvidos. A experimentação e adaptação é incentivada e tende a produzir software mais adequados às necessidades dos usuários. Promove o feedback do cliente, devido aos seus ciclos de entregas curtos e constantes.
11 O Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
12 DevOps É o alinhamento do time de desenvolvimento com o time de operações, em relação à: Processos; Ferramentas; e Responsabilidades. Visando acelerar as entregas em produção com um elevado grau de qualidade. Na prática, DevOps aproxima as práticas de desenvolvimento ágil com testes e implantação fazendo um bom uso da automação para tal.
13 Tópico III Principais Desafios Integração dos Times Documentação adequada Definição do Pronto Definição do Retrabalho Definição do "Elemento de Medição Elaborar modelo de Sustentação
Integração dos Times CONTRATANTE e CONTRATADA Time único? Fisicamente juntos? FATTO Consultoria e Sistemas - www.fattocs.com 14
15 Integração dos Times (papéis) O que diz o Manifesto Ágil: Princípio #4: Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. Se o SCRUM for adotado, quem exercerá os papéis? SCRUM MASTER Remover impedimentos Garantir que o SCRUM está sendo seguido PRODUCT OWNER Descrever as necessidades dos clientes Gerenciar o backlog do produto (e priorizar seus itens) Apoiar o entendimento e esclarecimento dos requisitos à equipe de desenvolvimento
16 Documentação adequada Deve atender, simultaneamente: Princípios ágeis O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. Governança de TI, ainda que o foco não seja: Promover a TROCA DE INFORMAÇÕES entre os diferentes especialistas RETER O CONHECIMENTO desenvolvido pelo projeto Permitir RASTREABILIDADE
17 Documentação adequada Via de regra, se trabalha com Histórias de Usuário É um requisito capturado normalmente em 1 parágrafo que descreve a necessidade de um usuário de forma breve utilizando uma linguagem comum ao negócio. Como/Sendo <QUEM>, eu quero/gostaria/devo/posso <O QUE>, para que/de/para <PORQUE/RESULTADO> Riscos Se métrica de remuneração é UST ou Pontos de História, corre-se o risco de transferir o poder de fabricar unidade de remuneração para quem recebe. Exemplo: 1 História de Usuário = 1 UST
18 Definição de Pronto Tá pronto, só falta testar... É um acordo formal do time SCRUM que define claramente quais são os passos mínimos para a conclusão de um item potencialmente entregável. Criar uma Definição de Pronto ou DoD é um esforço colaborativo entre o SCRUM Master, o time SCRUM e o Product Owner. Esta definição deve ser incluída no contrato?
19 Definição de Pronto : Exemplos 1. Codificação concluída; 2. Testes realizados; 3. Repositório de código atualizado; 4. Código revisado e inspecionado quanto à padrões de qualidade de código; 5. Testes unitários escritos e aprovados; 6. Liberado no ambiente de testes; 7. Aprovado nos testes de aceitação do usuário e assinado como aderente aos requisitos ; 8. Mudanças em itens de configuração implementadas/documentadas/comunicadas; 9. Documentação relevante produzida e/ou atualizada; 10. Apontamento de horas remanescentes zerado e tarefa concluída.
20 Definição de Retrabalho Toda mudança é retrabalho? UX: Mudança como retrabalho ou deve ser vista como a continuação do trabalho ainda não concluído (refinamento de requisitos)? E se houve falha no Levantamento de Requisitos? E se houverem mudanças no ambiente externo (legais, condições do negócio, etc)?
21 Definição de Retrabalho Toda mudança é retrabalho? UX: Mudança como retrabalho ou deve ser vista como a continuação do trabalho ainda não concluído (refinamento de requisitos)? E se houve falha no Levantamento de Requisitos? E se houverem mudanças no ambiente externo (legais, condições do negócio, etc)? As mudanças são bem vindas?
22 Definição do Elemento de Medição Homem-Hora (HH): O contratante deve gerenciar a produtividade do fornecedor Há dificuldade de receber garantia Remunera sem vínculo aos resultados, sem estímulo à produtividade No governo, há vedação legal (IN-04/2010, SLTI/MP, Art. 15º)
23 Definição do Elemento de Medição Pontos de História (Story Points): Seleciona-se uma história de usuário para assinalar uma complexidade nominal que servirá de referência para avaliar as demais história A história torna-se a medida Como a medição é baseada na experiência da equipe e na analogia com outras histórias, impossibilita a comparação com os pontos de história medidos por outra equipe Os resultados da medição só possuem significado para a própria equipe
24 Definição do Elemento de Medição Unidade de Serviço Técnico (UST): Baseia-se em Catálogo de Serviços: Descrição da atividade UST Modelagem de banco de dados Elaboração do Desenho/Arquitetura da solução, para projetos novos Elaboração do Planejamento do Produto 4 Manutenção corretiva do de banco de dados Riscos Remuneração independente do tamanho do projeto 1 por classe de objeto Por permitir a apropriação direta de custos, permite pagar por RF e RNF na mesma demanda 6 42 por ação Corretiva
25 Definição do Elemento de Medição Unidade de Serviço Técnico (UST) NÃO HÁ corpo de conhecimento de referência Se houver DÚVIDAS a respeito do seu uso, que ESPECIALISTA deve ser consultado? Como AVALIAR se o seu USO foi CORRETO ou não? Como dimensionar O VOLUME do CONTRATO? NÃO HÁ uma definição uniforme 1 UST = 1 hora 1 UST = 1,5 horas 1 UST = equivale a 1 hora de esforço especializado, não individualizada Por isso, inviabiliza a utilização de dados de Benchmarking
26 Definição do Elemento de Medição Medição Funcional (Pontos de Função) Vantagens: Padrões internacionais: IFPUG, COSMIC, NESMA, MARK-II, FISMA Centenas de empresas e profissionais Vocabulário independente da tecnologia Método padrão de medição funcional (simples e consistente) Medição baseada numa Perspectiva do negócio Fornece informação no nível tático/estratégica x operacional
27 Elaborar modelo de Sustentação Quem será o responsável pela Sustentação? CONTRATADA: Como distribuir as demandas entre os recursos compartilhados entre o PROJETO e a SUSTENTAÇÃO? Ou haverão recursos dedicados à SUSTENTAÇÃO? Há margem para isso no contrato? Como remunerar estas atividades? CONTRATANTE: O conhecimento da solução foi compartilhado pela equipe externa com a equipe interna? Se houver necessidade de modificação no código, como fica a garantia contratual? Após a modificação no software em produção, quem atualizará a DOCUMENTAÇÃO?
28 Considerações Finais Ágil exige muita organização e não é falta de planejamento Ainda que não se utilize estritamente uma abordagem Ágil... É possível ser MAIS ÁGIL! Não há incompatibilidade entre ser MAIS ÁGIL e as exigências de governança corporativa e transparência tão importantes hoje em dia As métricas funcionais são PIVOT em uma estratégia de conciliação ente uma abordagem MAIS ÁGIL e os objetivos de controle interno e externo
29 Como podemos ajudá-los? Preparação da organização Prestação de serviços de Consultoria e suporte especializado para: Elaboração de Termo de Referência ou Contrato de Prestação de Serviços Revisão de Metodologia Implantação da Análise de Pontos de Função Análise de produtividade Contratação de serviços de desenvolvimento de software utilizando métodos ágeis
30 Como podemos ajudá-los? Capacitação Profissional Levantamento de requisitos, seleção e organização do Backlog Curso: Engenharia de Requisitos: Software Orientado ao Negócio Oficina de Requisitos: O negócio como alvo do desenvolvimento Estimar o prazo global do projeto Curso Estimativas de Software: Fundamentos e Técnicas Medição do projeto numa perspectiva externa Curso de Capacitação em Análise de Pontos de Função Oficina de Contagem de Pontos de Função
31 Avaliação do Evento
32 Próximos Eventos Webinar: SAFE: Promovendo o alinhamento, colaboração e entrega para múltiplas equipes ágeis https://fatto.clickmeeting.com/safe Próximas turmas: Capacitação em APF São Paulo: 12/03 a 15/03 Engenharia de Requisitos Rio de Janeiro: 20/03 a 22/03 Capacitação em SNAP Online (Ao VIVO): 19/03 a 22/03