Boa noite, Osvaldo. Obrigado por criar o forum de metodologias ágeis.
Compartilho aqui alguns blogs que criamos (eu e o Eros) sobre metodologias ágeis e arquiteturas de software.
Criamos posts dos seguintes processos ágeis até o momento:
AUP
Essential UP
OpenUP e Controle de Riscos com o OpenUP

Exibições: 89

Respostas a este tópico

Muito legal Marco, estou dando uma olhada! Aproveitando o gancho eu gostaria de lançar uma questão: qual a relação entre a metodologia utilizada na gestão de um projeto e a arquitetura do mesmo? Metodologias ágeis fazem com que o trabalho do arquiteto seja mais fácil, mais difícil ou não há uma relação entre as duas coisas?
Olá, Osvaldo. Vejo a implementação de atividades de arquitetura dentro de uma metodologia ágil "simples" se o arquiteto seguir alguns preceitos que coloco abaixo. Infelizmente, entretanto, seguir estes preceitos não são simples embora eu acredite que devamos continuar tentando alcança-los.

Preceitos.....
- O arquiteto deve buscar continuamente gerar "valor" sobre os seus artefatos e evitar criar "lacunas de valores" na entrega do projeto, que é basicamente a diferença entre o valor produzido pelo time de arquitetura e o valor percebido pelos outros stakeholders do projeto. O post do Alcebíades sobre isso traz idéias interessantes (Lacuna de Valor).
- O arquiteto deve ser muito mais um facilitador do que alguém que monte arquiteturas em sua "torre de marfim" . Ele precisa envolver ativamente todo o time e criar o que chamo de "arquitetura coletiva". Tecnicamente, o Scott Ambler escrever um excelente artigo a respeito (Agile Architecture). O Eros também escreveu um artigo interessante a respeito.
- Estabelecer confiança e autoridade moral (e não formal) sobre o time. Escrevi também um blog a respeito com idéias do Stephen Covey adaptadas para arquitetura de software. Por favor as critique! :-)




Osvaldo Pina said:
Muito legal Marco, estou dando uma olhada! Aproveitando o gancho eu gostaria de lançar uma questão: qual a relação entre a metodologia utilizada na gestão de um projeto e a arquitetura do mesmo? Metodologias ágeis fazem com que o trabalho do arquiteto seja mais fácil, mais difícil ou não há uma relação entre as duas coisas?
Osvaldo,

Apenas um ponto de observação sobre o tema. Métodos ágeis são normalmente confundidos como métodos rápidos. Isso significa que muitas pessoas (acredite, até mesmo gerentes de projeto certificados PMP, XYZ, etc) acham que deve-se usar Agile para se entregar software de forma mais rápida. Isso é um problema que deve ser atacado quando se pensa em aplicar agile num projeto, em especial, Scrum.

Métodos ágeis, na verdade se referem a métodos ou conjuntos de práticas que passam menos tempo se preocupando com burocracias de projeto (artefatos ditos como importantes, entregáveis ditos como essenciais) e mais tempo se preocupando em agregar valor ao cliente, seja dispondo um entregável de qualidade, seja orientando a equipe sobre os riscos do projeto, seja dando feedback contínuo sobre o que ocorre no projeto, e usando o cliente e demais stakeholders como aliado.

Neste caso, se você estiver num projeto, onde a expectativa criada sobre o método ágil é de entregar software rápido, sem duvida alguma, vários problemas sobre a ótica arquitetural irão ocorrer, em especial, destaco o problema de priorização de requisitos, organização de entregas em sprints, gerência de ataque a riscos técnicos e de projeto bem como flexibilização da equipe em pró das entregas. Outra questão importante é sobre a natureza dos projetos. Se você tiver em mãos um projeto onde o ataque aos riscos é mais interessante quando você cruza horizontalmente cenários de negócio, os falsos agilistas irão ser contra esta prática, uma vez que em suas cabeças, um bom entregável, é um caso de uso completo.

Este é apenas um aspecto que pode ser influenciado pelo uso de métodos ágeis, mas é facilmente contornado quando antes do inicio do projeto, você gerencia e acomoda as expectativas dos stakeholders sobre o que esperar de agile, prática esta que reflete ajudar as pessoas a entenderem os métodos e as práticas, antes de pô-las em prática pra depois explicar por que estão sendo usadas.

Abraços,
Ricardo,

Você tocou em uma questão muito importante em relação a metodologias ágeis. Mas vejo também uma preocupação enorme de algumas empresa e profissionais buscando implantar metodologias ágeis, principalmente o Scrum, sem ter um conhecimento técnico em relação a metodologia.

Já vi empresas adotarem Scrum onde tinham os famosos "Scrum Masters" certificados que nunca tinham lido um livro de Scrum ou um livro sobre metodologia ágil. Infelizmente são pessoas "formadas" em um sensacional curso de 1 final de semana que tem nas esquinas por aí.

Há um artigo muito interessante do James Shore (http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html) que faz justamente um alerta a este tipo de comportamento onde "comem a sobremesa antes do prato principal".

ps: Há um resumo no InfoQ Brasil (http://www.infoq.com/br/news/2008/11/decline-of-agile)

Abraços,
Marcos,

Concordo com vc em parte. Quanto ao ScrumMaster a questão tem que voltar ao princípio: o que é um ScrumMaster? Na minha opinião é alguém que participou de um curso de 2 ou 3 dias e conhece as práticas do Scrum. Conhecer estas práticas é muito fácil, realmente dá para aprender em 2 dias. Ele sabe o que é um Sprint Backlog, um Product Backlog, etc. Considerando o título é apenas isto! Aí entra uma falha muito grande do Scrum allience que é o nome do certificado: ScrumMaster! Quem vê este título infere que quem se certificou é experiente no assunto (é um "master"), mas na verdade não é isto que o certificado significa. Neste ponto o artigo que você postou aqui é excelente! Ele aborda muito bem o assunto. As técnicas do Scrum são uma externalização de uma filosofia, elas não tem nenhum valor se elas não representam a filosofia que as originou. E é o que tem acontecido. Eu já vi isto acontecer na prática. Equipes indisciplinadas que acham que projetos ágeis são projetos onde não há prazo e todo mundo faz o que quer porque não tem “gerente” mandando você fazer as atividades do projeto. Seguir esta filosofia requer muita disciplina, muita mesmo! Scrum, quando bem aplicado, também vai tornar muitos problemas da organização visíveis, coisas que todo mundo sabe mas que fingem não existir. Membros da equipe que não tem nenhum compromisso com o time, por exemplo. Aí entra outra questão: o que a empresa vai fazer com isto? Vai tentar resolver estes problemas ou vai “empurrar com a barriga” com normalmente é feito? Se a opção for a segunda, nada vai mudar. Uma metáfora que eu gosto de usar é a seguinte: se você me perguntar se eu quero levar uma vida saudável eu vou te dizer que sim, que quero muito, mas se você me perguntar se eu quero acordar as 5:30 da manhã para correr 10 Km eu vou te dizer que não! A vida saudável custa caro. É como está descrito no artigo: todo mundo quer a sobremesa, mas ninguém quer os vegetais! Resumindo tudo: em termos de práticas o Scrum é muito mais fácil que uma metodologia tradicional, mas filosoficamente é infinitamente mais complexo, e o problema é que o que importa é a filosofia.

Marcos Sousa said:
Ricardo,

Você tocou em uma questão muito importante em relação a metodologias ágeis. Mas vejo também uma preocupação enorme de algumas empresa e profissionais buscando implantar metodologias ágeis, principalmente o Scrum, sem ter um conhecimento técnico em relação a metodologia.

Já vi empresas adotarem Scrum onde tinham os famosos "Scrum Masters" certificados que nunca tinham lido um livro de Scrum ou um livro sobre metodologia ágil. Infelizmente são pessoas "formadas" em um sensacional curso de 1 final de semana que tem nas esquinas por aí.

Há um artigo muito interessante do James Shore (http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html) que faz justamente um alerta a este tipo de comportamento onde "comem a sobremesa antes do prato principal".

ps: Há um resumo no InfoQ Brasil (http://www.infoq.com/br/news/2008/11/decline-of-agile)

Abraços,
Osvaldo,

Vou discordar de você quanto a parte filosófica do Scrum ser mais complexa que metodologias não ágeis, como o RUP por exemplo.

O grande lance de qualquer metodologia que já conheci é exatamente enteder e aplicar sua filosofia. Por isto acredito que bem aplicado (de acordo com filosofia) tanto o RUP quanto o SCRUM vão produzir bons resultados. Me arrisco a dizer que o RUP, por ser mais abrangente, tem mais chances de sucesso.

O grande problema de metodologias como o RUP é que chamam mais a atenção para seus artefatos. Ou seja, estou cansado de ver equipes produzindo dezenas de artefatos que não serão usados para nada e que, de fato, não representam nada.

Os métodos ágeis, entre outras mudanças filosóficas, aumentaram o foco nos entregáveis de software ( o que já era um principio não compreendido do RUP) e aboliram os outros artefatos (não proibiram, apenas abandonaram a sua formalização). O Scrum fez isto esquivando-se da definição de um processo de engenharia de software e restringindo-se a um processo de gerência de projetos de software.

E, neste ponto, volto ao assunto principal da discussão: Não creio que o Scrum é quem vai ditar as atividades arquiteturais no projeto. Elas são sim influenciadas pelo Scrum, porém ainda continuo a criar uma arquitetura executável no primeiro sprint do projeto como forma de mitigar riscos técnicos. Procuro também aplicar o bom senso ao definir o selected product backlog usando as definições do product owner (como reza o método), mas também selecionado os requisitos mais complexos ou que irão permitir uma maior abrangência do ponto de vista arquitetural. Continuo escrevendo casos de uso e realização de casos de uso para requisitos mais complexos, mas aproveito do desprendimento burocrático da filosofia ágil para não perder meu tempo fazendo desenhos para casos de uso elementares como um CRUD simples.
Colocando lenha no fogão, recomendo o post do Eros sobre XP e (ausencia de) Arquitetura de Software. Bem instigante e reforça a minha crítica sobre o XP para projetos de grande complexidade.
Qual a opinião suas?
Gustavo,

Você está certo quanto à filosofia de qualquer processo ser o mais difícil de compreender e aplicar; fui eu quem me expressei mal, fui muito impreciso ao usar a palavra filosofia. O que eu realmente queria dizer é que existe uma diferença muito mais sutil entre uma metodologia como o RUP e as metodologias ágeis. Esta diferença está no aspecto formal/informal ou objetivo/subjetivo.

Uma metodologia é um método para se conseguir um fim. Se formos criar uma metodologia para fazer sapatos, por exemplo, observaríamos o trabalho de um artesão e formalizaríamos o seu método de trabalho, para que o mesmo pudesse ser replicado. Extrairíamos o conhecimento que o artesão tem, mas que está subjetivo, e formalizaríamos o mesmo, tornando-o objetivo.

O problema é que se pensarmos nas metodologias ágeis desta forma vamos chegar a um beco sem saída, porque nestas metodologias os aspectos menos formais (pessoas, interações, código, colaboração com o cliente e resposta a mudanças) são mais importantes que os aspectos formais (processos, documentação abrangente, negociação de contrato e obediência a um plano de projeto). É um paradoxo: é um método que dá mais valor a aspectos não formais e subjetivos!

Acredito que a idéia destas metodologias é não descer muito nos detalhes de como o software está sendo feito. Elas vão até um determinado ponto a partir do qual fica a cargo do time decidir o que é melhor. O que vai ter que ser observado para o preenchimento deste vácuo são preceitos subjetivos como comunicação, por exemplo. O problema é que quando o time escolhe o seu conjunto de práticas dentre deste espaço livre estas podem não estar em sintonia com a filosofia ágil.

Resumindo tudo: o que eu quis dizer foi que nas metodologias ágeis existe um espaço muito maior para a subjetividade do que em uma metodologia como o RUP o que torna a verificação da aderência de um projeto a tais metodologias muito mais difícil.

Voltando à questão principal, e já emendando com o post do Marco, acho esta questão sobre design e arquitetura muito relevante. Não consigo imaginar um projeto grande onde discussões sobre a arquitetura não existam inicialmente. Acho que as metodologias ágeis tiveram um papel muito importante na criação de um concenso de que é muito difícil criar uma arquitetura completa para um grande projeto no início do mesmo, mas também acho que o extremo oposto, nenhuma planejamento de arquitetura, pode ser tão maléfico quanto. Além do que tem um potencial muito grande de esconder deficiências dos envolvidos quanto à habilidade de criar uma arquitetura, de ver o sistema sob uma ótica mais geral; algo que não é fácil, que depende de muita experiência. Como filosofia acho que o melhor caminho é o caminho do meio: deve ser criada uma arquitetura básica e geral tendo em vista o escopo inicial do projeto e a mesma deve ser incrementada e revista a cada iteração. No campo das práticas eu achei muito interessante a idéia as estórias do desenvolvedor, mas não consegui ver o artigo apontado no post. Alguém aqui tem o artigo?

Abraços.
Concordo com várias opiniões levantadas neste post. Realmente, é muito polêmico este tipo de discussão. Como disse o Ricardo Ferreira, ágil nem sempre quer dizer rápido. Acredito que um ponto problemático deste tipo de metodologia se encontra neste assunto. Uma vez que se acredita ser mais "rápido" utilizar esta metodologia, muitas empresas resolvem abrandar e, em alguns casos, remover o papel de arquiteto quando utilizada as metodologias ágeis. Deve-se ressaltar que, mesmo utilizando uma metodologia ágil, a empresa precisa ter a visão de que há a necessidade de se ter um planejamento sobre as ações e deve-se agregar valor sobre o que se está produzindo e que o arquiteto, acredito eu, é uma peça fundamental para estas e outras características.

Apesar de algumas metodologias ágeis "parecerem" simples, é preciso agregar organização e experiência para que possa produzir resultados positivos. Como mencionado pelo Marco, as vezes temos pouca capacidade aplicada pelos profissionais na organização e gerência do processo ágil. Um outro item que pode ser um obstáculo é a falta de preparo e, muitas vezes, a falta interesse em proporcionar este prepara para as pessoas certas.

Acredito que, independente de qual metodologia é utilizada, a arquitetura de um sistema deve sempre ser avaliada e considerada na estruturação de um projeto. A aderência de um determinado projeto a uma metodologia ou outra depende, em um dos fatores, de como o arquiteto irá proporcioná-la. Por isso ressalto o importante papel do arquiteto dentro da organização, independente de qualquer metodologia.

RSS

Evento TDC2016

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço