Certified Scrum Master – como é o processo para a certificação?

Ser um Certified Scrum Master (CSM) não é muito difícil. Basta fazer um curso por um Certified Scrum Trainer (CST) e no final responder uma média de 36 questões enviadas pela ScrumAlliance. E então, você é um Certified Scrum Master.

E pra que serve?

Ela é criticada por profissionais de TI, mas existem duas coisas importantes para analisar antes de criticar:

• Se você já tem um bom nome no mercado e você é o valor da sua empresa em si, não vai precisar de certificação nenhuma. Exemplo? Pessoas como Eike Batista e Steve Jobs podem abrir uma empresa amanhã e ela já começa com um valor X, só porque eles são os dirigentes e seus clientes não querem saber se a empresa deles tem profissionais certificado YHY. Isso porque a confiança é toda depositada neles e quem a deposita conhece o perfil de cada um e sabe o do seu nível de qualidade. Não precisa de nenhum órgão para testar isso, pois eles por si são os órgãos;

• Agora o contexto dois, no qual está a maioria de nós, pobre mortais. Aquele profissional que não tem esse valor todo no mercado e que precisa que algum órgão respeitado diga: “esse cara tem os conhecimentos mínimos; nos o certificamos” para conseguir vender seu produto. E então você precisa vender o seu certificado para ganhar alguns tipos de cliente. E é pra isso existem as certificações: para aproximar novos clientes incertos do seu serviço. Esta é a realidade do mercado, seja aqui no Brasil ou lá fora – claro com algumas particularidades de cada país, mas é muito similar.

Em resumo, se amanhã você pretende atuar como um consultor Agile, e um mercado já consolidado com seu nome impresso, ter as certificações pode te ajudar com os seus primeiros clientes.

A diferença

Este é o diferencial do CSM: ao sair do curso você não é Scrum Master. Por quê? Simples, você não compra liderança, motivação de equipe, etc. Você desenvolve essas habilidades e são os pontos chaves para atuar como um Scrum Master – pouco importa se você é ótimo em Java, ou .NET, mas se não sabe lidar com equipe, remover as barreiras, ou ter um bom relacionamento, você está perdido. Agora vem a sensação de outras certificações, como Java e algumas do PMI, que ao terminar você olha e pensa: “mas eu estudei isso e aquilo. Agora eu sei exatamente como fazer X. Já sei usar generics e entendi threads, ou aprendi como calcular custo do projeto com menos erros, depois da prova PMI xxx”.

Quem for fazer certificação Agile deve esquecer qualquer uma dessas sensações – pelo contrário! Você sai de lá com mais dúvidas e mais confuso ainda. No início achei meio estranho, porém com o passar de um ou dois dias achei que isso era um ponto-chave excelente, pois fiquei motivado a buscar como resolver aquelas confusões e para isso tinha que estudar mais, aumentar o faturamento da Amazon.com, etc. E quando fazemos as certificações tradicionais isso não acontece. Afinal, após termos sido aprovados, temos a falsa segurança que dominamos o assunto e nem abrimos mais o livro de estudo.  E então começamos outra jornada: o esquecimento daquilo que não se usa com frequência.

O treinamento

São dois dias de treinamento, no qual abordam os pontos core de Scrum, com conceitos teóricos, práticos e cases. Há muita discussão e aprendizado nesses dois dias. Não é um curso comum; o aprendizado é grande e muito valioso. E sabe por quê? Vou responder a seguir.

A sacada da ScrumAlliance

É fácil criticar quando não conhecemos, mas a ScrumAlliance fez algo que achei interessante. Ser um CST não é para qualquer um. Ou seja, só quem teve e tem vivência pratica em Agile pode ser um CST. E isso garante que o conteúdo do curso será com um profissional que tem conhecimento e experiência de fato (ou seja, teve muito conflitos para resolver). E isso enriquece todo o curso de uma forma que é difícil descrever. Na maioria da faculdade temos professores “doutores” que nunca tiveram uma experiência profissional e assim, o o curso só fica no meio acadêmico. Mas quando o aluno chega ao mercado vê que a coisa é bem diferente. No treinamento da ScrumAlliance isso não tem como acontecer.

Ao sair do curso

Bem, ao sair do curso não dá para ter a síndrome do estudante e achar que é o ScrumMaster. Talvez, os menos experientes profissionalmente possam sair com essa síndrome. A certificação não prova que você tem todas as habilidades de ScrumMaster expert. Porém, é esperado que o aluno tenha o conhecimento suficiente para rodar uma Scrum, mas isso não quer dizer que ele vai conseguir rodar bem ou vai rodar a melhor Scrum do mundo. No curso você percebe se é aquilo o que de fato que deseja para você. O framework Scrum deixa transparente o papel e o que um SM vai viver no dia-dia sem maquiagem.

Compensa?

Essa é pergunta que muitos fazem. Bom, responderia dizendo que sim. É um bom curso, com aprendizado diferenciado, baseado em experiência e case e não é só formado por conteúdo teórico. É como o meu CST, Michel Goldenberg, falou: “se fosse teórico e explicar o que já tem no Wikipedia, ninguém precisava estar aqui, pois isso já está disponível de graça”.

Valor do investimento

R$ 1.950,00. É isso que você vai ter que investir. Não posso dizer que é um valor fácil. A única coisa que invisto sem estar muito preocupado é no conhecimento, então nunca vejo um investimento em conhecimento como perdido. Mesmo se um dia fizer um curso e ele for ruim, eu vou conseguir aprender algo com ele. Do lado negativo sempre dá pra tirar algo de positivo para o seu aprendizado, mesmo que não seja no conteúdo do curso.

O mercado

Como o mercado vai ver essa certificação? Da mesma forma que ele vê as demais – talvez essa aqui ainda pior, porque um dos problemas ainda existentes é saber se quem analisa sabe interpretar e conhecer o curso e como ele qualifica o aluno.

Conclusão

Foi um curso muito produtivo, conheci pessoas diferentes, o Michael é de fato um cara muito experiente e com uma boa didática. Ele fez o que pouco fazem, ensina o porquê das coisas. Como eu não sou muito preso a esses papéis de parede, faria o curso mesmo sem certificado – não estou muito preocupado com ele, exceto se eu precisasse vender para um cliente que gosta de ver esses títulos “in english” de preferência.

Fonte: http://imasters.com.br/artigo/24284/agile/certified-scrum-master--como-e-o-processo-para-a-certificacao?trace=1519021197&source=single

Kanban e a facilidade visual

  A capacidade do cérebro de processar informações visuais é muito maior do que a de processar informações textuais. Usando o Kanban é possível ver todo o trabalho e entender com mais facilidade quais tarefas precisam ser realizadas e quais já foram cumpridas. Assim a ferramenta permite que vc observe o fluxo e consiga identificar gargalos e  filas.

  Quando você olha para seu processo graficamente, fica mais fácil organizar e limitar a quantidade de tarefas em processo ou inacabadas e com isso priorizar atividades. Outra grande vantagem do Kanban é que ele facilita a troca de informações, contribuindo para uma cultura de colaboração dentro da empresa.Você vai notar que, conforme for usando o Kanban, conseguirá detectar problemas escondidos, atrasos e falhas em sua gestão. Assim, essa é uma ferramenta que também te ajuda a encontrar soluções mais eficientes e melhorar seus processos.

   Essa ferramenta é muito útil tanto para grandes indústrias, como para pequenas e médias empresas. Afinal, mesmo que você tenha uma startup, o ritmo de vida e de produção imposto pelo mercado exige das empresas muita eficiência nos processos.O Kanban pode ser usado, por exemplo, para te ajudar no controle de estoque, e também para acompanhar processos ligados à serviços e atendimentos de demanda ou para gerir o seu funil de vendas.

   Para você aplicar o kanban nos processos da sua empresa é preciso, antes de mais nada, engajar toda a sua equipe. Ora, se é um sistema que funciona justamente por ser simples de manejar e alterar informações, todos devem saber como operar ele e participar ativamente desse fluxo. É responsabilidade de cada um manter o painel escolhido sempre atualizado e completo.

Fonte:https://endeavor.org.br/kanban/

A Ideia Central do Kanban

  O Kanban é baseado numa ideia muito simples. As Atividades em andamento devem ser limitadas. Algo novo só deve ser iniciado quando uma peça de trabalho existente é liberada ou quando uma função automática inicia isso.

  O Kanban, ou cartão de sinalização, é um sinal visual produzido indicando que novo trabalho pode ser iniciado e que a atividade atual não coincide com o limite acordado. Isso não soa muito revolucionário nem parece afetar profundamente o desempenho, cultura, capacidade e maturidade de uma equipe e a organização na qual está inserida. Mas o impressionante é que afeta! O Kanban parece uma mudança pequena e, no entanto, muda tudo a respeito de uma empresa.

  O que percebemos sobre o Kanban é que ele é uma abordagem para mudança gerencial. Ele não é um processo ou ciclo de vida de gerenciamento de projetos ou de desenvolvimento de software. O Kanban é uma abordagem para introduzir mudanças em um ciclo de desenvolvimento de software ou metodologia de gerenciamento de projetos. O princípio do Kanban é que você inicia com o que estiver fazendo agora. Você entende seu processo atual ao mapear o fluxo de valor e ao concordar, em seguida, em limitar as Atividades em andamento (do inglês WIP) para cada estágio desse processo. A partir daí você começa a rastrear as atividades pelo sistema para iniciá-las quando os sinais do Kanban aparecerem.

  O Kanban tem sido útil para equipes ágeis de desenvolvimento de software, mas tem ganhado popularidade, igualmente, em equipes que utilizam uma abordagem mais tradicional. Ele está sendo introduzido como parte de uma iniciativa Lean (enxuta) para moldar a cultura das organizações e encorajar a melhoria contínua.Porque o WIP é limitado em um sistema Kanban, tudo que fica bloqueado por qualquer motivo tende a parar o sistema.Se certa quantidade de itens de trabalho fica bloqueada, todo o processo pára de funcionar. Isso cria a necessidade de concentrar toda a equipe e toda a empresa na solução do problema para desbloquear o item e restaurar o fluxo.

Fonte: https://www.infoq.com/br/minibooks/kanban-scrum-minibook

Os Papéis do Scrum

Os três papéis definidos no Scrum são:

           * Scrum Master

           * Product Owner

           * Equipe

As pessoas que preenchem estes papéis trabalham em conjunto, numa base diária, para assegurar o bom fluxo de informações e resolução rápida de mudanças.

Scrum Master

O Scrum Master é o guardião do processo. Ele é responsável por fazer o processo correr bem removendo os obstáculos que atrapalham a produtividade da equipe, organizando e facilitando as reuniões.

As responsabilidades do Scrum Master incluem:

• Remover as barreiras entre a equipe e o Product Owner.

• Ensinar o Product Owner como maximizar o retorno sobre o investimento (ROI), e cumprir seus objetivos através do Scrum.

• Facilitar o trabalho da equipe removendo impedimentos que impeçam a equipe de trabalhar.

• Melhorar a produtividade da equipe da forma que for possível.

• Melhorar as práticas de engenharia e ferramentas para que cada incremento de funcionalidades seja potencialmente entregável.

• Manter as informações sobre o progresso da equipe visível a todos de uma forma clara e organizada.

Em termos práticos, o Scrum Master precisa entender bem do Scrum para treinar e orientar os outros papéis, e educar e ajudar as outras partes interessadas que estão envolvidas no processo. Ele deve manter atenção constante ao status do projeto em relação ao progresso esperado. Investigar e facilitar a resolução de quaisquer obstáculos que imobilizam o progresso e, geralmente, ser flexível o suficiente para identificar e lidar com quaisquer problemas que surjam. Ele deve proteger a equipe de perturbações externas.

O Scrum Master não atribui tarefas aos membros da equipe, isso é uma responsabilidade da equipe. Sua abordagem geral para a equipe é incentivá-la e facilitá-la na capacidade de tomada de decisões e resolução de problemas relacionados ao desenvolvimento, de modo que eles possam trabalhar com maior eficiência sem a necessidade de supervisão. Seu objetivo é ter uma equipe auto-organizável.

Product Owner

O Product Owner é dono do produto. Ele fornece o conhecimento do negócio em forma de requistos para a equipe assim como sua ordem de aplicação. Na prática, o Product Owner é a interface entre a empresa e os clientes.

Ele alimenta a equipe com requisitos e correções solicitadas por diversas fontes. É ele o ponto de contato para esclarecimento das dúvidas da equipe sobre os requisitos do produto.

Trabalha em conjunto com a equipe definindo as necessidades dos usuários, os requisitos técnicos, documentando-os conforme a necessidade, e determinando a ordem de sua execução. Ele gerencia o Product Backlog (que é o repositório de todas essas informações), mantendo-o ao nível de detalhe e qualidade que a equipe necessita.

O Product Owner também define o cronograma para liberação das releases, e faz a validação final para saber se as implementações têm as características e qualidade necessárias para a liberação.

Equipe

A equipe, no framework Scrum, deve ser auto-organizada e multidisciplinar, composta por pessoas que fazem o trabalho de desenvolvimento e teste do produto.

Uma vez que a equipe é responsável pelo desenvolvimento do produto, ela também deve ter a autonomia para tomar decisões sobre como executar o seu trabalho. A equipe possui, portanto, auto-organização: os membros da equipe decidem como dividir o trabalho em tarefas, e ao longo da sprint decidem a ordem de execução das tarefas em função da história que está sendo desenvolvida, respeitando sempre a prioridade.

O tamanho da equipe deve ser mantido até nove pessoas, se possível. Um número maior pode dificultar a comunicação e afetar a produtividade.

Fonte: http://www.cprime.com/about/scrum_faq.html

A gerência de risco no XP.

Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, se trata de uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança.

Esta metodologia nasceu nos Estados Unidos ao final da década de 90. E como a febre do gerenciamento de projeto com metodologias ágeis, também está fazendo sucesso em diversos países, ajuda a engajar equipes, ajuda a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica do que nos métodos tradicionais e tudo isso pode ser alcançado pois o XP tem em sua base, foco em valores, princípios e práticas, que vão na linha contrária da forma tradicional e antiga de de desenvolver software.

O XP tem seu foco maior, no escopo, como forma para atingir o sucesso dos projetos e é com o foco no escopo que vem junto a preocupação com mudanças e riscos, por isso aborda a gerência de riscos de forma mais completa do que metodologias ágeis como Scrum e Kanban, mostrando ter muito mais artefatos e maneiras de gerenciar o risco. 

Porém com algumas práticas do XP o risco se torna algo maior ou mais emergente, como por exemplo a necessidade da disponibilidade do cliente para colaborar em dúvidas, alterações e priorizações em escopo. Isso dar um dinamismo maior ao projeto porém faz com que o projeto também esteja na dependência de uma pessoa externa a equipe que pode precisa de incetivo para engajamento no projeto.

Outro exemplo é ter como fundamento a refatoração que diz que, a cada nova funcionalidade, é  necessário que o projetista ou arquiteto de software faça uma refatoração no código, porém esta prática reflete em mais hora de trabalho e  isso se torna uma prática nem sempre aceita, por envolver prazos e custos, há uma rejeição tanto por parte do cliente quanto por parte do gerente de projeto.Isso prova que trabalhar de forma ágil como no XP, tem uma complicação por provocar aumento dos riscos do projeto, implicando em um aumento no custo para se gerenciar riscos quando se adota metodologias ágeis, mesmo porque os métodos ágeis são menos eficiente do que os métodos tradicionais quando se fala de gerência de riscos.

O que é Kanban?

Kanban é um termo de origem japonesa e significa literalmente “cartão” ou “sinalização”. É um conceito relacionado com a utilização de cartões (post-it e outros) para indicar o andamento dos fluxos de produção em empresas de fabricação em série. Nesses cartões são colocadas indicações sobre uma determinada tarefa, por exemplo, “para executar”, “em andamento” ou “finalizado”.

A utilização de um sistema Kanban permite um controle detalhado de produção com informações sobre quando, quanto e o que produzir.O método Kanban foi inicialmente aplicado em empresas japonesas de fabricação em série e está estreitamente ligado ao conceito de “just in time”. A empresa japonesa de automóveis Toyota foi a responsável pela introdução desse método devido a necessidade de manter um eficaz funcionamento do sistema de produção em série.

O Kanban eletrônico (e-Kanban) é utilizado em substituição ao método físico evitando alguns problemas como a perda de cartões e proporcionando mais rapidez na atualização do quadro de tarefas.Atualmente, o Kanban é muitas vezes usado em conjunto com o Scrum, porque são duas metodologias usadas no desenvolvimento ágil de software. Outro conceito que por vezes é relacionado com Kanban, Just in Time e Scrum é Kaizen, que também tem como objetivo aumentar a produtividade.

Fonte: http://www.significados.com.br/kanban/

Formação do time - equipe SCRUM

                   O Time Scrum é composto pelo Product Owner, o Time de Desenvolvimento e o Scrum Master. Times Scrum são auto-organizáveis e multifuncionais. Times auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora do Time. Times multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe.

                  O modelo de time no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. Times Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades de realimentação. Entregas incrementais de produto “Pronto” garantem que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível.

Product Owner

O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. 

O gerenciamento do Backlog do Produto inclui: 

 Expressar claramente os itens do Backlog do Produto;

 Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões; 

 Garantir o valor do trabalho realizado pelo Time de Desenvolvimento; 

 Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e, 

 Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário. 

O Product Owner pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento fazê-lo. No entanto, o Product Owner continua sendo o responsável pelos trabalhos. O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner. Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. 

                         As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém tem permissão para falar com o Time de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem. 

O Time de Desenvolvimento

O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos. Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo. Os Times de Desenvolvimento tem as seguintes características: 

 Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis; 

 Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto. 

 O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra. 

 Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo; e, 

 Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios. Tamanho do Time de Desenvolvimento O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites da Sprint. Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Times de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando um Time de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável. Havendo mais de nove integrantes é exigida muita coordenação. Times de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem, a menos que eles também executem o trabalho do Backlog da Sprint. 

Scrum Master

                            O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum. 

O Scrum Master trabalhando para o Product Owner O Scrum Master serve o Product Owner de várias maneiras, incluindo: 

 Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto; 

 Claramente comunicar a visão, objetivo e itens do Backlog do Produto para o Time de Desenvolvimento; 

 Ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa; 

 Compreender a longo-prazo o planejamento do Produto no ambiente empírico; 

 Compreender e praticar a agilidade; e, 

 Facilitar os eventos Scrum conforme exigidos ou necessários. 

O Scrum Master trabalhando para o Time de Desenvolvimento 

O Scrum Master serve o Time de Desenvolvimento de várias maneiras, incluindo: 

 Treinar o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade; 

 Ensinar e liderar o Time de Desenvolvimento na criação de produtos de alto valor; 

 Remover impedimentos para o progresso do Time de Desenvolvimento; 

 Facilitar os eventos Scrum conforme exigidos ou necessários; e, 

 Treinar o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.

O Scrum Master trabalhando para a Organização

O Scrum Master serve a Organização de várias maneiras, incluindo: 

 Liderando e treinando a organização na adoção do Scrum; 

 Planejando implementações Scrum dentro da organização; 

 Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico; 

 Causando mudanças que aumentam a produtividade do Time Scrum; e, 

 Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum nas organizações.

Fonte: Guia do SCRUM