Scrum não subistitui gerenciamento de projetos
Esse assunto é de natureza polêmica. O Scrum é uma metodologia ágil focada em gerência de projetos. Na minha opinião dentre as metodologias agéis disponíveis no mercado Scrum é a mais eficiente e mais realista. Porem o que acontece é que existem vários níveis de gerenciamento começando com o planejamento diário, passando pelo gerenciamento da Sprint(Iteração) e por fim no gerenciamento do projeto.
Scrum atua no gerenciamento de tarefas, ou seja, no planejamento diário e no planejamento da Sprint. Isso por si em muitos casos não é suficiente. Em projetos de manutenção de sistemas, caso você não considere o uso do cliclo de projetos EUP, o Scrum é uma excelente opção. Em termos de desenvolvimento de sistemas pode ser uma boa opção também mas ai existem outros fatores na jogada.
O que é bom no Scrum é a questão da escalabilidade, de fato ele pode suportar o crescimento de sua equipe, através de um S.O.S ( Scrum of Scrums). Além de poder ser aplicado em projetos grandes e pequenos provendo um protocolo da comunicação e colaboração muito eficaz.
Onde os equívocos começam?
O ser humano por natureza tende a culpar qualquer coisa, inclusive outros seres humanos quando o mesmo fracassa. O mesmo acontece com ferramentas e processos, é comum que quando as coisas dão errado essas(Ferramentas,processos) são os primeiros a levar a culpa. E claro as pessoas não tem culpa nenhuma. Isso é muito errado e muito comum.
A polêmica dos Cronogramas
Muitos agilistas questionam veemente o uso de cronogramas. E dizem que eles não servem para nada e sempre estão errados. Eu particularmente tenho uma opinião agnostica sobre o assunto. Por que de fato em um projeto de software é extremamente complicado prever com precisão a data de termino de um projeto. Porem eu acho eXtremo dizer que "Cronogramas não funcionam" simplesmente por que:
Quanto maior o projeto, e não necessariamente estou falando de projetos de missão critica, mais complicado será do gerente gerenciar. Projetos maiores ou de missão crítica exigem um gerente com muita experiência e com grandes skills de gerenciamento de projetos.
O cronograma é uma excelente ferramenta, mas muitas vezes os gerentes de projeto não conseguem utilizar bem esse recurso.
A verdade sobre projetos de software
Muitos projetos de software fracassam. E eu não estou falando de projetos que utilizam ou dizem utilizar os "recursos" clássicos da engenharia de software e rup. Projetos agéis falham também e muito... Quem duvida, confira o projeto C3.
A verdade é que a aérea de desenvolvimento de software e engenharia de software é muito nova. Comparada com Engenharia e outras aéreas a aérea nem é um espermatozóide ainda. Então podemos concluir, até mesmo pelos resultados de projetos tradicionais ou agéis, que talvez nos não estamos preparados o suficiente para desempenhar a função.
Existem profissionais muito bons e outros nem tanto, mas o fato é que só com o passar de muitos anos nos vamos amadurecer e a cada vez mais entregar produtos de qualidade.
Scrum + GP
Para finalizar que Scrum não substitui gerencia de projetos, pelo contrário um ajuda o outro. Acredito que eles se completam. Mas ainda assim necessitamos de um bom GP; O fato de simplesmente ignorar cronogramas e custos e tudo mais relacionado a abordagem tradicional não vai fazer com que os problemas sumam.
Até a próxima.
Scrum atua no gerenciamento de tarefas, ou seja, no planejamento diário e no planejamento da Sprint. Isso por si em muitos casos não é suficiente. Em projetos de manutenção de sistemas, caso você não considere o uso do cliclo de projetos EUP, o Scrum é uma excelente opção. Em termos de desenvolvimento de sistemas pode ser uma boa opção também mas ai existem outros fatores na jogada.
O que é bom no Scrum é a questão da escalabilidade, de fato ele pode suportar o crescimento de sua equipe, através de um S.O.S ( Scrum of Scrums). Além de poder ser aplicado em projetos grandes e pequenos provendo um protocolo da comunicação e colaboração muito eficaz.
Onde os equívocos começam?
O ser humano por natureza tende a culpar qualquer coisa, inclusive outros seres humanos quando o mesmo fracassa. O mesmo acontece com ferramentas e processos, é comum que quando as coisas dão errado essas(Ferramentas,processos) são os primeiros a levar a culpa. E claro as pessoas não tem culpa nenhuma. Isso é muito errado e muito comum.
A polêmica dos Cronogramas
Muitos agilistas questionam veemente o uso de cronogramas. E dizem que eles não servem para nada e sempre estão errados. Eu particularmente tenho uma opinião agnostica sobre o assunto. Por que de fato em um projeto de software é extremamente complicado prever com precisão a data de termino de um projeto. Porem eu acho eXtremo dizer que "Cronogramas não funcionam" simplesmente por que:
- Muitos cronogramas falharam
- Um projeto de software é sempre diferente de outro projeto
- A predicatibilidade de se construir um software é menor do que a de se construir uma ponte ou uma casa.
- Só deus sabe o futuro
Quanto maior o projeto, e não necessariamente estou falando de projetos de missão critica, mais complicado será do gerente gerenciar. Projetos maiores ou de missão crítica exigem um gerente com muita experiência e com grandes skills de gerenciamento de projetos.
O cronograma é uma excelente ferramenta, mas muitas vezes os gerentes de projeto não conseguem utilizar bem esse recurso.
A verdade sobre projetos de software
Muitos projetos de software fracassam. E eu não estou falando de projetos que utilizam ou dizem utilizar os "recursos" clássicos da engenharia de software e rup. Projetos agéis falham também e muito... Quem duvida, confira o projeto C3.
A verdade é que a aérea de desenvolvimento de software e engenharia de software é muito nova. Comparada com Engenharia e outras aéreas a aérea nem é um espermatozóide ainda. Então podemos concluir, até mesmo pelos resultados de projetos tradicionais ou agéis, que talvez nos não estamos preparados o suficiente para desempenhar a função.
Existem profissionais muito bons e outros nem tanto, mas o fato é que só com o passar de muitos anos nos vamos amadurecer e a cada vez mais entregar produtos de qualidade.
Scrum + GP
Para finalizar que Scrum não substitui gerencia de projetos, pelo contrário um ajuda o outro. Acredito que eles se completam. Mas ainda assim necessitamos de um bom GP; O fato de simplesmente ignorar cronogramas e custos e tudo mais relacionado a abordagem tradicional não vai fazer com que os problemas sumam.
Até a próxima.
