Seguem os slides da minha apresentação:

Um grande abraço e até a próxima!

Posted via email from pellegrino’s posterous

Interaction Design, User Centric Design, User Interface Experience and Scrum fits very well together if people who are in Scrum Teams stop thinking in GETTING IT RIGHT THE FIRST TIME. The conflict that lies within the Interaction Design approach and Scrum [1] is the same conflict that we had in the software development industry since the beginning. If we know exactly how the result should be, than we can build it. Unfortunately this way of thinking creates a big problem: Speculation!

Scrum tried to solve all this: It is forbidden to have a prototype as a Sprint result. That you need a prototype for some causalities within a Sprint, ok. But not as a final result. Designers and developers need to work closely together within a Sprint. Stop believing you could or should know in details what you need to build in advance. Build it with the best ideas, check the result in the reality with the real thing and then do it again if you must.

[1] Interaction Design and Extreme Programming, http://stuq.nl/weblog/2009-02-11/interaction-design-and-extreme-programming

Este artigo do Boris Gloger mostra muito bem como se trabalhar com design de interação de maneira ágil. Excelente artigo, bem objetivo e centrado nas dificuldades que muitas equipes enfrentam quando estão trabalhando de maneira ágil.

Posted via web from pellegrino’s posterous

Conforme o Sylvestre Mergulhão disse em seu post, terei a difícil e honrosa tarefa de substitui-lo na apresentação do how-to Rails Otimizando client e server side. Também estará presente meu amigo Henrique Bastos que apresentará o tutorial sobre Django.

Posted via email from pellegrino’s posterous

http://www.otempo.com.br/otempo/colunas/?IdEdicao=1469&IdColunaEdicao=10007

Até é legal o artigo, mas esse lance de "anti-tecnologia" já é bem batido.

Sempre quando há um movimento de mudança, há sempre um movimento contrário de resistência. Isso é ciclico e a história tá aí pra nos mostrar isso

O que ele falou de que vivemos um momento de "revolução dos idiotas online" é realmente verdade; muita gente abre a boca por aí sem saber o que diz ou apenas parafraseando o que ouviu.

Agora pode ter certeza de que, depois de twitters, blogs e afins, o mundo jamais será o mesmo.

Ao invés de reduzir tudo isso ao nível de um "terreno baldio" ou achar que blog parece mais um "coaxar de sapo boi", acho que seria muito mais construtivo se ele utilizasse esse espaço para se comunicar de maneira mais direta ao público que o admira.

O passado, não importa o quanto o quisermos de volta, este não volta mais.

Vitor Pellegrino
http://vp.blog.br

Posted via email from pellegrino’s posterous

Globo.com

Saí de uma grande empresa (no melhor dos sentidos), vindo de uma equipe fantástica. Simplesmente a melhor que já tive a oportunidade de conhecer. É muito difícil sair de um ambiente deste tipo sem que a saudade do convívio diário esteja presente.

Olhando para trás, neste momento que, por si só, já é bastante retrospectivo, posso ver claramente como a convivência com esses caras me fez crescer enormemente. A Webmedia é uma equipe ímpar e a paixão e a garra com encara os desafios de cada um dos projetos são, no mínimo, inspiradoras.

Guilherme Chapiewski, Marcelo Azambuja, Guilherme Cirne, Ana Paula Coutinho, Cainã Nunes, Rodrigues Comandolli, Tiago Motta, Bruno Carvalho, Tiago Melo, Anselmo Alves, Leonardo Quixadá,Frederico Cunha, Bruno Souza, Rafael Pereira, Tiago “Pacman”,  Rafael Biriba, Carlo “Zed” Caputo, José Peleteiro, Danilo Bardusco, Antônio Carlos.

A todos vocês de Webmedia e que já passaram por lá de alguma forma, meu muito obrigado! Com certeza esta lista está incompleta e tem mais um monte de gente que foi super importante durante a minha caminhada pela globo e que sou grato da mesma forma.

A quem fica, desejo muito sucesso e muito boa sorte e, a quem está entrando, saiba que está prestes a integrar uma equipe única, “excepcional”, de uma empresa sem igual.

Um grande abraço do amigo,

Vitor Pellegrino

Infelizmente, é muito comum encontrar empresas que bonificam/promovem seus funcionários baseados apenas em fatores relacionados a “tempo de casa” ou “tempo de experiência” - ou qualquer outro tipo de parâmetro puramente objetivo. Há empresas que procuram avaliar seus funcionários até mesmo baseado na quantidade de linhas de código, ou pontos de função que eram capazes de produzir em um determinado tempo.

A busca por métodos mais objetivos de se avaliar as pessoas tem seus bons motivos, pois são excelentes para justificar - de forma irrefutável - a bonificação e/ou a posição de uma pessoa na hierarquia da empresa. Contudo, penso que há formas também eficientes, mas menos restritivas de se fazer isso.

Porque não Meritocracia?

É engraçado ver como algumas pessoas - por se sentirem “injustiçadas” por sua posição atual em suas respectivas empresas -  agem de forma irresponsável (não-profissional) de maneira deliberada, quase como em “protesto” por uma situação indesejável.  Este tipo de atitude, ao meu ver, é muito mais prejudicial a própria pessoa em si, do que a “injusta” empresa em questão.

Um jogador de futebol de um clube pequeno, ganhando um salário irrisório, frente ao que ganham jogadores dos grandes clubes, jamais faria um gol contra em protesto aos baixos salários! Do contrário, ele se esforçaria ao máximo para que pudesse ter seu talento descoberto por um time que melhor pudesse lhe valorizar. Ou seja, ele percebeu que para que fosse, de fato, promovido, ele deveria agir como se já fosse um jogador de um nível acima. Numa empresa que favoreça o crescimento profissional de seus integrantes, não é ela quem promove seus funcionários, mas, sim, eles que promovem a si mesmos através de suas próprias atitudes.

As pessoas recebem de acordo com a sua “raridade” ou importância para a empresa. Ainda que existam vários jogadores que possam desempenhar uma mesma posição - muitas vezes até com uma excelente técnica - poucos jogadores no mundo têm a habilidade do Ronaldinho Gaúcho ou a facilidade de marcar gols do Adriano. Por serem “exemplares raros” isso faz com que sejam recompensados de maneira semelhante.

Neste caso, nenhum tipo de métrica e/ou análise quantitativa foi utilizada para definir o quanto seria justo para aquele jogador; nada foi utilizado além do bom senso. Mesmo tendo sido usados parâmetros, de certa forma, bastante subjetivos, creio que poucos duvidariam deste julgamento. Creio eu, por esses motivos, ser mais importante ter uma percepção correta do valor que o profissional agrega do que ter meios formais de comprová-lo.

Este episodio do podcast Software Engineering Radio fala justamente sobre esse assunto; traz uma visão do que é esperado de pessoas desempenhando cada um dos papéis envolvidos em um time de Desenvolvimento de Software. Tal tipo de reflexão poderia ser muito útil, não só para servir como modelo para analisar o desempenho de cada pessoa em uma organização mas, também, para ajudar pessoas que queiram alinhar seu desenvolvimento pessoal aos objetivos de sua organização.

Disseminar este conhecimento pela empresa, fazendo com que as pessoas saibam o que delas é esperado, poderia contribuir, fortemente, para seu crescimento na empresa e, também, seu desenvolvimento pessoal. Valorizando os profissionais compõem uma equipe, estaremos contribuindo, também, para a criação de um ambiente melhor, onde as pessoas têm uma maior clareza de que sua ascenção na organização e seu sucesso profissional dependem puramente de seu próprio esforço e mérito.

Para qualquer um pensando em mudar de hospedagem e/ou conhecer este tipo de opção para os próximos projetos, esse post é uma grande pedida.

Um grande abraço e até a próxima!

Rails Rumble 2008!

Neste último final de semana participei do Rails Rumble 2008, a segunda edição de um concurso, de nível internacional, onde o objetivo é se desenvolver a melhor aplicação rails no em até 48 horas - do início ao fim. Não é permitido a criação de nenhum tipo de material digital. Toda a infra-estrutura do projeto, deploy da aplicação e setup do ambiente de produção também devem ser feitos dentro deste período. Ou seja, é necessário muito planejamento prévio, uma boa idéia e uma boa dose de pragmatismo.

Além destes fatores, também é necessário uma boa equipe. Posso dizer, com absoluta certeza, que, neste aspecto, tive muita sorte; a nossa equipe foi composta de profissionais profundamente comprometidos e talentosos.

A equipe January River (pra ser bem brazuca mesmo! rsrs) foi composta por:

• Bruno Dulcetti - HTML/CSS Combo Hit Master.
  
• Bruno Carvalho - Engenheiro de Software
• Vinícius Pellegrino - Designer e Ilustrador.
• Vitor Pellegrino - Engenheiro de Software

Té parece que rolou tanta concentração assim... rsrs

Bruno Carvalho, Bruno Dulcetti, Vinicius Pellegrino e eu

A ideía da nossa aplicação veio através de uma sugestão do Bruno Carvalho: uma aplicação onde fosse possível que os usuários enviassem fotos sobre o que comem. Essa idéia de se tirar fotos das suas refeições é algo que vêm sendo bastante utilizado lá fora e que tem o nome de flash diet. O próprio fantástico fez uma matéria bastante legal sobre esse tipo de dieta.

O nosso propósito era de fazer um site bem moderno, com um visual bem atual e descontraído, que fosse bem direto ao seu objetivo - ajudar pessoas a manterem um diário de sua dieta através da internet. O resultado desta aventura pode ser encontrado em http://rio.r08.railsrumble.com. (Você também pode ajudar a gente e votar através deste link :D).

Entretanto, apenas uma equipe talentosa, uma idéia legal e muita vontade de fazer não são suficientes:
Em resumo, poderia dizer que aprendi algumas lições:

1. Planeje bem o que você quer fazer ANTES. Perdemos muito tempo por chegarmos no dia que o projeto começou sem uma idéia clara e compartilhada com todos os membros da equipe. Definimos todas as telas, logos e funcionalidades no dia do projeto. Ou seja, tinha que dar errado… rs
2. Por mais simples que seja o projeto, divida em histórias (ou tarefas, ou casos de uso… ou qualquer representação de uma funcionalidade do sistema) e só parta para a próxima quando a anterior esteja finalizada e testada. Tivemos que abrir mão de diversas funcionalidades parcialmente prontas pois ao final do projeto elas não tinham condições de subir. Ou seja, trabalho jogado fora por falta de organização do time.
3. Seja pragmático. Saiba avaliar a razão entre custo x benefício de cada linha de código e/ou decisão tomada. Isso é fundamental para que não se perca tempo demais polindo uma funcionalidade específica e acabar faltando tempo para terminar o resto do sistema.
4. Teste sua aplicação.
5. Teste mais. Isso evita que bugs críticos sejam encontrados 20 minutos antes da entrega de um sistema e que tenham que ser corrigidos em menos tempo ainda.
6. Priorize e saiba priorizar. Organize seu trabalho de forma a construir as funcionalidades/tarefas que trarão maior retorno mais cedo.

Tivemos vários problemas. Infelizmente, foi necessário cortar mais que 80% do sistema poucas horas antes do final do concurso pois não conseguiríamos terminar a tempo. Um outro problema que foi muito grave, é que não tivemos qualquer tipo de planejamento antes do início do projeto. Todo o site, desde sua concepção, design, arquitetura foram construídos durante o concurso. Era permitido, às equipes, que qualquer tipo de planejamento, desenho (desde que não em forma digital) e modelagem da arquitetura pudessem ser feitos. Isso é uma vantagem enorme que não pudemos aproveitar.

Esta falta de planejamento à priori, também surtiu efeito na forma como executamos nossas tarefas - por não termos dividido em tarefas e funcionalidades de forma bem contida, nós não trabalhamos de forma muito eficiente e perdemos muito tempo fazendo coisas que não se encaixaram (e jamais se encaixaríam) bem com o produto como um todo.

Mesmo com todos os problemas, não tenho dúvidas que participar de um projeto como esse foi uma das melhores experiências em minha vida profissional; uma verdadeira aula de porque os projetos dão e não dão certo. Muitas das coisas que vemos nos longos projetos por aí, foram refletidas nestas 48 horas. Numa competição como esta, é necessário fazer escolhas a cerca de escopo, de composição da equipe (já que o número de participantes é limitado de até 4 pessoas), de processo de desenvolvimento e - ainda que  inicialmente desprezado por nós - gerência de projeto propriamente dita.

Depois do railsrumble, a vontade de realizarmos este projeto foi multiplicada. Portanto, aguardem surpresas e, podem ter certeza, que o picmydiet não vai ficar só por aí

Um grande abraço e até a próxima!

Desde a útlima vez em que escrevi algo por aqui, muitas coisas aconteceram: finalmente, concluí a graduação!!

PUC-Rio goodbye, farewell, see you later! :)

Essa é a primeira razão pela qual me faltou o tempo para dar a devida atenção que este espaço requer. O final da faculdade foi algo que me exigiu uma dedicação enorme - tenho certeza que vocês compreendem Terminada a graduação, hoje carrego, comigo, a certeza de ter conhecido pessoas fantásticas que tenho orgulho de chamar de amigos.

Neste meio tempo, participei, junto com o Tiago Peczenyj, de um workshop fantástico com Bruce Eckel, realizado pelo pessoal da Python Brasil, onde foi possível discutir com o criador do primeiro livro de Java que li. Foi uma oportunidade singular para trocar idéias, discutir conceitos e aprender diretamente com esse cara que é referência em arquitetura e desenvolvimento de software. Além de tudo, serviu para aumentar, ainda mais, a certeza de que estamos trilhando o caminho certo lá na Globo.com.

Workshop thinking in patterns

Um grande abraço pro Luciano Ramalho, Hugo Corbucci, Leandro Lameiro, Ramiro, pessoal da Python Brasil, pro Rafael da PUC de campinas e toda a galera que conheci durante o workshop. Sobre as coisas aprendidas no evento - e ainda melhor compreendidas após ele - dedicarei alguns posts em breve.

Até a próxima!

Mas o que é intraempreendedorismo?

Como ponto de partida, tomemos a definição da wikipedia:

Intrapreneurship is the practice of entrepreneurial skills and approaches by or within a established organization.

Ou seja, intraempreendedor é aquele que trata a empresa onde trabalha como se fosse a sua. Usando de todo o espírito empreendedor que possua, em busca de oportunidades para o negócio, é aquele que não se atem somente aos limites de sua “função” dentro da empresa, mas que, sim, procura ter a noção do todo e, principalmente, de como melhor contribuir para que a organização atinja seus objetivos.

Mas o que o Scrum tem haver com isso?

Absolutamente tudo! Na verdade, o Scrum depende, fortemente, que os integrantes compartilhem desta visão intraempreendedora.