Além do .NET

Será que agora o Waterfall é enterrado de vez?

2010-08-12T12:36:00.001-07:00

No segundo dia de palestras do AgileBrazil, Philippe Kruchten fez a melhor apresentação do evento, na minha opinião. Resumindo muito, ele ressaltou que é necessário contextualizar o Agile, ou seja, Agile sem contexto não é nada.

Ao longo do keynote ele fundamentou perfeitamente as suas idéias, defendeu o Waterfall dizendo que em determinados contextos ele faz sim muito sentido. Na minha opinião uma visão dessas, fundamentada como ele o fez, só pode vir de uma mente Agile…

Mesmo achando que ele estava certo, defendendo o Waterfall em algumas situações, ainda acredito que o Cascata deve ser a última opção quando o assunto é Desenvolvimento de Software.

Por pensar dessa forma achei muito interessante esse artigo. W. Royce, que aparece no vídeo do artigo, é intitulado como o criador do Waterfall, mas na verdade no seu paper (que deu oriem ao Cascata) ele apenas cita o Waterfall e enfatiza os problemas dessa abordagem, mostrando soluções de iterações para amenizar tais problemas.

O artigo fala de um evento da IBM onde a Agilidade foi o assunto principal, e uma das palestras foi de W. Royce. Para mim ter W. Royce em um evento da IBM falando sobre Agile significa muito!

O autor ainda brinca dizendo estar supreso pelo fato da IBM estar tomando partido do Agile, defendendo que essa é a melhor opção dentro do mundo do Desenvolvimento de Software.

Espero que isso seja mais uma pá de terra em cima do Waterfall, e mais bons frutos nascendo do Agile.

Agile Brazil 2010 – Overview e Fowler

2010-07-03T07:16:00.001-07:00

Nos dias 22 a 25 de junho ocorreu em POA o primeiro AgileBrazil. Um evento que reuniu a meca da comunidade Ágil do Brasil e do Mundo.

Entre palestras e cursos, muito se discutiu sobre agilidade e engenharia de software em Geral.

Primeiro dia de Palestras
Abertura

Os primeiros 2 dias de evento foram de cursos sobre XP, Scrum entre outros. Eu não fiz os cursos mas li alguns bons feedbacks sobre os mesmos.

Já de início a estrutura do evento agradava muito. Uma excelente infra com tudo muito bem organizado. Fiquei particularmente impressionado com a estrutura da PUC-RS, pois como sou natural de POA já conhecia o local e pude ver que evoluiu muito. Bateu até uma vontadezinha de voltar pra faculdade (que logo passou).

A cerimônia de abertura contou com um integrante do governo do RS, o coordenador do curso de tecnologia da PUC-RS, e ainda um representante do Ministério da Ciência e Tecnologia entre outros ilustres.

Logo na abertura do evento deu pra perceber que o empenho e a dedicação dos organizadores foi muito grande, mas o resultado final foi bem condizente com os esforços. Foi particularmente interessante saber que parte dos organizadores só foram se conhecer pessoalmente no dia do evento, e mesmo assim realizaram um excelente trabalho no melhor estilo Agile.

Keynote – Martin Fowler

Não posso negar que uma das minhas grande motivações para ir nesse evento foi para assistir o keynote de abertura do Martin Fowler. Como um admirador do seu trabalho no mundo do software eu estava com uma grande expectativa para vê-lo palestrar.

Não tem como dizer que a palestra foi ruim, mas pra mim que acomapanho de perto o trabalho dele, e estou bastante dedicado nos assuntos acerca das Metodologias Ágeis, confesso que fiquei um pouco decepcionado. A decepção foi porque ele não falou praticamente nada de novo. Quem acompanha as suas idéias assistiu a uma grande compilação de tudo que ele já falou desde o Manifesto Ágil passando pelo Scrum Flácido e chegando a integração/entrega contínua.

Mas apesar disso eu gostei bastante da palestra. Ver um dos caras que criou o Manifesto Ágil falando ao vivo sobre as origens do Manifesto e reafirmando tudo até então publicado de bom sobre Agile é sem dúvida uma experiência muito valiosa.

Outra decepção foi saber que Fowler não é muito fã de fotos. Ele disse que não queria parecer político, e por isso não tiraria foto com os “fãs geeks”. Diante desse fato foi rapidamente vítma do Twitter sob a hashtag #MartinTroller.

Na minha opinião ele não foi estúpido, só altamente sincero e pragmático. Porém quem quisesse conversar com ele bastava se dirigir ao stand da Througworks pois, pelo que eu vi, ele pareceu bem receptivo a uma boa conversa.

Rup Certified Solution Designer.

2010-06-06T18:15:00.001-07:00

No dia 21/06 obtive o meu mais novo título: Rup Certified Solution Designer.

A prova é bem tranquila, não vai muito a fundo nos conhecimentos do RUP, mas exige que vc tenha uma abrangente visão do Framework (nada mais justo né?).

Um problema que eu vi na prova é que as questões são bem diretas e curtas, sem muita enrolação. Isso acaba beneficiando quem estuda focado para a prova, pois as questões não exigem um raciocínio em cima do conhecimento que o candidato possui.

Quanto a isso eu penso que a prova poderia ter perguntas que tentassem “enganar” o candidato sobre o que está sendo cobrado em cada questão. Seria interessante também juntar os conceitos de forma que as perguntas fossem mais elaboradas e não tão diretas. Dessa forma eu acredito que uma vivência mais efetiva de projetos usando o RUP seria necessária aos candidatos.

Mas isso não tira o mérito da prova, que exige sim bons conhecimentos sobre RUP e boas práticas de Projetos Iterativos de Software.

A prova não é nada cansativa e pode ser tranquilamente concluída bem antes do prazo estabalecido para ela.

Para os estudos eu utilizei somente o livro de referência para a certificação RUP. Acredito que o livro é mais do que suficiente para os estudos, pois possui um conteúdo bem focado no que é cobrado no exame. O formato do livro também agrada, pois de forma iterativa ele vai abordando todos os assuntos exigidos. Independente de fazer a prova ou não, o livro ajuda muito a conhecer o RUP.

Os simulados do livro são bem parecidos com as questões que o candidato irá enfrentar no dia da prova, então, leia o livro (estude o livro), faça os simulados (estude os simulados), e certamente conseguirá a sua aprovação.

Mas, ainda vale a pena estudar o RUP diante desse mar de agilidade que inunda o mercado?

Bem, a minha opinião é sim, ainda vale a pena estudar o RUP, e em um futuro post pretendo justificar a minha opinião.

Programadores! Programadores?

2010-02-26T16:12:00.001-08:00

Eu sinceramente não sei se fico “aliviado” ou extremamente deprimido por saber que isso acontece em todo o lugar, inclusive com eles…

Profissionais ruins existem em todas as áreas, é verdade, mas a TI é especialmente contaminada por eles. Isso ocorre, aparentemente, pelo pouco tempo de vida que a TI possui, mas me preocupa muito saber que as faculdades formam profissionais que nem de perto servem para o mercado de trabalho. O despreparo é total tanto de professores quanto de formandos.

Claro que temos exceções, existem faculdades públicas e algumas particulares que possuem bons cursos, mas infelizmente são exceções e não regra. O apagão de profissionais qualificados é igual a crise de software, existe desde que o software é software.

Vivendo e Aprendendo.

2009-10-31T09:50:00.001-07:00

Um belo dia eu descobri que Analista de Sistemas realmente não existe.

Na semana desse mesmo dia, eu entendi que não se pode FABRICAR um software sob o paradigma de uma FÁBRICA.

Dentro desse mesmo contexto eu avaliei que especializar-se é necessário sim, mas que o excesso de especialistas e a ausência de generalistas acaba por criar células isoladas.

Analista de Requisitos, Analistas de Sistemas, Arquitetos, Programadores, DBA´s Gerentes, Analistas de Teste, Executores de Teste, Analistas de Qualidade, Analistas de Métricas - Penso que a esmagadora maioria dos projetos não precisa de um profissional para cada um desses papéis, e até acho que todos esses papéis se fundem dentro de uma equipe enxuta, coesa, auto-grenciável, e multidisciplinar.

Ainda em meio a essas "descobertas" todas, comecei a encarar o CÓDIGO FONTE de uma outra forma. Antes de mais nada, o código é uma DOCUMENTAÇÃO. E digo mais, é a única documentação viva, certamente atualizada e confiável de um sistema.

Sempre que argumento algo desse tipo para, normalmente um não-programador, escuto coisas do tipo:

"Mas Analista de Requisito não entende de código, e nem deveria entender." Dizem eles…

Bem, quanto a isso eu sou radical. Acho que um mínimo de conhecimento técnico é essencial para QUALQUER profissional de TI que esteja envolvido em um projeto de Desenvolvimento de Software.

Analista de <coloque-aqui-o-que-quiser> que não cohece OO, ou que não tenha condições de transcrever um modelo de classes na tecnologia que está sendo utilizada no projeto, torna-se TOTALMENTE inútil para o projeto.

É óbvio, mas vou destacar, que um "Analista" não precisa ser expert em C# ou em Visual Studio, mas precisa SIM ter uma certa desenvoltura para abrir, compilar, debuggar o projeto; Entender grande parte do que está sendo feito nas classes do projeto, saber sobre o básico da arquitetura do projeto, ter condições de criar um teste unitário simples para validar uma determinada regra ou criar um novo cenário para uma regra já implementada... enfim... até posso concordo que a função principal desse profissional não será ficar com a IDE aberta o tempo todo, mas sim, ele tem que ter condições para trabalhar com ela.

E nesse contexto onde o código fonte torna-se essencial para um projeto, e não apenas um monte de palavras que representam uma meia dúzia de modelos UML, nasce a necessidade do código legível, do código com expressividade. Nasce a necessidade de outra categoria de profissionais de TI. Profissionais esses que não podem ficar se escondendo atrás de papéis e de artefatos, mas sim fazer diferença na equipe. E eu vejo que o mercado está muito carente desse perfil de profissionais.

Agile, muito mais do que uma Metodologia

2009-10-16T18:14:00.001-07:00

Poucas vezes eu vi uma discussão tão acalorada quanto essa.

O encurralado está resistindo bravamente, responde até que educadamente a toda aquela enchurrada de críticas, umas construtivas e outras nem tanto.

Siceramente, eu até entendo, com algum esforço, o que o Diego quis dizer. Mas acho que ele errou na mão e no título ao criticar algo que, na minha humilde opinião, ele não conhece muito bem.

Acho que o grande problema está em definir Agile. Agile pra mim é um manifesto antes de tudo (valores), que levou a um movimento e desse movimento surgiram as metodologias (práticas). Então temos:

Manifesto Ágil + Movimento Agile + Metodologias Ágeis = NOVO PARADIGMA.

E esse é o ponto central. Trata-se de uma “nova” maneira de pensar sobre desenvolvimento de software e todo o seu universo, colocando no centro as pessoas.

Então, Agile antes de mais nada é um “novo” paradigma (não em idade mas sim em atitude). É uma forma diferente de entender, encarar e lidar com o Desenvolvimento de Software. Agile potencializa a competência e não tenta esconder a incompetência.

Agile não é pra qualquer um porque desenvolver software não é pra qualquer um, simples assim.

Simplicidade – Métodos curtos

2009-10-15T09:23:00.001-07:00

Acho que a evolução de um Desenvolvedor ocorre quando o seu código começa a ficar mais legível e simples. Eu acredito que mais de 80% dos códigos legíveis são simples, mas nem todo código simples é legível.

Kent Beck em Programação Extrema Explicada, cita 4 restrições que define o que é mais simples na visão dele:

O que é mais simples?

1) O Sistema (tanto código como testes) deve comunicar tudo aquilo que você queria comunicar;

2) O Sistema não deve conter código duplicado;

3) O Sistema deve conter a menor quantidade de Classes possível;

4) O Sistema deve conter o menor número de métodos possível.

Os meus 3 últimos meses trabalho foram sempre em projetos legados, as chamadas manutenções. Os Sistemas já estavam em produção e precisavam de reparos ou evoluções. Foram 3 projetos com essa mesma característica, e todos eles estavam com um código bem bagunçado e ilegível, naturalmente complexos.

Nada de padrões de codificação, códigos sem expressividade nenhuma, e métodos muito longos.

Como os sistemas estavam funcionando, e os Gerentes normalmente colocam os prazos apenas olhando o que deve ser feito como manutenção, nunca posso refatorar tudo o que eu queria e nem do modo como eu gostaria. Então, a primeira providência que eu tomo é quebrar os longos métodos.

Agindo dessa forma, de cara eu consigo:

1) Identificar de fato o que cada método faz ou deveria fazer;
2) Começar a organizar a “bagunça”;
3) Identificar e eliminar código duplicado;
4) Minimizar o impacto de futuras mudanças;
5) e por sim, simplificar um pouco mais as coisas…

Eu acredito que método curto normalmente:

1) Faz somente o que deveria fazer;
2) Torna-se fácil identificar o seu objetivo;
3) Pode ser reaproveitado mais facilmente;
4) Torna o código do sistema mais legível.

Bem, mas voltando ao início do post, Kent Beck define uma regra para simplicidade que é: O sistema deve conter o menor número de métodos possível.

O resultado das minhas refatorações, tentando quebrar os métodos longos, é uma quantidade bem maior de métodos na classe. Mas mesmo tendo uma classe com mais métodos do que no início, o resultado que eu percebo (e outros membros da equipe também) é que tudo fica muito mais simples. Bem, é verdade que fica mais simples do que estava, e é isso que hoje eu entendo. Agora eu sei que, deixar as coisas mais simples que antes não necessariamente é deixar as coisas simples.

Mas como explicar para o Gerente que precisamos “arrumar a casa” para tornar as coisas bem mais fáceis? Como refatorar com eficiência e produtividade sem uma cobertura de testes?

Cada vez mais vejo que codificar é modelar, e as práticas de XP fazem todo o sentido. Arrisco-me a dizer que, não existe como ter um projeto de qualidade e sustentável sem adotar ou adaptar as práticas de XP.

Você Testa o seu Software? Como?

2009-10-15T07:02:00.001-07:00

É realmente interessante e animador ver a grande quantidade de material, artigos, palestras e demais conteúdos sobre Testes proliferando na web. Isso mostra que estamos amadurecendo…

Acho que muitas vezes, nesse caso específico de testes, não tem meio termo. Ou testamos o nosso código ou não estamos fazendo um software de forma profissional. Podemos variar em fazer TDD ou não, ter uma cobertura 100% de testes, enfim. Mas a única coisa que não podemos é deixar de testar.

O que eu acho engraçado é que eu sempre escuto por aí que desenvolvedor não gosta de testar. Mas eu nunca conheci nenhum desenvolvedor que desse o seu trabalho como pronto sem antes rodar a aplicação e ver se o código que ele acabou de desenvolver está se comportando como o esperado. Pois bem, isso é testar. E eu acho até que isso é muito divertido, ver o código que você escreveu se comportando como você planejou.

Claro que, ficar testando as diversas possibilidades de cenários para os erros e tentar encontrar um bug no seu recém nascido (código) não é tão divertido assim. Mas o que eu quero chamar a atenção é que sempre, de uma maneira ou de outra, estamos testando o nosso código. E o pior é que os nossos testes são às vezes muito chatos pois precisamos rodar a aplicação, encontrar a tela no menu da aplicação, preencher diversos campos de um formulário da forma correta, clicar no botão que irá disparar a ação no formulário e enfim começar a debuggar o código pois, a maioria dos nossos testes são via break point! Isso sim pode ser muito chato.

Mas, quando criamos um novo método e escrevemos um código de teste para ele, não precisamos de nada disso. Precisamos apenas clicar em run e ver os verdinhos aparecendo na nossa tela, dizendo: Sim!! você estava certo e seu código está funcionando!! Isso sim é divertido!

Então, eu realmente não entendo a resistência que existe em criar testes unitários automatizados. E indo um pouco além, criar o teste antes pode até ser bem mais divertido. Nos ajuda a pensar, nos dá um desafio mais objetivo e por fim garante que realmente estamos criando os testes para o nosso código.

A diferença é que com os Testes unitários automatizados conseguimos testar muito mais vezes de uma forma muito mais rápida, e aos poucos podemos incrementar os nossos testes ampliando a qualidade do nosso código, além de todos os inúmeros benefícios que os Testes trazem.

Então, alegar qualquer motivo para não testar é uma tremenda incoerência, sendo que necessariamente vc irá testar o código ou a funcionalidade que você acabou de implementar, de um jeito ou de outro.

Então, Sim!! é claro que você testa o seu software. Resta saber se você testa bem e é realmente eficiente no seu teste… ou ainda, se você testa da maneira correta e esperta, ou da maneira burra e improdutiva.

Requisito/Análise é o mais importante?

2009-10-12T10:20:00.001-07:00

Na faculdade eu “aprendi” (!?) que a parte mais importante de um software é o Requisito. Também com uma vital importância encontra-se a Análise que realizamos baseada nos requisitos para chegarmos a um projeto de Software bem modelado, detalhado e definido. Após essa fase, dizem os “professores” (!?), teremos um conjunto de artefatos que possibilitará aos programadores apenas transcrever os requisitos em código. Feito isso, temos o nosso Software funcionando.

Bem, nunca é demais frisar que isso (o parágrafo a cima) não funciona. A (?) fase de análise (?) ou a Identificação dos requisitos, é apenas uma exploração. Trata-se de um pequeno passo na CONSTRUÇÃO (Código!!) de um software. Pequeno mas importante passo, é claro. O fato é que a única forma correta de validarmos os requisitos de um software é codificar o software e entregar uma parte dele para o cliente usar. Dessa forma sim, saberemos se estamos no caminho certo, e se os requisitos são aqueles mesmos que foram identificados.

Temos que entender que Codificar também é modelar (vide TDD). E precisamos aprender de uma vez por todas que modelagem gráfica (modelos e diagramas UML) ajuda na comunicação da equipe, ajuda a modelar também, mas que só poderá ser dada como válida ou correta após a implementação da mesma, do contrário é tudo especulação, é tudo desenho e ainda é uma abstração incompleta de um sistema.

Existem mais coisas importantes num ciclo de desenvolvimento de um software além do código… mas, quando vemos um software funcionando, a única certeza que temos é que ele foi realmente codificado por algum programador. Além disso, um software em produção está apenas iniciando a sua vida, então, mesmo tendo a melhor documentação do mundo, se o código estiver podre e mal cheiroso, essa documentação não irá adiantar de nada. Mas, se não tivermos nenhuma linha de documentação ou especificação desse produto mas o seu código for legível, coeso, expressivo, organizado, padronizado e possuir uma boa cobertura de testes, tenha certeza de que manter esse software será algo simples e divertido.

A verdade é que não existe, ou não deveria existir, uma separação entre as fases de requisito/análise e desenvolvimento. Vejo que é justamente tentando separar essas fases é que caimos numa perigosa cascata.

Quase chorei…

2009-09-13T12:37:00.001-07:00

Agile – Videos

2009-09-13T11:12:00.001-07:00

Ao longo dos meus estudos sobre Metodologias Ágeis algo que ajudou bastante foram os vídeos que eu assisti. Abaixo uma lista dos vídeos mais interessantes.

Akita – Agilidade, Qualidade e Futuro – Gosto dessa apresentação do Akita pois ele fundamenta muito bem toda a ideologia por trás do desenvolvimento ágil de software. É sem dúvida um daqueles vídeos que vemos e liga aquela luzinha de “Caraca! é isso mesmo!”

Scrum na Globo.com - Falando em Agile 2008 – Mostra de uma forma bastante direta a experiência de adoção do Scrum na Globo.com. Ajuda a desmistificar algumas práticas, e ilustrar os possível problemas que as equipes podem enfrentar ao adotar o Scrum. Pra mim a mensagem desse vídeo foi: Scrum, só funciona se você adaptar.

Contratação de Projetos de Software, manutenção de sistemas e portfólio de projetos com Agilidade - Falando em Agile 2008 – Nessa apresentação entramos em contato com uma questão muito importante mas que, na minha opinião, não é levada muito a sério pelos Gerentes de Equipes de Software. Os Contratos.

Scrum em ambientes PMBok - Falando em Agile 2008 – Gosto dessa apresentação pois toca bem na ferida dos Gerentes PMI que acham que Agile não é pra eles.

Só os imaturos não testam – Mostra de uma forma divertida a importância de automatizar os testes, criar uma cobertura efetiva de testes unitários e todos os benefícios que os testes trazem para as equipes.

XP na prática – Essa é uma apresentação feita pelo Bruno da Sea sobre XP. A apresentação (apesar de já bem modificada) faz parte da primeira parte do curso de XP realizado pela Sea.

Agile se paga – Um vídeo interessante que mostra como as práticas de Desenvolvimento Ágil se pagam ao longo de qualquer projeto.

Usando padrões para apresentar métodos ágeis – E se você não sabe como implantar ou vender as metodologias ágeis dentro da sua empresa, esse vídeo pode ajudar, além de ser bem divertido.

Eu na SEA!!

2009-07-23T17:02:00.001-07:00

O Post que eu fiz sobre o curso XP na Prática era, inicialmente, um depoimento/feedback que eu postei na lista AgilDF.

O pessoal da SEA gostou e resolveu postar o meu depoimento no blog deles. E eu gostei disso! Eu na SEA!

Curso XP na Prática

2009-07-20T17:31:00.001-07:00

No último dia 18/07 participei do Mini Curso XP na Prática, ministrado pelo pessoal da SEA Tecnologia. Gostaria de relatar aqui as minhas experiências e impressões sobre o curso.

Não é de hoje que eu estudo sobre metodologias ágeis, e o curso pra mim serviu como uma forma de aparar algumas arestas e experimentar de fato um ambiente Ágil na prática. A didática utilizada é algo completamente diferente do normal, pelo menos dos cursos que eu já participei, o que na minha opinião foi um ponto muito a favor.

Início do Curso:

O curso é prático mesmo. O que faz com que os participantes mergulhem num dia de trabalho XP.
Após uma rápida (muito rápida!) apresentação dos conceitos, valores, práticas e princípios de XP, entramos de cabeça no planejamento das atividades e iterações.

Planejamento das Iterações:

Achei interessante o fato do Bruno (Instrutor) conduzir a reunião de planejamento somente “ditando” as regras (alertando o grupo sobre o tempo máximo da iteração, ajudando na quebra das histórias, etc) e não conduzindo os alunos pela mão.

A turma foi obrigada a se entender quanto aos prazos para realizar as atividades do projeto, e nesse ponto conseguimos ver o quanto é difícil estimar prazos. O problema da estimativa é "resolvido" nas retrospectivas, onde podemos reavaliar e melhorar a nossa estimativa tendo a experiência da iteração anterior. O comprometimento com os prazos também é muito mais intenso quando o próprio time é quem os define, diferente das abordagens comando-controle.

Quebrar as histórias em atividades e tarefas menores, ajuda a enxergar o problema de uma forma mais realista, e com isso podemos estimar melhor e trabalhar mais focado em cada parte do projeto. Tanto gerenciar quanto trabalhar dessa forma é muito mais viável.

Mão na Massa:

Depois do planejamento inicial, o pessoal da Sea iniciou o desenvolvimento das funcionalidades programando para que a turma pudesse começar a se familiarizar com o jeitão XP de fazer as coisas. A programação foi sempre realizada em pares e usando as técnicas de TDD. Depois da primeira iteração os alunos começaram a colocar a mão na massa, também programando em pares usando TDD. Nesse momento percebemos que na prática, a teoria é outra!

TDD:

Sem dúvida o ponto alto do curso foi a utilização das Técnicas de TDD. Logo de início, pensar no teste antes de programar era difícil, e por isso muitas vezes o monitor nos chamava a atenção: “Faz o teste primeiro!”. Mas depois, em pouco tempo, já estávamos praticamente “dependentes” de criar o teste antes de programar, pelo menos no meu grupo foi assim. Não pensávamos mais na funcionalidade sem antes pensar no teste. Com isso ganhamos em foco, comunicação, simplicidade e segurança. Não chegamos a refatorar nada, em função do tamanho do projeto e do pouco tempo que tínhamos, mas certamente com a extensa cobertura de testes (acho que uns 26 testes para umas 8 funcionalidades, pelo que eu me lembro) qualquer mudança poderia ser feita sem as tradicionais dores de cabeça e, sem precisar “debugar” o código para entender o que estava acontecendo, bastava olhar a suite de testes.

Ao final do projeto, com todos os testes automatizados que tínhamos, estávamos com uma excelente documentação dos requisitos (atual e funcional!), com uma ótima rastreabilidade das funcionalidades e dependências de código, além de uma bruta segurança para fazer qualquer modificação necessária, sem medo de quebrar as funcionalidades existentes. Tudo isso graças aos nossos Testes Automatizados, tudo isso graças ao TDD.

Programação em Pares:

Ver o pessoal da Sea programando em pares é muito bacana. A sintonia dos pares, a troca de experiências, a comunicação, tudo parece muito necessário no contexto XP. Mas confesso que eu não sou muito adepto a essa prática, prefiro uma sessão de programação pareada mais específica, para um problema ou outro, ou até mesmo escrever alguns testes ou métodos em pares. Mas sempre programar em pares eu não vejo com muitos bons olhos e não tive tão boas experiências com essa prática. Mas tenho que admitir que existem muitos benefícios nela.

Retrospectiva:

Sempre depois de cada iteração nós realizávamos uma retrospectiva: O que fizemos, o que pretendemos fazer, e onde precisamos melhor para atingir os nossos objetivos. Nessas rertrospectivas tínhamos a chance de rever o nosso planejamento inicial e adequá-lo a nossa real necessidade naquele momento. Um ponto muito interessante das retrospectivas, era quando o Time sabia que não conseguiria entregar toda a funcionalidade prometida na release, e tinha que negociar com o cliente o que era mais importante, qual era a funcionalidade que agregava mais valor ao cliente, pois era essa que receberia o foco nas próximas iterações. Esse exercício mostrou o quanto a figura do "cliente presente" é importante para o sucesso do projeto.

Documentação? Modelos?

Normalmente eu sempre procuro ter um diagrama de classes à mão para programar. E antes de programar eu gosto de pensar no diagrama de classes. No nosso projeto não criamos e nem usamos qualquer diagrama UML, e sabe que falta eles fizeram? Nenhuma! Fui pensar nisso depois que cheguei em casa e analisei alguns pontos do curso para escrever este post. E eu creio que essa total irrelevância dos diagramas deve-se ao TDD. Criando os testes e modelando via TDD acabamos por saber exatamente o que precisamos fazer a cada passo, e com isso, os nossos métodos e classes vão nascendo de acordo com a necessidade real e momentâneas do projeto. Nada de desperdício!

Lógico que em nenhum momento foi falado que diagramas e modelos não são necessários nem importantes, mas o recado é: fazer quando necessário, fazer para auxiliar na comunicação da equipe e não fazer apenas por fazer.

O Pessoal da Sea:

Eu não participei de toda a programação, a turma ficou muito grande (um ponto negativo mas sem culpa do pessoal da SEA) e eu dei espaço para outro colega programar. Aproveitei e fui trocar idéias com o Willi, Bruno e Carol. Todos são muito acessíveis, humildes em escutar as nossas opiniões e bastante generosos ao explicar muito de como eles pensam e agem no dia-a-dia dos seus projetos. A troca de experiências é sem dúvida um outro ponto fortíssimo do curso.

Minha Conclusão:

O curso foi excelente, mas não é pra qualquer um. Eu acho - opinião exclusivamente minha - que nem todos poderão desfrutar dos ensinamentos do curso, porque ele é bem diferente de tudo que normalmente estamos acostumados (além do tema também ser bem diferente do tradicional). Para aproveitar o curso eu acredito ser extremamente necessário um conhecimento, e até mesmo uma simpatia prévia, de métodos ágeis. Em alguns pontos a ficha demora a cair, e só cai realmente se você pensar no que vivenciou e analisar de uma forma “mente aberta”, tudo o que foi visto e praticado no curso.

Pra mim, o curso serviu para reforçar todas as (boas) idéias e impressões que eu já tinha sobre as metodologias ágeis. Serviu também para que eu conhecesse na prática todo o poder de TDD e de iterações curtas, aliadas com um planejamento que nasce de dentro para fora (da equipe para o Gerente). Uma mensagem bem forte também que é passada durante todo o trabalho, é que as Metodologias Ágeis devem sempre ser adaptadas a sua realidade, então, não espere mágica!

Parabéns e sucesso ao pessoal da SEA!

Corrige aqui pra mim, é rapidinho…

2009-07-16T13:45:00.001-07:00

Ultimamente tenho escutado muito essa frase de algumas pessoas diferentes, e o que essas pessoas tem em comum? Todas são Gerentes.

Quando eu escuto uma frase dessas, a primeira coisa que eu pergunto, depois do frio na espinha, é: Quem disse que é rapidinho? A resposta que eu quero tirar dessa pergunta é: “se o Gerente acha que é rapidinho” ou, ”se algum Desenvolvedor (que depois eu procuro saber quem) afirmou que tal correção é rapidinha de ser feita”.

Normalmente é o Gerente que acredita que tal correção é rápida. Porém, em 98% dos casos o Gerente não programa mais (e eu conheço alguns dos 2% que ainda programam, e seus projetos são infinitamente melhor gerenciados), e com isso, não se preocupa mais com questões do tipo: o código está sendo bem feito, o Código está bem organizado ou no mínimo padronizado. Nem preciso falar que a cobertura de testes unitários no projeto desses mesmos Gerentes é nula.

Então, sem ter testes unitários, sem ter um padrão de codificação, sem um código limpo e coeso… como ele pode afirmar que é rapidinho???

Sem essas qualidades, qualquer correção a ser feita poderá gerar erros jamais imaginados!! Isso vem acontecendo muito nas minhas últimas manutenções… O grande problema é que algo que deveria ser simples acaba tornando-se uma jornada sem fim de refatoração extremamente arriscada, pra não dizer suicida.

Acredito que enquanto Analistas de Requisitos ou Analistas Não Programadores forem mais valorizados (maior salário) do que Desenvolvedores e Programadores, as correções rapidinhas jamais serão rapidinhas de verdade.

Apelo: Gerentes do meu Brasil! Cuidem dos códigos dos seus Projetos, e cuidem ainda mais dos seus Desenvolvedores, porque vai depender sempre deles se as suas futuras correções serão ou não rapidinhas.

Desenvolvimento Ágil Funciona

2009-07-03T17:52:00.001-07:00

Esse é o título da entrevista feita pela InfoExame com o Akita.

Pra quem não sabe, Akita é um cara muito influente no cenário do Desenvolvimento de Software Nacional. Na comunidade Ruby, ele é mundialmente conhecido e muito atuante.

Eu gostei muito da entrevista onde ele defende a adoção das Metodologias Ágeis. Achei que ele foi direto ao ponto desmistificando algumas questões que surgem principalmente de Gerentes, PMO´s e afins com relação às “limitações” das Práticas Ágeis.

Mas se tivesse que criticar algum ponto da entrevista seria o trecho onde ele diz o seguinte:

Aqui tem muitas empresas que desenvolvem para outras empresas, portanto têm pouca liberdade. Lá, elas desenvolvem produtos próprios e é aí que está a diferença.

Na minha opinião essas palavras podem servir como desculpas para os Gerentes não abraçarem a Agilidade, justificando que tais metodologias servem apenas para empresas que produzem produtos próprios e que em ambientes de licitações, terceirizações e “off-shore” seja impossível a adoção de tais metodologias. Algo que eu não considero uma verdade.

Mas eu quero destacar a resposta do Akita aos comentários/dúvidas deixadas pelos internautas, que pra mim, fechou com chave de ouro a entrevista, que pode ser lida aqui.

Espero que cada vez mais empresas e equipes acordem para as Metodologias e principalmente para as Práticas e Valores Ágeis!

Respostas do Akita aos Comentários:

Complementando as dúvidas: - não há nenhuma distinção em termos de projetos "grandes" ou "pequenos". Lembrando que projetos grandes simplesmente são um portfolio de projetos menores que podem ser feitos sequencialmente ou em paralelo por uma ou mais sub-equipes.

Cada uma delas seguindo normalmente me preceitos ágeis. É um mito que ágil só serve para projetos pequenos. - o problema de sistemas grandes que ficaram ruins de dar manutenção não é por falta de documentação e sim por falta de disciplina dos desenvolvedores.

Apenas Scrum não é suficiente, você precisa de técnicas de Extreme Programming e, claro, de desenvolvedores sênior. Uma equipe de desenvolvedores júniors sempre vai fazer sistemas ruins. Você precisa, no mínimo, de uma mistura igual de sêniors e júniors, pareando entre si.

Pair programming é importante, Test Driven Development é essencial, Integração Contínua é vital, etc.

O código precisa ser refatorado constantemente, os testes precisam rodar sempre.

Em se desenvolvendo da forma correta, o código mantém muita da sua flexibilidade em manutenção e inclusive na coesão do seu design sem que se precise fazer Big Design Up Front (BDUF), que é sempre ruim.

Detalhe: é sempre uma má idéia começar fazendo o diagrama de todas as centenas de tabelas que se "acha" que vai precisar. Design incremental, acompanhado de testes, com constante refatoração sempre funciona melhor, independente do tamanho do projeto.

Documentação por burocracia é totalmente desnecessário. Não quer dizer que "qualquer" documentação seja ruim. Veja qualquer projeto open source, no mínimo existe um README que dá uma visão geral do sistema. Em muitos casos só isso já é suficiente. Em outros casos temos Wikis que detalham um pouco mais alguns aspectos mais importantes do projeto.

Agora, documentação de tudo é irrelevante porque, por definição, toda documentação ficará obsoleta e dessincronizada com o código. Isso não é um "talvez", é um axioma.

A única "documentação" realmente efetiva é "Código Limpo", ou seja, código bem testado, bem refatorado.

O próximo programador deve conseguir ver o mínimo de documentação (o README), rodar os testes e saber começar a se inteirar com o código diretamente pelo código.

Manutenção sem testes é suicídio, e isso também é um axioma.

Sobre TDD

2009-06-25T17:17:00.001-07:00

Sempre que eu escuto falar de uma técnica, metodologia ou tecnologia, eu procuro ler muitas coisas sobre ela tentando me convencer de que eu preciso adotá-la, antes de aprendê-la de fato.

TDD é algo que ainda não faz parte totalmente da minha rotina diária quando estou no papel de desenvolvedor, mas já vi artigos e vídeos suficientes das pessoas mais renomadas no mundo do Software (algumas nem tão renomadas assim) e todas são unânimes... TDD é vital para qualquer projeto sério de software.

Algumas frases marcantes nessa minha jornada foram:

“Só os Imaturos não testam.”
“Desenvolvedores profissionais Escrevem testes, ponto final.”
“Um Desenvolvedor codificar sem criar Testes Unitários é o mesmo que um médico fazer uma cirurgia sem lavar as mãos.”

Quando eu falo em TDD não estou me referindo tão drasticamente à Técnica de escrever o teste antes de codificar, refiro-me mais da necessidade de ter uma cobertura de testes unitários efetiva no seu projeto. Apesar de que já estou me convencendo que com TDD codificar fica tudo mais fácil, depois que aprendemos bem a técnica...

É importante elucidar que, como quase tudo em Desenvolvimento de Software, devemos usar com inteligência os nossos testes, e não criar testes apenas por criar. Os testes são importantes, mas nem sempre precisamos de 100% de cobertura de testes no nosso projeto, enfim, como tudo, usar com Parcimônia.

Teve um post que eu achei bem bacana, e decidi que com a leitura dele finalizaria a minha “jornada motivacional” sobre Testes e TDD. Agora é arregaçar as mangas e escrever os testes necessários para criar código cada vez mais elegante, sustentável e de qualidade.

Então, aprenda você também a Como tornar-se inútil com TDD.

Viva a soldadesca

2009-05-15T08:12:00.001-07:00

Mauro Sant’Anna é um cara que eu admiro e respeito. Gosto do seu jeito franco e direto de avaliar certas tecnologias. Escuto e leio atentamente todas as suas opiniões sobre TI.

Na Edição 19 da MSDN Magazine (hoje .NET Magazine), ele escreveu na sua coluna um texto bem interessante, fazendo uma analogia entre uma equipe de desenvolvimento de software e um exército.

Quando eu li a primeira vez esse texto, em junho de 2005, eu estava começando a minha carreira. Naquela época, eu passei batido por esse artigo, li mas não refleti sobre a boa analogia feita entre uma equipe de desenvolvimento de software e um exército.

O início do texto começa assim:

No exército – ou pelo menos nos filmes americanos sobre o exército – todos os militares, até mesmo generais se consideram “soldados”. Todos já passaram por algum tipo de treinamento básico, quer como simples recrutas, quer em uma escola para oficiais. Todos sabem lutar e atirar, sendo que os oficiais carregam pistolas ao invés de rifles.

Parece lógico que alguém envolvido em uma guerra deva saber lutar e atirar né? Acho que essa analogia estende-se perfeitamente aos Projetos de software, todos os membros de uma equipe devem ter bons e sólidos conhecimentos sobre programação e tecnologia em geral. Mas são conhecimentos sólidos e ATUAIS, e não aquela velha história de que já programou muito em Delphi (ou outra linguagem mais antiga qualquer) mas hoje está enferrujado… essa é a desculpa mais comum que eu escuto. Se está enferrujado não serve para a guerra.

Ele continua o texto falando que o resultado de uma batalha depende tanto das estratégias feitas pelos oficiais quanto pela luta no campo de batalha que é realizada por soldados, cabos e sargentos. Além disso, ele enfatiza:

É até justo dizer que mais pessoas devem ter o conhecimento de luta no campo de batalha do que estratégia, pela simples razão que precisamos de um número bem maior de soldados do que de generais.

Ainda no texto, Mauro conta uma estórinha que funciona bem para reforçar as suas opiniões sobre o assunto.

Vamos imaginar um país – vou chamá-lo de “Polianalandia” no qual os oficiais além de não saberem pegar em armas, não se preocupam em treinar e verificar se os soldados realmente tem as habilidades necessárias à luta. Esses oficiais se trancam em longas reuniões fazendo planejamento e discutindo estratégia. As reuniões produzem sempre documentos coloridos muito bonitos…

Os oficiais então entregam estes documentos aos soldados e dizem que os soldados devem “se preparar para essas batalhas”. Os soldados então, sem ajuda ou supervisão dos oficiais, saem fazendo o que acham correto em termos de preparação para implementar aqueles planos brilhantes.

No decorrer do texto ele questiona se no Brasil os envolvidos no desenvolvimento de software se comportam como os “oficiais” da Polianalandia ou como os do exército dos filmes americanos, e completa:

Infelizmente muitas das pessoas envolvidas hoje no desenvolvimento de software no Brasil acham que apenas as atividades dos oficiais, como “arquitetura”, “levantamento”, “projeto” e “análise” têm mérito e podem ser desempenhadas por pessoas cultas e bem-sucedidas.

Ele continua o texto, falando sobre a importância de valorizar, treinar e acompanhar o trabalho dos Desenvolvedores, preocupando-se em como devemos fazer a programação em si.

O trecho abaixo destaca bem a essência do texto na minha opinião:

O mais irônico é que se um projeto de software é entregue a fase de programação foi feita com certeza. Já as outras etapas “de alto nível” podem não ter sido feitas ou – pior ainda – ter sido feitas “de mentirinha”, onde foram criadas páginas e mais páginas de diagramas inúteis, porque o projeto foi mudando ao longo do desenvolvimento e a documentação inicial tornou-se obsoleta.

Eu li esse texto novamente em maio de 2009, praticamente 4 anos depois, e infelizmente vejo os mesmos problemas da Polianalandia acontecendo a cada novo projeto.

Developers! developers! developers!

2009-04-15T14:25:00.001-07:00

Uma das piores coisas que alguém já fez para a TI foi comparar o desenvolvimento de software com a construção de um prédio, ou qualquer coisa relacionada a engenharia civil. Dentre muitos dos problemas que essa comparação nos trouxe, eu gostaria de destacar dois.

1) O "Efeito Cascata" - A idéia de que todos os cálculos e plantas devem estar prontos, revisados e homologados faz sentido para a construção civil. Quebrar paredes depois de prontas para adaptar uma porta não é nada muito sensato e nem barato. Por isso, dentro de um processo de edificação existe uma extensa e delicada fase de cálculos e confecção de plantas dos mais variados tipos, para que o início da obra aconteça de uma forma bem previsível e controlada. A tentativa excessiva de controle e previsibilidade em projetos de software quase sempre terminam por “Cascatear” o processo. E isso não é legal.

2) Programador = Peão (Desvalorização dos Programadores/Desenvolvedores) - Como estamos comparando o processo de desenvolvimento de um software à construção civil, é normal que tentemos relacionar os papéis entre essas duas atividades. Logo, temos arquitetos e engenheiros dos dois lados, e também temos o famoso peão, ou pedreiro de obras. Na construção civil o peão é um profissional importantíssimo, porém, como todo o trabalho já foi pensado e calculado por engenheiros e arquitetos, resta para ele literalmente colocar a mão na massa e fazer o trabalho pesado. "Ele não precisa pensar". Esse profissional é normalmente mal remunerado e tratado como apenas mais um na multidão, não tendo o seu merecido reconhecimento na maioria das vezes. Sua escolarida é baixa, ou nenhuma. Sua produtividade é medida e cobrada bem de perto, por que a obra tem prazo para terminar... enfim, "ele não precisa pensar", ele precisa apenas executar. Reconhecem esse cenário?

Se existe algum peão no contexto do Desenvolvimento de Software esse peão é o compilador. É ele quem "levanta as paredes do software". O Código Fonte, escrito pelo programador, é apenas um modelo que o compilador lê, entende e executa exatamente como epecificado.

Os Desenvolvedores são a engrenagem pensante do processo, ou pelo menos deveriam ser. São os resposáveis pela parte mais importante de um software que é o código fonte. No código fonte é que podemos criar um produto de qualidade, com boas práticas para garantir a manutenabilidade do produto e demais requisitos não funcionais como performance, entre outros. As tecnologias e linguagens mudam todos os dias, e os Desenvolvedores precisam estar atentos aos novos conceitos, novas IDEs, novas liguagens, padrões, etc.

É claro que existem outros papéis dentro do ciclo de vida do desenvolvimento de um software, mas não há a menor dúvida de que os Desenvolvedores são os que realmente deveriam ter uma maior remuneração e um treinamento constante (inclusive com a empresa bancando em muitos casos). Eles são o pelotão de frente, a frente de batalha, os criadores, os caras que encontram e arrumam os erros dos outros (outros = Analistas)... precisam ser competentes e muito bem valorizados. Com um ou dois programadores você constrói um software, agora, nem colocando 10 Analistas de Sistemas e mais 20 Analistas de Requisitos o seu software irá sair, exceto que algum desses saibam ou estejam dispostos a realizar a nobre arte de "sujar as mãos" ESCREVENDO CÓDIGOS.

Vejo que grande parte do insucesso dos projetos está relacionado com essa tendência de achar que, colocando um Analista e um Arquiteto chicoteando um bando de programadores jr as coisas acontecem. Essa é uma receita fracassada, mas ainda muito utilizada.

Espero que mais Gerentes e Coordenadores sigam o exemplo de Balmer, e enalteçam os seus desenvolvedores, ou você acha que um dos grandões da Microsoft grita Developers! Developers! Developers! com tanto entusiamo em vão? Claro que não.. ele sabe que os Desenvolvedores são a alma da sua empresa, um valioso ATIVO da organização. Ah, sim, mas não basta só gritar tá? Tem que VALORIZAR!

A Guerra dos Browsers

2009-04-01T20:23:00.001-07:00

Enfim, eu me rendo. Sou um entusiasta declarado dos produtos da Microsoft. Gosto de quase tudo que a empresa do tio Bill faz. Eu disse quase tudo.

Browser é uma coisa que definitivamente a MS não nasceu com o dom de construir. Ou melhor… todo mundo sabe fazer browser melhor do que a MS, pronto, assim melhorou.

Eu tenho 3 browsers no meu note. IE8, Firefox e Chrome. Eu gostava do IE, até usar o Firefox. Não tem o que discutir. O Firefox é infinitamente superior ao IE 7, e até agora, na minha opinião, continua melhor do que o seu sucessor.

Gostei do que vi no novo navegador da MS, mas a performance do IE é nitidamente inferior tanto ao Chorme quanto ao do Firefox. E eu não estou referindo-me a testes sofisticados, estou falando da simples navegação e inicialização dos 3 programas.

Sinceramente eu não espero mais nada da MS com relação a navegadores, porque pra o IE chegar ao nível do Firefox e do Chrome, só se a Fundação Mozila e o Google parar de vez de inovar nos seus browers, e certamente isso está bem longe de acontecer.

A verdade é que a Guerra dos Browsers está longe de acabar, mas mesmo sem terminar já tem um perdedor declarado, o IE.

Ah, e a propósito, isso não é Primeiro de Abril…

I T I L ? Sim, ITIL!

2009-02-06T21:02:00.001-08:00

No mês de Dezembro de 2008 obtive a minha primeira certificação de TI, a ITIL Foundation.

Mas, porquê ITIL?

Um dos principais motivos para que eu fizesse essa prova, foi a atualização para a V3 do ITIL, que aconteceu no final do ano de 2008. Como eu já havia feito um curso, muito bom por sinal, voltado para a ITIL V2, corri para aproveitar o conhecimento obtido com o curso e fazer a prova.

A ITIL foi o meu primeiro contato mais real com os conceitos de Governança de TI e Gerenciamento dos Serviços de TI, ambos essenciais para qualquer organização que dependa dos Serviços de TI. Estou gostando tanto dessa história toda que pretendo realizar a minha pós justamente em Governança de TI.

Diversidade é essencial para qualquer profissional da área, e a ITIL fez com que eu abrisse bem a cabeça com relação ao que acontece nos bastidores do software entregue. Vejo esses conhecimentos básicos para qualquer profissional que se preze.

Quanto ao conteúdo da prova, eu achei bem tranquilo. Tão tranquilo que consegui passar com o 92%. O curso cobre todo o conteúdo da prova, e os simulados disponíveis estão bem próximos da prova real. É fazer, estudar e passar.

Será que agora é ladeira abaixo??

2009-01-26T11:32:00.001-08:00

Ainda não tive a oportunidade de participar de um projeto ágil. Venho me esforçando para adotar as práticas e valores ágeis nos projetos que participo sempre que possível, mas como “manda quem pode e obedece quem tem juízo”, nem sempre posso ser ágil nos projetos.

Hoje, Janeiro de 2009, pra mim o desenvolvimento ágil ainda é o futuro, pois não vejo uma adoção em massa das grandes empresas do setor aqui em Brasília pelo menos, onde estou residindo atualmente, porém existem iniciativas bem interessantes…

O fato é que já li muitos posts por aí a fora decretando a morte do desenvolvimento Ágil, ou definindo Agile como uma buzzword. No início não embarquei muito nessa onda. Mas já é um fato de Agile não é mais novidade, e a tendência é que agora Scrum e XP fiquem cada vez mais no passado. Claro que não significa dar uma conotação pejorativa ao “passado”, mas é passado. Esse post foi que mudou a minha forma de pensar e de certa forma me abriu os olhos.

Mas penso que o Desenvolvimento Ágil ainda vai amadurecer muito, e claro que muita gente vai continuar torcendo o nariz para isso, pois os tropeços são inevitáveis. Afinal de contas, sair da zona de conforto nunca é muito fácil.

Porém, vejo que é um caminho sem volta, e que mais cedo ou mais tarde todos deverão ter a agilidade na veia. Assim espero. Então, prefiro pensar sobre tudo isso sob uma nova perspectiva. Que 2009 seja um ano cheio de tranquilidade no mundo e muita agilidade nos projetos.

O SCRUM caindo no gosto popular...

2008-12-04T16:41:00.001-08:00

Muitas são as equipes que estão adotando metodologias Ágeis. Por um lado isso é bom, muito bom. Mas, há sempre um mas, existe um lado não tão bom assim.

Muitas dessas equipes, que agora enchem a boca para dizer que utilizam o Scrum como metodologia, são as mesmas que faziam do RUP uma triste CASCATA.

Um post como esse deveria ser lido, re-lido e levado MUITO a sério por todos que estão utilizando Scrum.

Agile na HSM!

2008-11-20T16:11:00.001-08:00

A revista HSM Management é uma conceituada publicação voltada para executivos. Na sua edição de Nov/2008, a revista apresenta um interessante artigo intitulado Aprender com os programadores escrito por Keith McFarland.

O artigo faz uma comparação entre o Desenvlovimento de Software e o Planejamento Estratégico das empresas, indicando que a solução para um Planejamento Estratégico adequado ao dinâmico contexto atual está nas práticas do Desenvolvimento Ágil.

O que eu achei interessante é que o autor escreve que as práticas Ágeis tiraram a indústria de software de uma crise que já durava anos. Bem, eu ainda não vejo muita empresa no Brasil adotando e exaltando a adoção de metodologias Ágeis, infelizmente. Mas o fato de uma revista tão conceituada como a HSM conter um artigo desses já é, sem dúvida nenhuma, um bom motivo para comemorar!

Para baixar o artigo basta criar uma conta no site da revista, é rápido e grátis.

Existe também um podcast da própria revista comentando a matéria.

A Nova Bala de Prata.

2008-11-06T15:57:00.001-08:00

Já tem um bom tempo que eu estou lendo sobre metodologias Ágeis. O meu texto Mestre, que até agora serviu mais do que qualquer outro livro de uma metodologia específica, é A Nova Metodologia, de Martin Fowler. O artigo é incrível, surpreendente e esclarecedor. Considero esse artigo um divisor de Águas na Engenharia de Software.

Acredito que a frenética evolução tecnológica está nos deixando meio preguiçosos. Estamos com preguiça de pensar mais a fundo sobre as novidades, porque elas aparecem aos montes e todos os dias. Com a disseminação das práticas e valores Ágeis, o mercado está tendo que conviver agora com novas metodologias e paradigmas no Desenvolvimento de Software. Mas quando o assunto é metodologias a evolução é mais complicada, porque mexe muito com a cultura da empresa e da equipe.

E as novidades não param de chegar, agora a bola da vez são as Metodologias Ágeis, e o RUP de herói e antigo Mesias está virando vilão.

A idéia inicial daquele histórico dia em que alguns dos melhores desenvolvedores e profissionais de TI se reuniram, era discutir as práticas que eles utilizavam para obter sucesso nos seus projetos, e partindo disso, criar uma nova metodologia. Lá pelas tantas eles viram que não seria possível chegar a um concenso e resolveram ao invés de criar uma metodologia, escrever o Manifesto Ágil. Esse manifesto é um conjunto de VALORES e PRINCÍPIOS, que devem nortear o desenvolvimento de projetos Ágeis.

As metodologias ágeis seguem esses valores, são baseadas em princípios. Bem, isso todo mundo sabe. O que parece que ninguém sabe é que essas metodologias são um esboço do que devemos fazer, um norte mais "palpável", uma "tradução" do Manifesto Ágil. Nenhuma dessas metodologias podem ser consideradas como uma bala de prata! Metodologia nenhuma pode ser comprada, não podemos ler o XP ou Scrum e querer implementá-los de cabo-à-rabo. Devemos CUSTOMIZAR o XP, ADAPTAR o Scrum e, porque não, usar os dois juntos! enfim.

Muitas equipes que se diziam seguidoras do RUP na verdade utilizavam o modelo Cascata, esqueciam de uma premissa básica do RUP que é a iteração. Hoje vejo muitas equipes indo pelo mesmo caminho com as metologias ágeis. Pegam livros, fazem cursos, tornam-se Certified ScrumMaster e pronto, acham que os projetos estão salvos.

Adotar uma metodologia ágil significa mudar drasticamente o estilo de trabalhar e de gerenciar uma equipe. Trata-se de uma mudança CULTURAL bastante radical, a começar pela característica multidisciplinar das equipes ágeis.

A verdade é que ainda insistimos em ficar olhando para os céus esperando a Metodologia Salvadora, e desculpem o meu ceticismo, mas ela não existe.

Então, antes de ler qualquer livro sugiro a leitura atenta do Manifesto Ágil. Depois disso, leia A Nova Metodologia. Então reflita, e finalmente MUDE a forma de pensar e agir, com a equipe, com os cliente, com o código, com os diagramas e tudo mais do projeto. Estude as metodologias ágeis para adaptá-las ao seu processo, dessa forma sim você estará descobrindo melhores formas de desenvolver melhores softwares.

Reaproveitamente de Código (alheio).

2008-10-28T11:37:00.001-07:00

Procurar código no google é uma atividade normal na vida de um desenvolvedor (quem nunca procurou um exemplo de código na web, atire a primeira pedra...). Não vejo problema em copiar um código da net, o problema está em utilizar o código sem ao menos entender o que ele está fazendo, e principalmente não adaptá-lo às suas necessidades.

É bom ver o código dos outros, aprender como fazer determinada rotina ou até mesmo como não fazer.

Hoje já contamos com alguns buscadores específicos para isso, abaixo alguns:

Google
Krugle
Byte My Code
Code Fetch
Codase
Snipplr

Tem para todos os gostos, é procurar, estudar, adaptar e aproveitar...

Os "especialistas" da Agilidade...

2008-10-15T15:54:00.001-07:00

Certificação hoje em dia é quase que uma obrigação para um profissional de TI. Não que elas provem alguma coisa, mas enfim, o mercado "falou" temos que acatar...

Eu não sou contra as certificações, muito pelo contrário, acho que é uma forma de "especialização" mais rápida e voltada para o mercado, além de doutrinar o profissional à reciclagem constante. Porém, nem tudo são flores, e eu vejo um certo exagero em algumas certificações por aí.

Uma certificação que eu acho no mínimo curiosa é a tal da Certified ScrumMaster... Trata-se de um curso de 2 dias (eu acho) que ao final você receberá um certificado, e pronto, pode colocar mais essa certificação na assinatura do seu e-mail. Claro que eu estou simplificando bem o processo (até por um pouco de ignorância da minha parte) mas, mesmo se houvesse uma prova no estilo das certificações atuais, ainda assim eu não simpatizaria com a idéia.

Não vejo muito sentido nessa certificação. Acho louvável a iniciativa de participar de um curso de Scrum Oficial, mas não vejo com muitos bons olhos essa certificação, e não sou o único a pensar assim.

Não trata-se de uma crítica, mas sim um questionamento, uma reflexão. Também não estou criticando quem a têm, porque, afinal de contas, no mínimo o profissional está "correndo" na frente, está antenado, o que é essencial para um profissional de TI. Mas eu acho que já temos certificações de mais e profissionais realmente compententes e capacitados de menos.

Além disso, acho que Scrum, XP e as demais metodologias oriundas do Manifesto Ágil (ou que pelo menos seguem os valores Ágeis) foram feitas para serem usadas de forma adaptável. Tais metodologias são simples no seu conteúdo mas extremamente complexas na sua implementação por um simples motivo, o sucesso na sua adoção está diretamente relacionada a uma mudança cultural radical, e creio que não é com um curso ou um "canudo" que alguém consegue isso.

Os carmas da Microsoft

2008-07-11T18:03:00.001-07:00

"...um computador em cada mesa e em cada casa..." Assim profetizou Bill Gates (a frase foi mais ou menos essa...). Bom, não dá pra negar que ele de fato conseguiu, porém hoje vejo que a Microsoft sofre da síndrome do NNF (next, next, finish), e esse é o seu carma.

Para alcançar o seu objetivo a Microsoft investiu muito em facilidade e simplicidade para o usuário final, sejam eles usuários do Windows ou do Visual Studio. Com isso, hoje temos milhões de desenvolvedores, técnicos e profissionais de TI em geral, usuários das tecnologias da Microsoft, que não se preocupam em aprofundar os seus estudos na Arquitetura dos produtos, em segurança, em padrões de projetos e demais assuntos IMPORTANTÍSSIMOS para qualquer profissional que se preze. É bem verdade que “Não tem que ser difícil” (by Ramon Durães), mas é preciso ser bem feito, e ter qualidade.

Muitas críticas que eu já escutei acerca dos produtos e tecnologias da MS apenas demostram o completo desconhecimento, e porque não dizer ignorância, dos autores das críticas com relação aos produtos criticados.

Vejo que essa cultura está mudando, mas ainda de forma muito lenta. Creio que hoje a MS tem mais um importante desafio pela frente. Além de combater a agilidade do google e a criatividade da Apple, a gigante de Redmond tem que doutrinar os seus usuários (refiro-me aos usuários técnicos) a investirem de fato no estudo e compreensão das tecnologias que eles utilizam. Trocando em miúdos, não adianta mais levantar um servidor na base do NNF, tem que planejar a instalação, LER e entender o guia de instalação (documentação na MS é o que não falta!), entender as questões de seguraça e performance do produto, etc, etc e etc... Trocando ainda mais em miúdos... VAMOS ESTUDAR GALERA!!

Enfim, eu me rendo... Agilidade já!

2008-07-04T18:10:00.001-07:00

Nos últimos meses eu tenho estudado muito sobre Metodologias. Curiosamente o RUP não está mais em todas as minhas pesquisas, apesar de saber que o RUP 7 está bem mudado...

É consenso na indústria e entre os profissionais de TI que adotar uma metodologia de desenvolvimento é um fator crucial para projetos de software. Mas o que poucos entendem é que a metodologia adotada deve ser totalmente adaptada a realidade da empresa e principalmente da equipe que irá tocar o projeto.

Outro erro recorrente na minha opinião são as metáforas utilizadas para os projetos de Software. Quem nunca leu ou escutou comparações entre um projeto de Engenharia Civil e um Projeto de Desenvolvimento de Software? Penso que esse tipo de analogia nos induz a cometer erros seríssimos em nossos projetos, e as metodologias tradicionais como o RUP, além de mal interpretadas e aplicadas, não condiz em muito com a realidade do "código nosso de cada dia".

Vejo nas Metodologias Ágeis uma luz no fim do túnel. XP e Scrum caem como uma luva no contexto dinâmico dos Projetos de TI. Práticas e Valores ao invés de processos é uma escolha sensata. Tudo se encaixa quando começamos a estudar, entender e aplicar os valores ágeis no nosso dia-a-dia profissional, é o tipo de coisa que a gente não entende como conseguiu viver tanto tempo sem.

Hoje estamos vivendo uma grande mudança na Indústria de Software. Ela é silenciosa para os tradicionais e acomodados, porém barulhenta pra galera que anseia por dias melhores em seus projetos, e como toda mudança ela tende a ser difícil e um tanto dolorosa, mas acho que valerá a pena todo o esforço.

Espero que a indústria como um todo abrace os Métodos Ágeis o mais rápido possível!

eXtreme Programming - O BrainStorm da Programação.

2007-09-04T19:13:00.000-07:00

Hoje participei de uma reunião onde foi decidido a adoção de algumas práticas de desenvolvimento ágil no projeto do qual estou participando, e a primeira será a Programação em Pares.

Logo de início eu torci o nariz para essa tal de Pair Programming, mas, mesmo antes de vivenciá-la, consegui ver alguns benefícios nessa prática da Extreme Programming (XP).

Nivelamento do Conhecimento da Equipe: Normalmente a dupla é formada por desenvolvedores de diferentes níveis de conhecimento. Dessa forma o nivelamento da equipe ocorre mais rapidamente, possibilitando a criação de um ambiente mais homogêneo com relação ao conhecimento dos desenvolvedores, ou seja, um time mais coeso.

Código fonte comunitário: Todas as duplas devem revesar na codificação, se a equipe possui 4 duplas, é importate que todas as 4 duplas desenvolvam pelo menos uma funcionalidade do caso de uso, ou que dêem continuidade a uma funcionalidade já iniciada por outra dupla. Com isso todos os membros da equipe terão o conhecimento de todos os casos de uso do projeto, e não teremos um "dono do código", então, a manutenção de qualquer funcionalidade de qualquer caso de uso poderá ser feita por qualquer membro da equipe.

Comunicação/FeedBack: A comunicação é um importante conceito para as práticas do XP. Ao trabalhar em pares, e efetuando rodízios contínuos das duplas e das tarefas para as duplas, temos uma comunicação constante da equipe. Os FeedBacks poderão ser feitos em pequenos intervalos de tempo com a efetiva participação de todos.

Qualidade de Código: Quando trabalhamos em dupla, e principalmente, quando sabemos que logo em seguida alguém irá revisar o nosso código, certamente iremos nos preocupar ainda mais com a forma como programamos. Essa prática ainda estimula uma constante verificação e validação do código aumentando a qualidade do produto.

Logo que fui entendendo essas questões, a primeira analogia que me veio a cabeça foi a de uma reunião nos moldes BrainStorm. Como toda a mudança essa também irá provocar um certo desconforto inicial na equipe (pelo menos em mim já está provocando) mas não tem como negar que essas práticas todas beneficiam o projeto como um todo, logo, tende a beneficiar também todos os envolvidos no projeto.

Java? ainda não, obrigado.

2007-02-11T17:31:00.000-08:00

Estava lendo sobre o que vem por aí nas próximas versões da Framework .NET e gostei muito...

First look at Orcas by ScottGu's, Oneda, DLinq, etc, etc...

Desde a primeira vez que trabalhei com.NET não tive saudade nenhuma do mundo Java e pelo visto ainda vou ficar muito tempo sem sentir saudade.

Mundo .NET

2007-02-11T16:54:00.000-08:00

A MSDN Magazine Americana é uma revista muito boa. Tive a oportunidade de ler vários artigos pela web, fiquei impressionado com o bom conteúdo que a revista oferece. Já a MSDN Magazine Brasileira, bem, o conteúdo não é tão bom assim... O que vale mesmo é a coluna Encarando o Desenvolvedor escrita por Mauro Sant'Anna .

Eu era assinante da MSDN Magazine, mas já tinha um bom tempo que a única coisa que eu fazia era ler a coluna do Mauro e dar uma folheada geral na revista, largava a mesma na estante sem a mínima vontade de ler o seu conteúdo.

Mas pra minha felicidade, nessa última sexta-feira peguei nas mãos a revista Mundo.NET. Fiquei muito empolgado pois trata-se de uma publicação da Editaro Mundo, que faz as excelentes revistas Mundo PM e Mundo Java. Li a revista toda e o conteúdo não decepcionou... finalmente os desenvolvedores .NET tem agora uma publicação em português (bimestral) de ótima qualidade.

O injustiçado DataSet

2007-01-27T13:30:00.000-08:00

Desde sempre eu ouvia falar mal dos DataSets, obviamente quem mais criticava vinha do Java, mas também escuto muitos desenvolvedores .NET falando mal de arquiteturas que usam DataSets e TableAdapters.

Uma das frases que li e me motivaram a escrever esse post está no blog do Fábio Galuppo, um cara do qual eu tenho muito respeito, a frase é a seguinte: "... a melhor fonte para dados serem mapeados são objetos, não Datasets!".

O fato é que eu não creio que as coisas funcionem bem assim. Tudo depende. A panacéia da orientação a objetos trouxe à tona o Object-Relation Mapping (ORM). Ou seja, a OOP trouxe muitas "solução" para problemas antigos, mas trouxe também novos problemas. Bem, nada contra esquecer as Querys e trabalhar apenas com Objetos, e mais ainda, abstrair a camada de dados, mas infelizmente eu não conheço hj uma ferramente boa que consiga unir a "forma direta e fácil" das querys se relacionarem com os dados e o poder da Orientação à Objetos.

Em projetos grandes até justifica-se a adoção de uma framework de persistência, ou a construção de uma. Mas nem sempre temos recursos para investir numa arquitetura assim.

NHibernate é "legal", mas não pra tudo e não com tudo. Outras opções de persistência também podem ser legais, mas nada como abrir o Query Builder direto do VS.NET e criar a sua query facilmente sabendo que ela estará encapsulada dentro de um método de um objeto gerado automaticamente (TableAdapter), e que ela tera como resultado um DataTable, que pode ser facilmente trabalhado...

É bem verdade que essa é uma solução onde a performance pode deixar a desejar quando trabalhamos em um ambiente "Enterprise", mas experimente trabalhar de forma errada com o NHibernate... convenhamos, quando temos uma aplicação relativamente simples não vejo mal nenhum em usar extensivelmente a injustiçada dobradinha DataSet/TableAdapters. Vamos ver o que vem por aí nas próximas versões do .NET.

Motivação

2006-09-24T10:50:00.000-07:00

É incrível como algumas histórias, ou estórias, podem motivar a gente. Nesse final de semana assisti à dois filmes que motivam qualquer um.

V for Vendetta ou V de Vingança e A Luta pela Esperança. Ambos os filmes falam de ideais, perseverança, dignidade, luta, e sobre tudo: motivação. Todos os dois personagens pricipais tem objetivos muito bem definidos, sabem onde querem chegar, e por isso permanecem motivados a história toda.

Toda essa motivação faz com que eles sejam praticamente um super-herói, que vilão nenhum consegue deter.

Vale a pena assistir esses dois filmes, lição de casa pra quem anda meio desmotivado...

WEB 2.0 (beta)

2006-08-23T16:29:00.000-07:00

Até onde eu sei, o Google foi uma das primeiras, ou a mais conhecida empresa, a criar aplicativos totalmente baseados na web. Esse novo conceito de fazer software faz parte da nova geração da Web, a WEB 2.0. Essa reportagem do idgnow fala um pouco sobre isso e mostra alguns desses aplicativos.

<ironia>Parece que o primeiro passo para criação desses softwares é pensar num nome e colocar (beta) no final do nome...</ironia>

Existem 3 desses aplicativos que eu já uso com frequência, são eles: writely, um editor de textos; spreadsheet, o excel do Google; e o Google notebook, um pequeno aplicativo que permite salvar trechos de páginas para posterior leitura, ótimo pra quem adora navegar na web atrás de informações mas não gosta de ficar copiando e colando textos ou mesmo colocar os sites encontrados nos favoritos para depois ler o restante.

Vale a pena dar uma olhada nesses aplicativos e esperar pelo que vem por aí...

Post via Live Writer

2006-08-23T16:10:00.000-07:00

Pois é, mais um produto BETA na minha vida... Live Writer! Bem legal o aplicativo, bonito, prático e aparentemente estável. Com ele parece mais divertido escrever para os Blogs!

Primeiro Post

2006-08-01T00:56:00.000-07:00

Nunca pensei que fosse tão difícil escolher um nome para o blog. A idéia inicial era criar um nome bem alusivo ao .NET, assunto do qual eu pretendo escrever bastante, porém, eu não quero escrever apenas sobre .NET mas sim Tecnologia em geral. Sendo assim, resolvi dar esse nome (Além do .NET) também para homenagear um blog do qual eu gostava muito nos meus tempos de Java (Além do Java).

Gostaria muito de publicar o blog no TheSpoke, mas a ferramenta está bastante problemática, então, vou ficar por aqui mesmo.

Layout? Não, só conteúdo mesmo... quem sabe mais tarde...