BLOG

7 Lições de uma experiência realmente ágil

Autora: Isabela Ferreira, PMP, PSM

Analista PMO e Scrum Master do Grupo Neoenergia/Iberdrola

De acordo com Fabio Cruz: “Ser ágil é realizar um caminho apenas uma vez, ou o menor número de vezes possível. É realizar com qualidade na primeira tentativa e principalmente evitar o desperdício ao invés de pensar em fazer rápido.”

Compartilho aqui as lições aprendidas da experiência ágil publicada no último artigo: “É possível quebrar regras e permanecer ágil?”

Alerto que toda e qualquer regra quebrada do SCRUM tem suas respectivas consequências, algumas mais difíceis de serem contornadas que outras. É bom ficar claro que o SCRUM é um framework para desenvolvimento de produtos complexos e existem regras básicas que são inquebráveis para a entrega de valor com a agilidade esperada.

Vamos às 7 principais lições de uma experiência ágil que deu certo:

1. Sempre cumpra as regras “básicas” do framework que não são impactadas por fatores externos, apenas dependem do Time SCRUM para serem cumpridas:

  • Seus 5 eventos com respectivos time box: Sprint, Planejamento da Sprint, Reunião Diária, Revisão e Retrospectiva da Sprint;
  • Papéis e responsabilidades do: Scrum Master, PO (Product Owner) e Time de desenvolvimento;
  • Cumprimento dos Princípios e Valores ágeis: Comprometimento, Coragem, Foco, Transparência e Respeito;
  • Entrega de Artefatos: Backlog do Produto, Backlog da Sprint e Incremento “pronto” ao final de uma Sprint.

2. Se for imposto um prazo super curto para o projeto, tente analisar ao máximo o escopo junto com o PO (dono do produto) sempre priorizando os itens mais importantes. Tente detalhar os itens prioritários do Backlog do Produto e/ou desenhar um protótipo, assim como escolher uma ferramenta de fácil desenvolvimento antes da reunião de planejamento. No nosso caso, optamos em construir os Dashboards através da ferramenta TABLEAU que nos permitiu inclusive desenhar os protótipos na fase que antecede a Sprint;

3. Se o protótipo for aprovado pelo PO e usuários chaves, arrisque em modelar o banco de dados. A antecipação deste item foi um dos mais importantes na nossa experiência, pois para que a arquitetura fosse construída os analista de TI tiveram que entender a origem dos dados dos quatro sistemas legados. Durante a fase de construção ficou mais fácil para os desenvolvedores entenderem os requisitos necessários. O ponto negativo dessa iniciativa foi a dificuldade de decompor em partes menores de desenvolvimento o protótipo dos Dashboards, uma vez que o produto não foi construído de forma empírica e incremental;

4.      Se o projeto corresponde a construção de um novo produto ou tecnologia pouco conhecida, aloque no time um arquiteto de soluções para definir a melhor forma de construir, integrar com outros sistemas, gravar e disponibilizar os dados. Importante envolver também o time de infraestrutura para evitar futuros impedimentos;

5.      Se o time não puder trabalhar junto, tente pelo menos a participação presencial de todos na primeira reunião de planejamento. Durante os outros dias, sempre utilize uma ferramenta de comunicação (utilizamos o ZOOM) para que o time mesmo remotamente fique disponível todo o tempo de duração da Sprint para:

  • Facilitar a interação e colaboração entre os componentes do time;
  • Evitar perda de tempo em relação ao entendimento do escopo;
  • Facilitar realização dos testes durante a Sprint e não na véspera da revisão;
  • Incorporar os conceitos ágeis orientados pelo Scrum Master, neste caso principalmente o auto gerenciamento e motivação do time.

6.      Tente registrar as regras de negócio discutidas em reunião no Backlog do Produto e disponibilizar para todo o time em alguma ferramenta. No nosso caso usamos a ferramenta Smartsheet que é uma planilha colaborativa. Esta iniciativa evita retrabalhos e facilita a comunicação além de deixar registradas as regras no escopo do produto para futuras consultas;

7.      Se a quantidade de pessoas envolvidas no time ultrapassar nove, que é o limite máximo do SCRUM, minha sugestão é alocar de forma integral e dedicada um Scrum Master no projeto. Neste caso o sucesso do projeto vai depender muito da experiência ágil do Time Scrum e da habilidade, disponibilidade e experiência do Scrum Master para evitar os seguintes problemas:

  • Não cumprimento dos Time box estabelecidos, principalmente o tempo da reunião diária que fica comprometido;
  • Maior probabilidade da perda de foco e falta de transparência do time;
  • Ausência de autogerenciamento dos envolvidos. A sensação de desordem faz com que as pessoas esperem que alguém “tracione”, organize e direcione os trabalhos;

E você? Arriscaria iniciar um projeto para construção de um Dashboard integrado com 4 distintos sistemas legados, envolvendo um equipe de 12 pessoas de 5 distintos fornecedores, trabalhando remotamente, em apenas 1 mês? Ao invés de responder que é impossível, faça a seguinte pergunta: “O que eu consigo entregar de valor em apenas 1 mês para o meu cliente?”. A resposta vai depender muito da sua criatividade, capacidade de planejamento, coragem de arriscar e decisões que podem não ser as melhores práticas quando se usa metodologias ágeis.

Compartilhe nas Redes Sociais

Outros Artigos

Nuvem

CE | RN | PE | SE | BA | MG | SP - Telefone: (85) 3119.5969

Golden Technologia © 2018 - Todos os direitos reservados.
Termos de Uso | Política de Privacidade

Nunan