Eventos do Scrum – A Sprint

O Scrum possui 5 eventos ou cerimônias em seu framework, dos quais, todos são obrigatórios. Esses eventos são todos “Time-Boxed”, tem tempo máximo definido. Apenas o Sprint, uma fez definida a sua duração, ela é fixa e não pode ser encurtado e nem alongado, os demais eventos, podem ser encerrados antes, desde que o seu objetivo tenha sido alcançado.

Esses eventos servem para manter os 3 pilares do Scrum, que são a transparência, inspeção e adaptação, não realizar ou realizar somente parte dos eventos, irão prejudicar esses 3 pilares.

Se caso a empresa ou a equipe decidir não realizar algum destes eventos, por julgar desnecessário, deve-se repensar se a empresa está preparada para o Scrum ou as pessoas não entenderam o Scrum, pois retirar qualquer um destes eventos não é possível implantar o Scrum na empresa. Lembre-se, o Scrum é fácil de entender, mas difícil de dominar.

Continue lendo “Eventos do Scrum – A Sprint”

Scrum Master em Ação

O papel do Scrum Master é de extrema importante dentro de uma organização que deseja implantar o Scrum ou que já o tem implantado.

É ele quem garante que as regras e cerimônias sejam cumpridas e assim aumentar a produtividade e eficiência do time Scrum.

Veja um verdadeiro Scrum Master em Ação no vídeo abaixo:

Os Papéis do Scrum – O Scrum Master

O último papel descrito no Framework Scrum, é o do Scrum Master. Pode parecer estranho, mas o Scrum Master é uma posição de gerenciamento, não de pessoas, ou do desenvolvimento ou do projeto, mas sim um gerente de processos.

O Scrum Master é um grande facilitador e age como um mentor e defensor do Scrum dentro da organização. Ele apoia o time de desenvolvimento para que as regras do Scrum sejam respeitadas, remove impedimentos, apoia o Product Owner na melhor forma de gerir o Backlog do Produto, divulga o Scrum dentro da organização, explica e faz com que as pessoas entendam o framework.

Continue lendo “Os Papéis do Scrum – O Scrum Master”

Papéis do Scrum – O Time de Desenvolvimento (Development Team)

O time de desenvolvimento, como o próprio nome diz, é o responsável por desenvolver o produto. Ele é responsável por transformar itens do Backlog do Produto em incremento de software potencialmente utilizável. Somente membros do Time de Desenvolvimento entregam incrementos do Software, mais ninguém.

É importante frisar de que o Time de Desenvolvimento, não é feito só por programadores. O time precisa ser composto por todas as competências necessárias para que o produto que se deseja desenvolver, seja construído pelo time, sem dependência de qualquer outra pessoa externa ao time.

Por exemplo, se o produto é um software para Web, desenvolvido em Java com banco de dados Oracle, você irá precisar compor o time com analista de sistemas, programadores Java, webdesign, alguém com conhecimento em Oracle ou até um DBA se for algo muito complexo e testadores. Nenhum item de backlog, selecionado por esse time, poderá ser “terceirizado” para outra equipe. Não é correto fazer por exemplo, com que o Webdesign que está em outra equipe, faça o “front-end” para que o time de desenvolvimento faça o “back-end” e teste a solução. O conceito é produto pronto, do inicio ao fim, da criação das tabela, front-end, back-end e testes finais da solução.

O time de desenvolvimento é responsável ainda, pela definição das tarefas necessárias para que um item do backlog do produto seja considerado pronto, no exemplo acima, as tarefas poderão ser separadas, entre Design da tela, construção da camada de negócio, preparação das tabelas do banco de dados, testes unitários, testes funcionais, testes de regressão e por ai vai. É o time de desenvolvimento quem define essas atividades e o tempo estimado para conclusão de cada uma delas. Para que isso funcione, as pessoas deste time precisam ser auto-disciplinadas, elas não precisam ter um chefe dizendo o que elas precisam fazer, pois elas sabem o que deve ser feito e se auto organizam.

Em resumo, um time de desenvolvimento precisa ter pessoas com habilidades específicas e generalistas ao mesmo tempo. Um time de 3 pessoas, aonde um só faz análise, um só programa e um só testa, não irá funcionar no Scrum. Esse time precisa ter um analista que pode ajudar no desenvolvimento e testar, um programador que pode auxiliar nas definições de análise e testar e um testador, que também faça a análise e monte manual do usuário. O time precisa ser multidisciplinar.

O tamanho do Time de Desenvolvimento, segundo o framework Scrum, precisa ser grande o suficiente para conseguir entregar incrementos de software por completo e pronto para uso e pequeno o suficiente para não ser ágil. Recomenda-se que o time seja de 6 +/-3, ou seja, de 3 a 9 integrantes, sem contar o Scrum Master e o Product Owner. Os mesmos só poderão ser considerados, se eles também fizerem entregas do backlog da Sprint, ou seja, se eles também desenvolverem, seja analise, programação, testes, etc.

Ter um time menor do que 3 integrantes, pode ser que não seja possível entregar softwares por completo e também reduz demais as relações interpessoais. Ter mais do que 9 pessoas, o time poderá ser tornar lento e difícil de coordenar, então, tente montar times de 3 a 9.

Ai vem a pergunta, mas e se eu tiver 20 pessoas na empresa? Simples, monte pelo menos 3 times de desenvolvimento, que poderão trabalhar ou em produtos diferentes (com backlogs diferentes) ou no mesmo produto, compartilhando o mesmo backlog do produto.

Em resumo, o que o Time de Desenvolvimento precisa ter:

  • Conhecimento sobre o Scrum, seus papéis, artefatos, cerimônias e regras.
  • Colaboração, trabalho em equipe é essencial;
  • Atuação com transparência;
  • Buscar o máximo de valor ao negócio;
  • Melhoria contínua;
  • Apoiar o dono do produto a manter o backlog do produto;
  • Auto-organização;
  • Comprometimento;
  • Trabalho com qualidade.

Sem dúvida, a essência do Time de Desenvolvimento no Scrum é o comprometimento total ao projeto, auto-organização e trabalho em equipe, sem isso, o processo não irá funcionar. Se na sua empresa, você não tem alguma dessas 3 qualidades no seu time, melhor trabalhar esses pontos que faltam e só depois implantar o Scrum, caso contrário, você irá se frustrar com os resultados.

Time que não tiver comprometimento, mesmo que seja auto-organizado, não vai funcionar. Um time comprometido, mas que não sabe se organizar e trabalhar em equipe, também não irá funcionar.

Mas existe uma pessoa que pode ajudar nesse processo, esse cara é o “Scrum Master”, que veremos no próximo post.

Até breve e um ótimo dia.

Os Papéis do Scrum – O Dono do Produto (Product Owner)

Papéis no desenvolvimento de software significa uma ocupação, uma responsabilidade, assim como em um teatro, um ator faz um “papel” em uma peça. No desenvolvimento, é mais ou menos a mesma coisa, em um projeto de software, cada um assume um papel no projeto, aonde terá um conjunto de responsabilidades.

Papel é um pouco diferente de cargo, por exemplo, o cargo de uma pessoa na empresa pode ser Assistente Administrativo, mas no projeto ele assume o papel de usuário chave (key user) do módulo financeiro. Então, antes de mais nada, separe a ideia de papel de cargos na empresa,

O framework Scrum contém apenas 3 papéis para composição do Time Scrum: O Dono do Produto (Product Owner), Scrum Master e Time de Desenvolvimento (Development Team).

 

O Dono do Produto (Product Owner).

O nome já diz tudo, esse papel é responsável pelo produto (software), ele é o dono do produto, ele é quem diz o que vai ter e o que não vai ter no produto, o que deve ser feito primeiro, ou seja, define as prioridades. Além disso, é responsável pelo ROI (Return On Investiment ou retorno sobre o investimento) e deve conhecer muito bem as necessidades do produto.

As necessidades do produto certamente não virão da cabeça do Dono do Produto, mas sim dos usuários, dos gerentes do negócio, do dono da empresa, enfim, dos stakeholders (interessados no projeto), mas é o Dono do Produto quem recebe as necessidades e as prioriza conforme os interesses destes stakeholders, pois ele é o representante oficial dos mesmos.

Para ser um dono do produto, ele precisará:

  • Conhecer o negócio do cliente / empresa e suas necessidades.
  • Precisará maximizar o valor do produto, avaliando o maior retorno possível sobre o dinheiro investido.
  • Deve ter facilidade de acesso aos interessados no projeto.
  • Deve ter facilidade de comunicação com diversos níveis hierárquicos da empresa ou cliente.
  • Cuidar do Backlog do Produto (lista dos itens e funcionalidades que o produto terá, veremos isso em detalhes em outro artigo).
  • Definir o período das liberações (releases) do software.
  • Ser uma única pessoa, não um comitê (ainda que influenciado por um conjunto de pessoas).
  • Detalhar os itens do backlog do produto, criando as estórias de usuário ou especificações dos requisitos, no nível de detalhe suficiente para o Time de Desenvolvimento.
  • Estar sempre disponível para o Time de Desenvolvimento, quando este requerer informações para realizar o desenvolvimento do produto.
  • Fornecer feedback constante para o time de desenvolvimento.
  • Garantir que o Backlog do Produto seja visível para o time scrum e todos os interessados no projeto.

O Dono do Produto, e somente ele, é quem determina o que deve ser desenvolvido pelo time de desenvolvimento, podendo incluir ou tirar itens do Backlog do produto, ele só não pode retirar itens de uma Sprint em andamento, mas caso necessário, ele poderá cancelar uma Sprint (o que é muito raro devido a sua curta duração e uma prática, apesar de possível, não recomendável). Obviamente ele atua sobre a influência de outras pessoas interessadas no projeto, mas é ele quem define se algo deve ser feito e quando (prioridade), pois ele é quem responde sobre o ROI do projeto.

O Dono do Produto, idealmente, não deve ser pressionado por decisões unilaterais, por exemplo, de um diretor, que utiliza seu “poder” para solicitar alguma demanda. Por exemplo, o diretor solicita que no pedido de venda, seja emitido um aviso sobre produtos em promoção e ao mesmo tempo, o gerente financeiro solicita que no pedido de venda seja emitido um alerta ao vendedor se o cliente selecionado estiver com alguma fatura em atraso e não deixe seguir com o pedido de venda. Neste ponto, qual o item mais importante? O que o diretor da empresa pediu ou o que o gerente pediu? A resposta é “depende”. A solicitação do diretor pode não ser mais importante em um momento em que as vendas estão indo bem, então faz sentido não vender para inadimplentes para não prejudicar mais ainda o caixa da empresa, mas pode ser muito importante em um momento que é necessário aumentar as vendas e os produtos em promoção são estoque antigos que estão parados.

Por isso a importância do Dono do Produto ter certa imparcialidade nas decisões em termos de “quem solicitou” e assim poder analisar o que é melhor para o negócio e definir o que irá trazer maior valor ao negócio primeiramente.

Outro ponto importante, é que é recomendável que se tenha apenas um Dono do Produto, para cada Backlog do Produto, para evitar conflitos de interesses e é extremamente recomendável que o Dono do Produto não seja o gerente ou chefe dos desenvolvedores.

Comparando com os modelos tradicionais de desenvolvimento de software, o Dono do Produto estaria juntando parte de 3 funções: Gerente do Projeto e Analista de Requisitos e Consultor de Negócios.

O Dono do Produto, se assemelha a um Gerente de Projeto pois é dele a responsabilidade de definir as prioridades, o escopo do produto (backlog do produto), define quando serão efetuadas as liberações em produção (releases do produto) e acompanha os prazos da entrega das releases. Porém, as semelhanças param por ai, pois ele realiza o “macro” gerenciamento, pois não cabe a ele definir o tempo de entrega de cada item do backlog, não determina as tarefas a serem realizadas muito menos o tempo das mesmas e não controla os prazos dentro de uma Sprint.

O Dono do Produto, se assemelha a um analista de requisitos, pois ele é quem realiza esse levantamento, coleta as necessidades e busca detalhar a nível de negócio as necessidades, mas ele não irá definir como será construída a solução para resolver o problema do negócio, como faria um analista de sistemas. Ele fica no nível mais acima, na camada do negócio, pois é o Time de Desenvolvimento quem irá definir qual a solução para resolver ou atender a necessidade do negócio.

E o Dono do Produto se assemelha a um consultor de negócios, pois ele deverá conhecer o negócio do cliente e analisar as demandas no nível de quanto cada solução irá trazer de retorno ao negócio, mas a responsabilidade para ai, pois encontrar melhores soluções para o negócio, já não faz parte deste papel.

Por fim, o que não se espera de um Dono de Produto:

  • Falta de conhecimento sobre o produto sendo desenvolvido ou do negócio.
  • Falta de tempo para atender o time de desenvolvimento.
  • Falta de habilidade de comunicação e relacionamento interpessoal.
  • O micro gerenciamento, tipo comando e controle, típico de gerentes tradicionais.
  • Dificuldade de tomada de decisão.
  • Falta de autoridade sobre o produto sendo construído.
  • Falta de conhecimento do Scrum.

No próximo post, irei abordar o Time de Desenvolvimento. Até a próxima.

Desenvolvimento Iterativo e Incremental

No desenvolvimento de software temos vários modelos, mas os mais conhecidos são o modelo em cascata, interativo e incremental. O modelo cascata é o mais utilizado, apesar de alguns acreditarem que é um modelo ultrapassado. Grandes empresas ainda utiliza esse modelo de desenvolvimento, por ser mais simples de gerenciar, mais facilmente entendido por todos, porém traz alguns problemas no mundo atual.

O modelo em cascata consiste em um sequenciamento de atividades, sendo que uma etapa só começa após a outra ter sido finalizada. Abaixo, uma figura que representa o modelo:

Modelo_Cascata

Mas quando se trata de métodos ágeis, esse modelo não se encaixa, precisa ser ajustado, pois ele precisa passar por todas essas etapas, porém, de forma mais rápida, ou seja, iremos realizar o levantamento de requisitos, mas não na sua totalidade, apenas o que é necessário para o momento, aquilo que é mais importante agora, iremos fazer o projeto, codificar esses itens, testar e implantar se necessário. Em métodos ágeis como o Scrum fazemos isso de forma Iterativa e Incremental.

Mas o que vem a ser desenvolvimento iterativo? E o que significa desenvolvimento incremental?

Continue lendo “Desenvolvimento Iterativo e Incremental”

O que é Scrum

A partir deste artigo, começo uma nova série, falando um pouco sobre este processo framework chamado Scrum.

Primeiramente, vamos falar do que é Scrum:

  1. É um framework estrutural, ou seja, uma caixa de ferramentas que serão utilizadas para construção de um software, na qual você emprega vários processos e técnicas.
  2. É utilizado para desenvolver e manter produtos complexos (um software é sempre algo complexo).
  3. É leve, pois não é um framework extenso.
  4. É simples de entender.
  5. Difícil de dominar, mesmo sendo simples e leve, por muitas vezes e difícil de ser implementados em certas organizações.

Continue lendo “O que é Scrum”