Tag: metodologia

Case – Site da Milk-it

22 de outubro de 2007 às 18:07 | Michel Filipe | , , , , ,

Olá a todos! Tomei a iniciativa de criar uma “coluna” no blog para contar as histórias dos cases da Milk-it. Vou começar a coluna contando a história do nosso próprio site.

Muitos aqui não sabem, mas a Milk-it ficou um ano sem site. Não tínhamos condições de parar algum projeto para nos dedicar somente ao nosso site, e ainda não temos, mas é com isso que entra a parte interessante. Eu, Lucas e Carlos sabíamos que uma empresa de tecnologia sem site é equivalente a um cavaleiro sem cavalo – me perdoe a analogia hehe. Pensando assim, resolvemos aproveitar a semana em que um projeto estava em homologação e decidimos botar a “mão na massa”. Uma semana é muito pouco? Sim, também achamos, mas conseguimos!

1ª Etapa – Elaboração das telas

Esboço das telas do site da Milk-itPor sorte o Lucas havia elaborado uma idéia de layout para o site em suas horas vagas. Isto facilitou muito o nosso trabalho por conta do tempo que tínhamos disponível, porque não precisávamos passar pelo famoso ócio criativo.

Aqui na Milk-it temos um quadro branco que serve para rabiscarmos idéias e tarefas, então fizemos uma reunião para definir os elementos que vão ter nas telas e os fluxos delas. A imagem ao lado mostra o esboço que fizemos – a qualidade da foto está ruim, porque foi tirada de um celular. Se reparar, vai ver que o site segue os fluxos de telas desse esboço apesar das seções não serem as mesmas.

2ª Etapa – Corte do layout e os textos do site

Esboço dos textos do site da Milk-itNesta etapa dividimos o trabalho em duas partes: O Lucas cortou o layout, eu e o Carlos produzimos os textos. A imagem ao lado mostra como era feita (Google Docs) a produção dos textos. O Lucas finalizou rapidamente o corte do layout e começou a ajudar na produção dos textos. Com todo o conteúdo produzido mandamos para a nossa redatora freelancer, que também concluiu o trabalho em poucas horas.

3ª Etapa – Integração do layout com o Rails

Essa parte foi a mais fácil! Só precisou do Lucas trabalhando sob demanda para o Carlos. Em menos de 1 dia de trabalho foi tudo concluído. Claro, como um bom admirador não poderia deixar de dizer que o Rails ajudou demais o nosso trabalho.

Apesar das “mil maravilhas”, eu e o Carlos tivemos uma pequena discussão: “Usar a página de busca do Google ou a API do Yahoo para fazer as buscas no site?”. Eu, focando sempre em simplicidade, queria usar a página de busca do Google e o Carlos a API do Yahoo. O Carlos acabou me convencendo que iria desenvolver rapidamente e iria ficar muito mais bonita. Tenho que tomar cuidado, acho que sou um fanático por simplicidade… Hehehe!

Apesar de existir a 4ª etapa, foi nessa etapa que lançamos o site e concluímos uma semana de trabalho.

4ª Etapa – Correção dos bugs

Para quem já leu o Getting Real (37Signals) e/ou A Catedral e o Bazar (Eric Raymond) sabe que é melhor lançar uma versão Beta e continuar melhorando, do que lançar uma versão Release e deixar parada. Você acaba moldando naturalmente o software para atender aquilo que ele realmente se propõe, sem funcionalidades X,Y,Z que ninguém usa. Corrigimos alguns bugs que aconteciam na renderização de alguns browsers – minha raiva pelo IE só aumenta -, melhoramos algumas páginas e implementamos alguns detalhes no site.

Já estamos com algumas alterações para fazer no site. Estamos planejando para ver se “aquela semana” aparece. E quero deixar claro que o desenvolvimento do site não acabou e que precisamos da ajuda de vocês para deixa-lo da melhor forma possível. Então, para sugestões, bugs e críticas utilize o nosso contato.

Comente! »
Compartilhe

Pergunte à 37signals

17 de outubro de 2007 às 14:07 | Carlos Júnior | , ,

Bom, estou traduzindo um post do Signal vs Noise que achei muito interessante. Foi colocado em palavras o que pensamos aqui na Milk-it, e claro, nos acrescenta bastante também, mesmo que apenas por saber que estamos no caminho certo.

Pergunte a 37signals: Eu preciso de um designer para embelezar meus projetos?

Edwin escreveu:

Uma coisa que me atormenta frequentemente, é o design da interface do usuário. Eu sou um desenvolvedor web, usando Rails e capaz de produzir HTML, CSS e JavaScript. Então, eu devo estar ápto a produzir interfaces simples. Mas, se você quer uma interface mais estilizada, você provavelmente utilizará programas gráficos e criará belos ícones e logos. Contratar um designer é normalmente caro e pode fazer com que o desenvolvedor perca o poder de decisões de deisgn de epicentro.

Como a 37signals resolve este problema? Vocês tem um designer em full-time trabalhando em um website ou fazendo as maluquices do CSS para criar a interface?

Pensar em designers como alguém que pinta o aplicativo bonitinho no Photoshop é comum, mas é um infeliz erro de conceito. Nós certamente não temos nenhum designer desse tipo. Ao invés disso, nossos designers aplicam seus talentos nos materiais nativos da Web trabalhando diretamente com HTML, CSS, e ocasionalmente códigos Ruby ou JavaScript.

Isto é uma ligeira noção ímpar para muitos dos programadores web. Eles consideram HTML, CSS, e especialmente JavaScript e Ruby de seus domínios. Se designers trabalham com exatamente o mesmo material, como eles são diferentes?

Pense nisso como papel e caneta. Um programador pode usar estas ferramentas para criar diagramas técnicos de bancos de dados e objetos. Um designer pode usar as mesmas ferramentas para criar um layout persiasivo com um fluxo correto.

Quando designers e programadores trabalham com o mesmo material, eles falam a mesma língua. Isto é um modo incrivelmente eficaz de se trabalhar junto (contrasta com artistas falando sobre Photoshop e “cortadores de HTML” tentando adaptar aquilo à Web).

Designers decidem e projetam o fluxo, a ambíguidade, a estrutura da página, os programadores trazem tudo isso a vida conectando ao software. Tudo juntamente com concessões de ambas as partes em como fazer um recurso da forma mais rápida agregando o valor de facilidade.

Então pare de pensar em designers como artistas que trabalham em um universo diferente de belos gráficos e comece a pensar neles como alguém que decide onde, qual elemento de formulário usar, como dividir um recurso entre telas, quais palavras usar, e como tudo isso encaixa em uma experiência coerente.

1 Comentário »
Compartilhe

Genérico ou Especializado?

21 de setembro de 2007 às 17:21 | Michel Filipe | , , , ,

Aqui vai uma pergunta aparentemente fácil: Software bom é aquele que atende a todos ou só a um grupo especializado? A maioria das pessoas não vai hesitar em responder, mas o número de pessoas que acham melhor o software que atende a todos ou o que atende a um grupo especializado é quase igual. Temos softwares de sucesso em ambos os lados como o Microsoft Project e o TRAC. O Microsoft Project procura atender a todos os clientes que precisam de um gerenciador de projeto, enquanto o TRAC procura atender somente aos que precisam de um gerenciador de projeto simples. Não existe o melhor ou pior, mas neste post vou tentar convencer a vocês de que se construir softwares para um grupo especializado é melhor.

Uma empresa de Chicago, Estados Unidos, chamada 37Signals lançou há algum tempo um livro que considero uma obra-prima do desenvolvimento de software, o Getting Real (versão em português). Alguns gostaram tanto do livro a ponto de dizer que seu conteúdo é uma metodologia. Na verdade o Getting Real está mais para uma filosofia de gerenciamento de projeto de software, que também pode ser aplicada em outras áreas. O livro tenta deixar claro que você ganha mais quando faz menos – e que novos problemas, funcionalidades e mudanças vão aparecer sempre, e se você se mantiver pequeno passará por eles mais facilmente.

Um conceito interessante é que você sempre deve se focar na prática, fazendo com que a teoria se torne uma maneira de melhorar a prática. A prática é tão levada a sério que o livro recomenda que você comece o sistema pelas telas e não pelos diagramas uml, porque com as telas que os usuários do sistema vão interagir. E eles não estão mentindo.

Também seguindo o conceito de A Catedral e o Bazar (de Eric Raymond), o Getting Real incentiva que o software seja liberado para os usuários o quanto antes, porque assim você passa a ter feedbacks que direcionam o desenvolvimento do seu software para a real necessidade dos usuários. Então eu devo liberar Beta? Sim! O quanto antes você liberar o seu software, mais satisfeito ficará o usuário e mais chances ele terá de alcançar o sucesso.

Voltando a comparação do Microsoft Project e o TRAC, depois de ter entendido o Getting Real, faço algumas perguntas:

  • Para solucionar bugs, qual é o mais fácil? TRAC.
  • Se tiver que solucionar problemas no projeto, qual tem mais prejuízo? Microsoft Project.
  • Mudança grande no projeto, qual vai sofrer mais para concluir? Microsoft Project.
  • Qual software precisa de uma linha de aprendizagem maior? Microsoft Project, que é muito maior.
  • Qual software tem a maior parte de suas funcionalidades sendo usadas? TRAC, que por experiência própria chega a ser quase 100%.
  • Qual software precisa de um maior investimento inicial? Microsoft Project – dá até medo de pensar.
  • Quando você usa o TRAC, você fica tão satisfeito quanto o Microsoft Project? Sim, apesar que raramente tenho que usar algum outro software para uma necessidade específica.
  • Qual precisa de um maior esforço inicial do cliente – sem pensar no pagamento da licença? Microsoft Project.

Na Milk-it usamos a filosofia do Getting Real em tudo que podemos e nossos ganhos para uma empresa nova estão sendo significativos. Se você quer evitar stress no mundo de hoje onde temos que gerenciar várias coisas, sempre ao mesmo tempo, leia o livro e pratique. :)

Comente! »
Compartilhe

Está na hora de largar o MandaV

14 de setembro de 2007 às 12:22 | Michel Filipe | , ,

scrum.pngAtualmente, muitas empresas empregam a metodologia MandaV. O que é o MandaV? É aquela metodologia ágil, mas tão ágil, que a análise, diagramas, orientação a objeto, programação orientada a teste e tudo-que-requer-parar-para-pensar é perda de tempo. Todos nós já vimos empresas assim e o pior é que muitos de nós já sofremos com elas. Quantas vezes trabalhamos como loucos para deixar um projeto “funcionando” no dia da apresentação para o cliente? Isso acontece diariamente em muitas empresas que desenvolvem software.

Apesar de até agora não ter mencionado a palavra Scrum, ela é a personagem principal deste post. O Scrum nada mais é que um framework para ser utilizado em sua metodologia principal. Ele se foca em iterações diárias – chamados de sprints, são os ciclos de incremento do software; na Milk-it transformamos isso em ciclos de versões -, lista com prioridades de tarefas e produtividade da equipe. A imagem ao lado dá uma visão geral do que é o Scrum. Felizmente temos bastante material em português, como algumas web-palestras e alguns artigos sobre o framework.

Com o Scrum você começa a trabalhar focado no que o cliente realmente quer, colocando a seu favor as mudanças e os problemas. Você não precisa mais ser a Mãe Dináh e fazer um cronograma baseado em seu sexto-sentido, porque agora você vai largar a teoria e se basear na prática. Para adotar o Scrum não é preciso ler livro algum de 300 páginas e nem seguir a risca o que é falado. É possível adaptá-lo à qualquer empresa (exceto as “MandaV de cabeça fechada” ou “CMMI-PL200-CKZ-pt_BR 5″).

- Tem certeza que o Scrum não é uma metodologia?

Muitos lugares vão dizer que sim, mas ela não é. Como diz Ken Schwaber, criador do Scrum: Scrum é um processo Ágil ou framework para gerenciamento de projetos ágeis. Ele é enquadrado como um processo para gerenciamento de projetos e certamente não é uma metodologia, se o fosse, seria muito pesado. Ela não vai te dizer passo-a-passo o que sua empresa tem que fazer do início ao final do projeto e nem resolver todos os seus problemas, mas sim fazer com que boa parte dos problemas sejam identificados.

Atualmente na Milk-it fazemos uma mistura de Scrum, Getting Real e XP. Sobre o Getting Real posso dizer que é uma filosofia (e o resto é com vocês), mas em um post futuro eu vou abordar mais sobre ele. Voltando à Milk-it, trabalhamos com um escopo inicial junto ao cliente, sprint semanais – o que não é o recomendado, mas nossa equipe é pequena e atende vários projetos simultâneos -, TDD e Ruby on Rails. Se você quiser saber mais sobre a nossa forma de trabalho, entre em contato. Ficaremos felizes em responder! :)

OBS.: O nome “MandaV” eu criei a um tempo atrás com a intenção de rotular a “metodologia de trabalho” de algumas empresas.

Comente! »
Compartilhe