fatto consultoria e sistemasfattocs.com/files/pt/apresentacoes/desenvolvimento-agil-10-2015... · o...

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


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.


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


Capacitação em APF:

Medição e

Estimativa de Software


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


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 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


Á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


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?


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





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 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





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





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





Elementos do modelo de negócio





Medição do desenvolvimento conforme a abrangência





Modelo de valor agregado





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-de-

riscos-como-lidar-com-as-incertezas-do-

projeto/register


fatto consultoria e sistemasfattocs.com/files/pt/apresentacoes/desenvolvimento-agil-10-2015... · o...

Documents