Princípios do Manifesto Ágil

Ver más

DA001 - Princípios da Administração Publica

por Eduardo Savarro

Abordagem Clássica da Administração

por Dylhermando de Souza de Oliveira

O que é sistema de informação

por Josué Ricardo Pereira Costa

O PLANO PARA FATURAR R$10.000 NO MERCADO LIVRE (COMO VENDER DE R$300 - R$1000 por dia no Mercado Livre)

por Honey Midia

Scrum

Artefatos do Scrum

Incremento

O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar na condição de ser utilizado e atender a definição de “Pronto” do Time Scrum. Um incremento é uma parte principal inspecionável de trabalho pronto que suporta empirismo no final da sprint. O incremento é um passo na direção de uma visão ou de um objetivo. O incremento deve estar na condição de ser utilizado independente do Product Ownerdecidir por liberá-lo ou não.

Backlog da Sprint

O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint. O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento “Pronto”.

Backlog do Produto

O Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no produto. É a única origem dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação.

Controle de mudanças no Scrum

Assim, em certas situações específicas, talvez seja necessário monitorar as mudanças. Monitorar as mudanças usando algo como o product backlog rotativo ajudaria a erradicar os resíduos no processo e possívelmente tornar o product owner mais eficiente. Há outras razões e modos de monitorar mudanças também, mas a chave é manter o processo enxuto e detalhar somente o necessário.

Suas principais recomendações são: Registrar a mudança no backlog ou monitor de mudança Eliminar tantas aprovaçõe quanto for possível Ter um formulário de controle de mudança leve, se necessário Manter envolvidos os stakeholders e o time de operações

Atualizando o Backlog Priorizado do Produto com as Mudanças Aprovadas.

Solicitação de mudanças

Por que um time precisa monitorar as mudanças? É impedir que o product owner faça adições desnecessárias ao product backlog. Isto por sua vez reflete sobre a eficiência do product owner. O grupo concordou que as vezes os itens do backlog não são bem pensados, resultando no fato de que eles tendem a mudar com muita frequência.

Gerência de riscos no Scrum

O mais importante é que o quadro esteja acessível para as partes interessadas e responsáveis pelo gerenciamento dos riscos.

Uma boa prática é a manutenção de um quadro de riscos. A idéia por trás deste é de funcionar como o quadro de tarefas do SCRUM, porém dividido em três partes: mitigar, aceitar e evitar, que são as categorias básicas de respostas aos riscos. Evitar um risco é a ação de eliminar a causa deste inviabilizando a sua ocorrência (ex: mudança de estratégia de projeto). Mitigação de um risco é a suavização das consequências, ou a diminuição da probabilidade de um risco por meio de um plano de mitigação (ex: compra de um seguro). Aceitação de um risco é a ação de simplesmente aceitar suas consequências, podendo haver ou não um plano de contingência para o caso deste ocorrer. A medida que os riscos vão sendo identificados, eles vão sendo adicionados ao quadro, de acordo com o modo de gerenciamento escolhido para os mesmos.

Analisando dois casos podemos identificar, no primeiro caso, os riscos são identificados naturalmente, frutos de reuniões diárias, plannings ou revisões. No segundo caso, basta incluir a realização desta atividade, explicitamente, na pauta de alguma cerimônia do SCRUM. Seja qual for o caso, após a identificação, é necessário realizar as demais atividades do processo.

É possível realizá-lo sem sacrificar a agilidade desta metodologia. Sendo assim, ele pode ser realizado de maneira orgânica ou evidente.

Todo o processo é documentado formalmente e comunicado às partes interessadas no gerenciamento dos riscos.

Estas atividades são realizadas antes do início do desenvolvimento e revisadas, posteriormente, em marcos pré-definidos do projeto.

A gerência de riscos é uma atividade importante a ser realizada no decorrer de um projeto. Ela tem o objetivo de manter o controle sobre possíveis entraves que possam ameaçar a boa execução deste. Além disso, é imperativa a sua realização para alcançar o nível de maturidade de processos G e C do MPS-BR (Melhoria de Processos de Software Brasileiro) e 3 do CMMI (Capability Maturity Model Integration).

Princípios do Manifesto Ágil

Simplicidade é essencial.

As melhores arquiteturas, requisitos e projetos provêm de equipes organizadas.

A equipe deve refletir sobre como se tornar mais eficaz, então sintoniza e ajusta seu comportamento.

Atenção contínua à excelência técnica e a um bom projeto aumenta a agilidade.

As equipes de negócio e de desenvolvimento devem trabalhar juntas diariamente durante o projeto.

Entregas com frequência de software funcional, sempre na menor escala de tempo, de algumas semanas a alguns meses, preferindo sempre um período curto.

Mudanças que não colaboram com a evolução do projeto devem ser descartadas.

Processos ágeis esperam que a mudança traga uma vantagem competitiva ao cliente.

Entregas de forma rápida e eficientes

Entregas regulares

Construa projetos objetivando manter uma equipe motivada, fornecendo ambiente, apoio e confiança necessários para realizar o trabalho.

A maneira mais eficiente de a informação circular entre a equipe de desenvolvimento é por uma conversa cara a cara.

Ter um software funcionando é a medida primária de progresso.

Processos ágeis promovem o desenvolvimento sustentável. Patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante.

Papéis no Scrum

O Scrum Master

O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia Scrum. O Scrum Master faz isso ajudando todos a entenderem a teoria, as práticas, as regras e os valores do Scrum.

O time de desenvolvimento

O de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento potencialmente liberável do produto “Pronto” ao final de Sprint.

Product Owner

O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto resultado do trabalho do Time de Desenvolvimento.

Pilares do Scrum

Adaptação

Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o resultado do produto será inaceitável, o processo ou o material sendo produzido deve ser ajustado.

Inspeção

Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo da Sprint para detectar variações indesejadas.

Transparência

Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. A transparência requer que estes aspectos tenham uma definição padrão comum para que os observadores compartilharem um mesmo entendimento comum do que está sendo visto.

Definição de Pronto

Benefícios de se utilizar DoD são: O ScrumTeam e os demais stakeholders do projeto passam a utilizar um vocabulário único, seguro e irrestrito para a palavra 'Pronto'. Depois da DoD todo mundo entende o que significa (E o trabalho que isso dá). A confiança dos demais stakeholders aumenta em relação ao ScrumTeam Os Releases passam a ser mais previsíveis em termos de qualidade (Aquele susto ao final do projeto deixa de existir) Qualquer impedimento é rapidamente identificado, tornado público e sobrepujado. Os membros de toda a equipe passam a compreender melhor as expectativas de entrega do Projeto e trabalham para cuidar que o produto seja entregue com toda qualidade. Os membros da equipe aprendem um novo jeito de se entregar produtos e nunca mais desejarão trabalhar de outro modo. A Melhoria contínua passa a ser a cultura do projeto.

É imperativo que a DoD seja revisitada a cada Sprint. Um momento que pode ser útil para verificar se a DoD está sendo adequada é o Sprint Review, afinal, se o produto apresentar qualquer “Desvio de Caráter”, a probabilidade da culpa ser de uma DoD mal definida é altíssima.

O documento de DoD pode evoluir normalmente ao longo do projeto, porém recomendo que a primeira versão seja criada durante a 1ª Sessão de Sprint Planning, isto é, antes de iniciar o 1º Sprint do projeto.

Serve como um contrato entre o ScrumTeam e o Product Owner, garantindo que todo o produto gerado pelo projeto estará dentro dos padrões de qualidade estabelecidos entre eles. É uma forma de se buscar a excelência, especialmente em um cenário multi-iterativo.

Criar uma Definição de Pronto ou DoD "Definition of Done" é um esforço colaborativo entre o Scrum Master, o ScrumTeam e o Product Owner.

Processos do Scrum