Combinando o melhor dos métodos ágeis e tradicionais, o gerenciamento híbrido de projetos é uma nova tendência que equilibra estrutura com flexibilidade
Nem me lembro quanto tempo se passou desde que li pela primeira vez o livro de Robert Sternberg Inteligência de Sucesso, principalmente porque o reli mais de algumas vezes e é uma das minhas cinco principais recomendações. Há muitas coisas boas nesse livro, mas uma parte que realmente me impressionou é uma seção muito pequena dedicada à pressa e como ela se relaciona com a inteligência.
O autor conduziu uma pesquisa perguntando a pessoas de todo o mundo o que elas acham que é um sinal de que alguém é inteligente. Para sua surpresa, os americanos responderam com palavras como “rápido”, “rápido” e “rápido”, enquanto os europeus optaram por palavras como “contemplativo”, “perspicaz” ou “criativo”. Ele prossegue argumentando que na vida tendemos a testar as pessoas quanto à rapidez com que conseguem fazer o seu trabalho ou resolver um problema, mas raramente medimos a contemplação, a perspicácia ou a sabedoria.
Existem poucas palavras mais adequadas para descrever TI do que “rápido”. Gerentes de projeto e desenvolvedores escrevem código em uma velocidade vertiginosa, tentando lançar seus produtos o mais rápido possível. Está tão arraigado em nossa cultura que até temos conceitos para as consequências de um desenvolvimento precipitado (dívida técnica, alguém?).
Infelizmente, essa é a natureza da besta. Ninguém gostou noites inteiras e cronogramas indutores de estresse, mas os desenvolvedores não são líderes, somos caçadores, perseguimos um mercado que se move muito rápido e perseguimos tecnologias que crescem e mudam a cada minuto. Ou você corre ou fica para trás.
Equipes ágeis: uma vacina ou um curativo?
Durante muito tempo, o desenvolvimento seguiu a tendência dos métodos tradicionais, mais especificamente, o modelo em cascata. Todos nós sabemos os passos de cor: Requisitos, Projetar, Implementar, Verificar, Manter. E também estamos bem cientes dos riscos e problemas que acompanham o modelo.
Do lado do desenvolvedor, a cascata exige uma estrutura de benchmark de trabalho (EAP), que significa “não dê um passo sem um plano”. Isso pode levar a longos atrasos e ao que gosto de chamar de “esta reunião poderia ter sido uma síndrome por e-mail”, em que as equipes passam mais tempo discutindo sobre uma mudança do que realmente implementando-a.
No lado do cliente, o cascata é como uma caixa preta: você dá um conjunto de instruções, recebe alguns telefonemas a cada duas semanas informando que as coisas estão acontecendo e, finalmente, quando chega a hora de implementar, você recebe um produto que pode ou não ser o que você tinha em mente.
Em ambos os casos, a rigidez é o principal problema. Sob este paradigma, a estrutura é importante para o processo de desenvolvimento, mas também pode ser uma camisa de força. Os modelos lineares funcionavam na década de 70 porque os mercados eram mais lentos naquela época (você literalmente tinha que viajar até o escritório do cliente com fitas ou disquetes nas mãos).
Em contraste, a velocidade do século 21 exige algo diferente, e é por isso que tantos desenvolvedores adotaram o paradigma da equipe ágil, como um pequeno grupo de pessoas altamente independentes com um amplo conjunto de habilidades e uma estrutura básica, além de um desenvolvimento iterativo. processo.
O lema do Agile é “falhar rápido”, implantar o mais rápido possível e esperar que seu projeto falhe espetacularmente para que você possa corrigi-lo. Parece desleixado, mas é tudo menos isso. O paradigma apenas pressupõe que A. a implantação rápida é uma necessidade dos tempos e B. todo software falhará inevitavelmente, mas um pequeno problema é mais rápido de resolver do que aquele que pode passar despercebido até a implantação completa.
Os clientes estão mais envolvidos no desenvolvimento ágil, testando constantemente o software e dando feedback à medida que experimentam diferentes construções. De certa forma, eles são participantes ativos do processo. Isso se o cliente tiver tempo para trabalhar lado a lado com a equipe ágil.
É claro que o ágil também tem seu quinhão de problemas. Sem uma estrutura clara, você abre a porta para aumento de escopo e mudanças no backlog. Além disso, se o cliente não tiver um objetivo claro em mente, o feedback constante e revisado pode acabar atrapalhando o projeto.
Talvez, o mais importante, o ágil não seja bom em escalar – é a melhor teoria do caos. Funciona perfeitamente quando há poucas variáveis, mas à medida que o projeto aumenta de tamanho, as chances de as coisas saírem do controle aumentam até chegar a um ponto sem retorno. É por isso que as equipes ágeis nem sempre são a melhor escolha para uma equipe de desenvolvimento dedicada.
Saiba mais sobre Equipes Dedicadas para Desenvolvimento de Software
Contate-nos
Equipes Híbridas, a Terceira Via
Aristóteles, um dos maiores filósofos gregos, propôs que a virtude é o meio entre dois extremos. Como encontrar o equilíbrio certo entre duas forças opostas. O mesmo ocorre com o gerenciamento de projetos híbrido, um meio-termo entre a estrutura do modelo em cascata e a frouxidão do modelo ágil. Voltando ao meu argumento original, você pode ser rápido e também contemplativo, resultando em um desenvolvimento mais “inteligente”.
Vamos fazer um rápido resumo das funções:
- As equipes híbridas têm gestor de projeto que também atua como gerente de produto. Eles pesquisam o cliente, configuram uma EAP e atribuem funções gerais às equipes. Em contraste com o método em cascata, o PM não é um gestor no sentido tradicional, a tomada de decisões não precisa passar por eles, a menos que isso mude radicalmente a EAP.
- Como o gerente do projeto está lidando com o front-end do projeto, outros membros da equipe recebem a função de Mestres Scrumliderando o desenvolvimento durante os sprints, eles gerenciam o back-end enquanto o gerente do projeto permanece em contato com o cliente.
O processo de desenvolvimento é mais ou menos assim:
- Analisar: O gerente de projeto pesquisa o cliente e cria uma lista de requisitos para o projeto.
- Plano: O PM se reúne com a equipe e cria uma EAP com um cronograma aproximado do projeto. Neste ponto, o primeiro scrum master é formalmente nomeado.
- Projeto: A fase de design começa e a primeira sessão do sprint é planejada com antecedência, estabelecendo os objetivos e as bases do processo de desenvolvimento.
- Corrida: O Scrum master assume e a codificação começa. O processo geralmente dura entre 4 e 6 semanas enquanto um produto de teste é preparado para o cliente.
- Teste: O cliente experimenta o produto e dá feedback ao PM para trazer de volta à equipe
- Corrida: Um novo Scrum master pode ser nomeado quando a segunda fase do sprint começar, incorporando o feedback do cliente. Tenha em mente que nesta fase os sprints não são mais planejados com antecedência como foi o caso do primeiro. Aqui, a equipe atua como uma equipe ágil.
- Iterar: Continue entre o sprint e o teste até chegar ao final do projeto.
Como você pode ver, a ideia por trás das equipes híbridas é criar uma estrutura forte desde o início, mantendo uma estrutura flexível e com o mínimo de burocracia possível. Claro, isso significa que uma equipe híbrida, assim como uma equipe ágil, funciona melhor quando os membros da equipe estão na mesma página. Felizmente, a fase de planejamento original ajuda a colocar todos em uma mentalidade comum.
Na melhor das hipóteses, uma equipe híbrida tem a estrutura subjacente para assumir grandes projetos com flexibilidade para se adaptar e mudar à medida que o projeto avança. Pense nisso como navegar nos velhos tempos: a WBS é a estrela polar, sempre apontando para o seu norte. Você pode seguir o caminho que quiser ou precisar (flexibilidade), desde que não perca de vista sua estrela-guia.
Existem desvantagens nas equipes híbridas? É claro que nenhum sistema é perfeito. Como uma malha entre dois paradigmas, você pode acabar enfrentando os mesmos desafios de cada um dos paradigmas-mãe. Felizmente, o método é construído especificamente para que os problemas que possam surgir de um lado possam ser compensados com os pontos fortes do outro lado.
Fonte: BairesDev
