Orientações iniciais. FATTO Consultoria e Sistemas -

Transcrição

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

2 FATTO Consultoria e Sistemas Missão: Ajudar nossos clientes a planejar e controlar melhor seus projetos de software. 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 Representante do Scope Project Sizing Software Aumenta seu nível de governança nas medições funcionais e na gestão dos ativos de software FATTO Consultoria e Sistemas - 2

3 3 Cursos da FATTO APF: Fundamentos, Benefícios e Implantação 8 horas (EAD e presencial) Preparação para o Exame CFPS 96 horas (EAD e presencial) Capacitação em APF: Medição e Estimativa de Software 16 horas (EAD e presencial) Medição e Estimativa de Software com o Método COSMIC 16 horas (presencial) Workshop APF: Metodologia e Práticas de Medição 16 horas (presencial) Oficina de Contagem de Pontos de Função Sessões de 8 ~ 40 horas Estimativa de Projetos de Software com o COCOMOII 16 horas Engenharia de Requisitos de Software 24 horas Introdução ao Gerenciamento de Projetos 16 horas Oficina de Requisitos Sessões de 8 ~ 40 horas Gestão de Riscos em Projetos 16 horas

4 4 Desafios e soluções para trabalhar com Requisitos de Software Sejam bem vindos Guilherme Siqueira Simões

5 5 O que será apresentado? O que é a Engenharia de Requisitos Importância da Engenharia de Requisitos O que é Requisito? Comunicação, acesso a partes interessadas, usuários que não sabem o que querem, requisitos implícitos, mudanças, conflitos, resistência à mudança, usuários que não dominam o seu negócio, clientes que não leem a especificação de requisitos Conclusão

6 O que é Engenharia de Requisitos Disciplina da Engenharia de Software que consiste no uso sistemático e repetitivo de técnicas para cobrir atividades Obtenção, Documentação, Manutenção de um conjunto de requisitos para software que atendam aos objetivos de negócio e sejam de qualidade* FATTO Consultoria e Sistemas - * 6

7 7 Causas de fracasso em projetos* 47% dos projetos fracassados tem como causa gestão de requisitos deficiente Sintomas diretos ou indiretos desta deficiência: Scope Creep; Comunicação deficiente; Baixo envolvimento de partes interessadas e Suporte inadequado do patrocinador *PMI s Pulse of the Profession: Requirements Management A Core Competency for Project and Program Success

8 8 Origem dos defeitos Em um estudo mais recente, Capers Jones afirma que 20% dos defeitos têm origem no trabalho de requisitos Software Defects Origins and Removal Methods Capers Jones ~40% do orçamento total dos projetos é gasto em retrabalho. Em projetos maiores, ~50% Encontrar e corrigir erros originados em requisitos consome entre 70 e 85% do custo total de retrabalho do projeto em função de sua quantidade e efeito multiplicativo

9 Quanto custam os reparos de defeitos Custo unitário para detectar e reparar um erro durante a codificação FATTO Consultoria e Sistemas - Leffingwell, D; Calculating the Return on Investment from More Effective Requirements Management ; American Programmer 10(4); 13-16; Software Defect Reduction Top 10 List Barry Boehm y Victor Basili

10 Definição de Requisito (1) uma condição ou capacidade necessária por um usuário para resolver um problema ou alcançar um objetivo. (2) uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente de um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto (3) uma representação documentada de uma condição ou capacidade como em (1) ou (2) FATTO Consultoria e Sistemas - desejo (projeto) produto Documentação das capacidades do projeto ou produto 10

11 Quais os problemas nesta tirinha? Imagem extraída de FATTO Consultoria e Sistemas

12 E se não houvesse telefone sem fio? FATTO Consultoria e Sistemas Entregar exatamente o que o cliente pede é garantia de satisfazê-lo???

13 13 Dificuldade: Comunicação Comunicar-se com objetividade e sem ambiguidade Os requisitos em geral são expressos em linguagem natural, o que facilita a compreensão, porém permite que se crie múltiplas interpretações Falha na interpretação das mensagens trocadas entre clientes e analistas de requisitos, bem como propagação incorreta da mensagem entre os membros da equipe do projeto

14 14 Comunicação - Solução Desenvolver suas habilidades de comunicação (verbal, não verbal, escuta e escrita) e relacionamento interpessoal

15 15 Dificuldade: Acesso aos interessados Nem sempre está ao alcance do analista de requisitos selecionar as pessoas com quem irá levantar requisitos As vezes um intermediário é selecionado para representar o papel do usuário. Isto é mais comum quando o usuário é de fora da empresa (cliente, fornecedor, parceiro, etc) Isto significa um risco considerável da informação levantada não ser a mais adequada Não tenho tempo Qual o papel desta pessoa? Cliente direto? Cliente indireto? Externo à empresa?

16 16 Acesso aos interessados - Solução Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto Princípio 4 do Manifesto Ágil ( Promover cultura de participação Esclarecer a importância do papel do interessado no processo Obter ajuda de alguém com mais autoridade (GP?) Usar métodos de levantamento que necessitem de menos tempo do interessado: observação, questionário, análise de documentos Identificar outra pessoa que também possa ter a informação e que tenha mais interesse em participar e disponibilidade

17 17 Dificuldade: Usuário que não sabe o que quer Esta dificuldade varia desde o usuário que não sabe dizer o que quer até aquele que diz a necessidade incorreta O que fazer? Trocar os usuários?

18 Usuário que não sabe o que quer - Solução O grande valor do trabalho do analista de requisitos é compreender corretamente as necessidades, ainda que o usuário não saiba dizer com clareza o que deseja. Para alcançar isso, o trabalho deve ser proativo, e não passivo Selecionar os métodos adequados para elicitação O que funciona para alguns não funciona para todos. Prototipação e observação são muito efetivas para lidar com aqueles que tem dificuldade em se expressar FATTO Consultoria e Sistemas

19 Dificuldade: Requisitos Implícitos Ou óbvios, mas não ditos O analista ouve os usuários, documenta e confirmar suas necessidades, especifica uma solução, valida este projeto com os usuários e obtém a aprovação. O produto é desenvolvido e na entrega são apresentadas várias necessidades não supridas pelo produto Quem falhou? O analista? Os usuários? A B C FATTO Consultoria e Sistemas - Correcto Especificado 19

20 20 Requisitos Implícitos - Solução Acreditar que o trabalho de requisitos está restrito ao que é explícito não é a realidade Entretanto não há método que garanta que uma especificação esteja completa. É possível minimizar via: Aprofundar o conhecimento no negócio Técnica de observação Técnica de prototipação

21 21 Dificuldade: Mudanças "(...) requisitos mudam a um ritmo de 2% ao mês (...)" - Capers Jones en Software Engineering: The State of the Art in 2008.

22 22 Mudanças - Solução Mudanças geram trabalho adicional. Porém nem todas significam problema. Mudanças deveriam existir para aumentar (ou preservar) o valor do projeto Um trabalho de requisitos passivo, quase sempre provoca muitas mudanças desnecessárias mais à frente (para corrigir o escopo). Postura proativa é fundamental Para as mudanças inevitáveis, o que se pode fazer é estar preparado para a mudança. Criar especificações de requisitos facilmente modificáveis é uma maneira

23 23 Dificuldade: Conflitos Conflitos aumentam na proporção da quantidade de interessados. Exemplos: Pedidos de partes interessadas distintas que não se podem atender simultaneamente Dados inconsistentes sobre o processo de negocio Falta de sintonia entre as áreas de negocio Solicitações fora do escopo do projeto Partes antipáticas umas às outras

24 24 Conflitos - Solução Resolução de conflitos é uma responsabilidade mais direta do GP que do analista de requisitos Porém, desenvolver habilidades de relacionamento interpessoal é fundamental para o analista de requisitos. Antes de tudo, ele não deve ser um foco gerador de conflitos Além disso, para muitos cenários, ter habilidades de diplomacia, política e psicologia é muito eficaz para evitar e eliminar conflitos

25 25 Dificuldade: Resistência à Mudança Projetos introduzem novidades. Novidades frequentemente geram temor e/ou preocupação nas pessoas Manter a zona de conforto é a reação natural da maioria

26 26 Resistência à Mudança - Solução Qual a motivação para a resistência? Interesse de alguém é prejudicado? Buscar fontes de informação alternativas: outras pessoas, documentos, observação Falta de conhecimento sobre os objetivos do projeto? Comunicar os benefícios a serem gerados pelo projeto

27 27 Dificuldade: Cliente não domina seu negócio Espera aí, como é que é? Como assim? Isso não seria obrigatório? Às vezes isso ocorre, mas como uma situação transitória, por exemplo: um novo gestor assume a diretoria de uma área de negócio nova para ele Porém é frequente em alguns casos: Pessoas em cargos não por competência, mas por política Trocas frequentes de gestores (governo depois de eleição) Áreas de negócio que delegam para a TI decisões que são de sua própria responsabilidade

28 28 Cliente não domina seu negócio - Solução Melhorar o próprio conhecimento no negócio Buscar outras fontes de informação (outras pessoas quase sempre há, documentação existente) Alinhar os papéis entre a TI e as demais áreas de negócio da organização

29 29 Dificuldade: Cliente não lê a especificação A especificação de requisitos é o contrato da equipe de desenvolvimento para com o cliente Ela deve comunicar ao cliente tudo que será entregue (logicamente satisfazendo todas suas necessidades) e o cliente deve conseguir compreendê-la e dar sua aprovação para que o trabalho no projeto possa seguir adiante Contrato que não é aprovado pelas partes não tem validade

30 30 Cliente não lê a especificação - Solução Parar o projeto? Entender o motivo para não se ler a especificação As pessoas não compreendem sua função e acham que é só burocracia Comunicar como funciona o processo de desenvolvimento Simplificar a documentação Apresentação equivocada dos requisitos Definir o nível de feedback desejado O cliente acredita que já sabe tudo Se isto é verdade, ótimo. Se não é, apresente estes pontos

31 31 Conclusão Os itens apresentados abrangem boa parte das dificuldades mais frequentes no trabalho de requisitos. Porém não esgota a discussão É possível que você tenha experiência com outros desafios ou soluções para o que comentamos. Participe! Comente agora no chat

32 32 Fechamento Perguntas? Obrigado pela atenção e participação! Guilherme Siqueira Simões guilherme.simoes@fattocs.com linkedin.com/in/guilhermesimoes Skype: guilherme.s.simoes