Rafael Noronha

Aqui tentarei contextualizar o cenário que envolve as experiências que me levaram a escrever esta série de posts.

Nossa equipe

O SDC conta hoje com quase cem profissionais.

Somos um time multidisciplinar e que apóia o processo de desenvolvimento de modo iterativo e incremental.

O maior patrimônio de nossa equipe é a cultura:
Não possuímos níveis hieráriquicos rígidos, não tratamos nossos profissionais como recursos, não possuímos gerentes de projetos que micro-gerenciam atividades.
Isto porque valorizamos nossos profissionais e acreditamos que eles são completamente capazes de cuidar da organização de seus projetos.

Um de nossos maiores desafios tem sido escalar esta cultura, devido ao fato da equipe vir crescendo bastante para dar vazão às demandas de nossos clientes.

Nossos serviços

O cliente

Esta série de posts é um apanhado das minhas experiências dentro do SDC.
Venho atendendo a um único cliente desde minha chegada ao SDC.
Trata-se de uma instituição financeira de grande porte.

Como eu disse no post de inauguração da série, grandes corporações estruturaram-se de modo que área de negócios e área de TI se conflitem, baseando seu relacionamento em um processo rígido e burocrático.

Agile na Cascata?

A motivação para compartilhar a experiência de minha equipe vem do fato de atuarmos em um cenário ainda um tanto quanto estranho para os partidários da Agilidade.

Nós reconhecemos a dificuldade de implantar Agile no cenário de outsourcing, (des)amparados pelo modelo de fábrica de software.
No entanto, temos tido sucesso na adaptação da cultura e práticas de agilidade a este cenário, e é sobre algumas das lições aprendidas que estarei escrevendo nesta série de posts.

Nos próximos textos a serem publicados por aqui, estarei compartilhando algumas experiências vivenciadas por minha equipe, de algum tempo pra cá.

A idéia é mostrar como nós temos atendido demandas de projetos de software de um grande cliente do setor financeiro.

É de conhecimento da comunidade que grandes instituições financeiras tipicamente possuem uma área de TI burocratizada, que viciou-se em atender a área de negócios através de um modelo rígido e baseado em ciclos, também conhecido por waterfall.

O que estariam eu e minha equipe, agilistas ferrenhos, desempenhando dentro deste cenário?
Nos próximos posts!

Aconteceu o Agile Brazil 2010.

O evento ocorreu na bela cidade de Porto Alegre, e eu estive por lá:

Pessoal da Stefanini compareceu em peso no evento.

Um dos aspectos positivos foi a quantidade de participantes, que girou em torno de 800 pessoas.
O número superou a expectativa dos organizadores, que mandaram bem em disponibilizar a infra-estrutura necessária para comportar o público.

Martin Fowler foi o responsável pelo keynote que deu início ao evento.
Dentre outras coisas, seu discurso abordou um pouco da mentalidade que deu origem à comunidade.

Não me dei muito bem com a programação do primeiro dia de evento.
De relevante gostei de ouvir a experiência do pessoal da DBServer, que também estão preocupados em agregar valor ao negócio de seus clientes, e expuseram os modelos de contrato sobre os quais seus projetos têem sido vendidos.

Já no segundo dia, gostei da palestra do James Lewis, da ThoughtWorks, que apresentou uma série de anti-patterns vivenciados na implantação de práticas ágeis.

O destaque positivo fica para o keynote de encerramento, que foi dado pelo Klaus Wuestefeld, e vou explicar o porquê no balanço que fiz do evento:

A conclusão que tiro do Agile Brazil 2010 é que ainda temos muitas lições a aprender.
Acredito que antes de qualquer coisa, a motivação por trás das práticas ágeis é a de entregar, com frequência, maior valor de negócio ao cliente final de um projeto de software.
O que tenho visto na comunidade ágil é a ineficiência na transmissão desta motivação.

Destaquei o keynote do Klaus pois ele se mostrou muito mais preocupado em extrair maior resultado de seu trabalho do que seguir receitas de bolo. E expôs suas idéias com muita clareza e propriedade.

Concluindo, espero que o amadurecimento da comunidade se acelere daqui para frente, e que a transmissão dos valores do manifesto ágil não se perca em meio ao hype que tem tomado a indústria.

Ter em mãos um conjunto pré-definido de boas práticas a serem consideradas no início de um novo projeto pode ser muito positivo.

No entanto, algo muito negativo pode decorrer do reconhecimento de boas práticas:
A falácia de interpretá-las como verdade absoluta, um modelo rígido a ser seguido.

A verdade é que não existe resposta fácil na disciplina de engenharia de software.
Boas práticas são importantes sim, porém estas devem ser consideradas e contestadas conforme as características do contexto existente.

Segundo Taiichi Ohno, autor do sistema de produção da Toyota, se você enxergar um modelo como solução para todos os problemas, então a motivação pela busca por melhoria contínua deixará de existir.

Além disso, antes de enxergar uma determinada prática como algo importante para o alcance dos objetivos de seu projeto, saiba exatamente o que esperar do emprego desta prática, e qual o custo-benefício envolvido.

E para concluir, vale lembrar também do primeiro item do manifesto ágil:
Indivíduos e interações são mais importantes que processos e ferramentas.

Este texto está disponível apenas em Inglês.