Sabemos
que o framework Scrum não é a bala de prata que solucionará todos os problemas
de gestão de projeto nem tão pouco os problemas identificados nos processos de Engenharia
de Software e que nenhum dos processos ágeis descritos por seus criadores é
perfeito para as empresas. Diversos fatores, inclusive os culturais e
principalmente o nível de maturidade, deverão ser levados em consideração, como levantado no post anterior.
Taiichi Ohno, criador
do Sistema Toyota de Produção, escreveu que “há algo chamado trabalho padrão,
mas padrões devem ser alterados constantemente. Se você considera o padrão como
melhor que pode fazer, não há avanço”. E ainda afirma que se estabelecemos algo
como “melhor maneira possível, a motivação do Kaizen [melhoria contínua
incremental] deixará de existir” (1982).
Antes
da implantação do framework Scrum, realizei a analise das instalações da
fábrica, a infraestrutura tecnológica, os processos praticados na empresa, a
estrutura organizacional, o modelo organizacional, o sistema de gestão, a
existência de planos de capacitação, a garantia da qualidade dos produtos e o
nível de maturidade com base nas certificações existentes.
A
revisão das áreas que compõem a Fábrica de Software teve como objetivo a identificação
do nível de maturidade, fornecendo subsidio para avaliação da possibilidade da
institucionalização e prática do framework Scrum, como metodologia padrão de
gestão, para projetos de pequeno, médio e grande porte.
Segundo
Mike Cohn, "qualquer um deles (processo ágil) pode ser um bom ponto de
partida, mas você terá que adaptar o processo para que ele se ajuste mais
precisamente as circunstâncias exclusivas de sua empresa, as pessoas e o
segmento da indústria. (2011, 28)
A
implantação do novo modelo reduziria o risco no projeto, aumentaria o controle
de versionamento, o controle de mudanças, aliás, bem-vindo à metodologia,
viabilizaria as entregas de releases funcionais em curto espaço de tempo, e estes
benefícios seriam garantidos pelos três valores praticados no framework Scrum:
- Transparência
- Inspeção
- Adaptação
Alistair Cockburn
concorda com a afirmação acima: "Ter a chance de mudar ou adaptar um
processo para aumentar sua conformidade parece ser um fator crucial de sucesso
para a equipe que está adotando. É o ato de criação que parece aderir às
equipes ao seu próprio processo".
Durante
o trabalho de análise, pude identificar que ao longo dos anos em que a empresa
atua no mercado, sempre sofreu com as constantes reclamações dos clientes, relacionada
aos atrasos nas entregas dos sistemas, por falhas no entendimento do domínio do
negócio, participação incipiente dos gestores do projeto e baixa qualidade
tanto no produto quanto na documentação gerada para o usuário final.
Após identificar essas pequenas fraquezas, no
entanto, ainda ficamos com o problema de como eliminá-las. É difícil (e com
frequência impossível) prever exatamente como as pessoas responderão às várias
pequenas mudanças que serão necessárias no percurso de se tornar ágil.
Não é possível direcionar um sistema vivo, só perturbá-lo e
esperar para ver a resposta... Não temos como conhecer todas as forças que
moldam a empresa que queremos mudar, portanto, só podemos provocar o sistema de
alguma forma fazendo testes com uma força a qual achemos que possa ter algum
impacto e, em seguida, observar para ver o que acontece.
O
processo de implantação do framework Scrum passou por várias fases, gerando uma
dinâmica diferente na empresa. Dentre elas podemos destacar a fase de seleção dos
recursos que mais se identificavam com a metodologia e que após a implantação
do framework participaram dos primeiros projetos fazendo uso do Scrum,
o que culminou na implantação do novo modelo de gestão em todos os projetos.
Grande Abraço,
Gilberto Ribeiro.
Nenhum comentário :
Postar um comentário