produção à Engenharia de Software Unidade III Exemplo de um Processo de Software - Scrum

Transcrição

1 Introdução à Engenharia de Software Unidade III Exemplo de um Processo de Software - Scrum Pedro de Alcântara dos Santos Neto pasn@ufpi.edu.br Roteiro Explicaremos o SCRUM seguindo a seguinte estrutura: Um breve histórico Detalharemos os Papéis Detalharemos todas as cerimônias prescritas pelo processo Ritual com formalidades a serem seguidas Detalharemos, dentro das cerimônias, resultados associados Correspondendo aos principais artefatos a serem gerados nos projetos Um breve histórico Jeff Sutherland Uso inicial do scrum na Easel em 1993 IDX e mais de 500 pessoas usando scrum Ken Schwaber Apresentação na OOPSLA 96 com Sutherland Três livros sobre Scrum Mike Beedle Padrões para o Scrum na PLOPD4 Ken Schwaber and Mike Cohn Fundaram a Scrum Alliance em 2002, inicialmente junto com a Agile Alliance Quem usa Scrum? Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce Para que o Scrum tem sido usado? Software comercial Desenvolvimento interno Desenvolvimento contratado (terceirização) Projetos de preço o fixo Aplicações Financeiras Aplicações certificadas pela isso 9001 Sistemas embarcados Sistemas disponíveis 24x7 Desenvolvimento por hackers solitários Video games Sistemas para suporte à vida Sistemas para controle de satélites Websites Software para handhelds Telefones celulares Aplicações para redes Aplicações de ISV (Independent Software Vendors) Algumas das maiores aplicações em produção Para que o Scrum tem sido usado? Equipes que se auto-organizam organizam O produto evolui em uma série s de Sprints mensais O Sprint é um período definido em que se trabalhará buscando cumprir um objetivo Os requisitos são listados em um Product Backlog Não háh prática de engenharia prescrita (o Scrum adequa-se a todas) Usa regras generativas na criação de um ambiente ágil para a entrega de projetos É uma das metodologias ágeis 1

2 Os Papéis... Com relação à equipe Aconselhado para equipes com pelo menos 3 colaboradores Idealmente de 5 a 9 Multi-funcional Programadores, testadores, webdesigners,, etc. Tempo integral Quando houver estagiários rios, todos no mesmo turno Trocas só na mudança de Sprints Todos devem sentar junto. Ter funções variáveis veis podendo ser fixas em um sprint Pedir ajuda e ajudar sempre que necessário Com relação ao Scrum Master Toda equipe deve ter um Scrum Master Representa a gerência para o projeto Responsável pela aplicação dos valores e práticas do Scrum Remove obstáculos Garante a plena funcionalidade e produtividade da equipe Garante a colaboração entre os diversos papéis e funções Escudo para interferências externas Com relação ao Product Owner Todo projeto deve ter um Product Owner Idealmente membro dos clientes do produto Mas em casos excepcionais um membro da equipe Ele deve priorizar as ações da equipe Para isso, deve entender o produto a ponto de priorizar sem gerar problemas Ajusta funcionalidades e prioridades Aceita ou rejeita o resultado dos trabalhos As Cerimônias... Cerimônias: A Reunião Inicial 2

3 A A Reunião Inicial Definição das estórias/funcionalidades do produto Product backlog Geralmente feito com a participação de toda a equipe + product owner e, opcionalmente, outros membros representante dos clientes Um ou mais dias de conversas, com registro dos dados em um documento Equivalente ao levantamento de requisitos Nos processos tradicionais A A Reunião Inicial Como obter informações sobre o produto? Estudando e lendo materiais relacionados Analisando softwares pré-existentes Perguntando... O quê perguntar? Tente seguir os passos do negócio para se fazer algo Sempre que um passo for descrito, questione o que necessita para aquilo ser exeqüí üível Se existe algo anterior, questione sobre ele Repita esses passos até que tudo tenha sido coberto... A A Reunião Inicial Como registrar? Diagrama de casos de uso fornece uma boa visão sobre os atores do sistema e funcionalidades Composto por atores e casos de uso Atores são papéis associados ao uso do sistema (e não pessoas!) Casos de uso são as funcionalidades do produto, que possuem um valor para seus usuários, sem lacunas nem superposição com outros casos de uso Número de ordem Caso de uso 1. Cadastro de Solicitação de Leito 2. Autorização de envio para lista de espera 3. Controle da Lista de Espera 4. Controle da Lista de Encaminhamento 5. Controle de Internações Descrição Cadastro das solicitações de leitos para pacientes com necessidades de internação. Registro da autorização da solicitação para constar na lista de espera por leitos. Controle da lista de espera por leitos, com registro de evolução dos pacientes, além de registro de entrada ou encaminhamento em leitos hospitalares e eventual remoção da lista. Controle dos encaminhamentos de pacientes para leitos, com remoção automática da reserva associada caso não seja realizado o registro de entrada no prazo previsto. 6. Controle de Leitos Bloqueio e liberação de leitos. Controle das internações em leitos, com possibilidade registro de alta, e conseqüente liberação do leito, além de transferências para outros leitos. Número de ordem Ator Definição 1. Intensivista Médico plantonista que coordena a UTI no hospital e faz a solicitação das vagas. 2. Regulador Médico regulador da Central de Leitos, que recebe, avalia e gerencia as solicitações e eventuais internações. 3. Auditor Médico da Central de Leitos, que visita os hospitais e verifica se as informações no sistema correspondem à realidade. 4. Gerente Médico regulador da Central de Leitos que atua em casos excepcionais, controla leitos e usuários do sistema. 5. Plantonista Profissional da saúde escalado em plantão, responsável por verificar a necessidade de internação de um paciente em UTI. 6. Médico Profissional da medicina escalado em Plantão. 7. Enfermeira Profissional de enfermagem, escalado em Plantão e responsável por auxiliar o Intensivista em suas tarefas. 8. Auxiliar Enfermeira escalada em Plantão responsável por auxiliar o Intensivista em suas tarefas. 9. Chefe de Setor Profissional de saúde responsável por controlar as escalas de plantão de um hospital. 3

4 A A Reunião Inicial Principal resultado: Product Backlog Representa os requisitos do produto Uma lista de todo o trabalho desejado no projeto Cada item deve ter seu peso de acordo com a vontade dos usuários Priorizado pelo dono do produto Repriorizado no início de cada Sprint A A Reunião Inicial Principal resultado: Product Backlog ID Nome Prioridade Tempo Estimado Tempo Gasto 2481 Preparar ambiente para integração contínua Criar projeto base no CVS Modelar Contrato e Remuneração Implementar Gestão de Contrato Implementar Gestão de Remuneração Testes Funcionais Gestão de Contrato Testes Funcionais Gestão de Remuneração 50 8 Product Backlog Cerimônias: A Reunião de Planejamento Planejamento A equipe seleciona itens do Product Backlog com os quais compromete-se a concluir Definição da carga de trabalho da equipe O Sprint Backlog é criado Com criação dos cartões Tarefas identificadas e estimadas Criação do gráfico de acompanhamento Definição do local e horário rio das reuniões diárias Definição do conceito de feito Organização do quadro do projeto É importante a participação do product owner, para entender o funcionamento... Para determinação da carga de trabalho do grupo, devemos calcular o tempo disponível Definir tamanho do Sprint (em dias) Normalmente usa-se se 2 semanas (10 dias úteis) Esse número n pode ser menor, quando precisamos ter respostas mais rápidas r e para obter dados sobre produtividade Ou maiores, quando as coisas jáj estão mais estáveis 4

5 Um grande problema: Tarefas não planejadas! Tarefas que surgem durante o sprint e que necessitam ser realizadas Muito comum nos locais que tem softwares em operação Como resolver essa questão, visto que temos que planejar as atividades? Previsão de tempo para tais tarefas Podem ou não fazer parte do sprint Registro do tempo gasto, para facilitar novas estimativas O fator de ajuste pode ser utilizado nessa direção! Fator de ajuste Percentual de tempo produtivo efetivamente utilizado para computar carga de trabalho da equipe Colaboradores que trabalham 8h/dia, dificilmente passam 8h realizando tarefas diretamente relacionadas ao desenvolvimento Existe tempo para ler se Conversar com colegas Tomar café,, ir ao banheiro, etc... Um fator de ajuste muito comum é usar 75% Mas esse número n depende da organização... Dedicação dos membros da equipe Colaboradores com cargos chaves no processo precisam ter sua carga de trabalho analisada Scrum masters normalmente gastam metade do tempo útil em tarefas relacionadas à condução do processo Quando um colaborador assume o papel de Product owner,, provavelmente gaste também m metade do tempo útil com tarefas de verificação e eliminação de dúvidas, além m do contato com os usuários do produto Cada projeto é uma realidade diferente! Exemplo Objetivo Duração Fator de ajuste Contrato e Remuneração 10 0,6 Colaborador Dedicação diária Total Pedro 4 24 Emanoel 8 48 Daniel 8 48 Danilo 4 24 Eric Muniz 6 36 Total do Sprint Total = dedicação diária * duração sprint * fator ajuste 180 Colaborador em outro projeto Product owner Fator de ajuste reduzido por conta do não cumprimento dos prazos Scrum Master Total do Sprint Gráfico de acompanhamento h Gráfico de Acompanhamento Dias do Sprint 180 Gráfico de acompanhamento Representa a quantidade de horas associadas às tarefas do Sprint Idealmente, as tarefas deveriam ser finalizadas ao longo dos dias do Sprint O O gráfico ideal é uma reta que inicia na carga de trabalho da equipe (180h no exemplo) e finaliza em 0 no último dia do Sprint A A cada tarefa concluída e verificada, devemos descer a quantidade de horas no gráfico Discutido mais a frente... 5

6 Devem ser utilizados cartões para representar as tarefas Criados no planejamento O verso pode ser utilizado para observações ID Tempo Estimado NOME DESCRIÇÃO COMO VERIFICAR Tempo Real Responsável pela tarefa Planejamento Divisão dos cartões ID: identificador da tarefa Utilizado para acompanhamento em ferramentas que controlam a apropriação de horas Nome Descrição: texto simples e objetivo descrevendo a tarefa Como verificar: indicação de como deve ser feita a verificação dessa tarefa, quando a mesma estiver concluída Embora pareça dispensável,, quando existem muitas tarefas a verificar, podemos perder o foco no que é importante» Fortemente aconselhável para toda e qualquer equipe» Base para construção dos testes para a funcionalidade Divisão dos cartões Tempo estimado: tempo especificado pela equipe para realização da tarefa Como estimar tal tempo? Jogo do planejamento» Todos da equipe possuem cartas» Discute-se se sobre a tarefa e solicita-se se que todos joguem cartas representando sua estimativa (viradas para que ninguém m veja a estimativa antes que todos estimem!) Divisão dos cartões Tempo estimado: Pode-se considerar a média, m descartar alguns valores (maior e menor, por exemplo) O importante é estabelecer parâmetros de aceitação» Um? indica que mais explicações são necessárias» Um 0 indica algo tão pequeno que não merece estimar» Uma xícara x indica necessidade de tempo pra pensar...» Tarefas acima de 16h merecem ser divididas» Estimativas muito diferentes merecem explicações Divisão dos cartões Tempo real: Tempo efetivamente utilizado para realização da tarefa Fundamental seu registro para auxiliar estimativas futuras Responsável Colaborador encarregado de realizar a tarefa A princípio pio não deve ser pré-estabelecido» Cada um faz o que mais lhe agrada das tarefas Mas o bom senso sempre deve imperar!» O objetivo é seguir o plano, desde que não se crie ilhas do conhecimento Como selecionar tarefas para o Sprint? Deve-se selecionar do Backlog as tarefas mais importantes Encaixando dentro da carga de trabalho indicada pela equipe De forma a termos o maior aproveitamento dessa carga de trabalho 6

7 Como selecionar tarefas para o Sprint? As tarefas selecionadas representam um compromisso assumido com o Product Owner Para isso, todos devem concordar e acreditar nas estimativas Mais uma vez o bom senso deve imperar Se alguém m não acredita no que foi dimensionado para o Sprint,, fale sobre isso!!! Definição de Feito (DoD( DoD) Todo projeto deve ter uma definição claro sobre o que é considerado feito! Para uma tarefa de modelagem, por exemplo: Diagrama representando a modelagem feito na ferramenta JUDE Diagrama contido no CVS Revisão em conjunto com o Scrum Master Definição de Feito (DoD( DoD) Para uma tarefa de implementação no modelo: Criação das classes no projeto Criação do teste de unidade Inclusão do teste na integração contínua nua Classes no CVS Para uma tarefa de implementação na visão: Criação das classes no projeto Criação dos testes funcionais com Selenium Classes no CVS Redação do manual do usuário e inclusão no CVS Definição de Feito (DoD( DoD) Podem haver definições de feito gerais na organização Podendo haver especializações por projeto É importante deixá-las clara no planejamento, para que todos saibam que existe e com isso garantir sua utilização ão! Dependendo do projeto,, novas definições precisam ser criadas O que é feito para uma tarefa de documentação ão? Definição do local e horário rio das reuniões diárias No planejamento é fundamental especificar tais dados Essas reuniões são vitais para o bom andamento do projeto Organizar a equipe de forma que todos participem Problemas quando temos pessoas dedicadas parcialmente Definição da data, horário rio e local para apresentação dos resultados do Sprint Definição da data, horário rio e local para apresentação dos resultados do Sprint Todos devem saber das datas! 7

8 Organização do quadro do projeto Organização do quadro do projeto Os quadros devem ter as seguintes divisões para tarefas Não iniciadas, Em execução ão, Concluídas das, Verificadas Organização do quadro do projeto para Objetivo do Sprint para o Gráfico de Acompanhamento para especificar a Equipe para detalhar a data de início e fim do sprint para especificar dia da apresentação dos resultados para especificar local e horário rio das reuniões diárias para especificar o dia da retrospectiva Cerimônias: A Reunião Diária A A Reunião Diária Importante: Deve ser diária ria! Em torno de 15 minutos Todos em pé! Facilita o gerenciamento do tempo Não é para a solução de problemas Problemas devem ser identificados Sua solução é tratada depois Ajuda a evitar reuniões adicionais desnecessárias A A Reunião Diária Todos respondem 3 perguntas: O que foi feito de ontem pra hoje? 1 2 O que será feito de hoje até amanhã? 3 Existe algum impedimento? 8

9 A A Reunião Diária Problemas são detectados e discutidos inicialmente Impedimentos são registrados Itens não planejados também são registrados para acompanhamento Todos falam,, sob a supervisão do scrum master Cerimônia: Acompanhamento do Projeto Acompanhamento do Projeto Além m das reuniões diárias, o Scrum Master possui outras tarefas rotineiras: Verificar tarefas concluídas Atualizar gráfico de acompanhamento Resolver impedimentos Atuar quando houver desvio no planejamento Acompanhamento do Projeto Verificação das tarefas concluídas Idealmente deve ser feito pelo Scrum Master + Product Owner Utilizar a definição de como verificar existente no cartão Seguir a definição de feito Se algum item não coincidir com o especificado, indicar ao responsável para efetiva conclusão Muito cuidado com os testes! Para tarefas de implementação Não se ater somente no funcionamento Incluir a análise do códigoc Acompanhamento do Projeto Atualização do gráfico de acompanhamento Para cada tarefa verificada, baixar número n correspondente à estimativa no gráfico Estimativa e não o tempo efetivamente gasto!!! Mas pode-se ter uma outra linha com o tempo trabalhado» Existem controvérsias rsias sobre o que utilizar, assim, use as duas linhas Acompanhamento do Projeto Resolução de impedimentos Durante as reuniões diárias impedimentos podem ser identificados Cabe ao Scrum Master garantir sua resolução Isso pode significar atuar junto à gerência Os impedimentos devem ser acompanhados Registrar identificação do impedimento» Ou seja, criar cartão diferenciado, associado ao cartão impedido e deixar isso bem visível vel Registrar solução 9

10 Acompanhamento do Projeto Atuação nos desvios de planejamento Durante a atualização do gráfico de acompanhamento podem ser notados grandes desvios O Scrum Master deve atuar para tentar identficar causas Tentando propor contramedidas para reduzir os atrasos Atividade freqüente ente e contínua... nua... Mas sem um guia sobre como agir Cada caso é um caso... Acompanhamento do Projeto Os membros da equipe devem: Pegar uma tarefa e indicar isso através s do quadro Mudando para área em execução ão e registrado-se se como responsável Atualizar registro de tempo gasto na tarefa Registrando no meio indicado pela empresa (atualmente no Quantum) Onde não existe meio eletrônico, pode-se usar marcas representando tempo gasto (*, _, etc.) Informar a finalização de uma tarefa, com registro do tempo gasto Lembrando que ela pode voltar para em execução ão,, caso não seja aprovada...» Ou seja, não finalize no Quantum tarefas ainda não verificadas... Cerimônias: Apresentação do Sprint Apresentação do Sprint Equipe apresenta os resultados obtidos durante o Sprint Tipicamente, demonstração de novas funcionalidades ou sua arquitetura Informal Sem muita preparação Preocupar-se com o ambiente» reserva de sala, equipamentos Sem slides Toda a equipe participa Todos são convidados Cerimônias: Retrospectiva Retrospectiva Durante o Sprint, é necessário observar o que funciona e o que não funciona Na retrospectiva, isso deve ser discutido por todos Tipicamente uma reunião rápida,, com cerca de 1h Feita após cada Sprint Toda a equipe participa ScrumMaster Dono do produto Membros da equipe Clientes e outros 10

11 Retrospectiva A equipe tenta responder a três questões O O que você achou muito bom no Sprint e que deveria continuar sendo feito O O que você achou muito ruim e não deveria mais ser feito (ou mudado) O O que não está sendo feito mas deveria iniciar Continuar fazendo Parar de fazer Iniciar a fazer Retrospectiva Cada membro anota as respostas em cartões Cada cartão com uma resposta No máximo m 3 cartões por pergunta As resposta similares devem ser agrupadas Continuar fazendo Parar de fazer Iniciar a fazer Retrospectiva Para cada questão registrar as 3 respostas mais utilizadas Elas devem ser utilizadas pelo Scrum Master na condução dos novos Sprints Evitar o que foi considerado ruim Garantir que as coisas boas continuam Garantir que o que foi sugerido iniciar realmente iniciou Continuar fazendo Parar de fazer Iniciar a fazer Final do Sprint Terminei um Sprint,, e agora? Utilize no máximo m um dia para pequenos ajustes e realize novo planejamento Introdução à Engenharia de Software Unidade III Exemplo de um Processo de Software - Scrum Pedro de Alcântara dos Santos Neto pasn@ufpi.edu.br 11