Bom, estava pensando ontem durante o curso de certificação de
Scrum, o maior problema da falha na construção de
SW são as pessoas e não a metodologia em
sí.
Pensem da seguinte forma:
Cascata, todos sabem que esse tipo de
projeto não dá muito certo, ainda mais no esquema de escopo fechado, isso porque em todo o ciclo de vida do
projeto as prioridades, os requisitos e o conhecimento seja ele por parte do fornecedor ou do cliente mudam, melhoram e o sistema tende a mudar.
Vendo as metodologias ágeis (Não estou apenas falando de
SCRUM, não importa se é
Scrum, XP,
FDD,
Crystal e etc...), quando falo metodologias ágeis quero dizer o Manifesto Ágil em si.
O que nos diz o manifesto ágil?
- 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.
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Fonte: Improve IT
Sinceramente vejo que muitas empresas, seja elas de pequeno, médio e grande porte dão muito mais valor as ferramentas e processos do que as pessoas.
Tanto que normalmente quem trabalha (principalmente em fábrica) é um "recurso", um
Code Monkey que pode ser descartado a qualquer momento e substituído por outro.
E isso é um erro, pessoas são importantes, quando você deixa de motivar as pessoas de sua equipe elas tendem a sair, ou seja, não é só dinheiro que tira um cara bom do
projeto e sim o ambiente no qual ele está instalado (Não estou dizendo nada sobre trabalhar de graça, dinheiro não importa e etc), se o cara é motivado de qualquer forma, ele sente que tem participação e
importancia naquele determinado
projeto o funcionário tende a estar mais motivado, produzir mais, estudar mais, porém, se a cultura da empresa preza que o cara é apenas um "recurso humano" e deixa ele meio que de canto (típico: "Vai fazendo aí"), o cara deixa a produção quase no zero, não quer saber de nada e
provávelmente se ver outra oportunidade ele vai embora da empresa, isso é fato.
Nesses meus 5 ano de experiência tive diversos gerentes de
projetos, daqueles mais arrogantes aos mais humildes, pessoas que trabalharia de novo e pessoas que nunca mais gostaria de ver na vida, pensando porque grande parte dos gerentes de
projetos tendem a ficar assim:
1 - O gerente normalmente tem pouca ou nenhuma experiência e está sozinho;
2 - Comando-Controle, ele quer controlar tudo que alguém vai fazer;
3 - Status, o gerente está no topo da cadeia e todo mundo abaixo é serviçal.
E o que as metodologias ágeis vão me ajudar em uma cultura assim?
Provavelmente se ninguém mudar, não vai ajudar nada, na verdade a forma de melhorar um ambiente assim é começar mudando a forma como as pessoas pensam, isto é, o Cliente tem que estar 100% envolvido no
projeto (não tem desculpas do tipo,
ahhh ele está acostumado a fazer o levantamento junto ao analista de requisito e depois ele vai embora e só volta depois de 1 ano para ver o que aconteceu), a equipe não pode ficar tendo conflitos internos como acontece no modelo Cascata, como assim? vou mostrar o modelo cascata e dizer como ocorre esses conflitos:
Você tem a fase de Requisitos do sistema, requisitos de
SW,
design, Programação, Testes e Manutenção.
Normalmente o Analista de Requisitos de
SW não gosta do Analista de Requisitos do Sistema porque ele faz a análise "Errada", o
Design não gosta do Analista de Requisito de
SW porque não era "necessário" para montar as telas do Sistema, o Programador não gosta do
Design porque as telas são complexas e coloridas, o programador também odeia os
Testers porque eles acham falhas, os
Testers detestam os programadores porque não fazem certo e TODOS odeiam o Cliente que é o cara que está pagando.
Este exemplo eu vi com o
Alexandre Magno e é a mais pura verdade, todos estão separados, assim que chega para o programador é como se a parte acima estivesse pronta e o
projeto "terminado" e não é bem assim.
As metodologias ágeis forçam as pessoas a cooperar, o "
Status" (Entendam
Status como: Gerente, Coordenador,
Arquiteto e etc) morre, o que existe é o
Time, o
time é responsável por fazer aqui andar, o
time tem responsabilidades e o principal não é uma pessoa que vai ser cobrada, é o
time todo, a
idéia de individualidade deve desaparecer, o
ScrumMaster não é
necessáriamente um cara
tecnico ou um Gerente de
Projetos, o
ScrumMaster é um cara que vai facilitar a vida do
time e forçar que o
time cumpra o que o
Scrum diz, o Cliente tem que estar envolvido, seja de forma
direta como de corpo presente, seja por um representante, o Cliente ou a pessoa que irá representá-lo no caso do
Scrum em particular é o
Product Owner (
PO), o
ScrumMaster não é o cara que a todo momento sozinho conversa com o
PO, o
time participa, o
time faz as reuniões junto e o
time aprende a ser auto-organizado, ou seja, o
time se sente parte do
projeto, o
time evolui e o
time sabe se organizar.
Muitas pessoas afirmam que isso não funciona, o famoso: "No meu
projeto não se aplica", isso porque "dói" você mexer na zona de conforto, "dói" dizer que você não tem mais um poder soberano e só você manda, "dói" dizer que o
time também decide o que vai dar para entrar em um
Sprint ou não e principalmente "dói" mostrar ao cliente que ele não vai poder mexer em um
Sprint em andamento, que pode cancelar um
Sprint, se e somente se, o
Sprint estiver comprometido com a mudança, ou seja, sair da zona de conforto é algo que dói e o pessoal acha
comodo trabalhar em um modelo que o cliente não muda requisito porque tem uma multa gigante caso ele o faça, coloca uma gordura enorme no ciclo de desenvolvimento e o
time além de desmotivado, transforma o
projeto em um laboratório de pesquisa (Ou seja, testa tudo que há de novo no mundo da tecnologia que ele utiliza, mesmo que seja
ultra-
alpha 0.1.1_01) e muitos acabam como o próprio Alexandre diz, na famosa
Síndrome do Estudante, vai deixando pra depois porque o tempo é grande e na última semana vara a madrugada fazendo porque foi deixando pra lá.
O fato é que qualquer metodologia ágil funciona SIM, desde que você
Scrum Master treine o pessoal, ensine, mostre as vantagens, para o cliente, mostre quanto ele está gastando no modelo de escopo fechado com a gordura que você vai precisar colocar, mostre para ele que não vai poder ter mudanças pois não é algo previsto, mostre que levantar um sistema todo no começo provavelmente não dará certo.
Para a equipe, mostre para eles as vantagens de ser comprometidos com o
projeto além do
PO e do
Scrum Master, mostre que eles fazem parte do corpo do
projeto e que são importantes, não mais recursos, mas membros que fazem o
projeto andar.
E
Scrum Master cuidado para nunca cair no Comando-Controle, você não manda, você mostra, você opina, você tira dúvidas com o
time e com o
PO e você FACILITA a vida do
time e não dá ordem para eles.
Mostre que o
PO e o
Time tem que estar comprometidos, que eles são toda a essência e importância do
projeto e é claro, você já sabe que no papel de
Scrum Master, você também tem que ter foco e estar comprometido.
Resumindo: Ouço muito o pessoal achando que
Agile é apenas uma
Buzz Word, uma modinha que não dará certo e que depois de um tempo você simplesmente esquece, bom, isso não é verdade, se você usa um
Scrumbut, ou seja, tudo o que você acha legal, e o que "dói" você não pratica, realmente seu
projeto e prazo vão estourar e realmente a metodologia não vai funcionar e é mesmo culpa dela? É duro sair da zona de conforto, mas os resultados serão totalmente positivos.
