Software melhor e mais rápido: resultados de um caso real

Transcrição

1 Software melhor e mais rápido: resultados de um caso real IIBA, BABOK, Business Analysis Body of Knowledge e CBAP são marcas de propriedade do International Institute of Business Analysis. Estas marcas são usadas com permissão expressa do International Institute of Business Analysis. Suzandeise Thomé, CBAP Willem Dijkgraaf, CBAP 19/março/2014

2 Livro do Willem Start at the End with SMART requirements Comece pelo fim com requisitos inteligentes/smart -Willem Dijkgraaf and Mike van Spall

3 Livro da Suzandeise Foco desta palestra Público alvo: quem investe em TI Conteúdo: 1. A responsabilidade é sua 2. TI deve entender o contexto do negócio 3. O que exigir de TI? 4. O valor da análise é o resultado final 5. Diga não disperdício! Como decidir se o investimento realmente deve ser feito 6. Quem deve analisar a oportunidade de investimento? 7. Análise de Negócios é importante demais para ser feita de graça em fase de proposta

4 Agenda: caso real Objetivo e contexto Intervenções em: Gestão: Kanban Qualidade das regras Qualidade dos requisitos Testes ágeis (agile testing) ALM: Application Lifecycle Management (Gerenciamento de Ciclo de Vida de Aplicativos) Resultados

5 Objetivo Melhorar a qualidade e a velocidade das entregas da TI estabilizar plataforma atual preparar equipe para desenvolver novos produtos Tornar requisitos e regras executáveis foi uma parte das intervenções

6 Contexto Equipe de TI: Analistas funcionais Desenvolvedores Analistas de Processos fora da TI Equipe não atendia as expectativas dos seus clientes internos: Atrasos Projetos cancelados Baixa qualidade das entregas Muito retrabalho

7 Contexto Enorme backlog: Bugs Melhorias Projetos Todos tentando fazer tudo ao mesmo tempo Backlog aumentando a cada dia

8 Backlog Chamados Semanas

9 Como resolver? É só melhorar requisitos e regras que tudo se resolve, certo? CLARO QUE NÃO!!!!!!

10 ...e pra tornar o desafio mais interessante Profissionais: Cansados/frustrados Atitudes: muitos comprometidos e ansiosos por melhorias poucos descomprometidos e resistentes à mudança Trabalhar a atitude das pessoas não é o foco desta palestra, mas sem fazer isso TUDO o que vem depois deste slide fica MUITO mais difícil.

11 Por onde começar? Você pode fazer qualquer coisa, mas você não pode fazer tudo.

12 Kanban Antes de implantar o Kanban Cada um atuando em várias solicitações ao mesmo tempo, gerando desperdício: Levava meses para entregar de uma solicitação (lead time) Frequente repriorização do trabalho Não havia visibilidade do que realmente estava sendo feito Solicitações eram canceladas antes de serem entregues Cada subida em produção gerava mais bugs do que resolvia Backlog aumentava, aumentava e aumentava Colaboradores cansados e desencorajados

13 Kanban Como começamos? Com o processo do jeito que estava ( as is ) Com as solicitações (requisitos) do jeito que estavam Com o backlog que existia Sem alterar papéis e responsabilidades Sem indicadores Sem estimativas Tudo foi pro Kanban O que aconteceu? A situação atual ficou visível!

14 issue (problema/dúvida que impede trabalho de continuar) O que é possível descobrir olhando o Kanban? Kanban Legenda a fazer especificar desenvolver testar homologar em andamento pronto em andamento pronto em andamento pronto em andamento pronto pré- deploy deploy Legenda: bug melhoria alteração de dados

15 Kanban: resultados Após 6 meses de utilização do Kanban: Cada pessoa faz uma coisa de cada vez Minimizamos desperdício: 70% das solicitações são entregues em até 7 dias Não há re-priorização do que já está no Kanban, a priorização acontece quando existe disponibilidade pra puxar mais trabalho Não há cancelamentos de trabalho em andamento Melhoria de qualidade: poucos ou nenhum bug é introduzido em produção a cada deployment Backlog diminue constantemente Colaboradores motivados

16 O que é possível descobrir olhando o Kanban? antes de desenvolver!! analisar especificar testes em andamento pronto desenvolver testar homologar deploy em andamento p/ em pronto andamento migrar p/ pronto em migrar andamento pronto prédeploy Legenda: bug melhoria alteração de dados issue (problema/dúvida que impede trabalho de continuar) FAST TRACK: classe de serviço mais rápida

17 Kanban: resultados O que melhorou? Processo foi modificado para incluir feedback o mais cedo possível AN se certifica que a necessidade do negócio foi entendida corretamente Menos documentação Critérios de aceite mais completos e mais precisos Papéis e responsabilidades foram modificados com foco na entrega AN é responsável no início ao fim AN é também quem testa a entrega (testes manuais) AN e desenvolvedor conversam mais

18 Kanban: resultados O que melhorou? São executados somente as solicitações que fazem sentido Redução agressiva do backlog ( sejamos realistas ) foi cancelado tudo que era muito antigo ou não fazia mais sentido Passou a ser possível enxergar o que existia dentro do backlog Agrupamento de itens Criação de um resumo do que seria feito Entendimento de onde estava doendo mais Quando um chamado é tratado, é pra resolver o problema de vez Implantamos Kanban eletrônico além do físico

19 Além do Kanban O que adicionamos? Estimativas de chamados usando story points Estimativa no começo do fluxo de trabalho Ajustes à estimativa no final do fluxo Introdução gradativa de indicadores * à medida que informações pertinentes se tornavam disponíveis Velocidade da equipe (story points entregues por semana) Variabilidade do cycle time (tempo que um chamado demora para ser executado) Certo na primeira vez (first time right) = (novos bugs em produção / story points em produção) * indicadores gerados a partir do Kanban eletrônico

20 2/16/2013 2/23/2013 3/2/2013 3/9/2013 3/16/2013 3/23/2013 3/30/2013 4/6/2013 4/13/2013 4/20/2013 4/27/2013 5/4/2013 5/11/2013 5/18/2013 5/25/2013 6/1/2013 6/8/2013 6/15/2013 6/22/2013 6/29/2013 7/6/2013 7/13/2013 7/20/2013 7/27/2013 8/3/2013 8/10/2013 8/17/2013 8/24/2013 8/31/2013 9/7/2013 9/14/2013 9/21/2013 9/28/ /5/ /12/ /19/ /26/ /2/ /9/ /16/ /23/ /30/ /7/ /14/2013 #REF! 20/03/ /04/ /04/ /04/ /05/ /05/ /05/ /06/ /06/ /07/ /07/ /07/ /08/ /08/ /08/ /09/ /09/ /09/ /10/ /10/ /11/ /11/2013 Indicadores Story Point Cumulativo CycleTime 15 22% 13% 8% 20% 38% mesmo dia em 7 dias em 14 dias em 21 dias mais de 21 dias Cycle Time (Novembro) /2013 Total

21 Além do Kanban O que adicionamos? Processo de Gestão de Demanda executado ANTES da solicitação entrar no Kanban: triagem imediata dos chamados 4 classes de serviço (determinadas pelo processo de Gestão de Demanda) Urgente Com data (tem que ser entregue até uma determinada data) Fast track (fluxo simplificado para solicitações simples) Padrão

22 Regras de negócio O que encontramos: Muitas páginas de documentos Word! Cada um documentava de um jeito Não se sabia direito o que era regra Regras redundantes ou conflitantes Não se sabia a relação entre uma regra e outra Regras escondidas no código: programadores conheciam mais as regras do que o negócio desperdício de tempo fazendo engenharia reversa Só era possível validar se as regras estavam certas em homologação ou em produção Muito desperdício

23 Regras de negócio Como começamos? Implementamos ferramenta para regra de negócios Modelagem visual das regras Foco em tabelas de decisão Testes unitários de cada decisão atômica Testes das regras como um todo (da decisão) Simulação das regras com dados reais para validar e otimizar as regras Análise de cobertura de testes e utilização das regras Como é isso na prática?

24 Regras de negócio Modelagem visual Fluxo chama tabelas de decisão

25 Regras de negócio Tabelas de decisão

26 Regras de negócio Testes unitários de regra atômica e de conjuntos de regras

27 Regras de negócio Simulação das regras com dados reais para validar e otimizar as regras Ferramenta lê inputs no banco de dados E escreve outputs da decisão no banco de dados Fluxo chama tabela de decisão

28 Regras de negócio Análise de: cobertura de testes frequência de utilização das regras

29 Regras de negócio: resultados Após 6 meses de utilização da ferramenta: ANs tem mais conhecimento das regras do que os desenvolvedores O Négocio aprecia imensamente poder ler e entender as regras que estão no repositório O Negócio conhece o comportamento das regras (em simulações) antes delas serem colocadas em produção Melhor qualidade certo da primeira vez (first time right)

30 Regras de negócio: resultados O que melhorou? Os ANs são donos das regras Feedback é dado o mais cedo possível Regras são executadas no ambiente em que são modeladas Verificação antecipada com testes unitários Validação utilizando dados reais Redução de desperdício Só são implementadas as regras que estiverem 100% corretas Modelo de regras é também utilizado para testar a implementação Não é necessário fazer engenharia reversa

31 Regras de negócio: resultados O que descobrimos? Redução natural de discussões sobre: O que é uma regra negócio ou não Qual a diferença entre requisitos e regras Qual a relevância de determinada regra: se é necessária no cálculo, é relevante Quase nenhuma discussão semântica o importante é que o processamento das regras funcione corretamente

32 Regras de negócio: resultados O que descobrimos? A facilidade de uso da ferramenta é mais importante do que discussões sobre metodologia Sim, um pouco de metodologia ajuda, mas sempre só o sufiente para tomar uma ação Fazer acontecer usando a ferramenta é o que agrega real valor Metodologia NIKE: Just do it

33 Qualidade dos requisitos O que encontramos: Muitas páginas de Word Requisitos desatualizados Redundância Vários requisitos como se fosse somente um Com prioridades diferentes Ambiguidade Descrição da solução e não do problema Muito desperdício

34 Qualidade dos requisitos O que fizemos: Colocamos em prática diretrizes p/ escrever requisitos: Como explicar melhor o que precisa ser feito (sem redundância, sem ambiguidade, etc.) Start at the End with SMART requirements -Willem Dijkgraaf and Mike van Spall

35 Qualidade dos requisitos O que fizemos: Requisitos passaram a ser escritos em forma de: User stories + critérios de aceite Mentoring um a um, exemplos Mapeamos processos essencias da empresa para entender o contexto

36 Processos essenciais User story não é só pra software! EXEMPLO: Como responsável por implantação de novos clientes quero entender o que foi vendido para garantir que as expectativas do cliente sejam atendidas no prazo esperado Entender o contexto aumenta a qualidade dos requisitos ANs e outros colaboradores passaram a conhecer onde o trabalho deles se encaixa dentro da empresa

37 Mas voltando a software Formato eficaz: user story + critérios de aceite Critérios de aceite indicam quando a user story estará pronta (definition of done )

38 Critérios de aceite: quando? o mais cedo possível!!! o Analista de Negócios escreve critérios de aceite e casos de teste para cada user story ANTES de passar para o desenvolvedor

39 Critérios de aceite: como? descrevendo cenários em Gherkin linguagem criada para descrever o comportamento da solução origem: Desenvolvimento Guiado pelo Comportamento (BDD - Behaviour Driven Development) sintaxe: Dado que... <sistema está em um determinado estado> quando <executo uma ação> então <este resultado acontece> formato pode ser facilmente transformado em teste de aceite automatizado (automated acceptance test)

40 Critérios de aceite automatizados Critérios de aceite automatizados = requisitos executáveis Quem está fazendo isso? equipes de desenvolvimento ágil desenvolvedores + agile testers Métodos ágeis influenciam MUITO como se faz análise de negócios Mudança drástica em como se testa software: agile testing Onde está o Analista de Negócios?

41 Agile Testing (Lisa Crispin e Janet Gregory) Argumentos convencedores para desmanchar equipes de testes e integrar testers em equipes de desenvolvimento ágil Analistas de testes [no modelo tradicional] obtem sucesso quando encontram bugs no software Agile tester obtem sucesso quando consegue ajudar a equipe a desenvolver software SEM bugs

42 Agile Testing (Lisa Crispin e Janet Gregory) Agile testers trabalham com uma equipe onde todos se sentem responsáveis por entregar [software] com a melhor qualidade possível Agile testers defendem a qualidade em nome do cliente e auxiliam a equipe de desenvolvimento a entregar o máximo valor possível ao negócio O que os agile testers descobriram? Quem testa precisa entender do negócio!! Agile testers participam de elicitação de requisitos!!

43 Moral da história Como Analistas de Negócios falam que vão resolver os problemas Cliente Análise de Negócios Desenvolvimento Teste Software que tem valor!!!!

44 Moral da história Como Analistas de Negócios falam que vão resolver os problemas Cliente Análise de Negócios Desenvolvimento Teste Software que tem valor!!!!

45 Moral da história Como Analistas de Negócios falam que vão resolver os problemas Como comunidade de desenvolvimento ágil está resolvendo os problemas!!! Cliente Análise de Negócios Desenvolvimento Teste Software que tem valor!!!!

46 Moral da história Como Analistas de Negócios falam que vão resolver os problemas Como comunidade de desenvolvimento ágil está resolvendo os problemas!!! Cliente Análise de Negócios Desenvolvimento Teste Software que tem valor!!!!

47 Moral da história Como Analistas de Negócios falam que vão resolver os problemas Como comunidade de desenvolvimento ágil está resolvendo os problemas!!! Cliente Análise de Negócios Desenvolvimento Teste Software que tem valor!!!! Desenvolvedores e Agile testers elicitam requisitos com o cliente. Vamos acabar com as panelinhas! O que importa é o resultado final! Próximo passo: envolva-se com agile testing e ALM

48 ALM (Application Lifecycle Management) O que encontramos: Silos Cada grupo criando a sua própria documentação para: Solicitação do negócio (equipe de processos) Especificação funcional ( especificadores ) Especificação de testes feita raramente pelo especificador funcional Passavam documentos para o desenvolvimento Muita sobreposição e inconsistência de informações Cada um só olhava o seu pedaço Sem olhar o resultado final Sem olhar o processo como um todo Deployments grandes (a cada mês) Muito tempo dispendido fazendo merge de código Muitos problemas de integração

49 ALM Como começamos? Implantando Microsoft Team Foundation Service (TFS) Solução na nuvem (sem custo de infra, algumas limitações de configuração) Kanban digital (utilizado junto com Kanban físico) Controle dos processos através de relatórios e alertas padronizados Melhoria/padronização de processos com base na ferramenta itens de trabalho Testes (bugs encontrados são reportados diretamente na ferramenta) Builds em preparação para deployment

50 ALM Após 6 meses de utilização do TFS: ANs documentam diretamente no TFS (nada de templates ou anexos) user stories + critérios de aceite casos de teste (que servem de input para o desenvolvimento) Desenvolvedores usam critérios de aceite e casos de teste como: Especificação Para testar o que eles desenvolvem Deploys mais frequentes (2x por semana) Indicadores relacionados a Kanban: é só apertar um botão! É fácil integrar com outros times remotos (terceirizar desenvolvimento, por exemplo)

51 2/16/2013 2/23/2013 3/2/2013 3/9/2013 3/16/2013 3/23/2013 3/30/2013 4/6/2013 4/13/2013 4/20/2013 4/27/2013 5/4/2013 5/11/2013 5/18/2013 5/25/2013 6/1/2013 6/8/2013 6/15/2013 6/22/2013 6/29/2013 7/6/2013 7/13/2013 7/20/2013 7/27/2013 8/3/2013 8/10/2013 8/17/2013 8/24/2013 8/31/2013 9/7/2013 9/14/2013 9/21/2013 9/28/ /5/ /12/ /19/ /26/ /2/ /9/ /16/ /23/ /30/ /7/ /14/2013 #REF! 20/03/ /04/ /04/ /04/ /05/ /05/ /05/ /06/ /06/ /07/ /07/ /07/ /08/ /08/ /08/ /09/ /09/ /09/ /10/ /10/ /11/ /11/2013 ALM Alguns indicadores: Story Point Cumulativo CycleTime 15 22% 13% 8% 20% 38% mesmo dia em 7 dias em 14 dias em 21 dias mais de 21 dias Cycle Time (Novembro) /2013 Total

52 ALM: resultados O que melhorou? UM time integrado Usando o mesmo ambiente, mesma ferramentea de ponta a ponta Redução do número de técnicas utilizadas na documentação (simplificação) Maneira fácil de executar o processo de forma padronizada Instruções de trabalho simples Novos membros da equipe aprendem o processo facilmente Cada um sabe o que fazer no momento certo (alto grau de autogerenciamento baseado no Kanban) Relatórios e alertas para ajudar os membros da equipe a cumprir as instruções de trabalho

53 ALM: resultados O que melhorou? Redução de desperdício Não há sobreposição de informações, redundâncias nem inconsistências Não é necessário trabalho adicional administrativo para gerar indicadores Deploys mais frequentes reduzem a complexidade dos merges e de integrações (menos tempo perdido) Resultados das mudanças: é possível ter uma equipe realmente auto-gerenciável!

54 Chamados Resultados: backlog Semanas

55 RESUMO: Qual é o seu valor? O que você entrega? O valor da análise é o resultado final! Chega de morrer na praia seu trabalho de análise não tem efeito se a entrega não for feita a contento Um só Kanban para o processo inteiro (AN+desenv+teste+deploy) Só existe uma cadeia de valor: Análise de Negócios faz parte dela! Não adianta investir só em AN sem olhar a cadeia toda!

56 Interdual Suzandeise Thomé, CBAP Willem Dijkgraaf, CBAP Links para livro/conteúdo:

57 Sobre a Interdual Experiência internacional Consultores certificados em análise de negócios Resultados através de: sinergia entre gerenciamento de produto, análise de negócios, gerenciamento de projetos e desenvolvimento de software métodos ágeis lean (desenvolvimento enxuto de software) melhores práticas segundo o IIBA Foco em mudança organizacional efetiva Paixão por excelência, ética e honestidade possibilitam à Interdual atingir resultados de alta qualidade e consistentemente atender às expectativas e compromissos firmados com seus clientes.

58 Clientes

59 Consultores Interdual Suzandeise Thomé, CBAP Suzandeise é altamente eficaz como facilitadora de sessões de trabalho, seja para identificar objetivos, priorizar projetos ou requisitos, ou para identificar o potencial retorno de investimentos em TI. Iniciou sua carreira há 18 anos como consultora nos EUA, onde definiu o papel do Analista de Negócios em projetos de desenvolvimento de software e prestou serviço para grandes clientes do mercado financeiro. No Brasil, trabalhou na GE e atualmente trabalha como consultora e instrutora pela Interdual. Em 2007 trouxe para o Brasil o IIBA International Institute of Business Analysis e presidiu o Capítulo São Paulo do IIBA durante os seus primeiros quatro anos. Participa ativamente de atividades que visam a disseminar a Análise de Negócios no Brasil. É uma das primeiras profissionais do país a obter certificação em Análise de Negócios (CBAP Certified Business Analysis Professional). É formada em Engenharia e Ciência da Computação pelo Massachusetts Institute of Technology (MIT), tem mestrado em Interação Humano-Computador pela Universidade de Michigan e é autora do livro TI para Negócios 2: Como aumentar o retorno do seu investimento em tecnologia e gerar lucro, que conta com prefácio de Delfim Netto. Especialidades: Análise de Negócios, facilitação, Arquitetura de Informação e Usabilidade, Certified ISO20000 Consultant, CBAP Certified Business Analysis Professional

60 Consultores Interdual Willem Dijkgraaf, CBAP Willem Norbert Dijkgraaf tem mais de 15 anos de experiência internacional (Holanda, Alemanha, Suécia, Brasil) na implementação de melhores práticas e adaptações inovadoras em áreas como a Análise de Negócios, Gerenciamento de Projetos e de Programas, Gestão de Produto e Engenharia de Sistemas. Já treinou e prestou consultoria para mais de gerentes de produto, especialistas técnicos, analistas de negócios e gerentes de projeto em formas pragmáticas e altamente eficazes de trabalhar com requisitos e regras de negócios, aplicando práticas orientadas a resultado. Willem é um excelente facilitador, capaz de inspirar as pessoas e construir um ambiente de confiança em todos os níveis de uma organização, seja na alta gestão ou no nível operacional. Tem como característica marcante o seu foco na criação de capacidades humanas, ajudando a (re)estabelecer a paixão e propósito, e aumentando a criatividade e produtividade das equipes. É autor do livro 'Start At The End, with SMART requirements'. Especialidades: Gerenciamento de Projetos e de Programas, Gerenciamento baseado em Business Case, Engenharia de Requisitos, BiSL Certified, PRINCE2 Certified Practitioner, CBAP Certified Business Analysis Professional