[MÚSICA] [MÚSICA] Olá! Bem vindo ao curso Princípios de Desenvolvimento Ágil de Software. Eu sou o Clovis Fernandes e na aula de hoje estaremos falando sobre o Sprint Zero. Ou seja, ao final desta aula vocês terão uma ideia da estrutura de planejamento ágil que estamos propondo para o nosso Scrum e XP. Suponha que você tem produto novo, quer seja para a sua empresa ou você vai produzir para outros. E você vai usar a modelagem ágil que estamos propondo. Então, você começa com o planejamento no Sprint zero. E o que vai caracterizar esse Sprint Zero? No nosso caso, nós estamos propondo três partes, três etapas. Mas existe uma coisa que é mais geral que devemos falar inicialmente. Imagine que você, dependendo do tamanho da aplicação que você vai desenvolver, esse Sprint Zero, ele não deve levar muito tempo. Ele tem que ser ágil. Então pode ser feito dia, uma semana, duas semanas, três semanas, mês. Até mês está bom. Excepcionalmente projetos muito grandes, até dois meses. Se existem muitos riscos envolvidos nesse desenvolvimento, coisas muito desconhecidas, até dois meses. Mas normalmente ele vai ser feito duas semanas, esse é o usual que nós vamos estar buscando, o ideal que estaremos buscando. E o que temos que levar conta, principalmente com isso? É isso! Nós não vamos estar fazendo, como é planejamento ágil, nós não estaremos tentando ser completos, nós estaremos usando o que a gente chamou de EDUF- Enough Design Up-Front. Projeto Antecipado Suficientemente. Nós iremos fazer planejamento que seja suficiente para que eu possa começar o meu projeto num patamar muito bom. Porquê? A ideia é fazer que eu olhe pouco para a frente. Mas sem compromisso forte de que aquilo que eu estou propondo é o que deve ser feito sempre. Não. Ele vai poder ser revisto. Aí você tem a informação suficiente para fazer bom começo, bom desenvolvimento. A parte vocês vejam que é montado grupo na empresa e não tem nada a ver com PO, com Scrum Master nem com Time de Desenvolvimento. Eles vão fazer uma avaliação de negócio dessa nova aplicação. O que eles chamam de Business Case que são avaliações bem rigorosas sobre a viabilidade do software. Aqui não estaremos fixando como fazer isso. Estamos só dizendo que de alguma maneira isso tem de ser feito. Dessa avaliação de negócios é que nós vamos extrair o que a gente chama de Visão da Aplicação Essencial, ou seja, é uma coisa muito resumida que nós já tínhamos usado quando fizemos a especificação da Visão da Aplicação anteriormente. Dos passos iniciais era fazer essa Visão Essencial. Eu até mostrei modelo, molde, template que eu vou relembrar aqui agora. Aqui no nosso exemplo do Livros a Jato "Para pessoas que compram na Internet, que querem usufruir de preço mais baixo, a Livros a Jato é uma loja virtual, website que oferece acesso a ebooks gratuitos e pagos de diferentes editoras brasileiras e estrangeiras." vem o diferencial do Livros a Jato relação às outras: "Diferentemente de lojas similares, nosso produto notifica o cliente quando grupos de 10 novos títulos são incorporados ao nosso acervo." Vocês vejam que essa Visão Essencial é baseado no resultado dessa avaliação de negócios e vai ajudar a gente a fazer as coisas. Ainda na parte os stackeholder ou interessados nessa nova aplicação clientes, usuários, gerentes, alta administração eles têm que comprar a ideia, ele têm que achar que isso vai dar retorno para a empresa. Isso vai ser importante de alguma forma para a empresa, às vezes, o retorno não é financeiro. Às vezes o retorno é mais na imagem da empresa, Não importa o que é que eles querem como retorno mas eles têm que comprar a ideia. É isso que no final a gente tem que obter. A aprovação da alta administração. Só então é que a equipe para desenvolver aquele software vai ser montada. É onde você vai designar Product Owner, PO, vai designar Scrum Master, e vai designar time de desenvolvimento. E são eles que vão agora trabalhar a etapa dois e a etapa três do que a gente está propondo para o Sprint Zero. Até esse momento é uma tomada de decisão. Por causa da aprovação dos stakeholders nós vamos continuar mas o produto podia ter morrido aqui e agora. Quer dizer, antes de definir, os stakeholders podiam não gostar e o projeto não vai para a frente. Indo para a frente, tem que garantir os fundos e tem que garantir vários recursos, incluindo a equipe. Na parte dois, já agora contando com PO e Scrum Master e o Time de Desenvolvimento, agora sim, nós vamos desenvolver de maneira ágil, voltada para os tipos de usuários, procurando evidenciar o que é que esses usuários gostariam que o sistema tivesse nós iremos então definir a Visão da Aplicação. Lógico, quem vai sacramentar que vai nessa Visão da Aplicação é o PO. Ele que vai sacramentar isso. Com base na Visão da Aplicação, agora pouco mais completa, iremos definir a equipe, vai definir quais User Stories são derivadas da Visão da Aplicação, as User Stories iniciais que vão aparecendo. Mais para a frente vão aparecer outras User Stories à medida que nós conhecemos mais a aplicação e à medida que novas demandas dos stakeholders aconteçam. Mas nesse momento são as iniciais. Essas iniciais a gente vai colocar numa coisa que a gente chama de Product Backlog, o Backlog do produto. Aí, duas coisas irão acontecer. O PO vai priorizar essas o que a gente chama do PBL, ele vai priorizar, por ordem as User Stories. Ou seja, as User Stories, vão ficar mais no topo aquelas que são mais interessantes de acordo com o valor de negócio que o PO junto com os stakeholders vai determinar. E outra coisa que vamos fazer também é Planning Poker. O Planning Poker que vai definir o esforço que nós vamos atribuir, uma estimativa de esforço para cada User Story do PBL. Então, no PBL eu vou ter essas informações, vou ter também Testes de Aceitação e com isso, lembrando que nem aquela parte why de uma User Story nem os Testes de Aceitação preciso estar com eles prontos todos agora. Mas é importante se eu posso defini-los antecipadamente ou já vou colocando mas, pode até ser mudados ou vir novos testes de aceitação. A parte três muitos planejamentos ágeis, elas são deixadas para serem feitas no Sprint. Se você tiver tempo, ela devia ser feita antes de começar o Sprint. O que nós queremos é propor uma arquitetura preliminar, a gente chama de walking skeleton, esqueleto ambulante, aquele que vai por de pé a aplicação, para eu começar a desenvolver o software cima disso. Então, eu vou definir sobre sistemas, eu vou definir banco de dados, eu vou definir plataforma web, eu vou usar Python e Jango para web, eu vou usar Java e Spring, eu vou usar o Ruby on Rails. Então, eu vou definir tudo isso nessa parte, tudo muito rapidamente. O que caracteriza o Scrum e XP, o Scrum especial, mas o Scrum e XP é que todas essas etapas, dependendo do tamanho do software, elas vão ter tamanhos, mas os tamanhos devem ser cumpridos. Se eu determinei que duas semanas é para fazer o Sprint Zero é duas semanas que o Sprint Zero tem que ser terminado, então você vai fazer aquilo que é possível porque você sabe que você pode ir desenvolvendo novas coisas ao longo do tempo. Com isso, você acabou de ser apresentado à estrutura de planejamento ágil que nós propomos que seja usado no Scrum e XP. Obrigado. [MÚSICA] [MÚSICA]