Projeto EAGLE

Apresentação

Quando foi que perdemos o com.passo?

Aonde estão as chaves?

De minha primeira Grande Visão

Revolucionando a Gestão Teconológica

A Metáfora do Elefante

Em Busca de Equilíbrio e Lucidêz

Cloud Computing

Encarando a nossa realidade

A Informação em Perspectiva

O Projeto EAGLE e os seus Dados

Índice

Em busca de equilíbrio e lucidez

Iniciativas Agiles

Creio que podemos classificar inciativas como Extreme Programming (XP), Agile Programming “Model” (APM) etc., como reações lógicas, e compreensíveis, a metodologias de desenvolvimento de software altamente formalizadas; principalmente [creio eu] porque estas – “no final do dia” – não parecem atingir, com verdadeiro sucesso, o objetivo a que se propõem.

É inegável que tais iniciativas representam muito, introduzem ótimos conceitos, e – potencialmente – agregam grande valor (financeiro inclusive) às nossas organizações. Mas pecam, quando consideradas no âmbito de corporações de médio-grande porte, por sua “extrema” simplicidade. Ao negar peremptoriamente o valor (conceitos, contribuições etc.) de aprendizados e “iniciativas” anteriores (largamente utilizadas e aprimoradas por décadas), “simplesmente” movem o “pêndulo” para o lado oposto, enquanto “jogam fora o bebê, junto com a água suja”.

Tais iniciativas, muito embora possam ser, e de fato têm sido, implementadas com grande sucesso em empreendimentos de pequeno-médio porte, como no desenvolvimento de jogos, aplicativos móveis (mobile apps), sistemas isolados (standalone, Independent Software Vendor – ISV) por exemplo; certamente não satisfazem os requerimentos de ambientes mais “robustos” e complexos. E por isso “falham”, ou são, neste caso, insuficientes; a menos que sejam devida e propriamente “estendidas”, complementadas e “enriquecidas”. Principalmente porque, neste caso, os requerimentos (user stories) são mais complexos, e demandam “controle(s)” e/ou especificações mais “formalizado(s)”.

Por outro lado, as nossas corporações, por mais “exigentes” que sejam, não deve(ria)m “virar as costas” a tão valorosas iniciativas; dado que existem aí conceitos e procedimentos que podem (e deveriam), de fato, contribuir em muito para as nossas tão almejadas metas de produtividade, TTM, ROI etc. Afinal, o que é um Backlog senão um conjunto centralizado e controlado (priorizado) de requerimentos; flexível e dinamicamente gerenciado? E o que é um Sprint, além de uma estratégia contextualizada e controlada de desenvolvimento – e entrega [delivery] – de funcionalidades (leia-se “business value”), de forma previsível e mensurável (monitoring), além de facilmente testável e repetitivamente reproduzível (quality assurance).

Não é isso o que todos buscamos? Não estamos, no fundo, falando da mesma coisa [tocando o mesmo elefante]? O que precisamos, portanto, é encontrar o equilíbrio, o “caminho do meio”, do encontro, entre estas categorias de iniciativas aparentemente antagônicas e/ou auto excludentes. Afinal, o que conta, de fato, no final, são os resultados.

Certo?

↑ Topo ↑
 
Anúncios

Deixe um comentário

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

%d blogueiros gostam disto: