Apenas uma recomendação de um post que li na InfoQ: Challenges in Adopting Scrum.

Um texto bem legal, que mostra que SCRUM, apesar de bem legal e interessante, não vai salvar o mundo nem fazer os terroristas do oriente médio virarem gente boa. Mostra que não adianta aplicar Scrum por aplicar, mas sim que é necessário antes de tudo, um bom entendimento do seu cenário/problema/contexto.

Segue um dos problemas encontrados, que eu achei mais interessate:

Using Scrum as a fix, without knowing the problem – A new methodology should not be adopted because of the hype surrounding it. An organization should try to define their expectations and measurement criteria. Answering questions like ‘Where does the current process hurt?’, ‘What caused the hurting?’, and ‘What would we be able to do when the hurting has stopped?’ would help define objective expectations and measurement criteria.

Bem legal, vale a leitura sim!

Até,

Uma coisa que pensava bastante durante o curso que fiz de CSM, foi na agilidade que teríamos se implantássemos SCRUM onde trabalho.

Sempre consegui visualizar um projeto usando SCRUM totalmente auto-contido, algo como minha própria empresa, ou um projeto com poucas pessoas e foco centralizado, e pensando assim, imaginava como lidar com cerca de 200 pessoas distribuídas em projetos de poucas pessoas, porém projetos muito dependentes entre si, o que na visão inicial que tive de SCRUM, cairia por terra.

Foi aí que no curso o instrutor veio com a história de Scrum of Scrums, que como o nome mesmo diz, seria colocar para funcionar reuniões com pessoas de cada equipe scrum, fazendo uma equipe “acima” daquela outra. E bem nessa questão “acima” foi que eu comecei a pensar e percebi que estaríamos instaurando mais uma hierarquia (hierarquia esta que o Scrum deveria ajudar a inibir, na minha opinião). Mas ok, tudo pelo bem da agilidade.

Hoje, lendo um blog, comecei a ver que se realmente nós tivessemos implantado SCRUM lá, teríamos na reunião de “chefes”, ou seja, na Scrum of Scrums, teríamos realmente uma bagunça, (mesmo segurando a caneta piloto vermelha) visto a quantidade de pessoas que teriam na reunião. Este blog falava justamente da ineficiência de escalar scrum usando o scrum of scrums, afinal, uma vez que você tem muitas pessoas envolvidas, vai começar a precisar de Scrum of Scrum of Scrums, ou como ele colocou, S3, e como ele mesmo disse no artigo, você estaria começando a beirar a imbecilidade. 

Neste artigo Will Read coloca uma possibilidade de comunicação inter-grupos para resolver o problema da ineficiência do SoSoS, de acordo com ele,  desta maneira acaba-se com a repetitividade de informações e de um modo mais objetivo e rápido os grupos todos se comunicam e a informação flui…

 

Com certeza vale a pena dar uma lida no blog, acesse aqui.

Alguém tem alguma experiência com este nível de projetos e equipes em SCRUM? 

 

Meu momento frustação… Já fiz o curso, leio bastante sobre scrum e metodologias ágeis, mas infelizmente não coloco em prática… Eu ainda vou trabalhar em um projeto com SCRUM um dia, alguém me ajuda? 

 

 

Semana passada eu havia visto este post, acabou passando em branco. Em função até do comentário do Marcos no post de Grails x Rails ter citado, acho que vale a pena deixar o link fácil pra quem precise:

Parte 1: http://thevirtualmachine.wordpress.com/2008/11/13/reducing-grails-deployment-size-by-a-lot/
Parte 2: http://thevirtualmachine.wordpress.com/2008/12/04/reducing-grails-deployment-size-part-2/

 

[]s,

Lucas

 

Bom, um dos cenários que eu mais tenho visto ultimamente em alguns dos lugares onde tenho passado, é quando o cliente quer disponibilizar um serviço para algum terceiro, porém faz questão (e está certo), que a partir do ponto de entrada do terceiro para o barramento de serviços do cliente esta requisição seja processada de forma totalmente assíncrona. 

Com isso, o cliente (que está processando a requisição) ganha em poder de processamento, e o terceiro (que está gerando a requisição) não percebe o que se passa “under the hood” (eu realmente gosto desta expressão), sendo para ele indiferente o que acontece durante o processamento.

Basicamente, este contexto é uma implementação de um Web-Service que utiliza como meio de transporte uma Fila JMS, ao invés do protocolo HTTP que é usado de costume.

Então, vou colocar aqui um exemplo de como fazer isso usando o Aqualogic Service Bus da Oracle (já era um produto da BEA).

Serão 3 pequenas aplicações para isto.

 

• Aplicação Legacy (é um costume horrível chamar estas aplicações de “legadas” visto que em grande parte dos processos de implementação SOA nas empresas, elas são reconcebidas, ou sofrem pelo menos, muitas alterações): É a aplicação que efetivamente possui a lógica de negócio, receberá a requisição do cliente e devolverá a resposta já processada.

• Configuração do Service BUS: Trata-se da exposição do serviço criado na aplicação legada no service BUS, como uma operação.

• Aplicação Tester: É a aplicação que irá consumir o serviço da aplicação legada, através da operação e endpoint disponibilizado no Service BUS.

Um desenho bem feio, mas aproximado deste cenário poderia ser este abaixo (clique para ampliar)

 

 

Diagrama do exemplo (clique para ampliar)

 

Bom, como meu tempo aqui se resume a pequenos intervalos onde eu poderia escrever isto, vou separar em 3 partes, uma para cada aplicação, um post para cada. Assim que der eu já começo!

Valeu!