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!

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

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.

Tendo como pano de fundo o cenário de software corporativo – estes que geralmente escrevemos em java ou .net.

Um bom domínio de ciência de computação, passando pela chamada escovação de bits, é imprescindível para a formação de um desenvolvedor de software?

Particularmente acredito que um desenvolvedor de uma plataforma moderna sobrevive bem, sem estes conhecimentos.
Mas aquilo que eu chamo de sobreviver está bem distante do que considero competências idealmente existentes em um profissional completo.

Então a coisa fica assim:

Você pode ser um bom desenvolvedor java/.net/[outra plataforma moderna] mesmo sem dominar ciência da computação.
Você não pode ser um desenvolvedor completo sem dominar ciência da computacão.
E por último, você não pode ser um arquiteto de software competente sem dominar ciência da computação.

E a sua opinião, qual é?