1up4Developers

Se você freqüenta este blog já deve ter percebido que nós não gostamos da maldita cascata. Fases bem definidas, detalhamento de requisitos, documentos inúteis, diagramas UML, papéis… tudo muito lindo na teoria. Eu fico até emocionado quando leio a documentação do RUP. Mas infelizmente a maioria dos profissionais de TI precisam são obrigados a trabalhar nestes ambientes cascateiros, enfrentando chefes sem noção, colegas com síndrome do funcionário público, prazos sem sentido, entre outras pérolas da área.

O principal apelo de um processo cascateiro são suas fases e papéis bem definidos, onde cada membro da “equipe” é responsável por uma determinada tarefa que é executada em uma seqüência previamente definida. Dentre os papéis, pode-se facilmente identificar os especialistas daquela tarefa, que defendem sua necessidade execução com unhas e dentes. Para ilustrar, resolvi chamá-los de guardiões, seja da tecnologia ou da atividade em questão. Um guardião protege sua fase, tarefa e interesses, defendendo-os para que o “processo” não seja quebrado. Desta forma, <sarcasmo> a “equipe” atinge seu objetivo: o software! </sarcasmo> Seguem alguns exemplos desses guardiões cascateiros:

O guardião do banco de dados: “Não rodarás nenhum script na base alheia“
Começo por este por ser o mais comum dos guardiões. Ele trata o banco de dados como um filho, mesmo que seja um adolescente que não obedeça inteiramente à 3ª regra normal. São vistos como semi-deuses, capazes de transcrever o modelo de negócio da empresa em uma linguagem de alto nível, impossível de ser compreendida por simples programadores. Protejem as tabelas com a própria vida e qualquer alteração na base de dados é motivo para um duelo até a morte! Utilizam um padrão para nomenclatura de campos que somente é conhecido pelo clã dos DBAs. Geralmente são seguidores do Oráculo, o senhor de todos os bancos de dados.

O guardião do projeto: “Guia-te pelo teu Gantt e serás recompensado”
Este guardião está presente em todos os projetos, garantindo que a palavra do Gantt seja cumprida, protegendo o escopo do projeto com a própria vida (ou a vida de algum programador). Adicionalmente atua como roteador de atividades: recebe os requisitos pelo email, encaminha para um recurso disponível (programador) que estima o esforço e define uma data de entrega, devolvendo para o guardião que atualiza seu Project.

O guardião do framework: “Venerarás o Struts e nada te faltarás”
O framework é o objeto de adoração deste guardião, nenhum outro framework é tão bom quanto o que ele venera. Ele provê solução para todos seus problemas simplesmente escrevendo um bloco de XML aqui, outro ali, mudando aquela linha acolá e estendendo uma classe X implementando aquela interface Z. Qualquer evolução do framework em questão não passa de uma tentativa frustrada de “reinventar a roda”.

O guardião da arquitetura: “Não usarás a instância do teu objeto em vão”
Uma variação interessante de guardião, que neutraliza seu oponente através de técnicas de tortura e perturbação mental, inundando as sessões de brainstorm com uma enxurrada de DTO’s, VO’s, Facades, EJB’s entre outros patterns que fazem a cabeça dos programadores entrar em conflito, até que seus órgãos faleçam (ou simplesmente se demitam). Geralmente são cúmplices dos guardiões do projeto, conspirando para a dominação do Gannt.

O guardião do root: “Teu processo não executarás no meu bash”
A jóia mais preciosa da empresa: a senha do root. Seu guardião é o mais honrado dos seres, sendo uma espécie de Frodo, protegendo-a com a própria vida pois uma vez em mãos erradas pode ser usada para a destruição da humanidade (ou apenas para reiniciar aquela instância do Tomcat travado em produção). Aquele que desafia este guardião perde o direito de executar seus processos como administrador local e fica vagando pelo filesystem eternamente.

O guardião dos guardiões: “Tua TI é um mal necessário”
Também conhecido como diretor, presidente, CEO, dono, investidor, sócio, etc. É o guardião das decisões, aquele que protege sua riqueza acima de tudo, economizando nos salários, contratando funcionários despreparados e investindo rios de dinheiro em consultorias e licenças de software para garantir seus investimentos.

Enfim, são guardiões dos próprios interesses. A “equipe” é apenas uma palavra que usam em discursos mas nunca aplicaram o conceito na prática!

Eu preciso desenvolver uma idéia que vem me provocando ultimamente. Na verdade é menos uma idéia do que um reflexo da situação desoladora em que a maioria de nós está.

Em se tratando de 1up4dev, nem preciso dizer que a situação a que me refiro é a de quase inevitabilidade do waterfall, em que estamos tão engolidos pelo “sistema” que, aparentemente, só nos resta lamentar, se frustrar e eventualmente se acostumar com tudo. Não deduzo, porém, que esses são estágios de uma manifestação de bunda-molice. Do contrário, seria suficiente encerrar o assunto com algo do tipo “ou somos parte da solução ou do problema” (doutrina Bush, em pleno 2008). E ainda assim, sem que ao menos sejam esboçados tanto “o problema” como “a solução”, esse raciocínio binário não serviria para nada.

Antes de continuar com a minha idéia, gostaria de escrever rapidamente sobre o panorama que se desenha para o futuro. Especificamente, o nosso futuro. Nem sempre lembramos dele, mas é lá que vamos viver em breve. E sem querer parecer auto-ajudesco, digo que o futuro do desenvolvimento de software está nas nossas mãos — e não de forma indireta ou abstrata. É lógico: as mãos que hoje controlam o “sistema” vão se aposentar daqui uns anos, e as nossas vão substituí-las. Nessa seqüência, é possível imaginar que, em breve, estaremos perpetuando o waterfall. Pois nesse dia nós é que seremos o status quo, e o status quo, para ser digno do nome, não quer saber de mudar nada.

Software já é estratégico há algum tempo e ocupará cada vez mais espaço na vida das pessoas, das empresas e dos governos. Que qualidade de software será oferecida quando nossa geração estiver no comando? Imagine o alto custo financeiro e social de se manter na periferia de TI. Sub-desenvolvimento passa a ter um novo significado, não é? Temos que assumir a responsabilidade, até porque ela pode significar a existência dos nossos empregos. Ou você vai preferir usar um software made in India?

Nada contra a Índia, claro. Mas o alerta já tinha sido dado por David Anderson no comecinho do livro Agile Management for Software Engineering. Abaixo traduzo livremente um trecho cujo original você encontra na página xxvi do livro:

Se a atividade intelectual de software tiver que permanecer nos países desenvolvidos e se os engenheiros de software americanos, europeus e japoneses quiserem manter o alto padrão de vida ao qual se acostumaram, eles devem aumentar sua competitividade. Há um mercado global de desenvolvimento de software, o que encolheu a distância entre um cliente na América do Norte e um fornecedor na China ou na Índia.

Esse medo do sr Anderson tem que ser nosso também (exceto que nós não temos como rebaixar nosso “alto padrão de vida”). Sabemos que precisamos melhorar, e muito, a nossa competitividade, e não só individualmente. Agora, a grande questão é: como vamos fazer isso, se não temos suporte para viabilizar novas formas de trabalho sem dispararmos o sinal de pânico no chefe, no cliente?

Pretendo desenvolver a minha sugestão em alguns posts, seguindo alguns princípios:

1. “Mudança” é definida como o amplo abandono da mentalidade waterfall no mercado de TI.
2. Você acredita na mudança e é o maior interessado nela, pois ela representa o futuro que você quer.
3. O risco da mudança é percebido com mais intensidade quanto maior é o poder de quem a observa.
4. O benefício da mudança é percebido com menor intensidade quanto maior é o poder de quem a observa.
5. A mudança pode ocorrer de baixo para cima na cadeia de poder.

No próximo post, pretenderei detalhar melhor os efeitos desses cinco pontos. Dali em diante, dificilmente irei sugerir uma ação coordenada e planejada — nada menos ágil que isso! Prefiro apostar no desenrolar natural das coisas, desde que os princípios sejam válidos. No mínimo, vamos avançar o debate. Tomara que eu não escreva muita besteira, e espero ser corrigido a qualquer momento.

Falta pessoal qualificado em TI, diz Assespro

http://www.guj.com.br/posts/list/15/92783.java#497015

Esta discussão está boa, e no meio das chamas levei um “impacto” ao ler a frase abaixo.

louds wrote: [...] Não usem a incompetência alheia como desculpa. Se está ruim e você não está ativamente combatendo isso, você é parte do problema e não da solução. [...]

Esta é uma das frases que eu deveria lembrar toda vez que começo a lamentar sobre o ambiente atual de trabalho, eu tento, me gerencio, mas confesso que é difícil.

Com o diabinho no ombro, logo ouvi um suspiro … Waterfall é bom ! Não questione … volte a codificar … Só que ao olhar pro lado, vi o meu poster do Dijkstra e voltei a realidade. Foi quando me perguntei:

Por que é difícil combater o Waterfall ?!?

Sei que esta é uma pergunta sem resposta direta e que depende de muitos fatores do seu ambiente de trabalho, mas eu numa análise fria e cruel respondo: Porque a maioria não sabe o que é waterfall.

No último ano da faculdade (cursei Sistemas de Informação), e sem brincadeira, nas aulas de Engenharia fui obrigado a decorar todas as fases, papéis, artefatos e etc. do RUP, e pra fechar com chave de ouro, no segundo semestre veio o famoso Análise de Ponto de Função. Isso somente prova que já aprendemos errado, e sei que muita gente fica nisso. Se hoje tivesse a oportunidade de encontrar este mesmo professor, iria fazer a pergunta acima, e acrescentar com questionamentos como, engenharia de software não é eng. civil e neste processo todo quem está preocupado com o Retorno de Investimento do cliente !?!

Acredito que a chave para combater o Waterfall é conhecimento, temos que trazer questionamentos a quem está do lado e isso não é nada fácil, como você convence os mais de vinte desenvolvedores que estão ao seu redor que eles estão na Matrix !?! O que fazer com o pessoal que não quer sair da Matrix !?! O Waterfall é uma grande mãe que coloca muitas pessoas (Analistas, Desenvolvedores, Gerentes, Testers … etc.) numa casca irreal de proteção e que gera um ciclo vicioso que se auto sustenta.

Neste exato momento que sou obrigado a concordar com o grande malucão Raulzito:

É pena não ser burro ! Não sofria tanto.

As vezes me questiono sobre esta insistência em tentar mudar, nadar contra o Waterfall. Não seria melhor se “render” logo e entrar no jogo, sei lá, poder falar, “Caso de Uso não é comigo, só programação!” e ver que são 10 pras 18, desligar o computador e sair sem o minimo peso na consciência.

Por que numa equipe de dez desenvolvedores, só eu sinto falta de testes unitários !?! Fico indignado ao receber um caso de uso que não agrega nada ao cliente, somente foi “inventado” pra ser cobrado dele, e só eu que vejo isso !?! Sei lá, eu devo estar maluco mesmo com toda esta historia de desenvolvimento ágil, e se preocupar com ROI do cliente, apesar de achar uns malucos por ai que sofrem do mesmo “problema” que o meu.

Como no filme dos 300, tenho esperanças e sei que poucos enfrentarão muitos, e continuo minha batalha com o Waterfall.

Paz a Todos !

Obs: Sei que o RUP é mal usado, pois uma brecha dele é ser muito genérico, e isto cada vez se confirma mais, que o modelo atual “tradicional” está falido.

Um post no estilo “remoendo coisas que passam pela minha cabeça”. À medida em que continuarem passando, aumento a FAQ.

1. Por que se fala mais de processos e ferramentas do que de indivíduos e interações?
   O item 1 do manifesto agile não me parece tão professado quando se observa a quantidade de informação dedicada a sistematizar — isto é, pôr em um processo — as alternativas agile. É da natureza do engenheiro colocar tudo em um diagrama?
2. Por que tanta gente (incluindo eu) prefere reclamar do emprego ao invés de arrumar coisa melhor para fazer?
   Parece haver uma terra prometida onde os projetos não atrasam, os clientes estão sorrindo, os chefes têm bom senso e os salários são muito bons. Lá você vai trabalhar quatro dias por semana e tem um andar com mesas de sinuca. Você acha que merece trabalhar lá, mas se conforma com “a situação”, que “é assim mesmo”, e ainda cobra pouco por isso.
3. Como metodologisificar* os projetos concebidos em erro?
   Imagine o seguinte: o cliente precisa cumprir uma meta, não vai conseguir e convenceu você a levar a culpa tocar o projeto. Não foi difícil te convencer, pois você precisa da fatura. Qual metodologia vai te salvar? Em casos assim, é sempre erro de negociação ou o projeto pode ser metodologizado* direito?

   *Dá pra sentir o quanto eu gosto da palavra metodologia

4. Por que é tão difícil segurar gente boa na equipe?
   Provavelmente o seu talentoso colega vai trabalhar num lugar que oferece praticamente as mesmas CNTP para a proliferação de programadores medíocres: projetos mal geridos, chefes acomodados, clientes insanos e café ruim. Tudo por 1 ou 2 reais a mais à hora. Por que tantas empresas insistem em tratar programador como commodity? (Os signatários do blog já viram pessoas sendo pagas para dizer isso.)
5. Por que é tão difícil mandar os incompetentes embora?
   Qualquer pessoa que faça a mesma coisa do mesmo jeito há mais de um ano está acomodada. Uma empresa que aceita um recurso desses, também. Desconfio que quando ela hesita em mandar incompetentes embora alegando “perda de conhecimentos esclerosados acumulados”, ela quer dizer “somos incapazes de fazer avaliação profissional objetiva”. Engraçado: cadê o programador-commodity nessas horas?
6. Existe uma palavra melhor para iteração?
   Essa palavra é muito pedante. Só os iniciados sabem do que se trata, e os demais ficam pensando em “interação”. Que, na boa, pode muito bem se referir à mesma coisa. Não estou falando de “iteração de loop/enumeração/lista”, onde a tal palavra é indispensável. Agora, falando de projetos, com gente normal (não-programadora), que se fale então em ciclo, passo, ação, ou interação mesmo — preciosismo pra quê, meu deus.
7. Por que as empresas acreditam em antivírus?
   Vou ter que interromper a escrita das FAQs pois o antivírus começou a executar sua rotina diária. Ele não vai encontrar nenhum vírus mas a empresa vai dormir tranqüila. Enquanto isso, estou numa máquina Windows com direitos de admin local e o único browser que posso usar é o Internet Explorer 7. Paciência.

– Inaugurando a minha participação no blog –

Sabe aqueles quadros que costumam vender na rua? Esses de feirinha, que são verdadeiros clássicos: casas toscas num gramado, cenários praianos, coisas deste naipe. São parte do que é chamado de arte naïf: obras não necessariamente intelectuais ou acadêmicas. Que podem até ser tecnicamente bem-feitas, mas dificilmente vão transformar seus autores em Van Goghs, mesmo que eles arranquem as próprias orelhas com os dentes.

Lembrei dessas coisas no mês passado, quando eu estava a ponto de precisar desenvolver um parser para uma certa linguagem de programação antiga. O parser seria um pedaço de uma ferramenta que extrai informações sintáticas e estruturais de um programa a partir do seu fonte — coisa que qualquer IDE atual disponibiliza quando se faz refactoring ou checagem de referências e dependências. Mas, como a tal linguagem não tem exatamente um IDE, a ferramenta (e o parser) tem que ser desenvolvidos “do zero”. E lá estava eu estudando as necessidades do meu trabalho.

Em pouco tempo concluí (instintivamente, não objetivamente) que o ideal era construir um mecanismo de parsing genérico, que servisse para qualquer linguagem. Entendi que esse mecanismo era possível de existir, desde que o léxico (sintaxe para definir sintaxes) fosse potente. Foi divertido então definir um léxico que permitisse uma estruturação a la BNF. E de forma bastante ingênua parti para montar um protótipo de parser. Um protótipo que entendesse uma linguagem simples. Um parser de XPath, por exemplo, só pra começar…

Foi aí que eu vi que ainda preciso comer muito arroz e feijão! O fato é que eu nunca precisei fazer um compilador na faculdade (ha!), e portanto não sabia que o buraco é muito mais embaixo. Existe um monte de formas de se construir um parser, uma porção de ferramentas, documentos, exemplos… e eu lá, escavando a pedra pra fazer a roda.

Pra mim foi interessante entender como esses mecanismos funcionam, e também foi bacana ter imaginado alguns algoritmos que, depois vi, são usados no ramo há muito tempo. Mas o ruim da história é ter entrado num caminho arriscado ao criar uma solução duvidosa, por pura ignorância. Nesse episódio eu fui um engenheiro naïf!

A minha “obra” até poderia ser passável tecnicamente, mas sem dúvida eu deixaria uma série de defeitos para trás, que qualquer um mais capacitado iria bater o olho e pensar: mas quem fez esta merda? Que é mais ou menos o que eu penso quando vejo uma ou outra pog alheia…

Seu código se sentiria à vontade na feirinha hippie?