1up4Developers

Atualmente as metodologias ágeis vêm aparecendo com cada vez mais freqüência nas empresas que desenvolvem software, introduzidas pelos próprios desenvolvedores (o que é mais comum) ou em alguns raros casos pela “cúpula” da empresa, na esperança de melhorar a produtividade e/ou o alto tempo de resposta do fracassado processo cascateiro. Porém, esta “fama” prematura dos métodos ágeis tem gerado mais resultados ruins do que bons. Sua aplicação na vida real, na maioria em muitos casos, ocorre de maneira equivocada, distorcida e desprezando-se os reais valores e princípios que apoiaram o surgimento desta filosofia.

Um exemplo claro de como os valores ágeis estão sendo desprezados distorcidos é o aumento constante de “cursos” e treinamentos de metodologias ágeis. Não é raro eu receber semanalmente vários spams e-mails de escolas de treinamento que ministram cursos de Scrum, XP, preparação para certificação ScrumMaster, técnicas de TDD, DDD, BDD, etc. Infelizmente o que estes cursos não ensinam (como todos os outros) é o verdadeiro significado de “ser ágil”. Fazer um curso de 20 horas de Scrum não o torna um ScrumMaster (você pode até ter um certificado, mas se você realmente é “ágil”, sabe que um certificado é um mero pedaço de papel sem valor).

E assim chegamos à “agilidade cascateira”, onde todos na empresa estufam o peito para falar que seguem práticas ágeis, desenvolvimento orientados à testes, utilizam Scrume para gerenciar os projetos, etc. Na verdade estão apenas praticando um waterfall incremental, cometendo os mesmos erros clássicos da cascata, valorizando os processos ao invés das pessoas, focando em soluções equivocadas ao invés de resolver os problemas dos clientes e assim, difamando e denegrindo a reputação e o propósito do AgileManifesto.

Esse é o cenário ideal para os guardiões cascateiros. É por estes e outros motivos que vemos “flames” oportunistas como The Decline and Fall of Agile começarem a fazer sentido na comunidade. Como disse o Guilherme Chapiewski, as pessoas estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. Utilizar uma metodologia ágil não é desenvolver software de forma anarquista, existe muito conceito e experiência adquirida para sustentar esta filosofia.

Neste blog você já viu várias maneiras de como ser um verdadeiro cascateiro e de como não ser ágil. Já que estamos falando nisso, vamos tentar resumir alguns pontos e características que tornam um desenvolvedor realmente ÁGIL!

Estude, mantenha-se atualizado!

A principal característica de um agilista é sua sede por conhecimento, sua busca incansável por novas técnicas, linguagens, ferramentas, etc. O seguidor ágil lê artigos, revistas, livros e o faz como diversão. Se você não leu pelo menos um livro técnico nos últimos 6 meses, isto é um mal sinal. Faça laboratórios, testes de novos frameworks, bibliotecas, etc. Pet-projects também são uma maneira pragmática de aprender novas formas e técnicas de desenvolvimento. Finalmente, conheça e pratique os princípios e valores do AgileManifesto, tendo-os como seu mantra, seu guia filosófico e seu mentor profissional.

Entenda realmente o problema do seu cliente

Isto parece ser óbvio, mas na maioria das vezes não é. Existem vários perfis de clientes, e é claro que você deve lidar de maneiras diferentes com cada um deles.

Alguns são visionários sonhadores e sempre têm necessidades mirabolantes, sem sentido. Outros são simplistas demais e muitas vezes “ocultam” detalhes importantes. Também existem os pseudo-técnicos, que acham que sabem fazer seu trabalho e já vêm sugerindo como você deve implementar aquela nova funcionalidade.

Reação comum quando há um problema

Como verdadeiro agilista, saber identificar o perfil de seu cliente é o início para um relacionamento de confiança e transparência. Só assim você será capaz de concentrar esforços para resolver seu problema e agregar valor ao produto.

Não tenha medo de mudanças

A única maneira de criar, corrigir ou melhorar algo é com coragem E com mudança. O essencial para mudar algo é saber identificar o que está errado. Por exemplo, você sofre diariamente para fazer o deploy da sua aplicação para homologação. Identificado o problema e uma possível solução, por exemplo, fazer o deploy em .war, você tem duas soluções: ou deixa como está e coloca a culpa na aplicação ou no processo de desenvolvimento (conformismo) ou com muita coragem investe algumas horas e resolve de vez o problema (agilismo).

Quando bater a insegurança, repita: coragem! coragem! coragem!

Coragem: o cão covarde!

Reflita e aprenda com os próprios erros

Existem várias maneiras de você evoluir seu conhecimento, e a maioria dos programadores utilizam somente uma: tomando na cabeça.

Prego só toma na cabeça!

Como um bom seguidor de práticas ágeis, reflita e aprenda com seus erros. Compartilhar seus problemas é a melhor maneira de escolher um solução adequada e ainda espalhar sua experiência entre a equipe para que outras pessoas não cometam o mesmo erro.

Errar é humano. Persistir no erro é burrice. Se você está com problemas, procure por pessoas que já tiveram um problema parecido e aprenda com ele. Não cometa os mesmo erros, e mais importante, não cometa os mesmo erros dos outros!

Resumo

Se tudo que você leu até agora não é novidade, parabéns! Caso contrário comece o quanto antes estudar e principalmente praticar estes conceitos no seu trabalho e na sua vida.

Seja responsável e comprometido com seu trabalho. Esforce-se para fazer o melhor. Faça valer o seu salário. E lembre-se: cuidado com os falsos agilistas!

Desenvolver software é uma atividade muito gratificante pois sempre podemos (ou deveríamos) exercitar nossa criatividade para solucionar os problemas dos clientes. Isto, apesar de divertido pode ser perigoso e/ou catastrófico se estivermos com o foco errado. Num ambiente cascateiro, onde cada envolvido está comprometido apenas com o processo e não se preocupa verdadeiramente com os problemas dos clientes, não é difícil que isto ocorra. Quase sempre o foco acaba sendo direcionado para a solução ao invés do problema.

Mas qual a diferença entre foco no problema ou solução? Vamos a um exemplo:

Quando a Nasa enviou os primeiros astronautas ao espaço, descobriu que as canetas não funcionavam com gravidade zero. Para resolver esse problema, os engenheiros contrataram uma empresa especializada para projetar a caneta espacial.
Dez anos e US$ 12 milhões depois, estava pronta a caneta que podia ser usada no espaço, em qualquer posição. Nem a temperatura poderia atrapalhar: a supercaneta funcionava bem fizesse frio ou calor.
Os russos, que tiveram o mesmo problema, optaram por uma solução mais simples: passaram a usar um lápis.

A história acima é bem famosa e mesmo sendo falsa, demonstra muito bem o que acontece quando o problema não está em foco. Neste caso, o problema é a impossibilidade de escrever em gravidade zero. Uma das soluções seria uma caneta que escreva nessas condições. Veja que aqui a solução já está em foco. Outra solução para o problema seria utilizar algo que escrevesse em gravidade zero: um pedaço de carvão ou um giz já serviriam. Assim, o problema seria resolvido.

Outro exemplo de falta de foco no problema é esta história da fábrica de pasta de dente, onde ocasionalmente algumas caixas da pasta de dente eram entregues vazias. Para eliminar este problema, a empresa gastou investiu milhões para garantir que durante a fabricação, nenhuma caixa ficasse sem o tubo de pasta de dente dentro. Mas o problema foi realmente resolvido depois que um operário deixou um ventilador soprando as caixas vazias para fora da esteira de produção. Simples não?

Na área de desenvolvimento de software não é tão raro acontecer algo parecido, onde o foco está inteiramente na solução. Sabe aquele sistema meio capenga, que funciona e dá dinheiro para empresa mas não é “web 2.0″ nem utiliza conceitos de “SOA”? De repente a diretoria decide que este sistema deve ser “migrado” para uma tecnologia da moda mais atual, que o permita “evoluir” mais facilmente.

Para atender esta necessidade, normalmente uma equipe nova é contratada, toneladas de documentos e diagramas são produzidos até que os programadores comecem a codificar. A esta altura, o prazo já está apertado e os “stakeholders” ainda não viram os resultados. Depois de muito tempo e dinheiro desperdiçados, um sistema feito às pressas, bonitinho mas meia-boca, é entregue com os mesmos defeitos do anterior. E o problema não foi resolvido…

Desenvolver software deve ser um investimento lucrativo, proporcionando algum ganho às partes envolvidas. Quando uma necessidade surgir, o primeiro passo é identificar o problema para então encontrar a melhor solução, ou seja, foco no problema. Neste exemplo da “migração”, o problema é que a manutenção do software atual é muito cara, porém “migrar” o sistema inteiro não vai resolver o problema, no máximo criará um novo.

Mas de quem é a culpa quando o foco está na solução? Eu respondo: a cascata! Apesar das metodologias ágeis estarem em alta e aos poucos serem adotadas pelas empresas, a maldição do waterfall ainda é está entre nós. Clientes continuam com a mania de pedir tudo no início do projeto. Ao exporem seus problemas, já estão pensando na solução. Fazem questão de engordar o escopo com coisas das quais não têm certeza da utilidade, mas querem que estejam lá pois podem precisar um dia. Os desenvolvedores também não estão isentos dessa culpa. Um legítimo analista cascateiro não se envolve com os problemas do cliente, apenas ouvem suas solicitações e transformam em casos de uso ou diagramas. É aí que uma simples necessidade se transforma numa bola de neve e a lenda da caneta da Nasa se repete…

Um verdadeiro desenvolvedor ágil deve se comprometer com o cliente, ouvir, entender e se envolver com suas necessidades para então sugerir uma solução simples, focada e que resolva o problema. Esta interação é muito importante e deve ser constante, pois o cliente passa a identificar o que realmente ele precisa, ou seja, o qual seu problema! Assim, começa a se concentrar em funcionalidades que realmente serão úteis e agregarão valor ao software e, consequentemente, ao negócio. Feedback é muito importante. O pessoal do Google sabe muito bem disso…

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!

Atualmente, desenvolver software não é uma atividade barata. O custo com os profissionais envolvidos, equipamentos, licenças de software (não é o caso se a equipe utiliza software livre), entre outros recursos, para um software que demore em média três meses para ser desenvolvido com uma equipe de 5 pessoas sairá pelo mesmo valor de um carro popular de luxo, por exemplo. Já que o investimento é alto, é importante que o software seja confiável, durável, adaptável e principalmente que sua utilização/adoção, além de atender a um problema/necessidade, obtenha o retorno sobre o investimento.

Para uma empresa que desenvolve software por encomenda, o retorno sobre o investimento (equipe, equipamentos, etc) é o lucro obtido com a venda do software através de uma conta muito simples: investimento - custo = lucro. Desta forma, qualquer CEO sabe que quanto menor for o “custo”, maior será o “lucro”. É aqui que mora o perigo!

Uma das falsas ilusões das metodologias baseadas no waterfall é o controle sobre o processo. Ou seja, com um processo bem engessado definido, o “motor” da empresa giraria de modo uniforme, sendo controlável e mensurável. Uma vez que esse mecanismo esteja funcionando, pode-se conter gastos contratando-se mão-de-obra mais barata para fazer a parte repetitiva e “não-criativa” do processo, que já foi previamente “projetada” pelos analistas e arquitetos. Desta forma, concentra-se a maioria do esforço no projeto ou desenho do software, que é mais caro, para recuperar o “gasto” na fase de construção, que é mais barata.

Modelo Waterfal: etapas bem definidas

Este método funciona muito bem… na engenharia civil, onde os problemas são bem definidos (a necessidade de atravessar um rio, por exemplo), a solução deve ser projetada (uma ponte) e executada por especialistas em construção (pedreiros). O esforço pode ser mensurado e cobrado do cliente. Dificilmente ocorrerão mudanças no projeto (ao invés de ponte, decidem mudar para um teleférico, por exemplo) e o tempo de construção pode ser diminuído aumentando-se a mão-de-obra porém permanecendo o mesmo custo no final do processo.

Infelizmente com software não é bem assim. O desenvolvimento de software é (ou deve ser) um processo criativo e iterativo, mais parecido com jardinagem. O problema/necessidade dificilmente é bem definido (dificuldade de controlar as vendas pela internet, por exemplo) e os requisitos geralmente mudam o tempo todo. Os clientes normalmente não sabem exatamente quais são suas necessidades e precisam “aprender” enquanto o software vai sendo desenvolvido, atendendo às necessidades aos poucos.

Clientes não sabem exatamente o que querem no início do projeto

Voltando ao assunto do post, para o cliente o que mais importa é que o software atenda suas necessidades (mesmo que ele ainda não saiba exatamente quais são). O retorno sobre o investimento começa a ficar evidente quando o cliente utiliza o software e obtém proveito dele, por exemplo, tendo um maior controle e organização de suas vendas pela internet. Neste caso o software é um meio pelo qual o cliente consegue resolver seus problemas ou atender suas necessidades. Isto o software não faz por sí só.

Para uma empresa que desenvolve software, o retorno sobre o investimento é obtido durante o desenvolvimento do software, guiado por práticas e ferramentas que fornecem velocidade e confiabilidade ao software, deixando-o adequado às necessidades do cliente, estável e fácil de ser mantido. Para obter estas características, a equipe deve estar muito alinhada e ter a experiência e habilidade técnica necessária para evitar trabalho desnecessário e focar na resolução do problema, colaborando com o cliente para fornecer constantemente software funcionando e que agrega valor ao negócio. Ou seja, devem seguir o manifesto ágil!

Atualmente, as empresas de desenvolvimento de software mais bem sucedidas utilizam metodologias ágeis, ou seja, pessoas ao invés de processos. O investimento em um bom profissional é recompensado pela sua experiência que pode economizar muito tempo e dinheiro ao longo de um projeto. Bons profissionais, motivados, utlizando metodologias ágeis são mais produtivos, ou seja, valem o investimento.

Durante minha carreira profissional fui obrigado tive a oportunidade de atuar brevemente no campo gerencial do desenvolvimento de software. Foi uma experiência que agregou muito conhecimento e me fez enxergar minha atividade principal, programação, com outros olhos. Também pude entender melhor as estratégias comerciais da empresa, gerenciamento de recursos, retorno sobre investimento, etc. Além de aprender mais sobre desenvolvimento de software, também pude conhecer os vilões dessa história, na maioria dos casos: a diretoria.

Na maioria dos problemas que presenciei, a diretoria (quem toma decisões e libera a grana do projeto) contribuiu para que as coisas ficassem cada vez piores, seja tomando decisões visando curto prazo ou aplicando conceitos ilusórios como adoção de uma tecnologia ou metodologia da moda. Seguem algumas pérolas da “diretoria”:

• “Programadores são descartáveis”. Não consigo acreditar que pessoas numa hierarquia superior ainda tenham esta visão dos programadores, comparando desenvolvimento de software com construção civíl e programadores com pedreiros (em alguns [poucos] casos é verdade). Certa vez presenciei um dos mais famosos defensores de práticas ágeis, autor de vários livros e que subiu na carreira devido a seu destaque como programador (Delphi), dizer: “programadores têm em todo lugar, basta sacudir uma árvere e cai um monte deles no chão”. Depois dessa, passei a ignorar tudo que ele escreve ou fala. Talvez se ele tivesse lido pelo menos o resumo do Manifesto ágil saberia que blasfemou feio!
• “Meu maior gasto é gerado pelos programadores”. Fiquei sem reação quando ouvi esta pérola do dono da empresa. Ele ainda achava que os atrazos e erros do sistema vinham dos seus quatro programadores juniores que utilizavam uma tecnologia quem ninguém conhecia direito (mas está na moda), não utilizavam nenhum processo ou metodologia e ainda tinham que manter contato direto com os clientes.
• “Precisamos de documentação”. Esta todos nós já ouvimos e conhecemos o final. Um certo dia alguem chega na empresa e decide que tudo deverá ser documentado. Então gastam-se alguns meses levantando os requisitos do sistema, definindo os casos de uso e diagramas UML, reuniões, definição do banco de dados, etc. Lá pelo 10º mês descobrem que nenhuma linha de código foi escrita e o sistema só existe no papel. Nem preciso contar o final da história né?
• “Como assim não dá pra desenvolver este ERP em três meses?”. Nunca assisti um Tech-Ed nem outra palestra do tipo, por isso não sei exatamente o que vendem falam sobre pazos, mas com certeza é uma mentira das grandes! Não existe mágica nesse ramo, não existe ferramenta nem tecnologia milagrosa e nenhum processo vai acelerar o desenvolvimento do sistema. Ponto. Somente uma pessoa que não entende nada sobre desenvolvimento de software acreditaria nesse conto de vigário. Um general sabe comandar seus soldados pois certamente foi um soldado e esteve num campo de batalha. Será que todo chefe/diretor foi programador (de verdade) no início da carreira? Ter programado em Cobol há 20 anos atrás não conta!
• “Não podemos perder tempo com refactoring e testes unitários”. Bom, se deixar o código do sistema mais “manutenível” e garantir que o que já foi feito funcione corretamente do jeito que deve ser for uma “perda de tempo”, então estou no ramo errado. Fazer com que o sistema “rode” é muito importante pois sistema rodando é dinheiro entrando no caixa. Mas abrir mão da qualidade é uma péssima estratégia a curto prazo, pois todos nós sabemos que sistemas mudam constantemente e ter mecanismos para responder rapidamente a essas mudanças é mais importante do que “parir” um sistema remendado de uma hora pra outra e depois perceber que a menor das mudanças custa 10 vezes mais do que o normal.

Por enquanto só consigo me lembrar dessas, mas outras pérolas virão e renderão novos posts.

Fiquem a vontade para comentar. Até o próximo post!

Já faz tempo que venho ensaiando este post. Minha idéia é mostrar como é importante na nossa profissão de “desenvolvedor” estar constantemente aprendendo novas técnicas, linguagens, frameworks, metodologia, etc. Com um mercado tão competitivo como o de Desenvolvimento de Software, não podemos nos dar o luxo de conhecer apenas uma linguagem. Evidente que é bom que você escolha uma para se especializar, mas de forma alguma deve ser a última linguagem que você aprenderá.

Há algum tempo atrás, orientação a objetos era uma coisa de outro mundo para mim. É sério, não conseguia pensar na possibilidade de existir outro paradigma de programação. Bem, depois que estudei muito sobre OO e passei a utilizar profissionalmente, hoje não consigo me imaginar trabalhando sem OO. Tudo fica claro, organizado, abstraído… O que eu ganhei com isso? Com certeza consegui ser mais produtivo, mais organizado e mais eficiente e, como consequência, melhor remunerado. Se ainda desenvolvesse proceduralmente, certamente ainda desconheceria conceitos e técnicas, sendo apenas mais um na multidão. E não é assim que um verdadeiro desenvolvedor ágil quer ser visto, certo?

Outra coisa que estudei muito e hoje fico feliz em utilizar profissionalmente são Testes Unitários. Uma das premissas do desenvolvimento ágil está relacionada à qualidade do código. Com testes unitários é possível desenvolver incrementalmente e responder rápido às mudanças pois seu código está “protegido”. Além de servir como apoio à refactoring. O que eu ganho com isso? Consigo me preocupar apenas com o desenvolvimento de uma pequena funcionalidade por vez, meu código fica mais “limpo” e manutenível. Em consequencia disto me torno mais ágil e sou melhor remunerado. Além de poder dormir mais tranquilo…

É importante reconhecer que há muito para aprender ainda. Nosso cenário de trabalho muda constantemente e os “usuários” são cada vez mais exigentes. Além disso, é importante lembrar que não existe bala de prata, não existe uma tecnologia que resolve todos os problemas. As linguagens e tecnologias são limitadas e precisam evoluir. Você precisa evoluir junto! Não se esqueça também que lá fora tem um mercado de trabalho começando a enxergar essas qualidades ágeis.

Ultimamente temos acompanhados posts-desabafo sobre metodologias e o cenário atual do mercado de desenvolvimento de software. Pois bem, mudemos de assunto um pouco.

Outro dia estava tendo uma conversa discussão com meu amigo Nivaldo sobre interfaces web com uso abusivo de javascript. Aí lembrei o que o Miguel disse sobre interfaces citando como parâmetro o Google e a Apple e a pouca importância que as empresas dão para esse assunto.

O mercado (alvo) está cada vez mais competitivo. Usuários não querem simplesmente um sistema funcional; ele deve ser bonito, intuitivo, agradável de usar. Um bom exemplo do que estou falando é o popular Goggle Reader: será que estaria tão popular se não fosse sua interface “rica”?

Acredito que atualmente, para sistemas web, a interface deve(ria) ser o principal “exciter” e onde as forças devem atuar consideravelmente. Digo isso porque as outras partes de um sistema (estou falando do negócio e banco de dados) estão razoávelmente maduras em termos de conceitos (OO, Teste, ORM), frameworks, etc.

Foi o tempo em que precisavamos saber apenas escrever código funcional. O desenvolvedor de hoje precisa saber muito bem HTML, CSS e JavaScript. E para isso, felizmente podemos (e devemos) utilizar recursos e frameworks para isso.

Recentemente trabalhei em uma empresa de pequeno porte tentando implantar (ensinar, vender, disseminar, ou outro termo que caiba aqui) Scrum na tentativa de organizar e agilizar o processo de desenvolvimento do software da empresa, que até o momento só conhecia (e conhece) Waterfall.

As desculpas da empresa para não adotar Scrum (ou outro processo ágil) são todas apoiadas em confiança (ou desconfiança): como confiar num projeto que não tem tudo detalhadamente especificado desde o início? Era comum ouvir: “só isso não vai dar certo”, “precisamos detalhar todas as funcionalidades primeiro”, “não quero chegar lá na frente e ter que mudar alguma coisa hein”, “o cliente não vai querer comprar uma coisa que ele nem sabe o que é”.

Na ocasião, encontrei este artigo falando sobre desenvolvimento iterativo e incremental, e utilizei estas imagens para (tentar) argumentar meu ponto de vista.

Iterativo:

Incremental:

É evidente que ninguém entendeu a mensagem. Para eles, a confiança ainda estava em jogo. Em termos de proteção, o Waterfall ainda garante uma “falsa segurança” à empresa: “estamos entregando apenas o que estava documentado nas especificações”, “a documentação nos protege”.

Bom, tá aí um resumo da minha experiência e tenho certeza que vocês já passaram por algo parecido. Continuamos nos comentários…

Diferente do meu blog, onde o foco é apresentar as idéias “mastigadas”, aqui eu pretendo gerar discussões para que possamos entrar num consenso.

Primeiro, deem uma olhada neste artigo que apresenta bancos de dados como commodities, ou seja, qualquer um serve. Depois tem mais esses posts sobre ORM e Frameworks que também acho interessante.

Agora gostaria de saber a opinião de vocês: dado um sistema não crítico de mercado (tipo um CRM, e-commerce, portal, etc), onde mais de 50% das funcionalidades são CRUD, 30% relatórios e os 20% restantes alguma lógica e processamento, a escolha do banco de dados e a forma com que os dados serão manipulados são os principais fatores determinantes do sucesso de um projeto?

1… 2… 3… Valendooo!

Este é meu primeiro post aqui no 1up4developers e tentarei ser objetivo.

É fato que a maioria das empresas de desenvolvimento de softwares são desorganizadas, têm problemas nas entregas, falta documentação, etc. Outro ponto em comum é a espectativa de resolver todos os problemas apenas adotando uma ferramenta/metodologia de nome forte ou que ainda não foi inventada.

Só para ilustrar essa afirmação, vou expor algumas situações reais que presenciei:

Multinacional alemâ com dificuldades no levantamento de requisitos e testes buscou resolver seus problemas com uma suíte de produtos da Borland. Não deu certo.
Empresa nacional de médio porte quando enfrentou uma crise financeira por não conseguir cumprir datas buscou solução contratando uma consultoria especializada e “organizar” a bagunça. Não deu certo e deixou a empresa à beira da falência.
Empresa nacional de pequeno porte pretendia migrar a tecnologia/plataforma de desenvolvimento fornecendo cursos para seus desenvolvedores na esperança de melhorar o processo e a qualidade de seu produto. O resultado foi desastroso.

É comum hoje ouvirmos nomes como RUP, XP ou Scrum como a solução para todos os problemas de uma empresa. Outros nomes como UML, Testes Unitários e TDD também têm ganhado espaço nessa lista de “celebridades”. O erro das empresas é achar que esses nomes são “roupas” que podem ser vestidas ou trocadas facilmente. Elas têm um problema X e acham que resolvem aquilo adotando uma ferramenta/metodologia Y.

A grande solução para esses problemas são as pessoas, os profissionais da empresa. Encorajar o desenvolvimento profissional, incentivar financeiramente, deixar os profissionais à vontade para opinarem são alguns pontos que geram resultados a longo prazo. Valorizar o profissional na contratação também é muito motivador ao invés de tentar negociar seu salário com base em seu tempo de experiência ou quantidade de ferramentas que já trabalhou.

Só para finalizar o post, esperando que tenham entendido a mensagem, fica um artigo do Fowler falando de quando o barato sai caro.