Verdades inconvenientes sobre agilidade

O desenvolvimento ágil vem ganhando força nos últimos anos, tornando-se uma febre. Papéis como Scrum Master, estão cada vez mais recorrentes nos currículos de profissionais de TI, muitas vezes, em tentativas oportunistas de aproveitar a febre do momento. Isso não é errado, mas tem um lado muito ruim, o da não compreensão do que é agilidade. Eu, particularmente não gosto de usar o termo agilidade, pois pra mim, só existe um meio de se desenvolver software, e é com desenvolvimento ágil. Mas algumas vezes, é necessário “dar nome aos bois”.

Disclaimer

Esse post não reflete a opinião do Tá Safo e é de total responsabilidade do autor  😛

Scrum não é ágil

Scrum não é metodologia ágil. Scrum é um processo para gestão e controle. Não é a toa que gerentes adoram. E como todo framework que se preze, possui alguns padrões embutidos em si. Ele implementa alguns conceitos ágeis, mas não é porque possui um processo interativo, que será ágil.

Não sou contra o Scrum. Na verdade acho uma ferramenta fantástica para equipes que estão começando no desenvolvimento ágil. E, uma evolução disso seria abandonar o Scrum à medida que a equipe evolui. Equipes mais experientes em agilidade não irão tolerar o Scrum por muito tempo. É preferível seguir os princípios e valores ágeis do que um processo by the book.

Também não curto papéis como Scrum Master e Product Owner. Se existe a grande necessidade de um Scrum Master, talvez a gestão da empresa não seja tão boa, pois é necessário um papel para proteger o time da burocracia. O PO é um papel, que sinceramente não sei pra que serve. O stakeholder é mais importante, pois é este quem define o que valor ou não. O que ocorre é que, muitas vezes, o stakeholder está ausente. Agilidade é sobre valor. Se não existe stakeholder, não existe valor, logo não existe agilidade.

Não existe agilidade sem testes automatizados

A verdade é dura. A verdade é única. O sistema é binário. Zero ou um. Vivo ou morto. Agilidade é sobre proporcionar feedbacks rápidos. Não é possível fazer isso sem uma boa cobertura de testes automatizados. Novamente: automatizados. De novo: automatizados. E ainda não estou falando de TDD (que por sinal, esse sim, é um método ágil). Estou falando de receber feedbacks rápidos sobre mudanças efetuadas no código.

Alguém pode dizer: posso proporcionar isso sem testes automatizados. Sou foda. Talvez, com uma base de código pequena e simples, seja possível. Mas lembrem-se que software é um sistema vivo (de acordo com o dogma máximo da ciência moderna, a teoria da evolução), ele muda e evolui com o tempo. A tendência é que ele se torne complexo. A não ser que ele só possua CRUDs, nesse caso nem é necessário um desenvolvedor.

Em 1981, Barry Boehm, em seu livro Software Engineering Economics, sugeriu que o custo de mudanças em um projeto de software cresce exponencialmente durante o desenvolvimento. Logo, seria melhor fazer a maioria das alterações necessárias logo no começo de um projeto, que seriam as fases de levantamento de requisitos e análise. Isso é método tradicional, conhecido como cascata.

O Extreme Programming nos dá outra alternativa. Podemos manter esse custo baixo e constante durante o ciclo de vida do software. Esse é um dos grandes benefícios do TDD. Ele nos proporciona um bom design e de cara nos dá uma cobertura de testes automatizados. Ganhamos uma facilidade na compreensão do código, segurança para modificá-lo e uma documentação executável. Não quero mais nada na minha vida.

A agilidade se desenvolve em torno de indivíduos motivados.

Não consigo descrever muito bem o que é Management 3.0. Jurgen Appelo fez, nada mais, que pegar várias idéias e conceitos bons que existiam soltos por aí e escreveu um livro excelente. Esse modelo de gestão que ele criou, chamada de Gestão 3.0 ou Gestão Ágil, trabalha com seis visões: energizar pessoas, empoderar times, alinhar restrições, desenvolver competências, crescer a estrutura, melhorar tudo.

Na minha não tão humilde opinião, este livro deveria ser leitura obrigatória para quem quiser adotar agilidade em sua organização. E se você tem preguiça de ler, existe um curso oficial sobre o tema, oferecido pela Adaptworks. Enfim, por que citei isso? Porque agilidade é sobre pessoas. Se não existe um desenvolvimento de pessoas, se não existe respeito, se não existe confiança, não existe agilidade.

Quando tem ser humano no meio, o bicho pega. Não é exato. Não existem verdades. O sistema não é binário. Quando o fator humano é posto em segundo plano, não há como adotar agile. Horas extras, trabalhos em feriados, pontos eletrônicos, tudo isso é, na verdade, uma tremenda falta de bom senso e, porque não dizer, falta de respeito. Empresas muito engessadas, departamentais, burocráticas em excesso, desorganizadas, com alta rotatividade de funcionários irão falhar miseravelmente e irão dizer que agile não funciona. E isso está acontecendo neste momento.

tl;tr

Muitos podem dizer que o importante é entregar software, seja ágil ou não. Não acredito nisso. Não devemos entregar software a custo do sacrifício de outros fatores, como motivação, qualidade, satisfação pelo seu trabalho. No fim das contas, metodologia não desenvolve software. Engenheiros desenvolvem software. A agilidade é inerente ao bom desenvolvedor.

A qualidade técnica sobrepuja qualquer dogma. Desenvolvedores, talvez não precisem de controle, mas sim de liberdade, para criar, para explorar, para desenvolver sua arte. Muitas empresas já perceberam isso e estão no caminho certo.

29 comentários sobre “Verdades inconvenientes sobre agilidade

  1. Rapaz já tem anos que falo isto e em varias palestras.
    Não adianta métodos ágeis, se ignorarem o fator humano, ele é o estimulo que torna tudo ágil ou não, caso contrario essas ideias se tornam outra forma de controle, voltando aos velhos modelos.

    Curtir

  2. Sempre que ouço de agilidade o que me vem na mente é o Manifesto Ágil. Ali, naquele dia, naquela reunião, aqueles caras não pensavam em mais nada a não ser de encontrar valores e princípios para serem seguidos como melhor maneira de desenvolver Software. Com a explosão da coisas, foi-se dando “nomes aos bois” e quem foi aprendendo foi aprendendo pelos nomes.

    Explicando: O cara aprendeu Scrum, não o Manifesto.

    Isso fez com que muito da pureza das ideias do ágil fosse perdida. Eu sou capaz de apostar todo o valor da minha conta corrente hoje (R$ 600,00 😛 Ah vai, dá pra fazer umas boas comprar) que existem bastante Stackeholders, Product Owner, Scrum Masters, TDDistas, pair programmers, etc. Que não sabem nem que existe o Manifesto e não sabe nem pra onde ele vai.

    Claro, é importante que isso um dia não se precise mais dar um nome, mas hoje se faz necessário para que as pessoas saibam que estão fazendo da forma errada e aprendam a fazer da forma certa.

    Enfim, sempre que tenho alguma dúvida sobre algum prática que estou começando a querer adotar, vou aqui: http://manifestoagil.com.br/

    Excelente texto Paulo, nunca havia pensado assim: “Eu, particularmente não gosto de usar o termo agilidade, pois pra mim, só existe um meio de se desenvolver software, e é com desenvolvimento ágil” mas definitivamente você não poderia estar mais certo.

    Curtir

  3. Bom, você pode vender as “suas verdades” e obter duas coisas: Concordância ou discordância. Algo natural, certo?

    De fato, ágil sem testes automatizados não existe. Você frisou isso bem e acho que não há o que acrescentar. O fator motivação também é algo indiscutível, a meu ver. Bem frisado, por sinal. Entretanto, você trocou o nome do PO por outro nome e não acrescentou nada. Você chamou de stakeholder o possível interessado (ou sua representação) no resultado e no valor a ser entregue/mantido. Quem é stakeholder? Uma pessoa? Um grupo? O time? O “cliente”?

    Alguém precisa definir um conceito de valor sobre o trabalho a ser feito. Isso é localizado, específico, quase pessoal. Não importa o nome dessa “entidade” (pessoa ou grupo/time). Você pode não gostar no nome PO (uma negação ao Scrum), mas alguém precisa assumir esse papel, qualquer seja o nome formal pra isso. Se todo mundo pode “definir valor”, na verdade ninguém poderá. Se você estiver acostumado a trabalhar em times pequenos, em linha de concepção e produção (vc/seu time define o que é valor e materializa isso), é bem natural não enxergar valor no papel. Entretanto, quando vc precisar ser apenas dev team, vc vai se sentir perdido enquanto não encontrar um referencial que lhe dê segurança sobre o que vc vai produzir, se o que vc vai fazer gera valor, se o produto de trabalho gera valor ao seu meio, quem vai usar, quem pagou por ele, etc.

    Curtir

  4. Cara, o PO é um gerenciador de backlog. É desnecessário em um time ágil. Ele é um intermediário entre o time e o cliente. Isso não é agile. Sou a favor do time trabalhar em colaboração com um especialista no domínio, que pode ser o próprio cliente ou um funcionário dele, por exemplo.

    De acordo com o Scrum, o PO não define valor, ele é responsável por fazer o time entregar valor. Um time ágil compreende a visão do cliente. No Scrum, esse é o trabalho do PO. Como falei, acho que scrum é para times iniciantes.

    Curtir

  5. Oi Paulo, muito bom seu post. Mas peço licença para fazer algumas ponderações:
    1 – O Manifesto Ágil é a referência para Agilidade, o Scrum implementa o Manifesto Ágil, logo ele é método ágil.
    2 – Desenvolvimento de Software, medicina, jogar futebol, pesquisa médica, todos são processos não prescritivos, ou seja, são processos empíricos onde o conhecimento das pessoas que estão envolvidos no processo fazem toda a diferença. O Scum, trabalha com teoria dos processos empíricos que para ser controlado utiliza práticas de inspeção e adaptação.
    3 – Gestão 3.0 ou Gestão Ágil, o TPS (Toyota Production System) da Toyota, a muito tempo já implementa os conceitos que são pregados por aí.
    4 – A evolução do Scrum é XP, por incrível que pareça, quando a equipe ganha maturidade, vão descobrir que as práticas pregadas pelo XP realmente são as mais relevantes para o desenvolvimento de software.

    Curtir

  6. Isso ficou bonito:

    “A qualidade técnica sobrepuja qualquer dogma. Desenvolvedores, talvez não precisem de controle, mas sim de liberdade, para criar, para explorar, para desenvolver sua arte. Muitas empresas já perceberam isso e estão no caminho certo.”

    Parabéns pelo post 😉

    Curtir

  7. Concordo com você, Rildo, em todos os pontos, principalmente o 4º. Com o tempo, a experiência, o entrosamento, etc; Times maduros realmente fazem a transição do Scrum para algo cada vez mais próximo do XP. Muito bem observado.

    Curtir

  8. Bem legal o post Paulo, parabéns!!! Em muitos pontos concordo com você.

    Nos últimos anos tenho trabalhado de uma forma bem diferente com “agilidade”, buscando o desprendimento das metodologias, mas ainda assim usando as técnicas e práticas quando se fazem necessárias, ou criando formas diferentes que se encaixam melhor. Resumindo deixei os “rótulos” de lado, se é Scrum, Kanban, Crystal, XP, DSDM, etc. não importa, o que importa é que estejamos alinhados com os valores e princípios do manifesto ágil.

    O manifesto ágil é a bússola para guiar o processo de melhoria contínua e tenho me orientado por ele para experimentar técnicas e práticas que ajudem o time a trabalhar e entregar mais valor.

    Então todos os estudos e métodos desenvolvidos que estão alinhados, ou buscam “implementar” o manifesto ágil se fazem necessários, para entender as técnicas e os motivos pelo qual elas foram desenvolvidas e isso vai se tornar mais uma ferramenta na sua caixa, e quando for necessário você pode experimentar e avaliar se é bom para a sua realidade ou não.

    A observações do Rildo estão bem alinhadas com o que eu penso sobre esse movimento. Na minha última palestra no Agile Brazil (https://palestrascoletivas.com.br/talks/buscando-agilidade-sem-rotulos) eu abordei exatamente o modelo que eu tenho adotado nos times que trabalhei e nos projetos que tenho trabalhado, e esse modelo está bastante alinhado com o que você colocou no post.

    Mais uma vez Paulo parabéns por abordar o assunto e expor seus pensamentos, essa discussão é muito válida e interessante!

    Curtir

  9. Como o Alexandre bem falou, faltou embasamento da minha parte em alguns aspectos. Para mim Scrum não é ágil. Agile é um mindset. Um conjunto de princípios e valores. Scrum não é um conjunto de princípios e valores. É um processo para gerenciamento que ajuda times, muitas vezes disfuncionais, a se tornar ágeis.

    E concordo plenamente que XP é uma evolução, pois o XP é para times ágeis, enquanto o Scrum, no meu ponto de vista, não. Scrum é lean e não ágil. Mas claro que essa é a minha opinião de b*sta. kkkkkkk

    Curtir

  10. Paulo, o Manifesto Ágil é conjunto de valores e princípios sobre desenvolvimento de software. Escrevemos um Manifesto quando queremos fazer ruptura da situação atual, e demonstrar quais os valores que acreditamos e que serão seguidos, em resumo, é um manifesto representa ou é materialização da quebra de paradigma.
    Todos os métodos, inclui, o Scrum, Lean, Kanban, etc coisa e tal, que implementam os princípios e os valores descritos no Manisfesto, são designados como métodos, métodos ágeis.

    Curtir

  11. Parabéns Paulo, tevis-te coragem ou quiseste passar isso. Não importa.

    O importante que a deu um norte as boas práticas de desenvolvimento de software alinhando a uma gestão integrada e comprometida. Ou seria uma gestão comprometida e integrando os processo de desenvolvimento de software? Sabe no fundo é a mesma coisa, sendo uma luta eterna contra a burrice, a ignorância e o desapego. Não há boa gestão sem valores, não há software sem clientes, não há empresa sem sociedade.

    Parabéns mais uma vez pelo post, eu precisava ler isso.

    Curtir

  12. Paulo, os seus argumentos são muito, mas muito interessantes. Eu sou analista de negócios e atuo como PO junto aos times no desenvolvimento e sempre vi meu papel de PO como um “mal necessário”.

    Você escreveu “sem stakeholder não é agile” e acho que só essa frase merece toneladas de reflexão.

    Quando digo que sou um “mal necessário”, digo justamente porque atuo para diminuir o prejuízo que vem do FATO de que quem precisa de software raramente possui o consenso e a disponibilidade necessários para que esse software seja bem desenvolvido.

    A questão é: usar algo (ou alguém) para compensar uma deficiência no ecossistema como falta de auto-organização (scrum master) ou para compensar a falta de consenso e disponibilidade (PO) para tentar ser agile desqualifica a iniciativa como sendo ágil?

    Sempre trabalho com a perspectiva de que meu trabalho vá se tornando menos necessário ao longo do tempo estabelecendo laços entre os stakeholders e o time. Será que a intenção de ser ágil já nos qualifica como ágeis ou só somos mesmo quando chegamos àquele ponto onde não há dificuldades na comunicação entre desenvolvedores e stakeholders e onde a necessidade de gestão tende a zero?

    Ui, o texto ficou bem pior do que o que tenho na cabeça, mas fica o abraço e a vontade de discutir isso pessoalmente.

    Um abraço!

    Curtir

  13. Legal seu comentário, Claudio.

    Acho que essas práticas não desqualificam a iniciativa de jeito nenhum. Acho perfeitamente possível ser ágil usando scrum ou mesmo Kamban. Você pode ter uma pessoa de negócios trabalhando com o time de dev e chamar essa pessoa de PO. Não vejo problema nisso. O que acho ruim é o time não interagir com o cliente.

    Também acho, que o agile não é pra qualquer ambiente. Você pode estar tentando ser ágil ad eternum, em um ambiente que nunca irá proporcionar isso sem mudanças profundas de cultura e organização, mas isso não invalida vc tentar.

    O Rildo é um Yoda e eu sou apenas um padawan ( nem gosto de star wars :P) e inclusive aprendi muita coisa com ele. Mas vou me atrever a dizer que o Scrum não implementa algumas coisas do manifesto ágil. Não sei se a interpretação do manifesto deve ser subjetiva ou não, só acho que o manifesto só funciona, quando usamos seus princípios em conjunto.

    “As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.”
    De que adianta ter a mona lisa no código se ele não tem valor de negócio.

    “Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.”
    Dificilmente iremos entregar valor, sem um bom design.

    Eu como desenvolvedor acho que a agilidade se estende além da gerência de produto, ela se estende à engenharia software ágil aliada a uma visão de negócio. E o Scrum não trabalha isso. Também por isso que digo que scrum é para iniciantes e que a experiência vai levar o time a práticas mais ágeis como são as práticas do XP.

    Curtir

  14. Muito legal o post Paulo, parabéns.

    É assunto que irá gerar bastante discussão, entre o que ser ágil ou não, ou a importância de certos papéis ou ainda a maneira com que a empresa trata seus projetos. Na minha opinião existem processos ágeis, independente de metodologia, que são ótimos, bem como, metodologias anteriores um pouco mais antigas que também são ótimas, tudo vai depender do tamanho do projeto e o objetivo do negócio.

    Mas enfim, o que eu quero comentar mesmo é a frase que você escreveu:
    A agilidade se desenvolve em torno de indivíduos motivados.

    Eu acho que este é o fator que irá determinar o sucesso de um projeto, independente de metodologia, tente aplicar métodos ágeis ou outros métodos ou metodologias em equipes desmotivadas, o que era pra ser ágil se torna bagunça, e o que era pra ser bem seguido conforme norma X se torna lento e engessado.

    Perfeito suas colocações a respeito do lado humano.

    Curtir

  15. Paulo,

    Lendo esse seu post lembrei de um post e bem antigo do James Shore(acho que todos devem lembrar) que retratava algumas verdades do desenvolvimento ágil. A grande sacada do desenvolvimento ágil é a agressividade de toda a mecânica, ou seja, entregas rápidas, respostas eficientes a mudanças e uma notável entrega de valor para o cliente e todo mundo feliz. Dentro desse cenário, garantir esses items não é uma tarefa fácil, afinal, ser ágil não é de longe trivial e pela simplicidade(falta de complexidade) do Scrum isso torna-se ainda mais caótico, e é aí que entra a forte aplicação de engenharia ágil para apoiar uma série de problemas que um time pode enfrentar ao longo do desenvolvimento, dizer que “Não existe agilidade sem testes automatizados” é um pedaço da verdade, digo que não existe agilidade sem Testes Automatizados/TDD, IC, Refactoring, Design emergente, linguagem unica de domínio e etc, etc, etc. Dado que naturalmente você irá aplica-las durante skill up do time, seja usando o XP ou não.

    Mas creio que não devemos por a agilidade somente como boas práticas de engenharia. Como muito bem colocado pelo Paulo Igor e Rildo, as metodologias tem como finalidade seguir o que esta no manifesto ágil, onde em sua maioria são empíricas provendo a melhoria continua do processo(inspeção e adaptação) e isso inclui a importância das pessoas no desenvolvimento de software onde o time se faz responsável pelo sucesso ou fracasso da entrega.

    Parabéns pelo post, achei a sua colocação bastante valida para discussões.

    Att,

    Curtir

  16. Legal Anderson. Talvez a agilidade não seja atingir a perfeição de um processo, mas sim um constante auto aperfeiçoamento com base no empirismo. Excelente.

    Curtir

  17. Se o objetivo do post era mostrar visões múltiplas, provocar e sacudir a zona de conforto das pessoas e provocar essa discussão, então o objetivo foi bem extrapolado 🙂

    Tem gente grande aqui em SP comentando seu post, Paulo. Esperando ansiosamente que elas entrem aqui pra enriquecer o papo.

    Curtir

  18. Concordo, mas vc consegue “usar” o Scrum e dos demais com processo inteiramente cascata e comando/controle, é claro, que estaríamos desvirtuando o objetivo dos métodos ágeis.

    Curtir

  19. Exatamente, minha opinião é que, ao aderir a uma metologia como o Scrum, XP e Kanban e etc, todos eles são parte de um processo como um todo não o contrario. E essa sutil compreensão que não se fez presente durante o ‘modisto’ do desenvolvimento ágil, tornou o Scrum o principal nome da agilidade(vulgo Scrum Alliance) sendo ele somente ele a ser aplicado como a salvação para os problemas, mesmo que dentro de um modelo cascata.
    A proposito! cuidado! “The boys from RUP (Rational Unified Process) are back” 🙂
    http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/

    Curtir

  20. Cara realmente o Agile Trends me fez ter uma visão mais parecida com tuas ideias Paulo. E realmente conversando com alguns Agilistas (se não me engano uns 4 ou 5) quando falava que era da Comunidade Ta Safo, este teu post era citado, também espero que eles, contribuam com esta excelente discussão.

    O que mais vi/ouvi no evento foi a importância de Colaboração entre time e o cliente. O aprendizado que isso gera e como dar ênfase a certos rótulos podem acabar desvirtuando o que está no Manifesto Ágil.

    Citando um exemplo de palestra que me fez refletir sobre a maneira de como trabalhamos com certas metodologias foi a nosso conterrâneo Alexandre Magno (Práticas Emergentes: uma viagem à margem do caos) onde foi mostrado que a tendência é que após aprendermos na prática o básico de Agile, será que não chegou momento de nos desapegarmos de tais métodos? Dai a importância do surgimento de práticas emergente que nos auxiliam a manter o foco nos princípios e valores do Manifesto Ágil ao invés de ficar defendendo que metodologia X é melhor que Y.

    Outro exemplo: “Com um cenário organizacional cada vez mais dinâmico, imprevisível e de grande necessidade de aprendizado (e desaprendizados), temos que desenvolver uma forte habilidade de adaptação em nossa sociedade de maneira geral.” (Apresentação de Manoel Pimentel – Aprendendo a viver na era da organoplasticidade) pude perceber o quanto é importante termos coragem de encarar as mudanças, não apenas para mudar o que está errado, mas também para aperfeiçoar o que está dando certo também. Dai volto a frisar que é melhor focar nos princípios e valores do manifesto a ter que levantar a bandeira de prática X, metodologia Y, etc.

    Parabéns mais uma vez Paulo, sugiro um PoadcasTI sobre o tema, ou até mesmo um #papoSafo numa #horaExtra qualquer dia desses.

    Curtir

  21. Esse Paulo Moura foi o mesmo cara que falou num podcast recente que matérias de matemática e correlatas não eram importantes em um curso de graduação em TI?

    Enfim, a resposta não fará muita diferença, apenas questão de credibilidade do que se ler por aí, nessa época de inclusão social….

    Quando aqueles 17 caras se reuniram naquela de estação de ski em Utah, o objetivo era claro: recuperar a estima dos desenvolvedores. Não sejamos bobinhos, a agilidade é uma abordagem top-down, isto é, da indústria pros operários. A agilidade resgatou o orgulho daquele que codifica e como post diz: valorizou as pessoas.

    A sopa de letrinha ágil nada mais é que uma “novidade” disfarçada de coisas que já sabíamos: indivíduos motivados desenvolvem software com qualidade e no prazo, mas a galera do RUP e derivados não tava nem aí pros pobres devs.

    Talvez, o Paulo tenha conseguido passar um pouco do que penso e concordo, ou não.

    Ser ágil nunca foi novo, fashion, certo, isso sempre existiu. A indústria percebeu isso primeiro e passou pros operários assimilarem a ideia.

    Nesse contexto atual, queria muito entender como as pessoas pagam 1.300/1500 reais numa “certificação” pra se considerarem Scrum Master, Product Owner….sem falar na indústria de cursos que é melhor nem comentar, se não certamente ofenderei alguém.

    Deixo a reflexão, até que ponto o mercado ágil prevalece sobre os seus principais conceitos (os quais a maioria são bem antigos)?

    Fico curioso pro termo pós “agilidade”…..

    Curtir

  22. “Quando aqueles 17 caras se reuniram naquela de estação de ski em Utah, o objetivo era claro: recuperar a estima dos desenvolvedores.”

    Acho que o objetivo, não era esse não. Mas obrigado pela contribuição.

    Curtir

  23. Quando a solução faz parte do problema?
    Obs.: Quase sempre sentido quando o projeto esta bem adiantado.

    “Enrolações à parte, a explicação é bem simples: ao buscar uma solução com outras pessoas, você acaba confiando mais naquilo que for consenso e dá menos importância a opiniões individuais. Isso pode te fazer ignorar pontos importantes ou soluções mais espertas. “O processo colaborativo é o próprio problema”, explica a psicóloga Julia A. Minson, que conduziu um estudo sobre o tema na Universidade da Pensilvânia.”

    Curtir

  24. Tentando resumir este post em apenas duas palavras: “Programming, motherfucker!” 🙂

    A primeira vez que ouvi o Paulo argumentar que “Scrum não é agil” pensei que ele estava louco (ou bêbado, para ser mais exato). Mas depois entendi o ponto de vista contra práticas doutrinárias, que muita gente fazem apenas “porque precisa”; e não porque a necessidade os dirigiu àquilo. Sem dúvida as práticas, papéis e etc têm a sua importância, mas não são a essência da coisa. (Não, o stand-up meeting não precisa ser sempre em pé).

    A única forma de saber se realmente você está sendo ágil é quando suas ações encontram respaldo nos valores ágeis que você tem dentro de si. Daí o porquê de a agilidade não ser para todo mundo.

    Infelizmente o próprio termo “agile” acaba sendo usado muita vez com fins mercadológicos.

    Lembrei-me deste antigo post, “Sou porque faço ou faço porque sou?”: http://viniciusban.blogspot.com.br/2009/12/sou-agil-porque-faco-ou-faco-porque-sou.html

    E também comungo do pensamento que testes automatizados é condição sine qua non para desenvolvimento ágil. Já tinha inclusive mencionado isto no post “Se você não testa você não é ágil” em https://tasafo.wordpress.com/2009/05/14/se-voce-nao-testa-voce-nao-e-agil/

    Curtir

  25. Pingback: Alguns pontos sobre estimativas | Blog do Tá safo!

O que tu achas?

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s