Por fim, hoje listarei algumas das principais certificações que preparei junto ao Antonio Santos, Scrum Master e atual supervisor de implantação de projetos da Modular Mining System, para estudantes e profissionais que desejam se aprofundar no SCRUM. Vamos lá!?

Certificações gratuitas para Iniciantes

Se o leitor deseja provar que conhece o framework e está apto a utilizá-lo, uma boa forma é através de certificações. Porém, o investimento pode ser alto para algumas pessoas, em especial, os estudantes, no qual muitas vezes não possuem renda para bancá-lo.

Por isso, separei algumas certificações gratuitas para que o leitor possa tirar a sua e, assim, tornar-se mais competitivo no mercado. Confira abaixo!

Scrum Fundamental Certified – SCRUMstudy

A SCRUMstudy disponibiliza gratuitamente a certificação Scrum Fundamental Certified para quem deseja confirmar que possui um entendimento básico do framework. O formato do exame é através de uma prova múltipla escolha.

Além disso, a prova contém 40 perguntas, onde o candidato deve acertar 30 destas, em 1 hora de prova, para ser aprovado . O exame é totalmente online e sem supervisão.

O nível de dificuldade do exame é relativamente fácil, porém exigirá um conhecimento intermediário do framework. Recomendo ler esta série do início – caso ainda não tenha feito isso – antes de aplicar para o exame.

Scum Foundation Professional Certificate – Certiprof

Além da SCRUMstudy, outra empresa que costuma disponibilizar algumas certificações gratuitas é a Certiprof.

Este exame contém 40 questões totalmente baseado no Scrum Guide. Para ser aprovado, o candidato deverá acertar no mínimo 70% da prova, isto é, 28 questões.

Assim como o exame anterior, este também é auto supervisionado e com 60 minutos de duração. Para ajudá-lo a se preparar melhor, a Certiprof ainda disponibiliza um material de apoio para quem deseja estudar o framework antes de tentar. Legal, não é?

Certificações recomendadas para quem deseja se Profissionalizar

As certificações acima são muito boas para iniciantes e estudantes que procuram um estágio ou primeiro emprego. Porém, se o leitor deseja se profissionalizar e ser um grande profissional em gestão de projetos, isso pode não ser o suficiente para torná-lo competitivo no mercado. Por isso, pedi ao Antonio Santos recomendações que pudessem ser úteis aos aspirantes. Vamos conferir!

Qual a melhor certificação?

Segundo Antonio Santos, escolher a certificação correta vai depender do objetivo de carreira que o profissional possui.

“Ao fazer a escolha de qual certificação tomar, o profissional deve estar ciente de qual o seu objetivo profissional. Assim, alinhará melhor sua escolha com suas expectativas, definindo melhor o valor do investimento que está disposto a bancar, assim como o risco da aplicação de cada exame” – Antonio Santos

Antonio nos informa que no Brasil, atualmente temos três grandes órgãos representáveis que compõem o pódio das consideradas melhores certificações ágeis. São elas EXIN, Scrum.org e Scrum Alliance. Abaixo listamos 3 das melhores certificações de Scrum Master dessas organizações.

Professional Scrum Master (PSM I) do Scrum.org

O PSM I é considerada uma das melhores certificações do SCRUM para Scrum Masters. O exame que atualmente custa 150 dólares (cerca de R$ 866,00) é considerado um dos mais difíceis, não pelo conteúdo em si, mas pelo tempo de resposta que o candidato tem para responder cada pergunta – são 80 perguntas em 60 minutos de prova – e a taxa de 85 % de acerto que ele deve superar a fim de ser aprovado. Além disso, o exame apresenta-se somente no idioma inglês.

A Scrum.org também apresenta outras certificações interessantes para quem deseja trabalhar com outros papéis do SCRUM, como Product Owner (Professional Product Owner I – PSPO I) ou Desenvolvedor (Professional Scrum Developer – PSD).

Certified Scrum Master (CSM) da Scrum Alliance

Outra organização bem consagrada é a Scrum Alliance que possui uma série de certificações bem interessantes. Uma delas é a Certified Scrum Master (CSM), no qual o profissional deve realizar um curso presencial de 14 horas – que normalmente ocorre na cidade de São Paulo – antes de realizar a prova.

Muitos participantes afirmam que o exame possui um fácil grau de dificuldade, uma vez que a prova é baseada inteiramente no curso, porém a obrigatoriedade deste no valor R$ 2.000 pode ser um desafio para alguns aspirantes. “Tanto a CSM quanto a PSM I são boas certificações para Scrum Masters, porém a PSM I costuma ser um pouco mais valorizada no mercado, principalmente por conta da dificuldade”, diz Antonio Santos.

Assim como a Scrum.org, a Scrum Alliance também apresenta uma série de certificações baseada nos papéis do framework, isto é, Product Owner, Scrum Developer e Scrum Master – este inclui também uma certificação de nível avançado.

Agile Scrum Master da EXIN

A EXIN é uma acreditadora holandesa muito prestigiada mundialmente. Dentre as diversas certificações que ela possui, a Agile Scrum Master é uma das mais conhecidas. O exame exige uma certa preparação, mas não é tão difícil quanto a PSM I do Scrum.org, uma vez que a prova possui a 1.5h de duração para 40 questões e pode ser realizada em português, sendo necessário um rendimento de apenas 65% para garantir a aprovação. O valor da prova é de $ 225 dólares.

Além disso, assim como os últimos órgãos, a EXIN também possui sua série de certificações, incluindo as de Dono do Produto e Desenvolvedor Scrum, além de outras como Agile Coach e Agile Business Professional.

Por fim, terminamos a série DESTRINCHANDO O SCRUM. Espero que o leitor tenha assimilado o que vimos e aprendido bastante. Em caso de dúvidas ou sugestões deixe seu comentário abaixo ou contate-me pelo LinkedIn. Até a próxima!

Já segue o Blog da Engenharia no Instagram?
Já me segue no Instagram?

The post Destrinchando o SCRUM [4/4] Certificações para quem deseja se aprofundar appeared first on Blog da Engenharia.

Na PARTE 1 abordei o que é o SCRUM, como ele surgiu e a relação do SCRUM com o Movimento Ágil. Já na PARTE 2 você pôde conhecer melhor quais os Papéis (Product Owner, Scrum Master e Development Team), os Artefatos (Product Backlog e Sprint Backlog) e os Eventos (Reunião Diária, Reunião de Planejamento, Revisão do Sprint e Retrospectiva do Sprint) que compõem o framework.

Então, hoje, veremos como se deve implementar e acompanhar o SCRUM com sucesso, e quando não se deve implementá-lo. Sem mais delongas, vamos destrinchar o SCRUM!

Como implementar o SCRUM?

Apesar do SCRUM ser um framework de métodos ágeis e, justamente por isso, ser associado como a “aversão” do modelo cascata – cujo os projetos seguem uma sequência, no qual o próximo passo só é dado quando o antecessor termina – na sua implementação é recomendado que você siga uma sequência linear de etapas, pois caso contrário, pode acabar não funcionando. Dessa forma, siga o passo a passo abaixo:

1) Definindo o Dono do Produto

Se você já leu a PARTE 2 dessa série, entende a importância e o dever do Product Owner dentro da equipe SCRUM. Por isso, o primeiro passo, depois de definir o projeto piloto no qual será aplicado o framework, é definir quem será o Product Owner.

Ele é a principal ponte entre os Stakeholders e o Time de Desenvolvimento, por isso recomenda-se alguém com boa capacidade de comunicação, negociação, liderança, tomada de decisão e conhecimento sobre o negócio.

2) Definindo o Scrum Master

Além disso, é fundamental definir quem será o Scrum Master. Ele é o líder facilitador responsável por garantir a boa implementação, acompanhamento das principais etapas do SCRUM e providenciar orientação e suporte ao time de desenvolvimento e ao Product Owner.

Justamente por isso, é essencial que o profissional tenha um excelente conhecimento do framework.

3) Desenvolvendo a Backlog do Produto

O Backlog do Produto é um dos artefatos oficiais do SCRUM. Ele compele uma lista detalhada que contém os requisitos do cliente em uma ordem prioritária. Construí-la e organizá-la é um dos deveres do Product Owner. Portanto, após definido o Dono do Produto, este deve desenvolvê-la.

Na PARTE 2 desta série há uma imagem de um template de Product Backlog, no qual possui os elementos essenciais para o artefato, isto é, o Item a ser desenvolvido, o Grau de prioridade e a Estimativa de tamanho (pequeno, médio, grande).

4) Planejando o primeiro Sprint

Na primeira Reunião de Planejamento, a equipe desenvolve o primeiro Sprint que pode durar entre 1 semana a 1 mês e também o primeiro Sprint Backlog, isto é, a lista de tarefas extraída a partir do Product Backlog.

Além disso, é fundamental que o Product Owner deixe claro a visão do projeto de forma que todos entendam e concordem com o Objetivo do Sprint.

5) Criando uma Scrum Board

Um dos principais benefícios do framework SCRUM é a transparência durante o processo. Por isso, é muito comum que as equipes utilizem alguma ferramenta para controle de forma a tornar o progresso – ou atraso – visível.

Uma das melhores formas de fazer isso é utilizando o famoso Kanban da metodologia Lean, onde o fluxo de trabalho é separado em 3 colunas: A Fazer, Em Execução e Finalizado. Pode-se utilizar a metodologia tanto com Post-its físicos quanto digitais em plataformas como o Trello, por exemplo, que possui modelos de quadros muito bem desenhados para a gestão do projeto.

Além disso, também é possível e interessante acompanhar o progresso através de um gráfico de Burndown, no qual o eixo horizontal leva os dias do Sprint, enquanto o eixo vertical os pontos projetados para compor o Sprint.

Assim, após cada Daily Meeting, o Scrum Master pode somar os pontos concluídos e marcar no gráfico. Conforme os dias passam e o trabalho vai sendo concluindo, vemos uma “escada” se formando, indo dos pontos totais no primeiro dia à zero no último.

6) Organizando o Daily Meeting

Como vimos na PARTE 2, o Daily Meeting é uma das importantes reuniões do SCRUM que ocorre diariamente, no mesmo horário, não mais do que 15 minutos e em pé. Nela são respondidas as 3 perguntas que pontuei anteriormente. É uma reunião simples, rápida e prática.

“O objetivo desta reunião é alinhar os participantes com o que foi feito, o que deve ser realizado no dia, além de ajudar o Scrum Master a identificar os possíveis impedimentos”.

7) Marcando o Sprint Review

Organizadas no final dos Sprints, esta reunião auxilia a performance, pois é onde a equipe analisa o trabalho realizado, as tarefas que deixaram de ser feitas e também podem apresentar as novas funcionalidades para os Stakeholders.

Como disse na PARTE 2, no Sprint Review, participam o Time de Desenvolvimento, o Product Owner, o Scrum Master, além dos gerentes, engenheiros, clientes e qualquer outra Parte Interessada no projeto.

8) Organizando o Sprint Retrospective

Por fim, temos a Reunião de Retrospectiva de Sprint que também ocorrem no final do Sprint.

Inclusive, por isso, muitos testes cobram a relação entre o Sprint Retrospective e o Sprint Review, pois é fácil confundir o objetivo de cada um se você não está habituado com o SCRUM.

Perceba que o Sprint Review serve para rever o trabalho executado, enquanto que o Sprint Retrospective avaliará o andamento dos Sprints a fim de buscar possíveis melhorias no processo.

Siga todos estes passos com atenção que com certeza conseguirá implementar o SCRUM com sucesso dentro do seu ambiente de trabalho! Por fim, na PARTE 4 desta série, preparei junto ao Antonio Santos, dicas especiais para quem deseja se aprofundar mais no SCRUM. Até a próxima semana!

Já segue o Blog da Engenharia no Instagram?
Já me segue no Instagram?

The post Destrinchando o SCRUM [Parte 3/4] appeared first on Blog da Engenharia.

Portanto, se você já leu a PARTE 1, podemos começar segunda parte.

Neste artigo, daremos início ao framework propriamente dito, assim, abordaremos os papéis, os eventos e os principais artefatos do SCRUM e como se relacionam dentro do desenvolvimento de um projeto.

Basicamente, existem 3 papéis importantes na equipe que implementam o SCRUM. São eles:

• Product Owner (Dono do Produto).
• Scrum Master.
• Development Team (Time de Desenvolvimento).

Em alguns materiais são informados outros dois, os Stakeholders (Partes Interessadas) e os Gerentes.

Porém, embora sejam muito importantes, não tratarei desses papéis nesta série, pois a relação destes dois papéis são auxiliares e eles não se envolvem integral e frequentemente com os processos do SCRUM.

Product Owner

Todo projeto possui por excelência stakeholders, sejam os clientes, os fornecedores, investidores, a comunidade, os parceiros, o governo ou qualquer outro órgão que possa estar envolvido no projeto.

Portanto, dentro de uma equipe SCRUM é fundamental a presença de um Product Owner. Ele é o principal responsável por ser a ponte entre a equipe e os stakeholders, podendo assim gerar valor ao projeto.

Além disso, o Product Owner é o membro responsável por escrever as Product Backlogs  – artefato abordado mais abaixo.

É importante ressaltar que cada equipe SCRUM possui apenas um Product Owner.

Scrum Master

O Scrum Master é o líder facilitador do time SCRUM, cuja as principais funções são remover os impedimentos que possam vim a atrapalhar a execução das Sprints, ajudar o Time de Desenvolvimento a entender e praticar corretamente o framework, assim como garantir sua implementação dentro da organização.

Além disso, o Scrum Master também é o responsável por guiar o Time de Desenvolvimento em suas tarefas diárias, auxiliar os Daily Meetings (Reuniões Diárias) e servir como ponte entre o Time e o Product Owner.

Development Team

Por fim, temos o Time de Desenvolvimento, o time de pessoas responsável por executar as Sprints determinadas pelo Product Owner da equipe e entregar o produto.

O Time de Desenvolvimento é, geralmente, composto por 5 pessoas, no máximo nove, sendo a equipe constituída de profissionais multidisciplinares e auto gerenciáveis, no qual seu principal objetivo é entregar algum tipo de incremento funcional em cada Sprint.

O que é um SPRINT?

No esporte, um Sprint é quando um atleta se esforça para dar o máximo de si a fim atingir sua velocidade máxima, seja correndo, pedalando ou nadando. Por conta da fisiologia humana, as pessoas não conseguem se manter neste estado por muito tempo, então os sprints são rápidos, algo de 30 a 35 segundos.

Os Sprints do SCRUM seguem o mesmo preceito, isto é, são pequenos períodos de tempo, no qual o Time de Desenvolvimento se esforça para desenvolver e entregar alguma parte do trabalho. Assim como no esporte, os sprints do SCRUM duram pouco tempo, geralmente, entre 1 semana a 1 mês.

A ideia é que dividindo o trabalho em pequenas partes, a equipe possa entregar parte do projeto ao cliente e, assim, receber um feedback do trabalho realizado. Na primeira parte desta série, isto foi citado nos Princípios do AGILE, nos tópicos 1, 3, 7 e 12.

Eventos do SCRUM

Os Eventos do SCRUM são, basicamente, as tarefas que giram em torno dos Sprints. O framework apresenta 4, que são os:

• Daily Meeting (Reunião Diária)
• Planning Meeting (Reunião de Planejamento)
• Sprint Review (Revisão do Sprint)
• Sprint Retrospective (Retrospectiva do Sprint)

Daily Meeting

Como o próprio nome sugere, os Daily Meetings são as famosas Reuniões Diárias do SCRUM que ocorrem todos os dias durante um Sprint.

O objetivo destas reuniões é alinhar os participantes com o que foi feito, o que deve ser realizado no dia, além de ajudar o Scrum Master a identificar os possíveis impedimentos e, por isso, cada membro deve fazer as seguintes perguntas:

• O que você tem feito desde ontem em direção à meta?
• O que você planeja fazer hoje em direção à meta?
• Há algo que pode te impedir de realizar seu objetivo em direção à meta?

As Reuniões Diárias do SCRUM não ultrapassam o tempo de 15 minutos, além de serem realizadas em pé – por isso às vezes também são chamadas de Stand up Meeting. O objetivo disso é gerar um ambiente levemente desconfortável, assim as reuniões são mais práticas e eficazes.

Planning Meeting

As Planning Meeting, ou Reuniões de Planejamento, são as reuniões que ocorrem com toda a equipe SCRUM, no início de cada Sprint, a fim de definir qual o objetivo do Sprint e ajudar o Product Owner a gerar o Sprint Backlog.

É importante a presença de todos os membros, pois a Equipe precisa definir o “Que” deve ser feito, “Como” e também” Quem” fará o que. Planejar bem é muito importante, pois além de ajudar a concluir o processo com mais eficiência, ajudará a motivar a equipe conforme as etapas são finalizadas.

Review Sprints

As Revisões de Sprints são as reuniões que a equipe SCRUM organizam no final de cada Sprint com o objetivo de rever o trabalho que foi executado, as tarefas que deixaram de ser feitas e apresentar as novas funcionalidades para os Stakeholders.

Além disso, durante esta reunião é importante que o projeto seja avaliado em relação ao objetivo da Sprint que foi previamente definido na Reunião de Planejamento.

Nesta reunião, participam o Time de Desenvolvimento, o Product Owner, o Scrum Master, além dos gerentes, engenheiros, clientes e qualquer outra Parte Interessada no projeto.

Sprint Retrospective

 Os Sprint Retrospectives são reuniões que ocorrem no final de cada Sprint. São, geralmente, a última atividade dentro de um Sprint, pois seu objetivo é, principalmente, procedural.

Nestas reuniões a equipe SCRUM avaliará o andamento dos Sprints a fim de buscar possíveis melhorias no processo. Perceba a diferença entre a Retrospectiva do Sprint e as Revisões de Sprint, no qual esta se preocupa com o que a equipe está construindo, enquanto aquela trata de como o processo está sendo executado.

Artefatos do SCRUM

Por fim, temos os dois artefatos oficiais do SCRUM. O Scrum Guide, o manual oficial do SCRUM, os definem como:

• Product Backlog [Backlog do Produto]
• Sprint Backlogs

Product Backlog

Como vimos anteriormente, na parte de papéis do SCRUM, uma das funções do Product Owner é gerar os Product Backlogs.

Em inglês um Backlog é “um acúmulo de algo, especialmente um trabalho incompleto ou questões que precisam ser tratadas” (Dicionário de Oxford). Seguindo esta linha de raciocínio, um Product Backlog – ou Backlog do Produto – nada mais é do que uma lista que contém os requisitos do cliente em uma ordem prioritária.

Portanto, os Product Backlogs são extremamente necessários na execução da Sprint, uma vez que ditará o que deve ser realizado.

Porém, caso o Product Owner sinta necessidade de alterações, ele – como o responsável pelo Backlog do Produto – pode mudar durante a Sprint.

Sprint Backlog

Já a Sprint Backlog é uma lista de tarefas extraída a partir do Product backlog. Estas tarefas deverão ser executadas durante a Sprint.

Os Sprints Backlogs são criados durante a Reunião de Planejamento, onde a equipe SCRUM seleciona um número de itens da Product Backlog, além de estimar a quantidade de horas necessárias para realiza-los.

Na Reuniões Diárias, o Time de Desenvolvimento poderá realizar alguma mudança no Sprint Backlog, caso seja necessário. Por exemplo, se as tarefas estiverem quantitativamente menor que a capacidade da equipe ou muito difíceis de serem executadas em uma única Sprint.

Por fim, espero que tenha ficado claro quais são os Papéis, os Artefatos e Eventos do SCRUM. Atente-se às palavras em negritos, pois tratam-se de conceitos importantes para o framework. Espero você na PARTE 3 da série, até logo!

Aproveite e siga o Blog da Engenharia no Instagram!

Já me segue no Instagram?

The post Destrinchando o SCRUM [Parte 2/4] appeared first on Blog da Engenharia.

Isso porque o SCRUM tem se tornado muito popular nos últimos anos e seus adeptos ao redor do mundo só tendem a aumentar.

Mas, se você não sabe ou nunca utilizou o SCRUM, talvez esteja se perguntando “por que será que este termo anda tão em voga?”, “da onde surgiu esse tal de SCRUM” ou mesmo “como posso utilizar o SCRUM?”.

Assim, se você pretende começar a vislumbrar este framework ou se já conhece, mas pretende aprender um pouco mais – afinal conhecimento nunca é demais – você está no lugar certo.

Nesta série DESTRINCHANDO O SCRUM, dividida em 4 partes, veremos:

1. O que é o SCRUM e como ele surgiu. [PARTE 1/4]
2. SCRUM e o Movimento Ágil. [PARTE 1/4]
3. Quais os eventos, os papéis e os artefatos do SCRUM, além de outros termos. [PARTE 2/4]
4. Como implementar e acompanhar o SCRUM com sucesso! [PARTE 3/4]
5. Quando não se deve implementar o SCRUM. [PARTE 3/4]
6. Por fim, algumas DICAS especiais que preparei junto ao Antonio Santos,  Scrum Master e atual supervisor de implantação de projetos da Modular Mining System, para leitores que pretendem se aprofundar. [PARTE 4/4]

Sem mais delongas, vamos juntos destrinchar o SCRUM.

Afinal, o que é o SCRUM?

O SCRUM é um framework – não uma metodologia – de projetos com etapas bem definidas que, inicialmente, buscava auxiliar equipes no desenvolvimento de softwares.

Porém, sua implementação não se restringiu a este campo e, atualmente, pelo menos 60% dos projetos ágeis em todo mundo, de diferentes áreas, setores e níveis organizacionais o utilizam.

O grande destaque do SCRUM está no fato dele ter sido criado, especialmente, para lidar com alguns dos principais problemas que decorrem ao longo do desenvolvimento de um projeto, isto é, a imprevisibilidade, prazos curtos, burocracias, complexidade de problemas iminentes, hierarquias mal elaboradas, comunicação, dentre muitos outros.

Logo, dentre os principias benefícios de aplicar o SCRUM podemos citar alguns, como:

• Simplicidade
• Maior velocidade
• Mais flexibilidade
• Comunicação aprimorada
• Transparência
• Adaptabilidade
• Eficiência na execução
• Engajamento do time

Uma breve história do SCRUM

A história do SCRUM inicia-se em 1986. Em janeiro deste ano, Takeuchi e Nonaka, publicam o artigo intitulado The New Product Development Game – O novo Jogo de Desenvolvimento de Produtos – no qual destacava empresas no Japão e nos Estados Unidos que adotaram uma nova abordagem para gerenciar o processo de desenvolvimento de produtos.

Além disso, o nome SCRUM – derivado do jogo de Rugby – foi sugerido, depois que Takeuchi e Nonaka observaram que algumas equipes, pequenas, multidisciplinares e auto gerenciáveis, recorrentemente obtinham melhores resultados comparado às equipes grandes do modelo cascata de gerenciamento de projetos.

Já em 1993, Jeff Sutherland e Jeff McKenna, insatisfeitos com os recorrentes atrasos em seus projetos de desenvolvimento de softwares, orçamentos estourados, além do estresse gerado pela utilização dos modelos tradicionais de gestão de projetos, abraçaram o estudo de Takeuchi e Nonaka e arquitetaram o framework para utilizá-lo pela primeira vez na Easel Corporation.

“Na Easel, não tínhamos nada a perder, por isso decidimos tentar, embora o artigo se concentrasse na fabricação de produtos e não no desenvolvimento de softwares. Pensei que a ideia deles abordava algo fundamental, um processo descritivo de como os seres humanos trabalhavam melhor juntos em qualquer empreendimento” – Jeff Sutherland

Depois de dois anos de sucesso implementado o SCRUM, em 1995, Jeff Sutherland e Jeff McKenna apresentaram o artigo titulado SCRUM Development Process – Processo de desenvolvimento SCRUM – no qual, objetivavam a sistematização das práticas do SCRUM na conferência de pesquisa da Association for Computing Machinery (ACM), a primeira e maior sociedade de computação científica e educacional do mundo.

Desde então, o SCRUM vem se adaptando e evoluindo, mas o núcleo apresentado na conferência continua praticamente o mesmo.

SCRUM e o Manifesto Ágil

O Manifesto Ágil – também conhecido como Agile – é um documento que foi, inicialmente, elaborado entre os dias 11 a 13 de fevereiro de 2001, em uma reunião em Utah, EUA.

Na época, grandes gestores de projetos e profissionais influentes da computação se reuniram para discutir os fatores que realmente importavam no desenvolvimento de software.  Na reunião, acabou sendo compilada uma série de 4 valores e 12 princípios que deveriam nortear a gestão, tomada de decisões e ações das equipes durante a execução de projetos ágeis, assim, otimizando os resultados.

Além disso, vale ressaltar que entre os participantes da reunião se encontravam nossos caros Jeff Sutherland e McKenna. Por isso – e por outro motivos – o SCRUM também é consistente com os valores e princípios do Agile.

Enfim, confira abaixo os 4 Valores e os 12 Princípios do Manifesto Ágil, traduzidos diretamente do site oficial do agilemanifesto.org, onde se encontra o documento.

4 Valores do AGILE

• Os indivíduos e suas interações acima de procedimentos e ferramentas.
• O funcionamento do software acima de documentação abrangente.
• A colaboração com o cliente acima da negociação e contrato.
• A capacidade de resposta a mudanças acima de um plano pré-estabelecido.

12 Princípios do AGILE

1. Satisfação do cliente – Nossa maior prioridade é satisfazer o cliente por meio de entrega antecipada e contínua de software valioso.
2. Adaptabilidade –  mudanças de requisitos são bem-vindas, mesmo no final do desenvolvimento. Os processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.
3. Frequência de entrega – Entrega de software funcional com frequência, de algumas semanas a alguns meses, com preferência à escala de tempo mais curta.
4. Cooperação – Empresários e desenvolvedores devem trabalhar juntos diariamente ao longo do projeto.
5. Motivação – Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte de que precisam e confie neles para fazer o trabalho.
6. Face-to-Face – O método mais eficiente e eficaz de transmitir informações para dentro de uma equipe de desenvolvimento é a conversa ‘cara-a-cara’.
7. Softwares Funcionais – O software funcional é a principal medida de progresso.
8. Ritmo Constante – Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante, indefinidamente.
9. Bons Designs – Atenção contínua à excelência técnica e um bom design aumenta a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.
11. Auto-organização – As melhores arquiteturas, requisitos e projetos emergem de equipes auto organizáveis.
12. Feedbacks – Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, em seguida, sintoniza e ajusta seu comportamento de acordo.

Além disso, na PARTE 2 desta série abordaremos quais os eventos, os papéis e os artefatos do SCRUM, além de outros termos.

Continue atento aos próximos artigos e não deixe de acompanhar o conteúdo que trazemos diariamente aqui no Blog, pois sempre tem muita coisa interessante.

Aproveite e siga o Blog da Engenharia no Instagram!

The post Destrinchando o SCRUM [Parte 1/4] appeared first on Blog da Engenharia.