BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Por que Adoção de Agile falha em Algumas Organizações

Por que Adoção de Agile falha em Algumas Organizações

Favoritos

Introdução

Quantas vezes você ouviu que uma empresa que tentou adotar práticas ágeis falhou? Este artigo tenta analisar e explicar as principais razões, muitas vezes esquecidas, que fazem metodologias ágeis falharem em organizações, porque não é óbvio para a maioria de nós, e algumas estratégias para lidar com potenciais barreiras organizacionais. O público-alvo deste artigo são os gestores com responsabilidade orçamental, grupos técnicos também podem ter interesse.

Perspectiva histórica sobre Agile

Onde é que se originam práticas ágeis e por quê? Esta pergunta nos leva diretamente a grandes esforços de desenvolvimento de software em empresas no mercado software, que tem o mesmo como principal gerador de receita ou empresas que vêem o seu software personalizado como um diferencial competitivo para o seu principal negócio... Vamos chamar a empresa X. Agile não se originou de um esforço fixo de desenvolvimento em um departamento de TI na empresa Y.

Por que isso é importante?

A resposta está na forma como o esforço de desenvolvimento é visto pela empresa X e Y, financeiramente. Na empresa X, o esforço de desenvolvimento de software é visto como um investimento, de fato como o investimento primário, no futuro da empresa. Na empresa Y o esforço de desenvolvimento é uma pequena aplicação e é visto como um gasto de tempo que deve ser limitado e controlado. Na empresa X, a equipe é financiada. Na empresa Y o projeto é financiado. Leia as duas últimas frases novamente.

Com uma metodologia Ágil a empresa X terá êxito. Com uma metodologia ágil a companhia Y irá falhar.

Um esforço de desenvolvimento de software com proposta fixa destina-se a um objetivo final. Garantir o financiamento para o projeto exige que você primeiro defina, estime, levante os recurso necessários, desenvolva, teste, implemente, entregue e de suporte. Esta é a empresa Y.

Em um cenário de tempo e recursos materiais a companhia determina que tenha necessidade de uma equipe de desenvolvimento de software, pois há muitos projetos que necessitam de desenvolvimento no futuro. Uma estimativa de quanto a equipe pode trabalhar é criada para o calendário orçamental (1 ano, 2 anos), é dotada, e depois é feito o escopo do projeto e o agendamento é feito. Esta é a empresa X.

Você vê a diferença? Na empresa X, sempre haverá o desenvolvimento de software. Não há fim e a equipe é financiada com essa intenção. Assim colocando este trabalho no Backlog, priorizando, estimando e encaixando nas iterações.

Na empresa Y o esforço só pode se dar ao luxo de ser financiado por um subconjunto do período orçamental (digamos 3 meses). Depois disso, não há mais dinheiro ou a companhia não está disposta a gastar mais. Eles não querem que uma equipe de desenvolvimento a longo prazo, porque não podem pagar e, além disso, não haveria trabalho de desenvolvimento suficiente para mantê-los ocupados de qualquer maneira. Assim controles rígidos e forte gerenciamento de projetos são necessários para garantir que algo seja entregue no período de 3 meses.

Visto desta forma: financeiramente, Agile é um luxo. Ele pressupõe que você sempre terá uma equipe de software e sempre haverá trabalho de desenvolvimento. Assume-se que está equipe é financiada ano após ano, e você, como um gerente, não precisa se preocupar com o financiamento de projetos individuais. Como um gerente ágil você está principalmente preocupado com a agenda, escopo e capacidade. Os orçamentos são uma coisa anual ou bi-anual. Você deixa mais flexível ou não, dependendo da situação econômica da empresa. Os critérios de sucesso são em grande parte centrados na funcionalidade entregue ao longo do tempo.

Na empresa Y você pode ter R$ 50.000,00, para fazer o projeto em 3 meses. Orçamentar e acompanhar as despesas são pontos críticos e determinarão se o projeto será um sucesso ou não. Um gerente aqui consegue financiamento a nível de projeto em vários momentos ao longo do ciclo de capital. Você pode entregar todas as funcionalidades em tempo e custo estimados, mas isso não será visto como um projeto de sucesso. Como um gerente na empresa você está preocupado com as 3 pernas do triângulo. Sua equipe é provavelmente temporária e dotada de trabalho do contratante.Adoção de Agile nessa situação é um erro... Mesmo superficialmente. Por quê?

Estimativa

A chave reside na estimativa.

Em uma equipe ágil de software que você não estima o seu trabalho até pouco antes de começar. E você só estima, no caso do Scrum, as próximas Iterações. Então, como você sabe quanto tempo vai demorar? Você não sabe. Além disso, você realmente não se importa. Você vai continuar a oferecer a funcionalidade a cada iteração. Assim que a gestão de produtos e o QA disserem que você tem um produto bom o suficiente, ele será lançado como uma versão de produção. Você pode ter uma idéia, mas até que a equipe estime... Você realmente não sabe quanto tempo levará.

Em uma situação de oferta fixa... Sua estimativa deve realizar-se na frente. A empresa está querendo saber quanto custará para criar o aplicativo, porque eles não estão dispostos a financiá-lo para sempre. Eles querem que acabe... De preferência mais cedo! Os fundos são limitados e seu projeto, embora talvez necessário, não é visto como crucial para o futuro da empresa. O retorno do investimento (ROI) pode ser negativo. Voltando à liderança da empresa com a resposta: "Eu não sei quanto tempo vai demorar... só financie a equipe por um ano e vamos ver como ele vai a cada iteração" seria um erro que resultaria na sua provável demissão.

No segundo cenário, se eu disse a equipe, depois de garantir o financiamento e contratação deles, "Estamos usando o Scrum!": eles estimam o trabalho da próxima iteração. Eles assumem que as suas estimativas serão levadas a sério e você da tempo para eles completarem o trabalho como estimaram, independentemente de suas estimativas caberem no seu financiamento original do projeto ou não. Isso é justo. Infelizmente, isso coloca você, como o gerente, na desconfortável posição de apresentação do orçamento, desvios de cronograma e/ou corte de escopo, sendo provado que sua estimativa inicial foi imprecisa. Assim, você falhou na gestão do projeto e, portanto, "Essa coisa de Agile não funciona".

O erro foi assumir que a liderança da empresa entendeu e foi organizacionalmente comprometida com Scrum e os princípios ágeis. O simples fato de que eles estão pedindo para estimar o custo para conclusão do projeto nos diz o contrário. Se eles tivessem nos perguntado, "Qual o custo para criar uma equipe de desenvolvimento para os próximos 3 anos?" Então, sabemos que podemos aproximá-los de uma perspectiva ágil.

O Problema Real

Então, qual é o verdadeiro problema com a adoção ágil nas organizações? Ele pode ser resumido nos seguintes pontos:

  • Agile pressupõe que a empresa quer um esforço de longo prazo de desenvolvimento de software e não um projeto de curto prazo.
  • Agile é muitas vezes assumida pela liderança da empresa de ser um processo de desenvolvimento sem impacto no orçamento. Este não é o caso.
  • A equipe de desenvolvimento assumir a liderança compreende as implicações da adoção ágil ao nível orçamental.

A complexidade destes pontos não pode ser subestimada. Os desenvolvedores e equipes de desenvolvimento geralmente têm visibilidade zero do orçamento, sendo assim eles não têm conhecimento de como seus esforços ágeis estão sendo contabilizados em termos monetários. Isto é evidente em muitos artigos sobre Agile na web. Da mesma forma, a gestão é muitas vezes ignorante sobre desenvolvimento e, especificamente, sobre práticas de desenvolvimento ágil. A adoção do Agile requer educação para aliviar o conflito e incompreensão desses dois mundos.

Então quais são algumas das conseqüências de tentar de adotar as práticas ágeis em um projeto de escopo fixo... Essencialmente estabelecendo uma fachada ágil sobre um projeto Waterfall?

Story Points

Story Points são muitas vezes utilizados em equipes ágeis para determinar a complexidade do trabalho a ser feito. O número de pontos concluídos a cada iteração determina a sua velocidade (pontos por iteração) e dá a gestão uma aproximação de quanto trabalho pode ser concluído em uma determinada iteração.

Se você vem de uma loja de escopo fixo, como a empresa Y, sua pergunta imediata é: "Como isso se mensurado em horas? Como eu projeto os custos e o retorno do investimento? “Sinceramente, não. Os pontos não se destinam a isso. Novamente, o agilista está supondo que você está financiando uma equipe de desenvolvimento de software não um projeto de desenvolvimento de software.

Na empresa X, você poderia estimar as coisas por hambúrgueres ou em cigarros a cada iteração. Isso realmente não importa. Você está indo para obter o produto feito em algum ponto ( +/- funcionalidade solicitada). A única questão real é em que momento chamamos de completo e liberamos para a produção. O financiamento para a equipe não está subordinado à estimativa de esforço.

Na empresa Y o financiamento do projeto está diretamente relacionado com a estimativa de esforço. É fundamental que lidemos com isso, pois o custo é por hora. Story Points não têm qualquer significado aqui.

ScrumMaster vs. PM

"Agile acaba com a necessidade de um gerente de projeto." Já ouviu isso antes? É assustador para PMs tradicionais e involuntariamente ameaçador. No entanto, ele está correto. Se você assumir que uma equipe é financiada ano após ano, independentemente do esforço previsto, em seguida, as necessidades de organização e gestão do esforço de desenvolvimento são centradas na liderança técnica, tarefas e gestão de riscos. Cronogramas e orçamentos estão na rua. Um ScrumMaster é suficiente, preferível para começar o trabalho feito.

No entanto, se você estiver em uma situação não-ágil, como a empresa Y, práticas tradicionais de PM, em seguida, não são só válidas, mas essenciais para ter certeza que o esforço é mantido dentro do orçamento e das tolerâncias de programação. Nesta situação, o líder do esforço de desenvolvimento está recebendo a confiança para usar os preciosos recursos da empresa que não podem ser desperdiçados e precisa ter as habilidades de um CEO-Lite.

A equipe de desenvolvimento financiada muda o papel de gerente de projeto. Um projeto de escopo fixo não.

Reuniões Rápidas Diárias

Agile utiliza diariamente reuniões de pé por uma variedade de razões: motivação, minimização de riscos, estado, responsabilidade, espírito de equipe, etc. É uma boa idéia que é bem-vinda em um projeto waterfall de escopo fixo. Não há razão para essa prática não continuar a ser utilizada, mas a equipe em que o esforço de escopo fixo tem que perceber que você não está fazendo realmente agile e que há um prazo iminente. Você também pode querer avaliar o tempo necessário. As reuniões diárias devem ser curtas, mas 15 minutos por dia adicionam-se quando você tem apenas 3 meses de financiamento.

Retrospectivas de Iterações

Com equipes de software financiadas, que adotam Agile, a pergunta se algo está pronto é respondida de maneira incremental. A funcionalidade é revisada no final de cada iteração (digamos 30 dias) e avaliada quanto à prontidão para a versão de produção. Novamente, essa é uma boa idéia que poderia ainda ser utilizado em uma situação escopo fixo, mas os empresários precisam ser treinados para entender a revisão de iteração como uma minimização do risco e da responsabilidade técnica e não uma demonstração do produto terminado.

Reunião de Planejamento

A reunião de planejamento da iteração realmente faz supor que você está utilizando uma equipe ágil no cenário financiado. Isso necessita que seus custos sejam conhecidos e fixados para o ciclo orçamental e que qualquer estimativa da equipe venha sem criar confusão com o seu orçamento. Fazer planejamento de iteração em uma situação de escopo fixo quase certamente resultará em confusão, os desvios do orçamento e/ou perda de funcionalidade.

Gráficos Burn Down

Gráficos Burndown mostram os progressos de completar as funcionalidades em uma determinada iteração. Eles são uma medida de desempenho da equipe ao longo do tempo. Eles não mostram o quão perto o projeto está conclusão. Se fôssemos somar todos eles... até poderíamos ver isso, mas dado que são normalmente utilizados para o esforço de desenvolvimento de um projeto, o que nem sempre será o caso.

Em cenários de escopo fixo a questão não é geralmente quantas funcionalidades a equipe está fazendo por período. Isso realmente não importa. Eles precisam obter todas as funcionalidades feitas no prazo que o dinheiro permite.

Então, usando gráficos burndown e iterações em um projeto de escopo fixo enviam o sinal errado para a equipe e seus clientes.

Resumo

Em primeiro lugar gostaria de sugerir que tentando adotar ágil em um cenário de escopo fixo / projeto financiado a situação não é recomendada. Em vez disso, como um gerente, você deve fazer a avaliação de que a empresa pode apoiar uma prática ágil / com a equipe de desenvolvimento através do tempo. Se a empresa pode, então você deve usar Agile... Ele funciona bem. Se a empresa não pode.... Então você deve ser sábio para ficar com as práticas tradicionais de gerenciamento de projeto.

Se você determinar que sua empresa tem os recursos e a carga de trabalho para apoiar um esforço de desenvolvimento de software, mas não está usando ágil então ele se resume a convencer a liderança ágil que faz sentido para este esforço. Coloque a sua gestão da mudança e as vendas de chapéus .... você vai precisar deles.

Em segundo lugar papéis, gerente de projeto e ScrumMaster não são estáticos e títulos. Em uma empresa de um PM / SM pode ter responsabilidades orçamentais. Em outra podem não ter. Em algumas eles podem ter relatórios diretos em uma estrutura tradicional de organização. Em outras a estrutura pode ser mais matricial e o PM / SM pode não ter nenhum relatório direto. Menciono essas diferenças porque artigos sobre Agile, como toda a escrita, são escritos do ponto de vista do autor.Demasiadas vezes o que funcionou em uma situação é atribuído a um processo superior ou técnica hierárquica... quando na realidade organização e regras ajustam o processo e a técnica. Alterar as regras e a organização pode não funcionar tão bem. Contexto é frequentemente ausente no Agile vs Blogosfera Waterfall.

Finalmente, o debate ágil é muitas vezes comparado a uma guerra filosófica. Mas pela minha experiência e vantagem, a confusão é conseqüência de um grande mal-entendido. Muito freqüentemente um gerente técnico não pensou nas implicações da adopção de negócios ágeis. Da mesma forma pessoas de negócios freqüentemente interpretam mal o Agile como sendo "alguma coisa para o desenvolvimento" sem relevância à forma como eles financiam o esforço. Eu tenho tido sorte em minha carreira de atravessar a ponte de incompreensão e de ver os dois lados. Fazendo isso tive uma visão para o fundo dos pressupostos orçamentais que tantas vezes passam despercebidos como a causa para o fracasso aprovação ágil.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT