Aula 7

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Desenvolvimento Ágil
Ementa
Introdução à Engenharia de Software;
Desenvolvimento Ágil;
Engenharia de Requisitos;
UML;
Processo Definido x Processo Empírico
O processo definido é baseado em leis fundamentais;
Possui um conjunto de entradas, utilizando a mesma teoria, para se conquistar o mesmo resultado;
O projeto está em conformidade com as definições iniciais, como por exemplo, na construção de um edifício, antes do edifício ser construído já se tem todas as definições da planta e dos documentos gerados pelos engenheiros (funcionalidades e características que o edifício terá quando for concluído);
Processo Definido x Processo Empírico
Para utilizar o processo empírico é necessário identificar após a inspeção se ele atende aos seguintes critérios: 
O projeto não se enquadra no processo definido;
Nem todas as variáveis são conhecidas;
O sistema está começando a ser compreendido, é complexo, e com o tempo pode ser alterado;
Scrum
Processo Empírico para gerenciar o desenvolvimento e entrega de produtos complexos;
Empirismo depende de frequente inspeção e adaptação para que os objetivos sejam alcançados;
Scrum se apoia nos pilares do desenvolvimento iterativo que gera incrementos prontos de funcionalidades utilizando times auto gerenciados que são multifuncionais;
Scrum
Ganhou seu nome do rugby, onde é uma forma de recomeçar a partida reunindo todos os jogadores após um incidente ou a bola sair de campo;
A ideia básica é reunir os desenvolvedores para que o jogo continue rolando;
Jeff Sutherland e Ken Schwaber desenvolveram algumas práticas do Scrum ainda em 1994, inspirados pelo modelo LEAN;
Apresentado oficialmente no OOPLSA’96 (Object-Oriented Programming, System, Languages and Applications)
Quem usa Scrum?
Microsoft;
Yahoo;
Google;
IBM;
Eletronic Arts;
High Moon Studios;
Lockheed Martin;
Phillips;
Siemens;
Nokia;
BBC;
Capital One;
Intuit;
Nielsen Media;
BMC Software;
Ipstwitch;
John Deere;
Lexis Nexis;
Sabre;
Time Warner;
Tem sido usado para:
Software comercial;
Projetos de preço fixo;
Aplicações financeiras;
Sistemas disponíveis 24 x7
Vídeo Games;
Sistemas para suporte à vida;
Sistemas para controle de satélite;
Web sites;
Aplicações para handhelds;
Telefones celulares;
Aplicações para redes;
Processo Scrum
Papéis
Timeboxes
Artefatos
Product Owner
Release Planning
Product Backlog
Scrum Master
Spring Planning
Product Backlog Item
Team
Sprint
Sprint Backlog
Daily Meeting
Scrum Board
Sprint Review
Burndown Chart
Sprint Retrospective
Papéis
Timeboxes
Artefatos
Product Owner
Release Planning
Product Backlog
Scrum Master
Spring Planning
Product Backlog Item
Team
Sprint
Sprint Backlog
Daily Meeting
Scrum Board
Sprint Review
Burndown Chart
Sprint Retrospective
PO – Product Owner
É a voz do cliente;
Define as funcionalidades do projeto (visão do produto);
Decide sobre datas de publicação, funcionalidades e orçamento;
Prioriza as funcionalidades de acordo com o valor para o negócio e para o cliente, para otimizar o ROI;
Inspeciona os incrementos e faz as adaptações necessárias ao projeto;
Pode alterar as funcionalidades e as prioridades a cada nova sprint;
PO – Product Owner
Responsável por comunicar o progresso e status do projeto;
Define o valor agregado e principais funcionalidades do produto;
Aprimora continuamente os requisitos;
Define o cronograma, através do Product Backlog priorizado;
Trabalha com a equipe para estimar os itens no Product Backlog;
Responsável pelo sucesso do projeto e pelo retorno do investimento;
PO – Product Owner
Gerencia a entrada de novos requisitos e suas priorizações;
Atua como facilitador quando mais de um cliente estiver envolvido no projeto;
Garante que especialistas de domínio estejam disponíveis para o time;
Papéis
Timeboxes
Artefatos
Product Owner
Release Planning
Product Backlog
Scrum Master
Spring Planning
Product Backlog Item
Team
Sprint
Sprint Backlog
Daily Meeting
Scrum Board
Sprint Review
Burndown Chart
Sprint Retrospective
Scrum Master
Remover barreiras entre o desenvolvimento e o cliente de forma que o cliente guie diretamente o desenvolvimento;
Ensinar o cliente como maximizar o ROI e ir de encontro a seus objetivos através do Scrum;
Melhorar a vida do time, facilitando a criatividade e a capacitação;
Utilizar todos os artifícios possíveis para aumentar a produtividade do time;
Scrum Master	
Melhorar as práticas de engenharia e ferramentas de forma que cada incremento de funcionalidade seja um potencialmente entregável;
Implantar as práticas e regras do Scrum;
Garantir que o processo esteja sendo seguido;
Garantir que o time esteja totalmente funcional e produtivo;
Garantir uma cooperação estreita entre todos os papéis removendo barreiras;
Scrum Master
Remover impedimentos;
Blindar o time contra interferências externas;
Blindar o time contra distrações;
Ensinar o Product Owner e ao time como exercer com excelência seus papéis;
Ajudar o Product Owner a entender melhor como utilizar a capacidade do time;
Garantir que o time não assuma mais coisas do que eles conseguem em uma sprint;
Melhorar o dia-a-dia dos membros do time;
Scrum Master como membro do time
Quais seriam alguns dos desafios que um Scrum Master teria caso ele também fosse um membro do time?
O que poderia ajudar a superar estes desafios?
Papéis
Timeboxes
Artefatos
Product Owner
Release Planning
Product Backlog
Scrum Master
Spring Planning
Product Backlog Item
Team
Sprint
Sprint Backlog
Daily Meeting
Scrum Board
Sprint Review
Burndown Chart
Sprint Retrospective
Time
Normalmente composto por 7 + ou - 2 integrantes;
São auto-organizados;
Multifuncionais, conhecidos como “Desenvolvedores”;
Os membros devem estar alocados fulltime no projeto;
Comprometidos com o trabalho;
Se comprometem com aquilo que sentem que podem realizar;
Tem autoridade para fazer o que for necessário dentro das normas e padrões para alcançar a meta da sprint;
Time
Gerenciam a si mesmos e seus trabalhos;
Colaboram com o Product Owner para otimizar o valor;
Demonstram o resultado do trabalho para o Product Owner;
Comunicativos;
Organizados em um espaço físico apropriado para o trabalho;
Responsáveis pela solução de conflitos;
Devem estar comprometido com o projeto, e não apenas envolvido;
Formação do Time
Reserve pelo menos 1 dia quando o time estiver sendo formado:
Apresentação do time e fornecimento de background;
Definição do nome do time;
Definição do espaço físico de trabalho, além de local e hora para o Daily Scrum;
Definição de “pronto” para o produto e itens do Sprint Backlog;
Regras de desenvolvimento;
Regras de etiqueta;
Dinâmicas de resolução de conflitos;
Verdades sobre a formação do time
Times são mais produtivos que o mesmo número de indivíduos;
O tamanho ideal para times é em torno de sete pessoas, não mais que nove;
Produtos são mais robustos quando um time tem todas as habilidades necessárias focadas no trabalho;
Mudanças na composição do time geralmente diminuem a produtividade por algum tempo;
Verdades sobre a motivação do time
Pessoas são mais produtivas quando elas se auto gerenciam;
Pessoas levam mais a sério quando elas se comprometem com alguma coisa do que quando alguém se compromete por elas;
Pessoas tem diversos momentos criativos durante seu tempo ocioso;
As pessoas normalmente fazem o melhor que podem;
Sob pressão para trabalhar duro, desenvolvedores automaticamente e cada vez mais reduzem a qualidade;
Verdades sobre a performance do time
Times e pessoas realizam um trabalho melhor quando elas não são interrompidas;
Times melhoram mais quando eles resolvem seus próprios problemas;
Comunicação cara a cara é a forma mais produtiva para times trabalharem juntos;