Avalie gratuitamente seu conhecimento com desenvolvimento de software e Scrum

Scrum.org acaba de liberar o teste aberto de Scrum Developer, o Developer Open Assessment. É uma prova que você pode fazer gratuitamente para avaliar o seu nível de conhecimento com desenvolvimento de software usando Scrum. Diferentemente da Scrum Open Assessment, que também é grátis mas é focada apenas em Scrum, o Developer Open Assessment foca em práticas e ferramentas de desenvolvimento de software. Continue lendo “Avalie gratuitamente seu conhecimento com desenvolvimento de software e Scrum”

Kanban para os céticos: analisando e derrubando mitos negativos

Como um agente de mudanças, devemos assegurar as pessoas de que vale realmente a pena seguir o caminho escolhido. Essa necessidade se torna aparente em críticas e perguntas difíceis. Vejo isso com frequência atuando como coach de equipes ágeis. O mesmo acontece ao se introduzir o Kanban. Porém percebi que a partir do momento em que as pessoas aprendem o básico e começam a explorar o assunto por conta própria, surgem questões muito mais difíceis, em níveis de gestão e liderança. Um exemplo: “Como podemos planejar já que medimos em vez de estimar?” Continue lendo “Kanban para os céticos: analisando e derrubando mitos negativos”

O Kanban é o novo Scrum?

Por vários anos, muitas pessoas consideraram o Scrum como o ponto de partida ao se iniciar uma implementação ágil. De fato, muitos acreditam (de forma equivocada) que Scrum e Agile são a mesma coisa. Pela atual popularidade e extensa adoção, o Scrum tem sido a escolha ágil padrão de muitas organizações. Entretanto, com o recente crescimento da adoção do Kanban, alguns o veem como o próximo passo na evolução do Agile.

Abby Fichtner declarou em seu artigo que o Kanban é o novo Scrum:

Talvez seja pelo tempo que passei em startups, mas apesar de valorizar muito as ideias do Scrum como a auto-organização das equipes e do feedback contínuo, não posso deixar de pensar no Kanban como o próximo nível de agilidade, permitindo mais flexibilidade e aprendizado com as lições que temos extraído do Lean. Continue lendo “O Kanban é o novo Scrum?”

Como adotar Scrum na sua empresa

Existem muitas discussões nos grupos que tratam de Scrum e Agile sobre qual é a melhor maneira de começar a fazer Scrum. Vou falar um pouco sobre o meu ponto de vista sobre como iniciar com Scrum na sua organização.

Primeiramente você deve se perguntar: Estou pronto para iniciar a mudança com Scrum? Deve saber que não é fácil iniciar essa mudança, mas a recompensa é valiosa.

Você irá precisar de apoio e suporte para a mudança, possivelmente de alguém acima de você na organização, sem esse suporte não é possível iniciar a mudança a que se propôs, mas também irá precisar de apoio de pessoas do seu dia dia, do seu grupo de trabalho. Forme uma equipe com espírito vencedor. Scrum pode ajuda com isso, mas há muitos outros fatores que contribuem. Lembre-se que a principal mudança está nas pessoas e estas sim podem fazer toda a diferença.

Use algumas métricas para mostrar que você está fazendo progresso (Ciclo de entregas mais rápidos, quantidade de bugs conhecidos, funcionalidades entregues por iteração, por exemplo) . Não deixe que eles insistam em métricas perfeitas (nunca irão existir) e certifique-se que as pessoas usam de bom senso na interpretação dos indicadores. Mas cuidado, métricas mal aplicadas tendem a se virar contra você.

Seja extremamente agressivo sobre a remoção de impedimentos pois isso é fundamental. Na equipe, pelo ScrumMaster, pelos gestores. Difícil prever de antemão qual será o seu maior impedimento, mas podem ser: as pessoas, falta de disciplina ao fazer Scrum (ScrumBut), práticas de engenharia, o fluxo de informações de negócios para a equipe (por exemplo, PO fraco, especialistas de negócio inacessíveis).

Construir o sucesso fora da equipe. Percorra a meta de sucesso do negócio (o cliente está realmente feliz) e não apenas de sucesso técnico (nós fizemos mais rápido o que dissemos que faríamos X meses atrás). Eu não sei o que vocês fazem hoje, mas posso apenas garantir que depois de 3 Sprints, algum grau de sucesso relativo vocês terão.

A ‘mudança de gestão ” quando adotamos Scrum é bastante significativa. É interminável. As pessoas pensam que eles entendem bem de Scrum, mas acho que a mudança de paradigma é realmente difícil, sair de um modelo tradicional para um modelo ágil não é feito da noite para o dia. Normalmente as empresas precisam de treinamento para as equipes. Saia do seu cubículo e vá procurar alguém que conheça bem essas práticas. Pense que não apenas você, mas que o time todo, talvez muitas pessoas da sua organização precisem de treinamento para poderem entender a mudança que o Scrum irá trazer à organização.

Cuidado com a dívida técnica. Adote as boas práticas (TDD, BDD, design patterns e outros), pois isso será será muito importante, mais cedo ou mais tarde. Comece a atacá-los desde cedo. Se o seu time não escreve testes automatizados, ele não é ágil. O verdadeiro sucesso com Scrum deve ser medido como 5x-10x melhor do que sua base atual. Algumas empresas fazem isso muito bem e, muitas vezes, mas a maioria nunca chega lá. Acho que o segredo não é tanto as práticas do Scrum, mas as pessoas fixando melhor os valores e princípios subjacentes. Sem os valores e princípios, uma “reunião diária”, por exemplo, pode ser quase um desperdício de tempo.

Depois de ter certeza que você realmente quer adotar Scrum, comece. Não espere ter o backlog perfeito, nem o PO perfeito e muito menos o ScrumMaster perfeito, você no início provavelmente não terá nenhum deles, isso vem com o tempo. Adote as mudanças e perceba seus resultados, procure sempre a melhoria contínua. Fazendo isto os resultados serão notados e você perceberá que todo o esforço valeu a pena.

Fonte: http://micajeho.wordpress.com

Scrum é framework e não metodologia

Um dos erros mais comuns ao se falar em Scrum é defini-lo como uma metodologia, algo que de fato ele não é, e vou explicar porque. Uma metodologia é o estudo de métodos e técnicas embasados científicamente utilizadas em processos de investigação. Diferente de um processo mais tradicional o Scrum não irá te dizer o que fazer, você tem a liberdade para fazer o que melhor funcionar dentro da suas necessidades e possibilidades.

Os pilares do Scrum, transparência, inspeção e adaptação é que nos fazem melhorar nosso processo e isso vem apenas com tempo, com as evidências de melhoria contínua. Isso já afirma que nosso processo necessita desses três pilares para garantir sua sustentabilidade e evolução. Sendo assim podemos dizer que não temos a solução nem mesmo a pretensão de prever tudo ou ter a resposta para todas as perguntas.

Em uma metodologia todos os processos são conhecidos e previamente definidos, ou seja, prescritivos, diferentemente do Scrum onde o processo de aprendizado é empírico. Acreditamos que cada experiência traz um aprendizado que deve ser levado em consideração dentro do processo de controle.

Adaptworks, referência brasileira em Scrum, possui a seguinte definição : “Scrum é um framework iterativo e incremental para o desenvolvimento de qualquer produto ou gerenciamento de qualquer trabalho.”

Ken Schwaber da Scrum.org e criador do Scrum, defende que o este foi feito para desenvolvimento de softwares complexos, embora é conhecido que muitas empresas utilizam algumas práticas do Scrum e tem noticiado que tem sentidos os efeitos que as mudanças após a adoção Scrum proporcionaram para suas organizações. Quando começamos a usar Scrum não conhecemos todos os possíveis eventos, nem todo o negócio, nem mesmo os impedimentos que irão surgir durante o desenvolvimento.

Eu acredito tanto no Scrum que afirmo ser é viável adotar esse poderoso framework em outros ramos de atividade que não apenas desenvolvimento de software. Penso eu que numa empresa de marketing, por exemplo, é possível criar um product backlog com items de uma determinada campanha, e dele derivar as tarefas que devem ser realizadas assim como sua ordem de prioridade e retorno, definido sprints curtas para entrega de valor e por ai vai.

O Scrum irá te dar uma base de onde a partir dela poderá criar sua metodologia de acordo com as necessidades e peculiaridades da sua empresa. É permitido e digo até desejável aliás juntar práticas de outros métodos ágeis com o Scrum, como é muito comum o pair programming que vem do XP, por exemplo.

Por essa flexibilidade é que dizemos que o Scrum é um framework e não uma metodologia. Assim com qualquer framework o Scrum pode ser extendido, tendo algumas de suas práticas removidas se for o caso, mas cuidado ao remover alguma prática, pois o seu valor pode ser perder durante o processo. Tenha em mente os benefícios que tais práticas trazem para somente depois se julgar necessário remover algo. A Scrum.org já sinalizou que irá validar possíveis extensões no Scrum, para ver as propostas que já foram feitas sobre extensões por membros da comunidade basta acessar o site.

Fonte: http://micajeho.wordpress.com

Scrum ou Kanban, qual escolher?

Imagine esse cenário: Um ambiente onde há muitos produtos legados, código que requer manutenção constante e que necessita de fluxo contínuo, não podendo aguardar até determinada data para realizar um deploy. Neste cenário é evidente que o Kanban melhor ser adapta, pois com ele é possível visualizar esse fluxo e proporcionar um ambiente onde é possível organizar o trabalho a ser feito.

Por ser menos prescritivo que o Scrum, que tem suas cerimônias, papéis e artefatos, o Kanban é mais lean e menos complexo, talvez por isso, sua adoção é mais suave que o Scrum.

Porém se você necessita de um certo grau de controle, ciclos mais definidos possivelmente com necessidade de sincronia com outros departamentos, talvez ai o Scrum se encaixe melhor. Acredito que não há uma regra para definir qual método ágil é melhor. Não é porque estou em um projeto novo que devo usar Scrum e nem porque estou em um projeto de manutenção de sistemas legados que devo usar Kanban.

Aqui na empresa quando escolhemos adotar Kanban para manutenção, era evidente que não seria possível manter um backlog com itens de vários produtos legados com complexidades distintas e necessidades de negócios divergentes. Por este motivo foi-nos sugerido pelo Giovanni Bassi durante uma consultoria usar Kanban neste ambiente.

O que percebemos ao adotar Kanban:

  • Possibilidade de manter itens de vários produtos diferentes ordenados e juntos;
  • Marcando com post-its de cores diferentes cada produto visualizamos qual era o que mais demandava esforço;
  • Limitações nas marcações permitem visualizar onde estão os gargalos na execução de tarefas;
  • Deploy mais rápidos, entregando valor mais cedo;

Há outras coisas que podem ser evidenciadas também, como tempo médio de realização de uma tarefa, onde o trabalho está enroscando. Isto nos permite tratar as causas destes gargalos e ser mais eficientes na entrega de valor, não apenas seus efeitos. Um exempo pode ser o QA acumulando ou travando o fluxo de trabalho. Talvez seja aconselhável treinar melhor os executores do QA ou melhorar as práticas ao invés de contratar mais duas pessoas para realizar estas tarefas mais rápido.

Legal também citar que o Kanban não serve apenas para manutenção de código legado. Perceba que ao trabalhar com Kanban é possível ao final do ciclo realizar deploy da aplicação, logo, o valor daquilo que foi realizado já está disponível para o cliente, seja ele uma correção ou até mesmo uma nova feature. Assim notamos que assim é muito ágil seja para ambientes de desenvolvimento ou manutenção de software.

Agora imagine este cenário: Um produto novo, com um time to market predefinido, equipe com pouco conhecimento do negócio e da arquitetura e ainda em estado de formingnecessidade de alguma previsibilidade de deploy. Penso que este ambiente é bom para aplicação do Scrum, por muitos fatores, mas o principal é por ele ser mais prescritivo e assim garantir um pouco mais de controle do processo, mas veja que negritei o processo justamente por isso, para que não seja confundido com controle das pessoas envolvidas.

Se na sua empresa há uma necessidade de estimar projetos para que o departamento comercial ou o marketing possam se organizar seja para uma determinada campanha, pré-lançamento ou mesmo plano de posicionamento de produto por exemplo, recomendo estruturar as releases de forma a atender essa necessidade. O Scrum fornece meios para realizar esse tipo de colaboração mais facilmente.

O Kanban assim como Scrum permite usar partes de outros métodos ágeis, por exemplo reuniões diárias, do Scrum ou Pair Programing do XP. Lembre-se que sempre será necessário que alguém diga dentre as tarefas existentes no quadro, qual é a mais prioritária e assim por diante. Chamar essa pessoa de Product Owner ou não dependerá de você, não há regra quanto a isso, aliás a única regra evidente no Kanban é que os limites das marcações devem ser respeitados.

Usar Scrum ou Kanban vai depender de muitos fatores, que variam de produto e suas necessidades até empresa e seu meio ambiente. Quando pensar em um processo ágil, leve em consideração quais pontos proporcionarão mais desempenho em termos de negócio e técnicos e seja feliz. Lembre-se que fazer software também pode ser divertido e, aliás, deve ser divertido.

Algumas pessoas na comunidade concordam que Scrum e Kanban são facilmente combináveis, a Professional Scrum Trainer KaTe Terlecka, explica em seu blog  a maneira como ela combina esses dois métodos gerando o Kate-Ban, que segundo ela tem funcionado bem.

Fonte: http://micajeho.wordpress.com/

Sessões de Backlog Grooming (Organização do Backlog)

Para Roman Pichler, assim como o seu jardim que vai crescendo até se tornar uma selva se for devidamente cuidado, o seu backlog também vai crescendo e tornando desajeitado se for dada a ele a devida atenção. “O Backlog precisa de atenção e cuidado frequente, precisa ser organizado cuidadosamente.”

O propósito de Reuniões de Backlog Grooming é aprimorar o Backlog.

A palavra Grooming em inglês significa cuidar da aparência, manter limpo e arrumado. Para facilitar a semântica do artigo, traduzirei “Backlog Grooming” como “Organização do Backlog“, considerando que organizado é por consequentemente limpo e arrumado. Alguns autores preferem chamar de Refinamento de Backlog.

Backlog Grooming

Organizar o backlog é uma processo contínuo que envolve:

  1. A descoberta de novos itens, assim como alteração e remoção de itens antigos.
  2. Quebrar Estórias muito grandes (épicos).
  3. A priorização dos itens do backlog (trazendo os mais importantes para o topo).
  4. Preparar e refinar os itens mais importantes para a próxima reunião de planejamento.
  5. Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas).
  6. Incluir Critérios de Aceitação.

Muitas equipes que utilizam métodos ágeis como Scrum e XP, reclamam que suas reuniões de planejamento “levam uma eternidade”. Sessões de Backlog Grooming, podem ser utilizadas como uma ferramenta simples e rápida para tornar as reuniões de planejamento mais eficientes.

Embora a manutenção do Backlog seja de responsabilidade do Product Owner, outros membros do time podem colaborar na reunião de Organização do Backlog, Ken Schwaber sugere a participação de 10% da equipe durante de 5 a 10% do tempo da Sprint, de forma a incentivar a comunicação face-a-face entre as pessoas ao invés de outros meios como comunicação por e-mail ou documentos.

Roman sugere a utilização de cartões de papel como ferramenta para facilitar a colaboração na reunião, cada participante pode pegar um cartão e escrever suas ideias. Depois, estas podem ser agrupadas e, caso necessário, pode-se transferir as informações para uma ferramenta eletrônica, como o Pronto, por exemplo.

Referências

Metodologia Ágil

 “Governança de TI é igual redbull, pode lhe dar asas”

Em 2001, um grupo de 17 profissionais se reuniu para discutir sobre como melhorar o desempenho em seus projetos. Cada um deles possuía suas próprias praticas e métodos de trabalho, mas concordaram que um conjunto de princípios sempre estava sendo respeitado em todos os projetos que deram certo.

Por fim desenvolveram o manifesto ágil. Este manifesto definia os valores e princípios a serem seguidos, para se obter maiores e melhores resultados. O foco maior do manifesto é o de desenvolver softwares tornando este processo  mais pessoal, mais colaborativo e mais fácil.

 Valores das metodologias ágeis:

Indivíduos e interação entre eles mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Os doze princípios das metodologias ágeis:

  1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
  2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
  3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
  4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
  5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
  6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
  7. Software funcional é a medida primária de progresso.
  8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
  9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
  10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
  11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
  12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Para se utilizar dos benefícios fornecidos pelo manifesto ágil devemos adotar uma metodologia ágil, essa metodologia define algumas regras e formas de trabalho. Alguns exemplos de metodologias ágeis:

Cada metodologia tem sua maneira de trabalho, mas em geral são processos iterativos e incrementais. Sendo que ao final de cada iteração o cliente recebe uma versão utilizável do produto.

Hoje as metodologias mais conhecidas no mercado são a XP e a SCRUM. A XP (Extreme Programming), que possui um número de práticas um pouco maior e oferece práticas de certo modo radicais, ou vistas com certo receito, como é o caso do “pair programming”. Mas é uma metodologia que fornece excelentes benefícios quando aplicada corretamente. A SCRUM é outra metodologia ágil bastante utilizada atualmente, ela é um pouco mais simples e direta, não possui tantas praticas quanto a XP, mas fornece excelentes resultados para os projetos. A grande vantagem do Scrum é que através dele pode-se gerenciar vários tipo de projetos, mesmo que não seja de software.

Scrum Master ( CSM ) – regras para certificação

Desde 1º de Janeiro de 2012 estão valendo as novas regras para o exame de certificação para Scrum Master (CSM), de acordo com o comunicado da ScrumAlliance.org. O objetivo é o de tornar o processo mais rigoroso.

Assim, as novas regras são:

  • O Content Outline and Learning Objectives – a base para a estrutura e conteúdo do novo exame de CSM – está disponível para download no site da Scrum Alliance.
  • Todos os candidatos que prestarem o exame até o dia 31 de Março de 2012 serão automaticamente aprovados.
  • A partir de 1º de Abril de 2012, os candidatos serão aprovados ou não de acordo com o seu desempenho no exame.
  • A partir de 1º de Abril de 2012, os candidatos terão 60 dias para duas (2) tentativas gratuitas de aprovação. Após este período de 60 dias, o candidato deve pagar US$25 por tentativa. Após três (3) tentativas sem aprovação, é recomendado que o candidato faça um outro treinamento de CSM antes que sejam permitidas novas tentativas.
  • O novo exame terá 35 questões, sem limite de tempo. Os candidatos poderão marcar questões, mudar as respostas das questões e até mesmo interromper o exame, retornando a ele posteriormente dentro do prazo de 60 dias.
  • Ao final do exame, o candidato verá as questões respondidas incorretamente. A lista de opções não será exibida. Isto para encorajar os candidatos que não passarem na primeira tentativa revejam o conteúdo do curso antes de uma nova tentativa.
  • Candidatos que não sejam aprovados na primeira tentativa podem refazer o teste imediatamente (não é necessário um período mínimo) ou a qualquer momento dentro do período de 60 dias.
  • Depois de aprovado, o candidato pode renovar sua credencial a cada dois anos. A Scrum Alliance criará até Janeiro de 2013 o programa de Professional Development Units (PDUs). Os CSMs deverão obter estes PDUs para manter suas certificações.