Semana passada estive na Sociesc conversando um pouco sobre desenvolvimento ágil na Semana da Computação, realizada entre os dias 23 e 28 de agosto. Falei um pouco da minha experiência pessoal com desenvolvimento de software e no que estou trabalhando atualmente.

Segue o vídeo da apresentação:

Correções:
*Fiz um comentário sobre uma fábrica de software com mil programadores no Refice. Não sei porque falei esse número. É uma empresa com no máximo 400 funcionários.
*Logo após eu falei que NÃO sou especialista em nenhuma metodologia ágil e por isso não iria entrar em detalhes em nenhuma delas (aka XP, scrum, kanbam)

Alguns dias atrás eu comentava com um colega de trabalho, sobre o meu sentimento de que o “agilismo” (ou seja lá qual for o termo) já se tornou a moda da vez. Os “xipezeiros”, “scrunzeiros” e agilistas de plantão estufam o peito pra falar dos seus “sprints”… que utilizam quadros brancos… que tem post-its colados por toda empresa… que UML  não serve pra náda… e que ser ágil é sentar e sair programando.
Tenho o sentimento que muitas pessoas e consequentemente empresas, se juntam a manáda e começam a utilizar alguma metodologia, porque alguém disse que é bom, ou porque o blog do momento falou que é “cool” ser ágil.

Qual a empresa de tecnologia hoje, ser arriscaria a dizer para seu cliente que não é “Ágil” ?
Todo mundo tenta desesperadamente ser ágil.
Até a IBM, quer ser ágil.

Tenho a impressão que essa busca incansável, é motivada principalmente por 2 coisas:

- a primeira é que já sofremos muito durante os últimos anos  tentando fazer software
Quem já trabalhou numa fábrica de software, numa consultoria de 3 letrinhas, já encarou caso de uso de mais de 100 páginas, ou quis modelar um ERP inteiro em UML antes de começar a programar, sabe bem do que estou falando. Para quem já está na labuta a pelo menos uns 10 anos e passou por tudo isso já aprendeu que algumas coisas nem sempre funcionam. E vêem o agile como a melhor opção disponível para desenvolver software atualmente.

- a segunda é a falsa idéia de que as metodologias ágeis pregam… não utilizar metodologia alguma..!!!
Isso é fato quando se vê muita gente em fóruns e afins, falando que na suas empresas não tem análise, não tem documentação ou burocracia alguma...que após uma reunião, todos os programadores se debruçam-se sobre seus teclados e se põe a codificar até que algo seja “entregável” para o cliente.
Bem, IMHO isso me parece muito mais um XGH…. ou um “Just Do-it Programming” disfarçado de scrum.
Acho que muita gente que está entrando no mercado de trabalho recentemente (a uns 3 ou 4 anos), diz que utiliza XP, Scrum, Lean ou qualquer metodolgia ágil porque tem a ilusão de que é fácil de implementar.

“Se não tem documentação… não tem formalidade alguma….se é só fazer uma reunião de 15 min durante a manhã e programar durante o resto do dia… eu também posso ser ágil… vamos implementar isso aqui na nossa empresa !!!”

Essa é uma das maiores falácias do desenvolvimento de software. Por experiência própria, eu posso dizer que aplicar uma metodologia como Scrum ou XP na prática numa empresa e obter resultados positivos é um trabalho árduo. É difícil e vai requerer uma paciência que você achava que não tinha. Ao contrário do que muitos pensam, aplicar algumas práticas do XP, como o TDD por exemplo, vai exigir muito mais disciplina de uma equipe, do que se ela estivesse trabalhando numa fábrica de software com CMM5.

Com tudo isso, surgiram inúmeros cursos Scrum e XP por aí… apareceram centanas de especialistas em agile, que prometem demonstrar um conjunto de práticas para tornar qualquer empresa ágil…acabando com seus problemas de escopo, prazo e relacionamento com o cliente.

A verdade é que não existe uma fórmula, ou receita de bolo pra isso. A bala de prata não existe. Cada empresa tem uma caracterísitca….cada projeto tem um contexto… que faz com que seja necessário escolher as melhores práticas em cada situação.

A melhor idéia de agile que tenho até o momento, foram as palavras de Philippe Kruchten no seu keynote no final semana passado, no agile brazil 2010:

“Software development is not a Natural Science like Physics or any other. In Agile Software Develpment, we have different methods (aka: scrum, xp, lean) for diferente issues. We have to ask ourselves which practices or methods will fit better in our project context”

“Why we’re using XP ? What practices will fit better in these project ? … and why we’re doing this any way?”

Você consegue imaginar a utilização de XP no desenvolvimento do software que contola um caça F-35 ?

Xispezeiro: “Sem problemas,  nessas duas primeiras semanas vamos entregar a parte que faz ligar o motor e você já pode decolar com o avião”
Piloto: “E o controlador de vôo ?”
Xispezeiro: “O que ? O controlador de vôo ? Mas você vai precisar disso mesmo ? O mais importante agora é decolar… depois conversamos sobre o controlador de vôo…”

Não conheço náda de aeronáutica, mas é bem provável que um projeto de desse tipo seja obrigado a ter uma fase muito detalhada de design e documentação, porque um erro de projeto, pode gerar um prejuízo estratosférico.
E gerar muita documentação nesse caso está errado? Você faria uma reunião de 4 horinhas pra modelar uma funcionalidade num F-35 ?
Claro que esse é um exemplo extremo, mas existem muitas organizações e ramos de negócio que precisam de mais formalidade e provavelmente teriam muitas dificuldades implementando métodos ágeis.
Por isso que contexto, é fundamental.

Com toda essa confusão de post-its e sprints do falso agile, os verdadeiros valores do manifesto ágil acabam ficando em segundo plano para maioria das pessoas. Acabamos desconsiderando o mais importante: o contexto no qual estamos tentando implementar agilidade.

Por que estamos utlizando essa metodologia ? Qual o problema que estamos tentando resolver ? Essas práticas se encaixam no contexto desse projeto ?

Alguns dias atrás, me vi numa discussão com alguns colegas, sobre funções, atividades e cargos dentro de uma empresa. Apensar desse assunto ainda ser bem confuso em TI, a maioria soube descrever suas atividades diárias como programadores. Porém, essa descrição não foi obtida tão facilmente quando nos perguntamos: Afinal de contas, o que um “Analista de Sistemas” faz ?

Alguns me falaram que o analista de sistemas é um profissional com mais experiência, com perfil investigativo, que deve fazer a análise dos requisitos e modelar uma solução. Outros disseram que analista de sistema não devem “perder”  tempo com detalhes sobre linguagem ou tecnologia, porque “análise” de sistemas deve ser feita em alto nível, a.k.a UML. Escutei também alguns comentários clássicos: analista de sistemas necessariamente não precisa saber programar, precisa apenas conhecer UML e algum editor de texto. ( “analistas de sitemas não precisam saber programar…”. Com certeza essa merece estar nas próximas falácias da programação, parte ll … hehe )

Sobre esse assunto, tenho que dizer que concordo com Barry Hawkins: a super divisão de trabalho no desenvolvimento de software, foi umas das piores experiências da indústria de software nos últimos anos.

One of the most widespread tragedies in the practice of software development has been the tendency of corporate culture to over-compartmentalize the activities of software development. In the upper echelon of the artificial hierarchy of task separation sits the software architect. Sequestered away from the disturbing din of real life within the company, these persons are liberated from the mundane, in order that they may orchestrate plans that set in motion the work of many, unfettered by such things as domain knowledge and implementation constraints.
Know this; the only people who belong in white towers are the captured princesses of fairy tales, and even then it was not of their volition. Partitioning the activity of design away from implementation destroys the call-and-response cycle between design and implementation. The relevance of your work is directly related to how engaged you are in the domain.
- Barry Hawkins.

Estou convencido, que a separação das atividades de design e programação deveria ser qualificada como um anti-pattern do desenvolvimento de software. O waterfall já vem mostrando por anos, que essa abordagem é um erro.

Porque é necessário criar um cargo especial para atividades, que deveriam ser de responsabilidade do programador ?! Análise, design, programação e arquitetura são atividades e não cargos. Nós, como programadores, precisamos vestir “chapéus” diferentes dentro de um projeto.

Quando questionamos requisitos, buscamos informações de nossos usuários, organizamos e priorizamos tarefas, estamos vestindo nosso chapéu de analista e gerente de projetos. Quando estamos codificando, nos preocupando com manutenabilidade, performance e com a correta aplicação de patterns, estamos vestindo nosso chapéu de programador e projetista. Ao escolhermos por um framework, por uma API, estamos com certeza tomando decisões de arquitetura.
Não quero dizer aqui, que todo programador dever ser um  Macgyver em TI. Mas tenho certeza, que se você é programador, é bem provável que você precise colocar à prova diariamente suas habilidades como programador, analista, arquiteto ou gerente.

A maioria dos programadores passam anos querendo se tornar analista de sistemas, e quando conseguem, descobrem que como programadores, já desempenhavam atividades de análise a muito tempo. Além do mais, achar que um monte de diagramas UML podem modelar um sistema inteiro sem programar uma linha de código, não é algo muito inteligente. Analistas, arquitetos, projetistas, seja lá como for o nome que deram para ele, mas esse cara precisa saber programar -  If you design it, you should be able to code it - Mike Brown:

When designing the architecture for your project, you need to have a feel for what amount of effort is necessary to implement the various elements of your design. The easiest way to have the knowledge of the effort that a specific design element will take is to have developed it before.

Don’t use a pattern in your design that you haven’t personally implemented before. Don’t rely on a framework that you haven’t coded against before. Don’t use a server that you haven’t configured before. If your architecture depends on design elements that you haven’t personally used, there are a number of negative side effects. Mike Brown

Muitas empresas de TI estão procurando “achatar” hierarquias, procurando manter profissionais mais qualificados, com conhecimentos multidisciplinares e que possam atuar em diversos papéis diferentes. Que possam programar, tomar decisões de arquitetura ou conversar com usuários se for necessário. Por mais que muita gente ainda pense o contrário: Profissionais competentes e equipes motivadas são fundamentais em qualquer empresa.

E mesmo que os “Analistas de Sistemas” ainda existam para enfeitar alguns crachás corporativos ou anúncios de RH, eu já deixei de acreditar neles já faz algum tempo …