Rafael Noronha

Aqui tentarei contextualizar o cenário que envolve as experiências que me levaram a escrever esta série de posts.

Nossa equipe

O SDC conta hoje com quase cem profissionais.

Somos um time multidisciplinar e que apóia o processo de desenvolvimento de modo iterativo e incremental.

O maior patrimônio de nossa equipe é a cultura:
Não possuímos níveis hieráriquicos rígidos, não tratamos nossos profissionais como recursos, não possuímos gerentes de projetos que micro-gerenciam atividades.
Isto porque valorizamos nossos profissionais e acreditamos que eles são completamente capazes de cuidar da organização de seus projetos.

Um de nossos maiores desafios tem sido escalar esta cultura, devido ao fato da equipe vir crescendo bastante para dar vazão às demandas de nossos clientes.

Nossos serviços

O cliente

Esta série de posts é um apanhado das minhas experiências dentro do SDC.
Venho atendendo a um único cliente desde minha chegada ao SDC.
Trata-se de uma instituição financeira de grande porte.

Como eu disse no post de inauguração da série, grandes corporações estruturaram-se de modo que área de negócios e área de TI se conflitem, baseando seu relacionamento em um processo rígido e burocrático.

Agile na Cascata?

A motivação para compartilhar a experiência de minha equipe vem do fato de atuarmos em um cenário ainda um tanto quanto estranho para os partidários da Agilidade.

Nós reconhecemos a dificuldade de implantar Agile no cenário de outsourcing, (des)amparados pelo modelo de fábrica de software.
No entanto, temos tido sucesso na adaptação da cultura e práticas de agilidade a este cenário, e é sobre algumas das lições aprendidas que estarei escrevendo nesta série de posts.

Este é apenas um post rápido, para deixar registrado em meu blog a minha opinião sobre o assunto.

Se você é um gestor e utiliza o termo recurso para se referir aos membros de sua equipe, eu já sei o suficiente para dizer que você é um péssimo gestor.

Bons gestores sabem que para se alcançar objetivos de negócio é necessária a presença de profissionais talentosos e comprometidos dentro da equipe. E que encontrar estes profissionais nem sempre é uma tarefa fácil.

Bons gestores também sabem que mais importante que o trabalho gerencial é o trabalho de execução.

Uma equipe de desenvolvedores de software sem um gerente de projeto é capaz de entregar um software?

E uma equipe de gerentes de projeto sem um desenvolvedor de software?

Hoje faço parte de uma equipe altamente competente.
E percebo que formar e manter este tipo de equipe é tarefa para alguém (link para o blog do meu atual gestor) que realmente entenda de gestão de pessoas.

Se você é gestor mas não entende do assunto, procure se reciclar um pouco.

Você não precisa fazer um estudo científico para modelar um software (ao menos na maioria dos casos).
E acaba sendo bobagem tentar antever todo e qualquer tipo de problema que seu software deverá atender.

Enquanto você está pensando, o concorrente já pensou, fez e entregou.
Trabalhe e entregue iterativamente, ao invés de construir um frankstein e apresentá-lo ao mundo 12 meses depois.

Realizando entregas parciais você reduz o risco de errar no escopo.

Risco que por muitas vezes nem mesmo é levado em consideração.
Mas os problemas decorrentes desta desatenção são mais comuns do que você imagina.
(Siga este link e veja o gráfico do Standish Group antes de continuar).

Por meio de entregas parciais, as idéias mais exóticas do cliente ficarão pelo caminho.
Porque a cada nova entrega ele aumentará a percepção da quantidade de valor de negócio (e portanto da importância) que estas representam.
Ou seja, a iteratividade ajuda a elucidar qual o próximo passo, aquilo que de fato precisa ser incorporado ao produto.

Me parece óbvio dizer, portanto, que ser iterativo fatalmente resultará em aumento de assertividade, e talvez em redução de desperdício (e custos).

Em pararelo aos ganhos comerciais que a iteratividade pode trazer, existem também benefícios técnicos.

Para realizar entregas parciais, sua equipe trabalhará em features.
Eles se comprometem a entregar uma feature em determinado prazo, direcionando a este trabalho o seu foco.
Através do trabalho em conjunto os problemas vão sendo resolvidos. Em alguns casos, um a um.

O benefício técnico decorre do alinhamento de foco da equipe.
Poucos problemas serão desapercebidos, e todas as expectativas serão colocadas em discussão.
O que gera aumento de percepção de negócio e apropriação conjunta de conhecimentos dentro da equipe.
Refletindo diretamente na qualidade do código escrito pelos desenvolvedores.

Falando em qualidade de código, ela gera ótimos resultados comerciais, também.
Mas escrever sobre isto fica para uma outra oportunidade.

Concluindo.

Trabalhar iterativamente pode aumentar o envolvimento da equipe com o projeto.
Gerando também aumentos de apropriação do produto e de qualidade e efetividade dos trabalhos realizados.

Entregas iterativas aumentam as chances de atender as expectativas do cliente.
Se eu te peço um produto hoje e você me entrega daqui um ano, por que diabos você tem tanta certeza de que eu ainda quero exatamente o mesmo produto?
(Se é que você entendeu perfeitamente aquilo que eu pedi).

Ah, eu já ia me esquecendo.
Acabei de vender para você idéias ágeis, completamente contidas em um negócio chamado Scrum.

Mas seria um equívoco pedir para você adotar Scrum, sem te explicar, sem maiores cerimônas, o que é Scrum.

Você nem mesmo precisa chamá-lo de Scrum.

O que Scrum sugere para testes de software?

Não foi a primeira e nem será a última vez que vi pessoas perguntarem o que Scrum recomenda para determinada atividade de engenharia de Software.
Scrum não sugere nada, ponto.

Scrum é falho

Não, isto não faz de Scrum um processo falho.

Scrum não se propõe a resolver problemas de engenharia de software.
Scrum não te dirá como construir software seguindo as melhores técnicas de desenvolvimento.

E não há problema algum com isso.

Os benefícios que Scrum se propõe a oferecer são organizacionais, e não técnicos.
São estes benefícios que devemos buscar com Scrum.

Descentralização de tomada de decisão, auto-gerência, aumento de comunicação, transparência e comprometimento, entre outros.

Mas Então(…)

Não é porque Scrum não recomenda nenhuma prática de engenharia que devemos abrir mão delas.
Scrum não é uma receita de bolo para se entregar um projeto de software.

Uma metodologia que determina práticas de engenharia combina muito bem com Scrum: Extreme Programming, sendo isto reconhecido formalmente:

Scrum is a framework. XP engineering practices can be used within a Scrum Sprint to improve quality and productivity.

Ken Schwaber

Portanto, lembre-se que assim como um carro não foi feito para voar, Scrum não foi feito para resolver problemas de engenharia de software.
(Ainda que as práticas de Scrum ajudem a CONDUZIR a resolução de problemas técnicos).

Isoladamente, nenhuma prática será suficiente para te guiar ao sucesso.

Me desculpe, vou me fazer repetir:
Scrum não é uma receita de bolo para se entregar um projeto de software.

Concluí nesta sexta-feira o curso CSM (Certified Scrum Master), do qual participaram alguns colegas do grupo .Net Architects, entre outras pessoas.
Comecei a olhar para o Scrum há pouco tempo, mas o suficiente para conquistar o meu interesse.

Ministrado na Caelum pelo Alexandre Magno da Adaptworks, presenciei no curso uma experiência fantástica.

Passo a considerar o treinamento obrigatório para  aqueles que realmente apostam na filosofia que está por trás de Scrum, mas ainda não puderam marcar presença.

Digo filosofia pois Scrum não é apenas pregar post-its numa parede, fazer reuniões diárias e coisas do tipo. Existem diversos valores e princípios que dão profundidade às práticas recomendadas pelo Scrum.

E foi na transmissão destes valores que enxerguei uma qualidade incrível no treinamento de CSM.
Parabéns ao Alexandre por enfatizar a todos que optar por Scrum não é algo fácil, embora aparente para algumas pessoas. Demonstrou ainda muita capacidade e também paciência, lidando com a angústia daqueles membros da turma que precisavam de alguma maneira traçar um paralelo entre a realidade de suas experiências anteriores e a realidade que o Scrum se propõe a trazer, dentro do cenário de projetos de software.

Já ouvi críticas ao processo de certificação da Scrum Alliance, mas tenho certeza que os autores destas não se deram o trabalho de estudar o assunto, muito menos tentar assimilar motivações  coerentes que possam existir por trás desta organização.

Como mencionado pelo Alexandre, o certificado CSM apenas atesta que o profissional frequentou um curso preparado pela Scrum Alliance e ministrado por uma pessoa habilitada, e que consequentemente o profissional recebe da organização a confiança para INICIAR os seus trabalhos como Scrum Master.

O que não significa que esta pessoa já passou por todos os processos necessários para atuar como um Scrum Master de sucesso.

Penso que o curso pode ser encarado como o início de um ciclo. Se você aposta em Scrum e seus valores, dê continuidade ao ciclo. Aprofunde o seu conhecimento do processo, aplique no mundo real, lute para que esta aplicabilidade se viabilize e se expanda. Estude conceitos de administração e projetos.

A minha interpretação é de que se trata de um novo olhar para o gerenciamento de projetos. Um olhar moderno, baseado em práticas consolidadas no mercado. (Você já ouviu falar de Lean e Toyotismo, certo ? ).

Um olhar que visa mais comunicação e menos papel,  mais colaboração e menos negociação, mais receptividade a mudanças e menos procura por um plano perfeito.