Scrum e Estratégia
Se Scrum é completamente sobre curto prazo, como os caras da estratégia trabalhariam neste ecossistema?
Rastreando mudança e inovação na comunidade de desenvolvimento de software corporativo.
Apresentado por Alexandre Gomes em 21 Mai 2009 09:56 AM
Muito bom. Parabéns ao Alexandre pela palestra e a toda a equipe da InfoQ Brasil publicação.
Trabalho com esse paradigma em algumas empresas grandes (com muito legado) e acompanho o trabalho de Jimm Webber, por isso gostaria de acrescentar mais um ponto: promover o alinhamento com o negócio (ou processo de negócio) seguindo alguns princípios SOA, por exemplo, encapsulando o domínio do serviço (legado ou não). Esses princípios não estão relacionados com tecnologia, mas com design.
Gosto deste artigo do Jim Webber: “But there is a more sensible way to SOA, which maintains loose coupling and drives high cohesion and the secret is this: build your services to implement business processes. Don’t let the data guys scream at you that you need an enterprise data model (you don’t) and don’t let the application portfolio guys demand that you buy everything and stitch it together later (you can’t, this only gets you Frankenstein systems).” Anemic Service Model , Jim Webber, Ph.D. Global Architecture Lead, ThoughtWorks.
Atualmente, muitas empresas sem uma abordagem SOA possuem iniciativas de reuso e integração isoladas, baseadas em iniciativas individuais. Funcionando em um delicado equilíbrio, os desenvolvedores reusam seus próprios serviços ou de uma pessoa em que confiam, ignorando todos os outros possíveis serviços existentes. Esse cenário de reuso limitado, possibilita que empresas complexas, com integrações espaguete, funcionem, pois existe um nível de controle até certo ponto gerenciável, mas abrindo mão da agilidade.
No entanto, se o reuso dos serviços legados for promovido em larga escala, sem observar alguns princípios SOA, esse equilíbrio pode ficar comprometido. O que inicialmente pode parecer um ganho, com o efeito acumulativo, deixará muito mais complexo o cenário.
Para exemplificar, vamos imaginar um serviço legado de lançamentos contáveis que não encapsula todas as regras de negócio necessárias para efetuar o lançamento (não segue princípios SOA). Desta forma, todos os clientes deste serviço será obrigado a implementar algumas regras antes de usar. Neste exemplo, no mínimo, o serviço vai promover a redundância de regas de negócio para seus clientes.
Multiplique isso por 40 serviços e 200 sistemas, depois tente alterar um processo ou rega de negócio com agilidade... Se o negócio mudar, simplesmente será imprevisível o impacto em seus sistemas.
Para evitar esse problema e muitos outros, o serviço poderia ser encapsulado ou alterado para que atenda alguns princípios SOA, possibilitando que seja reutilizado por todos sem aumentar a complexidade e a redundância de regras. Portanto, os princípios SOA ajudam essencialmente no controle da complexidade, para lidar com limitações humanas como, por exemplo, memória.
Gustavo,
Concordo com o que você falou e em minha opinião para evitar esse impacto imprevisível, basta tratarmos as definições dos serviços a nível de estratégia de negócio.
Quando você quer oferecer um serviço para alguém, você deve deixar muito claro que serviço é esse e qual é o objetivo dele. Definir quão completo e robusto ele deve ser e também quão flexível. Definir um contrato a ser cumprido.
Apesar de que percebo que no mundo de SOA, muitos lerão o que escrevi acima e pensaram em termos técnicos, porém estou falando apenas em termos de negócio. A parte técnica deve ser escolhida e arquitetada de forma que atenda ao que foi definido acima com o menor esforço possível e com a maior simplicidade possível.
Felipe, esse é realmente um desafio constante: mostrar que SOA não é um monte de WS-*.
Concordo, contratos bem definidos (DbC) são fundamentais e simplicidade (usar a essência do negócio e não o simplismo) é o único caminho para organizar a TI e proporcionar respostas rápidas.
Vamos para guerrilha!
Gostei da forma como a palestra foi conduzida !!! NOTA 10
Se Scrum é completamente sobre curto prazo, como os caras da estratégia trabalhariam neste ecossistema?
Este artigo explica o porquê a adoção de Agile falha em algumas organizações.
Esse artigo apresenta o seguinte autoquestionamento: Eu seria liderado por mim mesmo? Essa é uma pergunta direta, porém,respondê-la é enormemente complicado.
ORMs estão na moda nos dias de hoje por uma boa razão: eles podem fazer o desenvolvimento de aplicações baseadas em banco de dados rápido e sem dor.
Os novos conhecimentos em neurociência (neurociência social, psicologia positiva e técnicas de imagem) nos dão ferramentas para entender e ampliar a habilidade de homens e mulheres trabalharem juntos.
Esse texto almeja gerar uma reflexão na forma como os times estão tratando os impedimentos que aparecem em seu cotidiano.
Este artigo aborda os desafios para adoção de métodos ágeis dentro da empresa e as estratégias para enfrentá-los.
Gerenciar a produtividade e o cronograma em um projeto é sempre um desafio devido à complexidade na tomada de decisões. Neste artigo, tentamos usar o gráfico burndown para endereçar este problema.
5 comentários
Acompanhar Discussão Responder