Experiências pessoais com ágil: 16 comentários, fotos e um vídeo sobre praticamente aplicar ágil

Eu reuni uma coleção de experiências pessoais que as pessoas colocaram em prática. Peças estruturadas são ótimas. Opiniões e como os gurus ágeis são definitivamente úteis. Mas é preciso equilibrar estudos de casos e histórias pessoais de pessoas nas trincheiras que colocam as melhores práticas em prática.

São as histórias das trincheiras que realmente ajudarão você a desenvolver suas próprias opiniões sobre o que é ágil e como aplicá-lo.

Ao reunir esta coleção de citações, comentários, imagens e resumos curtos, procuramos uma ampla variedade de experiências de todos os diferentes pontos de vista sobre o agile. A ideia aqui é dar às pessoas uma visão real de como a agilidade está sendo aplicada. Nós não estamos tentando colocar nenhum ponto de vista particular adiante.

Então, aqui vai. XXXX comenta sobre a aplicação ágil em toda a sua glória crua e em nenhuma ordem particular.

Ian Miell fornece uma visão profundamente filosófica de Agile , canalizando Sapiens

'A criação de metodologias úteis de software não é fácil. A dificuldade não está em defini-los, mas em convencer os outros a segui-lo. Grande parte da história do desenvolvimento de software gira em torno dessa questão: como convencer os engenheiros a acreditar em histórias específicas sobre a eficácia da coleta de requisitos, pontos de história, gráficos burndown ou preparação de atrasos? No entanto, quando adotado, ele dá às organizações um poder imenso, porque permite que equipes distribuídas cooperem e trabalhem em prol da entrega. Basta tentar imaginar como seria difícil criar a Microsoft, o Google ou a IBM se pudéssemos falar apenas sobre desafios técnicos específicos. '

Então sou legal com isso. Lean, Agile, Waterfall, o que quer que seja, o fato é que precisamos de algum tipo de ideologia comum para cooperar em grande número. Nenhum deles é malvado, então não é como se você estivesse escolhendo o racismo sobre o socialismo ou algo assim. Qualquer um que você escolher não vai refletir a realidade, mas se você espera a perfeição, ficará desapontado. E observe-se por ficções coletivas não pronunciadas ou não articuladas. Sua vida está cheia deles. Assim a sua opinião é importante. Não resisto a citar esta passagem de Sapiens sobre nossa relação com o trigo:

'O corpo do Homo sapiens não evoluiu para [cultivar trigo]. Foi adaptado para subir em macieiras e correr atrás de gazelas, não para limpar pedras e carregar baldes de água. Espinhas, joelhos, pescoços e arcos humanos pagavam o preço. Estudos de esqueletos antigos indicam que a transição para a agricultura provocou uma infinidade de doenças, como discos, artrite e hérnias. Além disso, as novas tarefas agrícolas exigiam tanto tempo que as pessoas eram forçadas a se estabelecer permanentemente ao lado de seus campos de trigo. Isso mudou completamente o seu modo de vida. Nós não domesticamos o trigo. Isso nos domesticou. A palavra "domesticate" vem do latim domus, que significa "casa". Quem é aquele que mora em uma casa? Não o trigo. São os sapiens.
Talvez não estejamos aqui para direcionar o código, mas o código está nos direcionando. Quem é o único que compromete a razão e a lógica para aumentar o código? Não o código. São os sapiens.

“Por que muitos desenvolvedores não gostam de agile?” No Hacker News:

Eu não vou reproduzir o tópico inteiro aqui, mas aqui estão alguns comentários dourados destacando as diferentes maneiras pelas quais as pessoas se aplicam e pensam sobre o agile.

KaiserPro diz:

O ponto principal do Agile era “pessoas não são processos”. No entanto, porque na minha empresa temos mestres profissionais, tudo deve ser religiosamente Ágil.

Isto significa que devemos ter um standup, todos os dias. devemos ter um retro, devemos ter planejamento.

quase meio dia por semana é perdido em reuniões inúteis. Eu só quero continuar meu trabalho. Confie em mim para usar o sistema de tickets para descobrir o que estou fazendo e aumentar os problemas de bloqueio .

zzalpha em resposta ao KaiserPro:

Isto significa que devemos ter um standup, todos os dias. devemos ter um retro, devemos ter planejamento.

Cada um desses ritutuals tem valor.

Só porque você está feliz codificando em silêncio, sozinho, em uma sala escura com a porta fechada, não significa que todo mundo está.

Ainda estou para ver uma loja ágil que não se beneficia de stand-up para manter a equipe coordenada e em pista. E o retrospecto é o fórum para autogerenciamento e refinamento / iteração de processos.

Além disso, alguns desses rituais (como o planejamento de sprint) também são necessários para os interessados, além dos próprios desenvolvedores, a fim de realizar seus trabalhos. Porque, acredite ou não, os codificadores não são de fato o centro do universo.

quase meio dia por semana é perdido em reuniões inúteis. Eu só quero continuar meu trabalho.

Woah, espere, wut? 90% do seu tempo aparentemente é gasto em codificação e isso é um problema para você? Você sabe, em algum momento isso começa a soar muito como um senso excessivo de direito …

eldavido diz:

Eu sou um gerente de desenvolvimento. Usamos ágil, funciona para nós e as pessoas são felizes.
Tudo o que você precisa fazer é fazer uma lista gigante de todas as coisas para fazer, certificar-se de que as pessoas estão trabalhando o suficiente, e as coisas certas, e usar o nível apropriado de design – às vezes um pouco, às vezes mais.

Eu acho que a coisa mais difícil é fazer com que as partes interessadas em negócios saiam da mentalidade de “projeto fixo”, no entanto: aqui está o que queremos, e quanto dinheiro temos, quanto tempo levará / quanto custará? Quando a questão real deve ser, o que devemos fazer primeiro, dado o orçamento que temos, que mais ajudará o negócio?

Além disso, devs devem ser tratados como adultos. Sem “planejamento de pôquer”, levantamentos diários forçados ou qualquer bobagem. Mantenha suas histórias atualizadas no sistema de acompanhamento de problemas, entregue de maneira iterativa e continue enviando.

Muito do que é atribuído à agilidade parece uma má política organizacional / má gestão das partes interessadas.

IanDrake diz:

Eu acho que muitos comentaristas aqui estão perdendo o ponto que está sendo feito no conto.
Agile é bom para startups construindo um produto onde eles já não têm um produto / mercado conhecido. É compreensível nessa situação.

Um cliente meu usa para desabafar com design inicial para um sistema de terceira geração que é bem conhecido e pode ser facilmente construído com cascata. Houve (o que eu chamaria) dois falsos começos já. Não vejo por que a agilidade é benéfica nessa situação.

Dave Thomas faz uma palestra intitulada “Agile is Dead”

David Thomas, um dos criadores originais do Manifesto Ágil, faz uma palestra intitulada “Agile is Dead”. Ele faz um ponto-chave "Agile foi cooptado em algo que nunca foi feito para ser".

Infográfico da Toggl sobre metodologias ágeis e outras

De um Pergunte-me qualquer coisa com o autor ágil James Shore

Um comentarista, Joehunk , que trabalha em um sistema de código de ~ 5m diz:

Você mencionou algo que despertou meu interesse: “você precisa ser capaz de executar seus testes…” (ênfase sua). Temos um grande desafio em definir quais testes são “seus” testes para qualquer componente ou recurso, porque uma parte significativa de nosso conjunto de testes são testes de integração que cobrem grandes partes do sistema.

Este tem sido o nosso principal desafio: para um produto tão grande, como podemos equilibrar a alavancagem que você obtém dos testes unitários com a necessidade de também ter confiança de que todo o produto integrado está em bom estado? Você tem alguma experiência com / exemplos de produtos em que uma abordagem dupla teve de ser tomada quando os testes de unidade permitem que os desenvolvedores testem componentes individuais rapidamente, mas os testes do sistema garantem a funcionalidade do produto integrado?

Há uma resposta interessante do jaybazuzi :

No início, a ideia de passar de testes integrados (que são lentos, quebradiços e difíceis de diagnosticar) para grandes testes de unidade (que são rápidos, confiáveis ??e apontam para o problema imediatamente) tem algumas limitações óbvias.

Claro, eu posso escrever um teste unitário para cada peça isoladamente, especialmente se eu introduzir os simuladores para separar os componentes durante o teste. Os testes resultantes serão mais rápidos (eles executam menos código), eles serão mais confiáveis ??(alterar o componente A não precisa interromper os testes para o componente B), e eles serão mais fáceis de diagnosticar (testes com falha para X indicam problema no X, e em nenhum outro lugar).

Mas eu não vou ter o mesmo tipo de confiança que meu sistema está correto, como consegui com testes integrados. Eu posso saber que A passa nos testes de A e B passa nos testes de B, mas eu não sei se A & B concorda plenamente com o contrato deles. (Para colocar de outra forma, se eu testar A contra uma simulação de B, não sei se a BMock tem fidelidade com B).

Isso parece um problema difícil de teste. Mas no TDD, a resposta não é "trabalhar mais no teste". É "refatorar para facilitar o teste".

Comentários perspicazes mais tarde no tópico do aaronbjork :

Acho que a chave é encontrar maneiras de permitir que suas equipes façam o que sabem ser necessário … mas ainda permanecem "conectadas" como uma organização. Não se trata de atualizações de status e condução de gráficos burndown. É sobre ter conversas reais sobre atrasos. A maioria das pessoas que vejo lutando com escalabilidade ágil está tentando "gerenciar" equipes ágeis. É aí que eles estão errando. Deixe que suas equipes gerenciem a si mesmas e, em seguida, concentre suas conversas com elas em torno do que vem a seguir e por que isso é importante.

De cory_foy ao encontro de datas fixas:

Há um ditado que você não pode ter datas fixas em "Agile" – mas isso é uma falácia. O objetivo é começar com o mínimo que atenda às suas necessidades, e então construir a partir daí, constantemente revisando com software funcional.

Além disso, para cumprir a data, você ainda precisará de uma colaboração próxima, inspeção frequente e alta visibilidade – todas as características de projetos com boa agilidade. Temos projetos para os anúncios do Super Bowl, bem como outras datas de marketing sérias – e nunca tivemos problemas para conhecê-los devido aos princípios de agilidade.

Agora, algo como “Scrum” se encaixa no que você está fazendo? Talvez – isso depende de como você está quebrando seu trabalho. Kanban pode ser um ajuste melhor se você não estiver dividindo as coisas em partes distintas de uma semana. Mas, independentemente da metodologia, há coisas boas que valem a pena investigar.

Processo ágil de desenvolvimento de software: 90 meses de evolução

Michael Dubakov, fundador do processo de segmentação de empresas de software, escreveu um artigo detalhando sua evolução com agilidade. É um relato detalhado de como a agilidade evoluiu na empresa ao longo do tempo.

O post é definitivamente vale a pena ler, mas aqui estão as principais conclusões:

  • Eles naturalmente mudaram de iterações para Kanban
  • Eles substituíram os Product Owners por uma placa de produto.
  • Eles tinham estimativas, livraram-se de estimativas, depois compraram estimativas de volta
  • Eles encontraram histórias de usuários menores
  • Eles abandonaram o TDD e parearam a programação ao longo do tempo.

Como você faz sessões de planejamento de sprint menos pintadas?

De bongunk :

Você não deve fazer estimativas durante sessões de planejamento de sprint!

A estimativa é um dos elementos de um backep de DEEP. DEEP significa Detailed Enough, Estimated e Prioritized. Detalhe vem dos analistas, estimativas de toda a equipe e prioridade do PO.

Portanto, você deve fazer suas estimativas durante as sessões de refinamento / preparação de backlog. Onde você estima alta prioridade (próximos 3 sprints) itens que são detalhados o suficiente para serem estimados.

Apenas as questões que são DEEP devem ser levadas para a reunião de planejamento de sprint pelo PO. É responsabilidade do PO obter o backlog nesse estado DEEP (obviamente com a ajuda de analistas e da equipe). O planejamento de sprint com um backlog que não é refinado é um processo incrivelmente frustrante.

Um dos maiores problemas que vejo com as novas equipes é subestimar a importância de um backlog adequadamente preparado. É absolutamente essencial ter sucesso com o scrum e precisa de um tempo adequado dedicado a entrar em forma.

Eu gastaria pelo menos 4 horas de um sprint de 2 semanas fazendo grooming backlog. Eu achei melhor dividir em sessões de 4 x 1 hora, senão fica cansativo.

Minha opinião depois de um ano de experiência scrum

Tirando algumas peças de Jan de Boer :

Minha opinião depois de um ano ou experiência de scrum não é positiva. Scrum é quase como uma religião com regras sagradas. Scrum para mim parece barulhento. Scrum aqui é um argumento de vendas de marketing para a alta gerência.
Outra coisa que eu não gosto é sempre dividir as coisas nas histórias que se encaixam no sprint.
Às vezes eu gosto de trabalhar um pouco mais sobre o assunto em que estou. Mas eu não posso fazer isso. Por quê? Não é scrum. E scrum é sagrado.

Por que Agile e especialmente Scrum são terríveis

Aqui está um trecho do post de Michael O'Church sobre ágil :

O problema com as iterações (ou “sprints”) de duas semanas do Agile e as histórias de usuários é que não há estratégia de saída. Não há nenhuma cláusula do tipo "Não teremos que fazer isso uma vez que alcançarmos [X]". Ele foi projetado para estar lá para sempre: as reuniões de engenharia e status voltadas para os negócios nunca irão embora. Arquitetura e P & D e desenvolvimento de produtos não fazem parte do trabalho do programador, porque essas coisas não se encaixam em “histórias de usuário” atomizadas ou sprints de duas semanas.

Como resultado, os tipos de projetos que os programadores desejam assumir, uma vez dominados os princípios básicos da arte, são frequentemente ignorados, porque é irritante justificá-los em termos de valor de negócios de curto prazo. A excelência técnica é importante, mas é doloroso tentar vender pessoas a esse fato, se elas não quiserem ser convencidas disso.

Certa vez, trabalhei em uma empresa na qual um gerente de produto dizia que a diferença entre um engenheiro sênior e um engenheiro júnior era a capacidade de fornecer estimativas precisas. Não. Isso é insultuoso, na verdade. Eu odeio estimativas, porque elas geram política e não fazem o trabalho ser feito mais rápido ou melhor (na verdade, é geralmente o oposto).

A pior coisa das estimativas é que elas levam a empresa na direção de um trabalho que é estimável. Isso faz com que os programadores favoreçam o material fácil e de baixo rendimento que a empresa realmente não precisa (mesmo que os gerentes intermediários pensem o contrário), mas isso é “seguro”. Qualquer coisa que valha a pena ser feita tem uma chance diferente de zero de falha e muitas incógnitas desconhecidas para que as estimativas sejam úteis. O foco da Agile no valor de negócios de curto prazo acaba empurrando as pessoas para longe dos tipos de trabalho que a empresa realmente precisa, em favor do gerenciamento de reputação em tempo real de cada programador.

Um pôster desmotivador e atrevido sobre o Scaled Agile

Texto original em inglês.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *