Blog Fratech

Manifesto TI 2.0

2010-03-11T16:45:00Z

Nós da Fratech temos acompanhado um pequeno movimento que aos poucos vem ganhando força. Até o momento ele possui vários nomes e ainda está para ser centralizado. Alguns o chamam de Manifesto 2.0, outros o chamam de Pensamento 2.0, há ainda aqueles que dizem que é um "Movimento Anti-Corporativista". O interessante é que este movimento tem partido de grandes nomes do agile no Brasil. Manoel Pimentel, Editor Chefe da Revista Visão Ágil, é um dos pioneiros do Agile no Brasil e recomenda, em seu <a href="http://visaoagil.wordpress.com/2009/05/21/nao-cresca/" title="Não Cresça - por Manoel Pimentel">post no blog da Visão Ágil, não cresça</a>: <blockquote> ...caso você esteja iniciando uma empresa nesse momento, permita lhe dar uma pequena sugestão: "Não Cresça!".</blockquote> Ele explica o motivo: <blockquote> Essa minha humilde opinião é oriunda da constatação de que as empresas ditas como "grandes" têm uma complexidade de funcionamento e de pensamento tão evidente, que simplesmente é muito difícil ou até mesmo impossível fazer as coisas certas acontecerem nessas organizações.</blockquote> Vinícius Manhães Teles da ImproveIt desabafa em um <a href="http://blog.improveit.com.br/articles/2008/03/28/o-mercado-está-mudando" title="O mercado está mudando">post</a> oriundo de uma <a href="http://br.groups.yahoo.com/group/visaoagil/message/591" title="O mercado esta mudando ou é impressão minha?">discussão na lista da Visão Ágil</a>: <blockquote> O que uma empresa produz é resultado de como ela está estruturada. Quem tem autoridade para dizer como deve ser a estrutura de uma empresa é quem está no topo. Então, a estrutura de qualquer empresa é, no fim das contas, o resultado do modo de pensar, da mentalidade, de quem está no comando. A mentalidade da maioria dos empresários, diretores e gerentes no mundo inteiro é, com raríssimas exceções, arcaica e incompatível com o trabalho de desenvolver software. Quando o topo da empresa não entende o tipo de mentalidade necessária para se desenvolver software de forma bem sucedida, não há santo que possa fazer milagre. E eu garanto, a maioria absoluta das pessoas que estão no comando das empresas não entende uma vírgula do que significa desenvolver software. Isso inclui, certamente, a maioria absoluta dos CIOs. Não é à toa que eles buscam recorrentemente coisas como CMMI, PMBOK, MPS.BR, ITIL etc, todos absolutamente incompatíveis com a NATUREZA do desenvolvimento de software. </blockquote> Em contra-partida, Alexandre Magno concorda que é necessária uma mudança radical, em sua palestra sobre Utilização de Scrum no alto gerenciamento da empresa. <blockquote> ...Na comunidade tem gente muito boa aplicando Scrum em projetos de TI. Mas isso não é suficiente para mudar a cultura das empresas... ...quando o Scrum é aplicado em uma única área, esta área sofre pressão das outras áreas ao seu redor...</blockquote> Mas lembra: <blockquote> Os altos executivos tem a mente aberta e querem resultados, independente da metodologia</blockquote> Isso que nos leva a acreditar que o problema é falta de confiança por parte dos executivos em relação às pessoas. Isso ficou bem claro no evento Scrum Gathering, quando Ricardo Vargas do PMI relatou: <blockquote> ...seria ótimo se todos fossem pig (comprometidos com o resultado), mas a grande verdade é que a maioria das pessoas são chicken (não se importam com o resultado), só querem saber do salário no fim do mês...</blockquote> Alexandre Gomes, Diretor da Sea Tecnologia e figura muito respeitada no meio de desenvolvimento de Software, discorda e vai além, apresentando o conceito um pouco mais a fundo, em seu <a href="http://blog.seatecnologia.com.br/2009/01/12/manifesto-2-0" title="Manifesto 2.0">post sobre o Manifesto 2.0</a>: <blockquote> Vemos então dois momentos históricos bem distintos, dois modelos de pensamento bem claros ou, como temos dito, duas escolas bem definidas. E o melhor (ou pior) é que não se trata de um evento exclusivo da TI. Pelo visto, é algo de dimensões ainda não muito definidas pra nós, também presente em outras áreas do conhecimento. Especulamos que chamarão isso no futuro de algum nome. Talvez pós-modernidade, realismo-moderno, whatever. Não vale a pena tentar definir um nome pra isso agora. Melhor observar, aprender e ter a sobriedade para colher seus melhores frutos.</blockquote> Dentre vários pontos importantes, Alexandre menciona a visão dos Recursos Humanos no modelo tradicional e como isso passa a ser tratado como gestão de Pessoas no modelo 2.0 <blockquote> Na visão tradicionalista, profissionais são vistos como máquinas, com comportamentos determinísticos, produtividade contínua e de fácil substituição. A nova visão, felizmente, já compreendeu que profissionais não são máquinas, mas pessoas que sofrem de alegria, tristeza, motivação, depressão, cansaço, empatia e vários outros aspectos que influenciam em seu trabalho. Por isso, é tão complexo extrair métricas precisas de sua produtividade. Afinal, cada dia é um dia, cada projeto é um projeto e cada equipe é uma equipe. Na mesma linha, a substituição de profissionais também não é matemática. A sinergia entre os membros de uma equipe são fatores ímpares para sua motivação e produtividade. Trocar seis por meia dúzia pode por toda a dinâmica do grupo abaixo.</blockquote> Como conclusão, percebemos uma grande sinergia da comunidade ágil em busca de um novo modelo da gestão, que preza: <ul> <li>mais qualidade e flexibilidade do que comportamentos determinísticos</li> <li>mais conforto e humanidade do que números de medição de produtividade</li> <li>mais reflexão e pensamento do que atividades repetitivas</li> </ul> Este é o modelo 2.0 que vem surgindo em meio ao movimento Ágil no Brasil e que acredito ter suas próprias vertentes no mundo.

O Básico do planejamento ágil

2009-06-24T11:58:00Z

Muitos acham que ser ágil é não planejar. Decidir escrever uma série de artigos que voltam ao básico da gestão ágil. Uma abordagem independente de metodologia, onde tentarei explicar o porque de algumas práticas. Neste artigo, falarei sobre o planejamento inicial, deste ponto de vista. Há alguns meses atrás, escrevi sobre <a title="Projetos Ágeis - Levantamento Inicial" target="_blank" href="http://fratech.net/comunidade/exibir/46">como iniciamos projetos ágeis na Fratech</a>. Agora neste artigo, venho descrever o porque fazemos desta maneira. <h2>Planejamento Inicial</h2> Projetos Ágeis tem um período de planejamento inicial. Claro que conta com algumas diferenças em relação ao modelo tradicional. <img width="150" height="113" border="0" align="right" style="margin: 5px;" alt="O plano não é importante. O Planejar é!" src="http://img520.imageshack.us/img520/295/83915198.jpg" />A primeira grande diferença é que o planejamento inicial demora alguns dias, uma semana ou duas no máximo. Esse é o tempo necessário para contextualizar todos os envolvidos e definir o objetivo comum do projeto. Comparado aos meses de levantamento de requisitos e preparação de documentos e diagramas do modelo waterfall, esse é um tempo bem pequeno. A segunda grande diferença é que os documentos resultantes do planejamento não são muito importantes. Servem mais como um guia, mas alguns até dizem que podem ser descartados. O fato é que acreditamos que o ato de planejar é muito mais importante valioso do que o plano em si. Isso ressalta a importância de todos os envolvidos no projeto participarem ativamente do planejamento. É nesta fase que se definem os objetivos, metas, declaração de visão, plataforma tecnológica, restrições tecnológicas e padrões a serem seguidos. Em outras palavras, é nesta fase que se definem as diretrizes técnicas e de negócio do projeto. Aqui, define-se também a equipe e o papel de cada um dentro do projeto. <img width="300" vspace="0" hspace="0" height="225" border="0" align="left" style="margin: 10px;" alt="Planning Meeting" src="http://img517.imageshack.us/img517/6479/82821233.jpg" />Para que conseguir realizar um bom planejamento. O planejamento gera contexto e permite que as pessoas envolvidas tomem conhecimento do que deve ser feito e quando deve ser feito. É fundamental para que todos possam ser pró-ativos e caminhe na mesma direção, além de permitir que todos saibam quando estão chegando perto do objetivo. Mas para que isso aconteça, é fundamental que todos participem do planejamento, pois somente através da participação é que existe o comprometimento. É impossível alguém se comprometer a buscar um objetivo se ele não tiver participado da definição deste objetivo. Devido a natureza dinâmica dos projetos de desenvolvimento de software, faz-se necessário um plano flexível e abrangente. Como veremos no capítulo sobre requisitos, os projetos estão em constante mudança e, cabe a nós, criarmos um plano que permita a mudança constante. Por isso, não deve especificar detalhadamente o resultado do projeto, mas deve se limitar a descrever como o projeto será realizado. O plano deve determinar os papéis de cada um dentro do projeto, deve determinar como serão levantados os requisitos e quais as subfases do projeto. Como todos participam desse planejamento, o comprometimento em relação ao que foi definido neste momento será muito grande. Todo este planejamento não deve demorar muito mais do que 2 semanas, dependendo do tamanho do projeto e dos recursos disponíveis. <h2>Declaração de Visão</h2> <img width="350" height="233" border="0" align="left" style="margin: 10px;" alt="Equipe olhando o plano" src="http://img523.imageshack.us/img523/4840/84930564.jpg" />É bom que se determine os objetivos e metas do projeto, de forma que todos saibam, em alto nível, qual o resultado esperado do projeto. É importante determinar restrições de ambiente e expectativas gerais. É bom descrever, em 1 ou 2 folhas A4, qual é o software desejado. Chamamos este documento de visão geral. Ele deve ser escrito pelo cliente que, dentro do limite de 1 ou 2 folhas, deve descrever de forma abrangente, as partes mais importantes do software. Também é interessante criar um modelo inicial do fluxo das informações dentro do sistema. Nós o chamamos de fluxo de negócio, que deve mostrar as principais operações de negócio realizadas pelo usuário do sistema, quando operando o mesmo.<img width="200" height="239" border="0" align="right" alt="Fluxo de Negócio" src="http://img145.imageshack.us/img145/1104/88619747.jpg" style="margin: 10px;" /> Tudo isso serve para guiar a equipe e o cliente ao longo do desenvolvimento. <h2> Estimativa Inicial</h2> O cliente também deve listar algumas das funcionalidades que ele espera ter no software, sem o compromisso de limitar o escopo, mas apenas para garantir que ele não esqueça o que deve ser implementado. Essas funcionalidades compõem uma lista conhecida como Backlog e podem ser ordenadas por prioridade, tamanho ou complexidade das funcionalidades. O backlog pode ser utilizado para criar uma estimativa inicial de esforço e complexidade para o projeto. Essa estimativa serve como parâmetro para  definir viabilidade, custo estimado e pode até mesmo ajudar no contrato, porém é de extrema importância lembrar que são apenas estimativas e que, apesar de aproximadas, não são os números reais.

Test Driven Development & Design Evolutivo

2009-04-02T19:24:00Z

<img height="300" width="246" border="0" align="right" style="margin-left: 10px;" alt="TDD: Todo código é culpado até que se prove o contrário!" src="http://img18.imageshack.us/img18/8726/steyf.jpg" />Código limpo e auto-explicativo! Este é o objetivo do Test Driven Development ou TDD. O TDD é composto por práticas propostas pelo eXtreme Programming, reforçando os conceitos de Design Evolutivo e Test First. Focado nestes dois conceitos, tentarei explicar quais os benefícios de uma abordagem baseada no TDD. <h2>Benefícios do TDD</h2> Algo que tenho visto freqüentemente em clientes e treinamentos por todo o Brasil é que, em se tratando de processos de desenvolvimento Ágil, os desenvolvedores ficam um pouco perdidos no início do projeto. Isso deve-se ao fato de que a prática tão falada de desenvolvimento incremental gera várias dúvidas sobre a integridade e arquitetura do sistema. Os desenvolvedores simplesmente não sabem qual componente usar, quando usar e principalmente se é necessário usar. Isso já era de se esperar, pois estávamos acostumados ao modelo tradicional, onde esse tipo de decisão era responsabilidade de um arquiteto e nós apenas obedecíamos. Para facilitar o desenvolvimento incremental, uma das soluções é aplicar o design evolutivo. Design evolutivo significa que você só deve se preocupar com o design relativo à funcionalidade que está em sua mão naquele momento, porém deixar pontos de extensão para facilitar o a evolução. Esse tipo de prática favorece o refactoring e garante flexibilidade quando o cliente decide mudar o escopo da aplicação. <img hspace="-" height="366" width="300" border="0" align="left" style="margin-right: 10px;" alt="Ciclo do TDD" src="http://img18.imageshack.us/img18/9751/tddcycle.jpg" /> Os desenvolvedores habituados ao modelo tradicional de desenvolvimento de software não estão habituados ao design evolutivo. Não estão acostumados a tomar decisões de design a cada funcionalidade que precisam implementar. Isso gera um desconforto e receio na hora de implementar a solução. O TDD ajuda nessa questão. Permite que o desenvolvedor se veja como um consumidor daquela funcionalidade, pois é obrigado a refletir sobre o código que irá escrever, pensando em como seria sua utilização. Para que isso seja realidade, é necessário utilizar também a prática conhecida como Test First. Essa prática consiste em escrever o teste antes de escrever o código real, obrigando que o desenvolvedor imagine o código real antes mesmo de começar a escrever. Dentre outras coisas, isso também ajuda a ativar o lado criativo do cérebro, pelo fato de exigir o uso da imaginação. Isso muitas vezes revela-se o maior desafio para os iniciantes dessa abordagem, porém conforme o avanço no desenvolvimento isso se torna natural para o desenvolvedor, aumentando em muito a qualidade do código. Isso reforça também a idéia de que desenvolver software é uma arte e deve ser realizada por artesãos de software. A pergunta mais freqüente que ouço sobre isso é referente ao retrabalho que isso pode causar e o impacto gerado por grandes mudanças no escopo. Como resposta, pergunto: Qual seria o impacto desse tipo de mudança em uma arquitetura rígida e pré-definida? Seria seguro e fácil alterar esse tipo de arquitetura? É aqui que o TDD se torna muito importante! Quando precisamos alterar algum código, precisamos nos certificar de que tudo que funcionava antes da alteração, também funcionará depois da alteração. A melhor forma de garantir isso é utilizando testes automatizados. Os testes facilitam o refactoring e permitem verificar rapidamente o que funciona e o que não funciona no sistema. <h2>Mas como isso acontece na prática?</h2> Como descrito no livro Test Driven Development By Example de Kent Beck (Beck2003), os seguintes passos resumem a prática: <ol> <li>Rapidamente adicione um teste</li> <li>Execute todos os testes e veja que o teste novo falha</li> <li>Realize um pequena alteração no código</li> <li>Execute todos os testes e veja se todos tem sucesso</li> <li>Refatore para remover duplicação.</li> </ol> Neste mesmo livro, estão relacionadas algumas das possíveis perguntas a serem respondidas: <ul> <li>Como cada teste pode tratar de um pequeno incremento de funcionalidade?</li> <li>Quão pequenas e feias as mudanças podem ser para conseguir fazer os novos testes funcionarem?</li> <li>Com que freqüência os testes são executados?</li> <li>Quantos passos formam os refactorings?</li> </ul> Essas e outras questões, bem como detalhes técnicos sobre como praticar o TDD serão abordados no <a href="http://www.fratech.net/eventos/detalhes/81">Workshop sobre Test Driven Development</a> realizado pela Fratech. Se seu sistema anda com problemas na hora de refatorar ou sua produtividade está restrita, mesmo quando utiliza metodologias ágeis em seus projetos, não deixe de participar.

Utilizando metáforas no design de software

2009-02-20T17:55:00Z

<img height="150" align="right" width="200" src="http://img27.imageshack.us/img27/9079/homersimpsonbraindx6.jpg" alt="Bad Designer Brains" />Uma das principais dificuldades no desenvolvimento de software moderno é disseminar o conhecimento e difundir as necessidades do usuário. É muito difícil para nós desenvolvedores enteder o sistema, pois temos de nos adaptar às diversas situações de negócio, que mudam conforme cada projeto. O problema é que entendemos de computação, mas fazemos softwares para tratar situações que não tem relação direta com a computação. Isso nos obriga a lidar com teorias e conceitos que não são familiares ao nosso cérebro. Isso pode complicar de forma significativa o design.  <h2>O lado direito do cérebro (R-mode)</h2> <img height="261" align="left" width="349" src="http://img8.imageshack.us/img8/1603/ff70brain1fas7.jpg" alt="Hemisférios do Cérebro" style="padding: 5px;" /> O fato é que na maioria das vezes essas informações chegam para nós de forma textual, o que estimula apenas o lado esquerdo do cérebro (L-mode). Acontece que design de software é uma atividade de intuição, criatividade e resolução de problemas, atribuições do lado direito do cérebro (R-mode). Estes dois lados são assíncronos. Não podemos utilizá-los ao mesmo tempo. Pior que isso, é o fato de que nào controlamos o R-mode, apenas o L-mode de nosso cérebro. Para mais informações sobre isso leia <a href="http://www.pragprog.com/titles/ahptl/pragmatic-thinking-and-learning">este livro</a>. Ao tentar raciocinar textualmente com o L-mode, pensando em sintaxe e detalhes técnicos, perdemos o contato com o R-mode e consequentemente a capacidade de criar, contando apenas com a capacidade analítica e lógica de nosso cérebro. Em outras palavras, somos fisicamente limitados a criar péssimos modelos a não ser que dominemos o assunto de que o software trata (domain).  <h2>As metáforas vem para ajudar</h2> Após aceitar o fato de que somo limitados, devemos procurar formas de ultrapassar nossos limites. De acordo com a explicação acima, isso envolve ser capaz de usar o processo criativo quando projetando um software, ou, dominar o domain em questão. Precisamos criar um ambiente onde o L-mode se encontre com o R-mode, possibilitando criatividade e análise simultâneamente. Este ambiente é o mundo virtual das metáforas.  "Metáfora é um local comum para a verbalização e as imagens, uma forma de viajar de para trás e para a frente entre o consciente e o subconsciente, entre os hemisférios direito e esquerdo de nosso cérebro." [The Journal of Creative Behavior, 15(1), 1981.]  <h2>Metáforas e os métodos ágeis</h2> O uso de metáforas é algo muito difundido na comunidade de métodos ágeis. O Extreme Programming chega ao ponto de listá-la como uma de suas práticas, destacando a importância do seu uso. Outros conceitos e processos, como Domain Driven Design contém referências ao uso de metáfora e seus benefícios. Como visto no <a href="http://www.infoq.com/br/news/2008/11/decline-of-agile">post no infoQ</a>, muitos projetos ágeis tem falhado e conforme Martin Fowler relata <a href="http://www.martinfowler.com/bliki/FlaccidScrum.html">neste post</a>, a maioria por falta da adoção de boas práticas de engenharia de software. O uso de metáfora, é uma delas. <h2>Metáforas e Domain Driven Design</h2> No <a href="http://www.fratech.net/comunidade/exibir/41">Domain Driven Design</a>, devemos orientar e restringir o design do software às peculiaridades de seu domínio. O Domain Driven Design, prega o uso de uma linguagem comum e amplamente utilizada pelo time, com o objetivo de tornar mais fácil o entendimento e a comunicação de ambas as partes. <h3>Metáfora do Sistema</h3> Eric Evans afirma em seu livro, Domain Driven Design - Tackling Complexity in the Heart of Software, que "o design de software tende a ser muito abstrato e difícil de entender. Os desenvolvedores e usuários precisam de uma forma tangível de entender e compartilhar uma visão do sistema como um todo.". Utilizando as metáforas, os desenvolvedores e experts do domain tem um ponto de referência para discussões que podem ser mais concretas que o modelo por si só. Na verdade, as metáforas devem ser utilizadas como ponto de partida para a criação de uma boa ubiquitous language. As metáforas são consolidadas através do uso de modelos explanatórios (Explanatory Models), uma espécie de diagrama sugerido por Evans em seu livro. <h2>Criando metáforas</h2> <h2><img height="210" align="left" width="210" style="padding: 5px;" src="http://img242.imageshack.us/img242/3214/brain7639821ng9.jpg" alt="Brain Connections" /></h2> A palavra Metáfora vem do grego "tranferir", implicando a idéia de transferir os atributos de um objeto para um outro de forma literalmente impossível. Combinar dois objetos ou situações de forma que resulte em uma história comum aos dois lados. <a href="http://en.wikipedia.org/wiki/Edward_de_Bono">Edward De Bono</a> propôs uma técnica chamada <a href="http://en.wikipedia.org/wiki/Po_(term)">PO</a> que ajuda na criação de metáforas. Basicamente pegamos um objeto aleatório e associamos com o domínio<img height="256" align="right" width="182" style="padding: 5px;" src="http://img24.imageshack.us/img24/165/82206928es5.jpg" alt="Liquidificador & brain" /> em questão. Por exemplo: Domínio em questão: Criação de Metáforas Palavra Aleatória: Liquidificador Metáfora:   Imagine que criar metáforas é semelhante a fazer uma vitamina. Você deve escolher cuidadosamente os ingredientes que você mais gosta. Colocá-los no liquidificador, ligá-lo e esperar. Enquanto o liquidificador faz seu processamento, você deve relaxar. Após algum tempo, a vitamina está pronta. Basta retirar e tomar. Assim funciona a criação de metáforas. Você junta alguns estímulos (ingredientes) de sua preferência e armazena em seu cérebro. Estimule seu cérebro relaxando (ouvindo música, assistindo TV, caminhando pela cidade) enquanto o seu R-mode processa os ingredientes e derrepente, algo extremamente saboroso fica pronto. Sua nova metáfora. Pronta para utilizar. Expresse sua metáfora em software, da forma que é explicado neste <a href="http://www.fratech.net/comunidade/exibir/43">artigo</a>. O resultado será um design bem feito e simples de ser explicado. Aconselho ainda <a href="http://conversamos.wordpress.com/2007/10/01/do-uso-das-metaforas-ou-dos-criadores-de-enigmas/">esta</a> leitura sobre metáforas.  O que você acha da utilização de metáforas para o design de software? Deixe seu comentário.

Projetos ágeis - Levantamento Inicial

2009-02-17T13:57:00Z

Na última semana na Fratech, iniciamos um projeto grande de desenvolvimento. O projeto consiste em um ERP voltado para a indústria de manufatura, principalmente para empresas de pequeno porte. Como em todo projeto de software, o começo é sempre a parte mais arriscada, neste não seria diferente. É no começo dos projetos que devemos decidir qual o caminho a ser tomado, qual a tecnologia a ser aplicada e principalmente, o que deve ser feito. O processo que utilizamos para responder a essas questões, podem definir o sucesso ou o fracasso de um projeto. Isso traz ainda mais responsabilidade (e problemas) no começo do projeto. Neste caso temos duas opções: Postergar esses problemas para um momento onde estejamos mais maduros em relação ao projeto (mera ilusão), ou <a href="http://www.martinfowler.com/bliki/EarlyPain.html">enfrentá-los imediatamente</a>. Por esse e outros motivos, decidimos que a abordagem ágil seria a melhor opção neste caso. Usamos várias práticas ágeis que vimos funcionar efetivamente em outros projetos, para compor um processo customizado. Nesse contexto, iniciamos nosso projeto com os seguintes passos:   <ul> <li> <h2>Definir o objetivo do projeto:</h2> Nesta etapa devemos identificar os principais aspectos do sistema de forma abrangente e sucinta. Descrever o <a href="http://visaoagil.wordpress.com/2008/07/07/sim-nos-agilistas-temos-escopo…/">objetivo</a> deste sistema, para que tenhamos em mente onde queremos chegar. Isso serve para mantermos o foco e a simplicidade do sistema e determinar o resultado que deve ser atingido.</li> <li> <h2>Definição das áreas e operações do sistema:</h2> Após definir o objetivo é interessante relacionar algumas das principais operações do sistema (não mais do que 10), com o objetivo de enteder qual a complexidade do sistema. É necessário ser abrangente para que se consiga uma visão geral de das partes do sistema. Uma vez que se tenha esta lista, deve-se organizá-la, agrupando os itens por áreas que compõe o sistema. Não estou falando de módulos, mas de conjuntos de operações de um único módulo do sistema. Dica: Comece pelas partes mais complexas, buscando assim estimular o conceito de <a href="http://www.martinfowler.com/bliki/EarlyPain.htm"> early pain</a>. Para isso, utilizamos o conceito de <a href="http://www.heptagon.com.br/fdd2">FBS (Feature Breakdown Structure)</a> do <a href="http://www.heptagon.com.br/fdd-oque">FDD (Feature Driven Development)</a>, que nada mais é do que listar as funcionalidades de seus sistema, organizadas por áreas. Você pode variar os níveis e a estrutura de uma FBS, porém ela é muito útil para construir seu backlog. Exemplo de FBS usando templates de Mind Map Modeling (M3): </li> <a href="http://img511.imageshack.us/img511/3761/exemplom3pm9.png" target="_blank"> <img border="0" style="width: 578px; height: 199px;" src="http://img511.imageshack.us/img511/3761/exemplom3pm9.png" alt="exemplo de arquivo m3" /> </a> <li> <h2>Construção de protótipos de telas:</h2> Com as principais funcionalidades do sistema em mãos, é hora de criar alguns protótipos de tela e assim vivenciar a dificuldade na hora de implementar. Esses protótipos também são simples e abrangentes, de forma que pode-se utilizar wireframes para representar as telas. O objetivo deste passo não é saber como serão as telas, mas sim validar as descrições das funcionalidades descritas no item anterior. Lembre-se que neste momento você deve ter por volta de 10 funcionalidades apenas, o que mantém este processo simples e rápido. <a href="http://img232.imageshack.us/img232/9580/prototipodetelagp0.png" target="_blank"> <img width="500" border="0" src="http://img232.imageshack.us/img232/9580/prototipodetelagp0.png" alt="Exemplo de protótipo de tela" /> </a> </li> </ul>   Este processo completo não tomou mais do uma semana no projeto em questão. Isso contece porque o objetivo não é detalhar tudo o que precisa ser feito no sistema, afinal não acreditamos no <a href="http://www.agilemodeling.com/essays/examiningBRUF.htm"> Big Requirements Up Front</a>, mas sim no modelo de <a href="http://martinfowler.com/articles/designDead.html">design incremental</a> adotado nas metodologias ágeis. Os passos seguintes a estes, fazem parte do desenvolvimento do software em si e incluem tarefas de modelagem, levantamento de requisitos continuamente e escrita de testes e código. A partir deste ponto o backlog é composto pelos itens iniciais da FBS, conforme reuniões de priorização com o cliente. O time já está pronto para começar o desenvolvimento do software e após 2 semanas, entregar software funcionando. Conforme o time se aprofunda no desenvolvimento, deve atualizar a FBS com protótipos e descrições das funcionalidades, seguindo o conceito de design evolutivo. Pode-se também listar os critérios de aceitação ou casos de teste para cada funcionalidade. A FBS alimenta o backlog e, ao final do projeto, ela servirá para mensurar a quantidade de funcionalidades implementadas e como estão divididas. Como um mapa da aplicação. Para mais informações sobre como desenvolver o escopo de sua aplicação veja <a href="http://visaoagil.wordpress.com/2009/02/05/escopo-iterativo-e-incremental-para-o-gerenciamento-agil-de-requisitos/">este post</a> do Manoel Pimentel.

Hello Merb

2009-02-03T13:36:00Z

Ultimamente tenho utilizado o <a target="_blank" href="http://merbivore.com/">Merb</a> no trabalho. O Merb é um framework MVC leve e prático que oferece agilidade no desenvolviemnto web, da mesma forma que o Rails e o Grails. O Merb é escrito em Ruby e dessa forma, utilizamos Ruby para seu desenvolvimento. Neste artigo, vamos caminhar por algumas das funcionalidades básicas do Merb, criando uma pequena aplicação hello World. O Merb se torna ainda mais interessante se levarmos em consideração que <a target="_blank" href="http://merb-br.org/merb-rails">o Merb 2 também será o Rails 3</a>. Por isso é bom ir entender melhor o funcionamento do Merb. Apesar usar um paradigma similar, o Merb possue algumas diferenças interessantes em relação ao Rails (que foi um dos motivos da fusão). O Merb é um framework agnóstico, que significa que não impões nenhuma escolha ao usuário, apesar de oferecer alguns padrões. Isso inclui o mecanismo ORM, biblioteca JavaScript e mecanismo de template. No quesito ORM, o Merb suporta o <a target="_blank" href="http://datamapper.org/">DataMapper</a>, <a target="_blank" href="http://ar.rubyonrails.org/">Active Record</a> e o <a target="_blank" href="http://sequel.rubyforge.org/">Sequel</a>. Os mecanismos de template suportados são o <a target="_blank" href="http://haml.hamptoncatlin.com/">HALM</a> e o <a target="_blank" href="http://en.wikipedia.org/wiki/ERub">eRuby</a>. Isso fez com que o time de desenvolviemnto pudesse focar no core do Merb. <h2>Instalação</h2> Para instalar o Merb,<a target="_blank" href="http://www.ruby-lang.org/pt/downloads/">é necessário ter o Ruby</a> e o <a target="_blank" href="http://www.rubygems.org/read/chapter/3">RubyGems</a> instalados e então, basta executar <code>sudo gem install merb</code> (sudo necessário somente para plataformas unix). Também devemos instalar algum servidor para executar nossas aplicações merb. O Merb pode ser utilizado com diversos servidores, como Mongrel, WebBrick, Thin, etc. Para instalar o Mongrel, basta executar o comando <code>gem install mongrel</code> O Merb oferece 4 modelos de aplicação (merb stacks) para iniciar um projeto. São eles: <ul> <li>App - Stack com mecanismos padrão definidos para ORM, templates e configurações gerais. Adiciona dependências através do arquivo <code>config/dependencies.rb</code></li> <li>Core - Stack que gera uma aplicação completa, com estrutura de diretórios e arquivos de configuração, porém não inclui dependência. Permite a você configurar sua aplicação para utilizar os mecanismos de sua preferência.</li> <li>Flat - Stack para uma aplicação onde a lógica está centralizada em um único arquivo controlador, porém com arquivos de configuração separados.</li> <li>Very-Flat - Stack para uma aplicação onde tanto a lógica quanto as configurações estão centralizadas em um único arquivo. Esse tipo de aplicação é comum nos famosos ruby micro-frameworks.</li> </ul> Para criar uma aplicação, basta executar o comando <code>merb-gen <<stack>> nome_aplicacao</stack></code>. Para este exemplo, vamos utilizar o stack app: <code>merb-gen app hello</code> O resultado deve ser uma lista com os arquivos criados: <pre> Generating with app generator: [ADDED] .gitignore [ADDED] public/.htaccess [ADDED] tasks/doc.thor [ADDED] public/javascripts/jquery.js [ADDED] doc/rdoc/generators/template/merb/api_grease.js [ADDED] doc/rdoc/generators/template/merb/index.html.erb [ADDED] doc/rdoc/generators/template/merb/merb_doc_styles.css [ADDED] doc/rdoc/generators/template/merb/merb.css [ADDED] doc/rdoc/generators/template/merb/prototype.js [ADDED] doc/rdoc/generators/template/merb/merb.rb [ADDED] doc/rdoc/generators/merb_generator.rb [ADDED] public/favicon.ico [ADDED] public/merb.fcgi [ADDED] public/robots.txt [ADDED] public/images/merb.jpg [ADDED] Rakefile [ADDED] app/views/exceptions/not_found.html.erb [ADDED] app/views/exceptions/not_acceptable.html.erb [ADDED] app/controllers/exceptions.rb [ADDED] app/controllers/application.rb [ADDED] app/models/user.rb [ADDED] app/helpers/global_helpers.rb [ADDED] autotest/discover.rb [ADDED] autotest/merb_rspec.rb [ADDED] autotest/merb.rb [ADDED] config/rack.rb [ADDED] config/router.rb [ADDED] config/environments/rake.rb [ADDED] config/environments/test.rb [ADDED] config/environments/development.rb [ADDED] config/environments/staging.rb [ADDED] config/environments/production.rb [ADDED] config/dependencies.rb [ADDED] config/database.yml [ADDED] config/init.rb [ADDED] public/stylesheets/master.css [ADDED] public/javascripts/application.js [ADDED] merb/session/session.rb [ADDED] merb/merb-auth/setup.rb [ADDED] merb/merb-auth/strategies.rb [ADDED] tasks/merb.thor [ADDED] spec [ADDED] gems [ADDED] app/views/layout/application.html.erb </pre> O Merb cria vários diretórios e arquivos, que compõe a aplicação completa. Em um outro artigo, explicarei o objetivo de cada um desses diretórios (para que este artigo não fique grande e chato.). Para testar a aplicação, basta executar o comando <code>merb</code> dentro do diretório de sua aplicação. <blackquote> </blackquote> Obs.: Caso receba uma mensagem parecida com <code>FATAL: The gem dm-core (= 0.9.9, runtime), [] was not found </code> não se preocupe. Isso quer dizer que o merb criou uma dependência que aponta para a versão errada de um determinado gem. Nesse caso, é necessário verificar se o arquivo config/dependencies.rb indica a versão correta do <code>dm</code> (o gem do DataMapper) e então corrigir a versão. Use o comando <code>gem list | grep dm</code> para verificar a versão de seus gems dm. A versão mais atualizada na data deste artigo era a 0.9.10. Dessa forma, vamos até o arquivo config/dependencies.rb e verifique se o valor da variável <code> dm_gems_version</code> corresponde à versão instalada de seu gem dm. Caso a versão indicada seja diferente, modifique para a versão apresentada no comando acima. Procure utilizar sempre a última versõa instalada, a não ser que você saiba o que está fazendo. Esse problema ocorre porque o merb usa sempre a primeira versão que ele consegue encontrar (geralmente a versão de númeração mais baixa, porque os arquivos são listados em ordem crescente). O mesmo vale para os gem <code>do </code>. Uma vez que sua aplicação inicie sem erros, você será capaz de acessá-la através da url <code> <a target="_blank" href="http://localhost:4000">http://localhost:4000</a>. Você deverá ver a tela a seguir:</code> <a target="_blank" href="http://img24.imageshack.us/img24/4827/merbemptyappdz0.png"><img border="0" width="480" title="Merb empty app Screenshot" alt="Merb Empty App Screenshot" src="http://img24.imageshack.us/img24/4827/merbemptyappdz0.png" /></a> As aplicações merb são organizadas utilizando o pattern MVC (Model View Controller), que significa que teremos uma classe representando nosso modelo de domínio (Model), um ou mais arquivos repreentando nossas telas (view) e uma classe para controlar o fluxo de nossa aplicação (Controller). No merb as classes controller extendem a classe <code>Application</code> gerada automaticamente pelo Merb. Application, por sua vez extende <code>Merb::Controller</code>. Para criar nosso primeiro controller, vamos utilizar o comando <code>merb-gen controller hello</code> <pre> /hello/config/environments/development.rb [ADDED] app/controllers/hello.rb [ADDED] app/views/hello/index.html.erb [ADDED] spec/requests/hello_spec.rb [ADDED] app/helpers/hello_helper.rb Don't forget to add request/controller tests first.</pre> Os controllers são compostos por métodos que são mapeados como actions da aplicação. Vamos criar a action index, adicionando apenas um método chamado index no arquivo <code>app/controllers/hello.rb</code>.   <pre> def index 'Hello World, from Merb!' end </pre> Agora basta reiniciar a sua aplicação (pare o servidor com <code>ctrl+c</code> e inicie novamente com <code>merb</code>) acessar o endereço <a target="_blank" href="http://localhost:4000/hello">http://localhost:4000/hello</a> para ver sua obra prima. Em breve teremos mais artigos sobre Merb e outros frameworks.

Hello Ioke!

2009-01-29T12:20:00Z

<a target="_blank" href="http://ioke.org"><img height="78" border="0" align="left" width="80" style="margin-right: 10px;" title="http://ioke.org" alt="Ioke Logo" src="http://www.ioke.org/img/IokeLogo.png" /></a>No dia 23 de Dezembro de 2008 <a href="http://olabini.com/blog/">Ola Bini</a> (desenvolvedor do JRuby e vários outros projetos) liberou a primeira versão de uma nova linguagem chamada <a href="http://ioke.org">Ioke</a>. Ioke já nasceu com certa popularidade devido aos vários <a href="http://olabini.com/blog/category/ioke">posts sobre suas idéias em relação ao ioke</a>. Apesar disso a comunidade de desenvolvedores tem por volta de 7 desenvolvedores ativos e as listas de email estão começando a caminhar. <a href="http://olabini.com/blog/2009/01/ioke-s-released/">A versão "S" da linguagem acabou de ser liberada</a>. Ioke é desenvolvida em Java e é uma linguagem concebida para ser executada na JVM, por motivos óbvios de adoção e estabilidade. Qualquer um com bons conhecimentos de Java pode ajudar em seu desenvolvimento. É também baseada em linguagens como Io, Smalltalk, Ruby e Lisp. Neste post quero apresentar superficialmente alguns dos conceitos básico da linguagem, que tem por objetivo principal, ser mais expressiva. Ioke é uma linguagem dinâmica porém fortemente tipada. É <a href="http://en.wikipedia.org/wiki/Prototype-based_programming">baseada em protótipos</a>, o que significa que não possui o conceito de classes. Todo e qualquer instância é criada a partir de protótipos (outros objetos) num processo de clonagem, ou imitação (mimic, como é chamado no Ioke) do comportamento e conhecimento de um objeto já existente. Isso significa que em Ioke, tudo (tudo mesmo) é um objeto. Existem alguns objetos já embutidos na linguagem, que nos possibilitam imitá-los para criar nossos próprios objetos. Por exemplo: <code lang="ioke">myObj = Origin mimic</code> O código acima cria um objeto chamado myObj que faz mimic (imita) o objeto Origin que é um dos objetos básicos oferecidos por Ioke. <h2>Instalação</h2> Para instalar Ioke, você deve ter o JDK1.5 ou superior instalado em sua máquina e baixar o pacote binário do Ioke neste <a href="http://www.ioke.org/download.html">link</a>. Depois, basta descompactar o arquivo em algum diretório de sua escolha e incluir a variável de ambiente IOKE_HOME apontando para o diretório de instalação do Ioke. Também acrescente IOKE_HOME/bin à variável de ambiente PATH. <h2>Hello World</h2> Como todo com artigo de programação vamos escrever o hello world em Ioke, passando por algumas características da linguagem. A seguinte linha imprime a famosa mensagem "Hello World!" na tela: <code>"Hello World from Ioke!" println</code> No código acima, podemos perceber a primeira grande diferença em relação a outras linguagens. Criamos um objeto que imita Text e ativamos a cell println. Atributos e métodos são chamados de cell em Ioke. Cells podem ser adicionadas ou removidas dinamicamente, permitindo criar objetos únicos em seu sistema. A cell println é definida no objeto Origin e está disponível em nosso Text, simplesmente porque Text imita Origin (<code>Text = Origin mimic</code>). Outra grande diferença é que as mensagens para acionar uma cell não possuem pontos. Isso quer dizer que para chamar métodos ou acessar atributos não há um '.' entre o objeto e a cell (método ou atributo). Reparem que <code>println</code> é uma cell do objeto <code>"Hello world from Ioke"</code>, e para acessá-lo utilizamos apenas um espaço entre o objeto e a cell. Isso tem por meta, tornar a linguagem mais expressiva. Vamos experimentar um pouco da dinamicidade do Ioke e entender melhor seu conceito de protótipos. Observe o seguinte código:   <pre> aObject = Origin mimic aObject aCell = "Hello world in a cell" aObject aCell println</pre>   Na linha 1 criamos um objeto chamado aObject e dizemos que este objeto deve ser baseado no objeto Origin do Ioke. Origin é um objeto embutido no Ioke, com o objetivo de prover um ponto de início para a maioria dos objetos. "Foi especialmente criado para ser a origem dos objetos" como dito no <a href="http://ioke.org/wiki/index.php/Guide">Ioke Guide</a>. Origin por sua vez, imita Ground (outro objeto) que por sua vez imita Base e DefaultBehavior. Juntos esses objetos definem o comportamento de um objeto comum em Ioke. <code>mimic</code> é uma cell do objeto Base, que retorna uma intância que contém todas as cells do objeto no qual foi chamado (neste caso, Origin) incluindo as cells dos objetos que Origin imita (Ground, Base e DefaultBehavior). Na segunda linha, adicionamos uma cell chamada aCell no objeto aObject. Na verdade, Ioke procura por uma cell com este nome e caso não encontre, esta cell é criada e adicionada dinamicamente no objeto. Esta cell recebe o valor literal <code>"Hello World in a cell"</code>. Acabamos de criar um atributo para nosso objeto. É assim que definimos objetos específicos no Ioke. A terceira e última linha, obtém o valor da cell <code>aCell</code> do objeto <code>aObject</code> e chama o método <code>println</code> do valor resultante da chamada <code>aObject aCell</code>. O valor contido em aCell apesar de ser literal, também é um objeto que imita Text que por sua vez imita Origin. Isso faz com que a chamada da última linha seja interpretada como <code>"Hello world in a cell" println</code>. Como podemos observar, Ioke é uma linguagem não muito típica, porém com grandes promessas em termos de expressividade. Mesmo tendo sido mencionada pela primeira vez em Novembro de 2008 já possui duas versões muito capazes que incluem, execução de macros, aspectos, iSpecs (no estilo RSpec do Ruby). Há ainda muitas outras características interessantes no Ioke, porém isso é assunto para um outro post.

Groovy ou Ruby? Um breve relato.

2008-10-03T18:58:00Z

Como já é de conhecimento publico, a InfoQ Brasil será lançada no dia 20 de Outubro de 2008 incluindo vários artigos e notícias traduzidos para o protuguês, além do livro <a href="http://www.infoq.com/minibooks/scrum-xp-from-the-trenches">Scrum e XP direto das trincheiras</a> também traduzido. Todos que conhecem o portal InfoQ sabem da qualidade de seu conteúdo e pretendemos manter a mesma qualidade na versão brasileira do portal. Para começar bem, iremos cobrir e publicar as apresentações do <a href="http://site.locaweb.com.br/railssummit/">Rails Summit 2008</a> ao longo do próximo ano. Esse evento promete ser um marco na história do Ruby e Rails no Brasil e como tal estarei lá pra conferir. =) Você devem estar se perguntando o que isso tem a ver com o título do post. =) Eu explico. Eu pedi pro Floyd Marinescu (co-fundador da InfoQ) uma idéia de quantos posts são publicados por mês na InfoQ original. Ele me respondeu o email dizendo que o máximo que ele podia fazer era conseguir um arquivo CSV com o seguinte conteúdo: Publications.csv TYPE;DATE;COMMUNITIES Interview;15/06/2008;Java Article;28/03/2008;Architecture Article;23/05/2008;SOA News;12/06/2008;.NET News;12/06/2008;.NET News;10/06/2008;Java ... continua ... Obviamente isso não resolvia meu problema. Nesse arquivo temos o tipo de publicação (Interview, Article, News ou Presentation), tem a data em que foi publicado e a comunidade em que foi publicado o artigo. O que eu pensei? Vou escrever um parser para esse arquivo e assim obter os dados que preciso. O objetivo era conseguir um resultado como esse: ANO A quantidade de materias desse ano foi: <<TOTAL ANO>> A media de materias por mes nesse ano foi: <<MEDIA DO ANO>> ANO A quantidade de materias desse ano foi: <<TOTAL ANO>> A media de materias por mes nesse ano foi: <<MEDIA DO ANO>> O Total de itens é <<TOTAL DE ITENS DO ARQUIVO>> Decidi que faria esse parser em ruby, abri meu <a href="http://www.e-texteditor.com/">e-editor</a> e comecei a digitar o programa. 15 minutos depois percebi que eu estava indo pelo caminho errado e que não conseguiria o reslutado esperado daquela forma. Meus anos de Java me acostumaram errado. Eu comecei a pensar que deveria haver algum modo mais fácil de fazer aquilo. Decidi então escrever em Groovy, linguagem que possuo mais domínio do que Ruby. Em Groovy não tive dificuldades e construi esse código: publications.groovy List items = [] new File('publications.csv').splitEachLine(';') { line -> items.add(line) } def range = 2005..2008 range.each { year -> println year numItems = items.findAll{it[1] =~ /${year}$/}.size println "A quantidade de materias desse ano foi: ${numItems}" def average = (numItems/12) as BigInteger println "A media de materias por mes nesse ano foi: ${average}" def weekAverage = (average/4) as BigInteger println "A media de materias por semana nesse ano foi: ${weekAverage}\n\n" } println "Total de itens em todos os anos: ${items.size}\n" Foi extremamente fácil e não gastei mais do que 15 minutos para concluir esse código. Decidi então que eu iria escrever o mesmo programa em Ruby, tentando seguir os mesmos passos que realizei em Groovy. O resultado saiu em 10 minutos com o seguinte código: publications.rb require 'csv' rows = CSV::Reader.parse(File.open('publications.csv'),';') @items = rows.to_a range = 2005..2008 range.each {|year| puts year @thisYearItems = [] @items.each {|item| if (item[1] =~ /#{year}$/) != nil @thisYearItems << item end } numItems = @thisYearItems.size puts "A quantidade de materias desse ano foi: #{numItems}" average = (numItems/12) puts "A media de materias por mes nesse ano foi: #{average}" weekAverage = (average/4) puts "A media de materias por semana nesse ano foi: #{weekAverage}\n\n" } puts "Total de itens em todos os anos: #{@items.size}\n\n" Dessa experiência pude observar várias semelhanças entre as duas linguagens e também algumas diferenças. Os pontos que mais me chamaram a atenção foram o seguinte: <ol> <li>Groovy possue mais métodos de conveniência do que Ruby. Esses métodos são projetados para oferecer mais comodidade para o desenvolvedor. Isso fez com que o programa escrito em Groovy utilizasse apenas 23 linhas de código, enquanto o programa em Ruby utiliza 29 linhas. </li> <li>Ruby foi mais performático neste caso (rodando ambos como script). </li> <li>Ambas são linguagens extremamento flexiveis e poderosas com recursos e facilidades muito boas. Eu não tentei escrever esse programa em Java e nem em C, mas imagino que teriamos pelo menos o dobro de linhas de código. Se alguém se habilitar a fazer essa experiência, eu agradeço.</li> </ol> Analisem os dois exemplos e tirem suas próprias concluões sobre qual delas é mais a sua cara. Isso me deu uma ótima idéia para postar sobre Groovy on Rails e Ruby on Rails. Também pretendo postar sobre meta-programação nestas duas linguagens.' Pra terminar o post vale a pena mostrar o resultado, assim já dá uma idéia de quanto conteúdo teremos na InfoQ Brasil. 2006 A quantidade de materias desse ano foi: 949 A media de materias por mes nesse ano foi: 79 A media de materias por semana nesse ano foi: 19 2007 A quantidade de materias desse ano foi: 1525 A media de materias por mes nesse ano foi: 127 A media de materias por semana nesse ano foi: 31 2008 A quantidade de materias desse ano foi: 878 A media de materias por mes nesse ano foi: 73 A media de materias por semana nesse ano foi: 18 Total de itens em todos os anos: 3352 Conto com a participação de todos vocês nesse novo e promissor portal brasileiro. =)