Agile x Todos

[Carlo Giovano]

Caros,

Segue um post interessante. Não entendam errado e não pensem que por
enviar esse email sou contra métodos ágeis. Sou praticante de Ágil,
CMMI, RUP, PMBoK ou o que quer que seja melhor e mais adequado para o
contexto do projeto e do cliente, mas achei interessante (apesar de não
ser novidade) a forma que ele coloca alguns pontos.

http://diego-pacheco.blogspot.com/2009/09/seja-inteligente-e-nao-use-agile.html

Giovano

[CMilfont]

Ele avalia do ponto de vista de processo vs processo, coisa que é insignificante,  principal diferença no que ficou conhecido como métodos ágeis e os modelos anterioes está muito bem definida no manifesto ágil.
Agile valoriza mais os itens a esquerda enquanto os tradicionais valorizam os da direita, simples assim. Ambos possuem e podem possuir os dois lados.

Minha resposta a esse tipo de coisa é http://www.milfont.org/tech/2009/09/17/qualidade-interna-vs-qualidade-externa/

2009/9/18 Carlo Giovano <cgio...@atlantico.com.br>

--
http://www.milfont.org

[Ivan Teixeira]

É ironico, metodologia ágil que começou como um processo revolucionário virou "Mainstream". Revolucionário agora é questionar metodologia ágil (tem até que já mandar e-mail se defendendo), e tem gente que ainda não percebeu isso.

2009/9/18 Carlo Giovano <cgio...@atlantico.com.br>

--
Ivan Romero Teixeira
Arquiteto de Software
SEFAZ-CE
Fortaleza, Brasil

[Cleyton Ribeiro]

Concordo Ivan,

não se deve negar o fato de que as metodologias ágeis tem sim base em
outros prpocessos de desenvolvimento mas que propõe em muitos outros
aspectos novidades relevantes ou mesmo uma nova maneira (Filosofia) de
se pensar em projetos de software. Xiitismos a parte não entendo e não
concordo com quase tudo do que foi escrito.

Cleyton Ribeiro
Gerente de Tecnologia
TERMACO LOGISTICA
www.termaco.com.br

2009/9/18 Ivan Teixeira <ivan.romer...@gmail.com>:

--
Cleyton Ribeiro
Analista de Sistemas
cleyto...@gmail.com

[Fabio Pinheiro Abreu]

Achei os posts interessantes. Hoje, vejo pouca visão crítica do que realmente é o valor agregado seja do modelo/processo A ou do modelo/processo B. Busca-se defender um modelo/processo através dos erros de implementação do outro modelo/processo. Será que a questão principal não é implementar o modelo/processo corretamente ao invés de escolher entre modelo/processo A ou B? E por que não podemos escolher o modelo/processo AB? Afinal a base de melhores práticas de gerenciamento e desenvolvimento é a mesma. Há uma tendência natural do ser humano de escolher um lado quando na realidade vejo que os modelos estão do mesmo lado.

 

Fabio Pinheiro Abreu, MSc, PMP

Consultor em GP e Melhoria de Processos 

2009/9/18 Cleyton Ribeiro <cleyto...@gmail.com>

[cgio...@atlantico.com.br]

Polemicas a parte o melhor disso tudo eh ver um pouco de debate na lista spince!

Abrcs
Giovano

Sent from my BlackBerry®

---

From: Fabio Pinheiro Abreu <fabiopinh...@gmail.com>

Date: Sat, 19 Sep 2009 08:43:43 -0300

To: <spin...@googlegroups.com>

Subject: [spinceara] Re: Agile x Todos

[Clavius Tales (Fortes Informática)]

Copio abaixo a resposta que dei noutra lista de discussão:

 

---

Já li uns três artigos do Diego. Me pareceu um cara bem erudito na área, bastante consistente. De certa forma, esse artigo dele segue essa regra, mas cabem algumas observações.

O título: "Seja Inteligente e não use Agile". É perigoso, não reflete o conteúdo do artigo, mas gostei. Gosto de títulos provocativos.

 

No primeiro parágrafo, ele fala dos "agilistas". O que são esses agilistas? São os signatários do Manifesto? São os proponentes de métodos ágeis? São os autores reconhecidos? São os praticantes de métodos ágeis? São os defensores dos métodos ágeis? Falta essa definição.

Não sei se os colegas perceberam, mas no mesmo parágrafo o próprio Diego se intitula um agilista, na silepse canônica. Um aparte, aliás: silepse elegantíssima, apesar de corajosa, já que normalmente é empregada com muito mau gosto.

Outra coisa que talvez tenha passado despercebida é a estratégia morde-e-assopra: "Em outro post depois [vou] falar dos pontos positivos..." Achei legal.

"Hoje em dia muitos colocam como os métodos ágeis sendo a única solução que funciona para o desenvolvimento de software, será que isso é verdade, será que não existem outras opções?"

O engraçado dessa passagem é que o Yosha talvez seja o agilista brasileiro que mais se alinha com a lógica do Diego, mas fala justamente o contrário: "Só Agilidade funciona". Estou com o Yosha.

 

Na passagem sobre palavras mágicas, um pecado: já que pede evidências, devia dá-las quando diz que os agilistas se referem às metodologias ruins, caras, lentas, pesadas e falhas. Aliás, todo o artigo contém essa falha: faltam referências. Ele diz que os agilistas falam isso e aquilo, mas nunca cita referências. Esse é o maior pecado do artigo.

 

"métodos ágeis não são a solução para a cascata a solução é desenvolver de forma iterativa incremental, e isso ja exite a muito tempo e foi criando muito antes do agile."

Existe uma clara diferença com o advento dos métodos ágeis: o tamanho das iterações, bem mais reduzido. Por exemplo, conheço poucas empresas que utilizam o RUP de forma (quase?) certa, e a menor iteração que vi nesses casos foi de dois meses, e normalmente de três a seis meses.

 

"Então o pessoal pega a uma solução que já existia e já solucionada e vende isso como uma solução nova para um problema velho, mas que na verdade é a única solução, pelo menos é o que os caras dizem."

 

Esquisito. Olha o que o Beck fala no XP 2nd Edition:

 

"XP frightens or angers some people who encounter it for the frist time. However, none of the ideas in XP are new. Most are as old as programming. There is a sense in wich XP is conservative - all its techniques have been proven over decades (for the implementation strategy) or centuries (for the manager strategy).

 

The innovation is

 

- Putting all these practices under one umbrella.

- Making sure they are practiced as thoroughly as possible.

- Making sure the practices support each other to the greatest possible degree."

 

"Defina métodos ágeis, me de um escopo"

 

Simples. Qualquer método que siga os valores e princípios do Manifesto. A sensação que tenho é que o Diego não entendeu direito o que se chama de Agilidade. É uma corrente. É uma resposta ao que nossa indústria estava se transformando. Um exemplo: CMM(I) estava se popularizando. Era tido como a pedra de salvação da nossa indústria. A criação do MPS.BR é uma evidência disso. Só que quase todas as implementações desses modelos são muito burocráticas, pesadas, guiadas por documentação, com fases e papéis rígidos. Foi assim aqui na Fortes e foi assim em quase todos os casos que tive conhecimento. Uma turma percebeu o risco a que nossa indústria estava se submetendo e resolveu criar uma peça "publicitária" para alertar a todos.

 

" Lean\Kanban ... não tem nada a ver com agile"

 

Não sei de onde ele tirou isso. Mary e Tom Poppendieck, os criadores do Lean Software Development, são frequentadores assíduos das conferências ágeis. Num dos livros do Beck, acho que o XP 2nd Edition, Mary dá um depoimento positivo a respeito.

 

"Em determinados cenários agile não funciona, com equipes muito verdes, com requisitos complexos e equipes que não tem disciplina não funciona."

Vamos quebrar.

 

"equipes muito verdes"

 

Há alguma metodologia que funciona nesse caso?

 

"requisitos complexos"

 

XP é especialmente recomendada nesses casos. Um processo mais prescritivo é justamente menos recomendado nesse cenário.

 

"equipes que não tem disciplina"

 

De novo: há alguma metodologia que funciona nesse caso?

 

"Pessoal estimar não ruim, isso não é errado"

 

Não conheço qualquer metodologia ágil que não trabalhe com estimativas. Scrum e XP, por exemplo, tem nas estimativas um dos pilares de seus processos de priorização.

 

"ter um gerente não significa ter um capataz"

 

Um dos papéis formalmente definidos em XP é justamente "Gerente de Projeto".

 

"nem todo o projeto vai ser de equipes colocadas"

 

Colocado da forma que foi, parece que métodos ágeis não funcionam para equipes distribuídas. Já há diversos relatos comprovando o contrário. A ThoghtWorks por exemplo é repleta desses casos.

 

 

Peguei só alguns pontos para comentar. Há vários outros. Mas a crítica maior que faço ao artigo já fiz no início desta mensagem: faltam referências. Quem são os agilstas que fazem essas afirmações? Que afirmações são essas?

---

Giovano

---

Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.103/2378 - Release Date: 09/17/09 06:18:00

[Ciro Coelho]

Aproveitando, copio abaixo a resposta que passei para a outra lista
com base nesse mesmo e-mail do Tales :-)

-----------------------------

Só tocando em alguns pontos com base nesse e-mail do Tales:

Tales: "O engraçado dessa passagem é que o Yosha talvez seja o

agilista brasileiro que mais se alinha com a lógica do Diego, mas fala
justamente o contrário: "Só Agilidade funciona". Estou com o Yosha."

Agilidade é questão de sobrevivência. O problema que eu vejo nesse
caso é só o uso que eu já vi gente fazendo dessa frase do Yoshima em
listas de discussão por aí, como se ele tivesse dito que só XP, Scrum
etc funcionam. O próprio Yoshima chama a atenção de que o RUP, se
aplicado corretamente, é ágil. O problema é o pessoal não entender que
um framework de processos precisa ser adaptado (lembram do dX, do
Robert Martin?) ou achar difícil de fazer isso, o que é verdade, e
deturpar o uso do RUP.

Tales: "Existe uma clara diferença com o advento dos métodos ágeis: o

tamanho das iterações, bem mais reduzido. Por exemplo, conheço poucas
empresas que utilizam o RUP de forma (quase?) certa, e a menor
iteração que vi nesses casos foi de dois meses, e normalmente de três
a seis meses."

Um das formas erradas de aplicar o RUP é justamente planejar iterações
longas. O RUP sempre defendeu iterações curtas para equipes pequenas,
por exemplo. É só dar uma olhada nos livros do Walker Royce e do
Dennis Gibbs. É mesmo raro ver uma aplicação do RUP assim, mas eu já
vi projetos, em duas empresas diferentes onde trabalhei, utilizando
iterações de 1 mês para projetos com processo RUP-like. Mas que a
abordagem "está aqui tudo que você precisa, agora adapte" do RUP é
muito menos factível do que a "está aqui o que você não pode deixar de
fazer, acrescente o que precisar" dos métodos ágeis, isso é verdade.

Ainda em relação às iterações, além de serem mais incisivas nesse caso
de utilizar iterações curtas, uma outra grande contribuição dos
métodos ágeis é definir claramente que o resultado de uma iteração
deve ser software funcionando e que as iterações devem ter tamanho
fixo. Isso impede que, como acontece em muitas implementações do RUP,
o modelo iterativo seja "cascatizado" e que as iterações curtas acabem
se tornando longas.

Abraços,

Ciro

2009/9/19 Clavius Tales (Fortes Informática) <ta...@grupofortes.com.br>: