Reflexões sobre o Agile

A medida da inteligência é
a capacidade de mudar.
Albert einstein

Prefácio


Estou introduzindo "Reflexões sobre o Agile" para a comunidade de TI ou este artigo pode ser chamado de "Agile, isso ainda é uma filosofia ou metodologia de design?"

O objetivo deste artigo é discutir com a comunidade de TI a questão do Agile que eu tinha depois de muitos anos de prática de projeto, as conclusões e o resumo que eu criei com base na análise dessa questão.

A questão em si é citada um pouco mais baixa, pois, para prosseguir, faz sentido expor alguns argumentos e conclusões.

Tópicos similares já foram levantados em Habré em vários tópicos de discussão, por isso a questão é urgente e tem seu próprio histórico.

Na minha opinião, a maioria dos artigos não dá uma resposta inequívoca à minha pergunta, portanto este artigo pode ser interessante para muitos.

Alguns artigos sobre Habr


Brevemente sobre o assunto


Para deixar um pouco claro onde o "vento sopra", observo que minha experiência no campo das TIC é de mais de 10 anos. No início de sua carreira, ele trabalhou ativamente em telecomunicações, tenho trabalhado no desenvolvimento de software relativamente recentemente, não mais que quatro anos.

Ao longo de sua carreira, ele participou de vários projetos de TI e Telecom, na função de gerente de projetos, nos últimos anos ele também foi analista de negócios e se esforçou como programador. Como resultado de uma breve mas volumosa imersão no desenvolvimento em Java, ele não adquiriu grande experiência, mas mesmo assim, em desenvolvimento independente, aprimorando as habilidades técnicas como programador júnior.

Agora, estou trabalhando ativamente na área de desenvolvimento de software como Gerente de Projetos, atuando opcionalmente como Business Analytics.

Assim, o assunto de discussão deste artigo é a prática do gerenciamento de projetos para o desenvolvimento de produtos de software, além disso, em relação ao desenvolvimento doméstico.

Compreendendo a pergunta do autor


Ao longo de sua experiência em projetos de TIC, ele criou uma regra importante: gerenciar um projeto usando a metodologia do projeto é bom, não fica claro sem uma metodologia.

Em conexão com o exposto acima, surgiu a necessidade de estudar várias metodologias de design, metodologias ITSM, vários livros de negócios sobre o tema e simplesmente livros "inteligentes" e complexos.

Dada a popularidade do PMI em geral e meu setor de telecomunicações nativo em particular, comecei a estudar com o PMBoK. Embora esse Talmud complicado não tenha sido entendido imediatamente, mais de uma vez ao ler o próximo capítulo, tive que pensar no que todos os mesmos compiladores do livro fumam. Como resultado, o corpo de conhecimento foi decomposto em átomos e adotado na íntegra. A propósito, ele nem sequer foi implementado em vários projetos com "zelo proletário", paciência e agilidade (não o PMBoK, é claro, mas suas ferramentas foram introduzidas).

Compreender o PMBoK vem com experiência.
@PM

Além deste trabalho “épico”, outras metodologias foram estudadas e estudadas, havia simplesmente autores de livros sobre gerenciamento de projetos (embora personalidades como T. Demarco, S. Berkun, S. McConnell não sejam apenas autores, mas algo mais), nem todos faz sentido, e o artigo não é sobre isso.

Para resumir, o autor do artigo sobre o assunto, tenta acompanhar as tendências mundiais, não esquece os clássicos.

Mergulho profundo no gerenciamento de projetos de software


Entediado em telecomunicações após oito anos de trabalho, e decidindo seguir em frente, ele se apressou na área de TI.

Descobriu-se que o setor de TI não quer viver em uma estrutura clara de “cachoeiras” clássicas, o GOST 34 não está na moda, a menos que, é claro, o Estado seja levado em consideração. setor. Existem outras tendências no gerenciamento de projetos no gerenciamento global de projetos.

O manifesto ágil não pôde passar. Depois de estudar vários livros e conversar com vários colegas, decidi que o Agile é, pelo menos, interessante. Mas não está totalmente claro como trabalhar com isso na Rússia, a filosofia não atinge a metodologia e, em nosso país, existe a sabedoria popular de que "o que não é proibido é permitido".

Como resumo: cheguei à conclusão de que o Agile é certamente uma coisa interessante, mas, no entanto, é mais adequado para livros de moda e pequenos projetos, mas como colocá-lo em prática não é claro.

A análise dos artigos sobre Habré, em geral, confirmou o breve resumo acima.

Após várias iterações de aprendizado do Agile a partir de livros, tive "sorte", participei de vários projetos domésticos do Agile.

Não foi nada divertido com esse Agile, e um RP com experiência no planejamento e gerenciamento de projetos do setor de telecomunicações foi simplesmente triste. Ao tentar controlar o desenvolvimento espontâneo de tais colegas, tudo se rompe completamente, e os rapazes dizem em uníssono: "Somos criativos, temos Agile, não nos preocupamos em viver / trabalhar / desenvolver". Eles não querem aprender e pensar, apenas têm Agile na cabeça.

Mas, apesar do meu ceticismo, o Agile andou pelo país, foi promovido ativamente por G. Gref e professado por vários gurus da indústria de TI ocidental e doméstica.

Mas, como a experiência pessoal demonstrou, o Agile usa tudo à sua maneira, com nossa mentalidade que acabamos de criar “Agile in Russian”.

Como resultado, a pergunta cresceu e ficou mais forte, e ninguém conseguiu responder.

Do mesmo modo, o que é esse Agile, uma pilha filosófica de idéias sobre psicologia e organização do trabalho, extravagância da razão e não um desejo de trabalhar de acordo com as regras, ou ainda está escondendo algo mais sério do ponto de vista metodológico, algo que pode ser aplicado aqui pátria, em projetos sérios, o que vale atenção?

Antes de concluir esta seção, há vários pontos que devem ser observados:

  1. Após o lançamento da 6ª edição do PMBoK em 2018, a edição do Agile se tornou ainda mais interessante (na 6ª edição, os autores incluíram casos usando o Agile).
  2. Para ler, li o livro de Lawrence Leach, "No prazo e dentro do orçamento".


Livro Lawrence Leach, "No prazo e dentro do orçamento"
Um livro interessante sobre gerenciamento de projetos usando o método "Critical Chain", o autor pode ser atribuído aos ideólogos do gerenciamento pesado. O livro de L. Lich descreve uma abordagem difícil, mas extremamente interessante, para a aplicação das teorias de E. Deming e E. Goldratt no planejamento do projeto.

Dado o conhecimento teórico e prático adquirido, aumentou a compreensão da incompletude na compreensão do Agile como metodologia para sua implementação adequada em projetos nacionais.

Fim de jogo


O PMBoK ágil ou adaptável da Mike Cohn.

Por acidente, ou como se costuma dizer, "de repente do nada", me deparei com outro livro sobre o Agile. Este é um livro de autoria de um certo Mike Cohn (Cohn Mike) intitulado “Agile. Avaliação e planejamento do projeto. ”

No começo, ele sugeriu que este é outro livro de negócios que descreve que o Agile é jovem, descolado e elegante.

Assim foi e decidiu ler o prefácio, mas já depois de ler o primeiro capítulo, tornou-se interessante quem ele era, esse Mike Cohn, e por que ele escreve essas coisas certas.

Referência Rápida Quem é Cohn Mike

Fundador da Mountain Goat Software, uma empresa de consultoria em gerenciamento de processos e projetos. Ele é especialista em ajudar as empresas a implementar uma abordagem ágil para aumentar a eficiência. Atrás de Mike, há mais de 20 anos de experiência trabalhando como gerente em organizações de vários tamanhos, de startups a empresas da Fortune 40. Ele é co-fundador da Agile Alliance e membro do conselho de administração.

Não pretendo descrever o livro na íntegra neste artigo, já que é melhor lê-lo para os próprios (aqueles que precisam), mas vou indicar o principal, o livro de Mike é um PMBoK PMI revisado, levando em consideração a filosofia do manifesto Agile.

Notarei imediatamente que Mike não escreveu outro conjunto de conhecimentos, chato e incompreensível, ele não copiou o PMBoK. Em vez disso, Mike Cohn criou um livro interessante, fácil de ler e relevante:

  • Descreveu os princípios e regras que devem estar no Agile;
  • Ferramentas descritas para planejar e avaliar o trabalho;
  • Deu uma idéia e uma gestão de desenvolvimento competente;
  • E muito mais

O livro descreve todo o ciclo de vida do projeto, concentra-se na fase de planejamento do projeto, descreve métodos e abordagens muito interessantes e sólidos para planejar e avaliar o trabalho e descreve as abordagens e ferramentas para as etapas do projeto, monitoramento e controle.

Apesar de o livro me surpreender com sua funcionalidade, aplicabilidade e maturidade metodológica, Mike também aplicou um método extremamente interessante e dificilmente descrito para mitigar os riscos de incerteza, que Lawrence Leach descreve em seu livro. Com tudo isso, Mike oferece em uma linguagem simples e compreensível como implementar e estender esse método na prática.

Para criar qualquer processo, você precisa de regras, normas e princípios, Mike os descreveu para nós.

Sumário


Na minha opinião, somos confrontados com várias questões interessantes desde 2001:

Precisamos de filosofia, metodologia Agile ou somos princípios suficientes?
Queremos desenvolver software de alta qualidade de forma eficiente e clara, ou deixaremos essa prerrogativa escolhida e continuaremos a "inventar uma bicicleta"?

O livro de Mike, na minha opinião, define as regras das quais muitos querem fugir, mas a experiência mostra que as regras ainda são necessárias.

Além do descrito acima, o livro de Mike fornece instruções metodológicas claras (embora alguém possa não gostar dessa palavra) sobre como o gerenciamento de projetos de software Agile deve ser construído.

De qualquer forma, tudo será como será conosco, mas uma coisa é clara: as regras e os princípios são necessários em tudo e estão no Agile.

Estes princípios são descritos e fixos, podem ser estudados, podem ser usados.

Para finalizar meu currículo, designarei o seguinte:

Ageli não está em crise, Agile não é um problema, Agile está trabalhando.

A única questão é se queremos estudar as regras e fazer como elas são prescritas, ou queremos continuar trabalhando como queremos.

Nunca perca uma santa curiosidade.
Albert einstein

PS

Caros leitores, que, no entanto, leem o artigo, estou muito interessado em sua opinião e comentários, além de recomendações sobre livros semelhantes, como o livro de Mike Cohn.

Source: https://habr.com/ru/post/pt460709/


All Articles