Untitled

Page 1

curso SCRUM eld

primeiras metodologias de desenvolvimento de software

- cascata (waterfall): fechado em etapas que não possuiam retorno. Era um ciclo de desenvolvimento unico. Como era um ciclo de desenvolvimento muito longo, o resultado demorava muito pra chegar ao cliente. as vezes eram dois anos e nada de haver um retorno ao cliente e o resultado gerado muitas vezes não era o que o cliente queria. Apos tantos fracassos, surgiu a prototipação

-prototipação: fazia varios ciclos de prototipos, de construção de prototipos, pra depois começar o desenvolvimento. A problematica desse modelo é que muitas vezes o cliente acreditava que o prototipo já era o modelo pronto. O problema do feedback foi então resolvido, porem, o tempo de desenvolvimento ainda era muito longo e levava a insatisfação.

-modelo iterativo: resolveu a questão da demora de um desenvolvimento. havia varios ciclos de desenvolvimento, mas a problematica desse modelo é que não havia foco em uma entrega de valor. o software só estaria pronto pra uso no ultimo ciclo de desenvolvimento.

MANIFESTO AGIL

surgiu em fevereiro de 2001, com os seguintes objetivos:

-restaurar a credibilidade da metodologia

-restaurar o balanço no desenvolvimento de software (diagramas eram necessarios mas não centenas de arquivos em um repositorio corporativo, também precisava haver documentação, mas não centenas de paginas raramente atualizadas, melhora no planejamento, onde se planejavam determinadas coisas, porem elas mudavam ao longo do planejamento, um contrato é obrigatorio, mas a colaboração deve estar acima. )

apos uma discussão com essas questoes, 4 valores funcamentais foram descritos:

individuos e interações são mais importantes do que processos e ferramentas

o software funcionando é mais importante do que uma documentação

a colaboração com o cliente é mais importante do que o contrato

e responder a mudança é mais importante do que seguir o plano.

em 2000, o cenário muda e iniciou-se a construção de MVP'S, que tinham por objetivos fazer entregas parciais aos clientes, mesmo que não fosse 100% o que o cliente queria.

existe um grafico chamado de matriz stacey. ele define uma tomada de decisão. Exemplo: há um time que trabalha com design web, porém a empresa resolveu fazer algo relacionado a I.A. Nesse caso, o scrum não é aplicavel, por trabalhar com sprints que possuem objetivos (que nesse caso seriam indefinidos pois o time não sabe o que está fazendo), então seria melhor a metodologia kanban.

há o framework cynefin, onde os devs começam a estudar e um ambiente que era desconhecido como a ia citada no paragrafo acima, começa a fazer mais sentido e deixa de ser complicado.

Portanto, no inicio, onde não se sabe nada, é possivel começar pela metodologia kanban e quando se adquire conhecimento, trocar pra scrum.

PASSOS DO SCRUM

- a equipe planeja em um periodo de um mes ou menos a entrega de um software

-a equipe cria o incremento de software

-o cliente passa um feedback sobre esse incremento

-o time adapta o plano com base nesse feedback pro proximo ciclo

O SCRUM DEFINE 3 PERFIS

-product owner (pessoa que estará focada no desenvolvimento do produto)

-scrum master (que foca na metodologia agil)

-devs (todas as pessoas que compoe a equipe)

o SCRUM não possui hierarquia e o numero recomendado para se montar um time é de até 10 pessoas.

P.O: ele tem que maximizar o trabalho do time pra entregar valor pro cliente, responsavel pela gestão do backlog, ele deve comunicar explicitamente a meta do produto, documentar e claramente comunicar os itens que compoem o backlog (quanto mais detalhado melhor pois ajudara o time a resolver o problema). Ele existe para que se evite a perda de informações sobre o produto (pra nao deixar os detalhes passarem batido). O p.o tem algumas habilidades atribuidas a ele. São elas: escriba (anota o pedido do cliente), proxy(comunicação entre o negocio e a equipe de desenvolvimento), representante de negocio(pensa na dinamica do procudo apoiado pelo produto de software), patrocinador(angaria recursos para a produção e desenvolvimento do produto), empreendedor(age como um mini ceo do produto, auxiliando no marketing).

Dev's: todas as pessoas que compõem a equipe do projeto, são responsaveis por criar o backlog da sprint dentro do jira, adaptam o plano para a sprint conforme a meta da sprint, se responsabilizam um pelo outro como profissionais e atendem a definição de pronto (definition of ready) que é um "contrato" dizendo o que o produto precisa ter pra ser considerado como concluido.

SCRUM master: responsavel pelo seguimento do scrum guide, se certificando de que o time siga as regras. Assegura que o que foi proposto dentro da sprint seja cumprido, remove os impedimentos do time que bloqueiam o progresso, realiza coach sobre o scrum com os membros do time.

ORIGEM do termo scrum: scrum é uma jogada de rugbi, onde os jogadores agem juntos pra tentar ganhar o passe da bola, que é o que acontece em um time, pra cumprir os objetivos de uma sprint.

PILARES DO EMPIRICISMO DO SCRUM

-trablhar com o que se conhece, que seria os 3 pilares do empiricismo (transparencia, inspeção e adaptação). Há inspeçoes e adaptações que são usadas nos casos de incerteza.

o papel da transparencia, é que a pessoa entenda seu papel e responsabilidade, disponibilidade do ambiente, progresso das atividades, requisitos e tarefas visiveis)

SPRINT

um evento que incorpora os demais eventos do scrum. È um intervalo de tempo fixo que pode ter no maximo um mes. Não é possivel estender a sprint. toda sprint tem sua meta(s) porem a entrega de valor deve ser levada em consideração. Entretanto, uma sprint pode ser cancelada se sua meta se tornar obsoleta e somente o P.O pode cancelar. Uma nova sprint começa ssim que termina a anterior.

CONCEITO DE META

o projeto deve ser pensado sempre com foco no cliente. Há uma meta maior a ser definida e metas menores para que se chegue a meta maior. A meta do produto é alcançada através do backlog do produto, meta é um objetivo de longo prazo para o time scrum. A meta de uma sprint deve ser bem clara, de forma que todos vejam da mesma forma o objetivo a ser concluido.

ARTEFATO

para que o empiricismo funcione, é importante se atentar aos artefatos. Eles devem sempre estar disponiveis para que o time possa verificar.

INCREMENTO

um passo concreto em direção a atingir a meta do produto. O ideal é que se tenha um incremento a cada sprint e ele é considerado um artefato da scrum pois é atraves desse incremento que é verificado se a meta colocada na sprint foi atingida. o incremento também é a soma do que se fez na sprint anterior com a nova.

BACKLOG DO PRODUTO

também considerado um artefato, pode ser definido por uma lista ordenada do que precisa ser realizado para desenvolver e melhorar o produto. é de responsabilidade do PO, incluindo sua disponibilidade, conteudo e ordenação. O backlog precisa estar alocado em somente um lugar, para que não fique muito confuso.

BACKLOG DA SPRINT

os responsaveis são os devs, eles organizam da melhor forma os itens dentro do backlog. deve possuir o maior numero de detalhes possiveis e abrigam as tasks e subtasks

PBI (product backlog item)

cada um dos itens do backlog do produto é um elemento a ser desenvolvido. pode ser uma historia, uma task, um bug, etc. é tudo o que contribui para que a entrega de valor possa ser realizada.

TAREFAS TECNICAS (task)

todo item da sprint é quebrado em tarefa tecnica. cada sub-tast não entrega valor sozinha. já uma task sim.

STORY POINT

são os pontos de esforço necessarios para que o projeto seja concluido. Ele é definido pelo dev, porem o scrum master auxilia na obtenção do consenso e o po na tirada de duvidas sobre os itens do backlog. Pode se utilizar a sequencia de Fibonacci para definir os pontos a serem distribuidos a cada pbi.

DEFINITION OF DONE

é um acordo feito entre a equipe do projeto e o cliente. Basicamente são definições a serem concluidas antes que se entregue ao cliente. exemplo: na eldorado não pode se entregar um software antes que ele seja testado. também há aplicações individuais. exemplo:

pro incremento temos: testes realizados, release notes documentado, defeitos criticos resolvidos.

sprint: eventos realizados, ações de melhoria acompanhadas pelo sm, backlog do produto refinado para a proxima sprint

requisito: codigo revisado, testes realizados, requisito aceito na srpint review.

DEFINITION OF READY

são itens que são descritos pra sinalizar quando que está tudo pronto para que algo se inicie. é como pegar todas as coisas de um acampamento para acampar.

GRAFICO DE BURNDOWN

é o quanto de trabalho que o time pegou pra fazer vs o tempo da sprint. Conforme o time vai trabalhando e finalizando os itens do backlog, verifica-se se o tempo da sprint vai ser suficiente pra completar todos os itens prorpostos. caso de pra ter uma estimativa de que o tempo não é suficiente, uma atitude pode ser tomada em relação a isso.

GRAFICO VELOCITY

conforme o time completa as sprints, há uma comparação de horas vs itens concluidos e o que foi entregue. Ele define a taxa media de entrega do time.

VALORES

O time scrum se compromete a alcançar os seus objetivos e apoiar-se mutuamente.

se baseia em 5 valores:

comprometimento: todos os membros do time scrum devem estar comprometidos com todo o trabalho a ser feito

abertura: a comunicação deve ser sempre aberta entre todos os membros do time sobre mudanças de requisito, prioridades, existencia de bloqueios e etc

Respeito: diferentes ideias e pontos de vista, nos eventos ou ao longo da sprint. todos os membros do time devem ter oportunidade de se expressar

foco: todos tem o foco de atingir a meta da sprint, todos precisam manter o projeto alinhado as expectativas do cliente e os devs devem se concentrar em uma unica tarefa por vez.

coragem: o sm deve ter coragem pra chamar um membro do time não engajado, o po deve ter coragem de dizer não ao cliente, os devs devem ter coragem de dizer que estão com dificuldade em algum item do backlog.

EVENTOS DO SCRUM

o objetivo do evento é minimizar necessidade de outros tipos de reuniões.

planning - acontece pra gerar o artefato (que é o backlog da sprint). é o primeiro evento da sprint e todos do time devem participar. tem três propositos: definir o motivo da sprint (WHY) (qual é o valor a ser entregue na sprint? o que é mais prioritario ao cliente?); definir o plano da sprint (WHAT) (definição de quais itens do backlog do poduto serão puxados para o backlog da sprint) e definir como cumprir o plano (HOW) (definida com story points ou horas (geralmente)). Apos definido esses tres aspectos, surgem as tasks. pra uma sprint de 15 dias, a planning deve ter duração maxima de 4 horas.

daily - reunião diaria acerca dos eventos que tem no maximo 15 minutos de duração. todos os devs participam. seu proposito é manter todos os devs alinhados acerca do progresso e atividades da sprint, sobre impedimentos e sobre o andamento do trabalho em relação a meta da sprint. não é o momento de verificar a solução de um problema. ele pode ate ser citado, mas será resolvido em um outro momento.

refinement - acontece em cima do backlog do produto. Não tem um tempo de reunião definido e tem que acontecer quando o po e outras pessoas do time tiverem disponibilidade. O objetivo é fazer com que os itens do backlog sejam amadurecidos, analisar requisitos que dependam da historia, a sequencia e ordem de prioridades deles. ele também serve pra encurtar a planning pois refina melhor os criterios de historia, de tasks.

review - pra inspecionar o incremento. é o penultimo evento da sprint e todo o time participa. pra uma sprint de 15 dias, ela deve durar no maximo 2 horas. deve ser apresentado somente os itens que foram completos. é importante que os devs apresentem os itens. também é discutido se a meta foi atingida. o roadmap pode ser ajustado de acordo com o andamento da review.

retrospective - momento de relembrar tudo do time com adaptações. o ideal é ter uma a cada sprint. todos do time participam. Os pontos ruins sobre o trabalho também são revistos, com propostas pra mudança.

-