Archive for the ‘Development’ Tag

Generalizando os conceitos de Integração Contínua

A utilização de processos de integração contínua no desenvolvimento de software, é hoje algo bastante corriqueiro em ambientes onde existe uma preocupação com a qualidade do código. A implementação de testes unitários e a execução dos mesmos de forma periódica, garante que o funcionamento de cada um dos componentes seja validado, o que impede a introdução de bugs, principalmente quando estamos falando do desenvolvimento de novas funcionalidades em uma aplicação já existente. Este conceito de integração contínua é tão importante para o processo de desenvolvimento, que por várias vezes me perguntei como poderíamos generaliza-lo para utilização em situações diferentes.

Quando conhecemos a complexidade dos processos de codificação de vídeos, nos deparamos com uma imensa quantidade de variáveis que podem interferir na qualidade do vídeo codificado, de modo que é praticamente impossível garantir que um determinado processo de codificação sempre irá gerar resultados satisfatórios. Além disso, fatores externos, como sistema operacional, hardware, etc, também influenciam nos resultados obtidos, seja na velocidade de codificação, seja na própria integridade do conteúdo.

Em ambientes de produção de vídeo em alta escala, é fundamental garantir que todas as variáveis que influenciam no processo de codificação estejam sob controle, de modo que os impactos de qualquer alteração sejam rapidamente identificados, antes que elas sejam efetivamente aplicadas no ambiente de produção. Se fizermos um paralelo com os processos de desenvolvimento de software, o que precisamos é exatamente o que a execução contínua de build e testes faz, ou seja, garante que não houve quebra de funcionalidades gerada por alterações no software.

Para exemplificar, podemos citar um processo de codificação com o Windows Media Encoder (Para quem não conhece, o Windows Media Encoder é um codificador WMV da Microsoft, bastante popular para quem usa Windows Media Video). Devido à uma alteração nas bibliotecas utilizadas pelo WME feita pela atualização do SP2 do Windows XP, podemos ter um aumento no tempo de codificação, além de alguns erros com arquivos específicos. Isto significa que a simples atualização do Service Pack do sistema operacional pode influenciar bastante no processo de codificação. Se, neste cenário, temos um processo de codificação contínuo, então essas diferenças seriam facilmente identificadas, antes que esta atualização fosse efetivamente aplicada.

Entretanto, ter simplesmente um processo de codificação que roda constantemente não é o suficiente para garantirmos a integridade de um ambiente. É de fundamental importância ter uma quantidade grande de mídias de diferentes perfis, ou seja, ter diversas mídias, de diversas durações, com vários tipos de conteúdo distintos e de várias fontes diferentes. Desta forma, com uma biblioteca de conteúdo diversificada e com um processo de verificação contínuo, temos como analisar de forma eficiente um ambiente de codificação.

Outro ponto importante no processo de codificação de vídeos é que a maioria deles não é “binário”, ou seja, se você codificar o mesmo vídeo 100 vezes, você não terá a mesma saída 100 vezes. Por isso, além de codificar continuamente diversos vídeos diferentes, é bastante importante codificar o mesmo vídeo repetidamente, sendo que este vídeo deve ser escolhido dentre um universo por ser aquele que apresenta a maior taxa de erros. Desta forma, estamos introduzindo mais uma validação de integridade.

Não conheço nenhuma ferramenta pronta para execução de testes desta natureza, porém, é relativamente simples escrever uma. Claro que se você deseja um output gráfico, em tempo real, é necessário dedicar um tempo razoável para isto, mas nada que não seja justificado pelos ótimos benefícios obtidos com esta prática.

Advertisements

Scrum, e os benefícios para os Team Members

Freqüentemente leio posts e artigos sobre a utilização do Scrum, entretanto, na maioria das vezes, existe uma grande ênfase nos benefícios obtidos com ele do ponto de vista da empresa, como o aumento na velocidade das entregas, e nem sempre é discutido sobre o que os team members ganham, quais as vantagens para as pessoas que efetivamente desenvolvem as tarefas. Desta forma, achei que seria interessante expor aqui um pouco da experiência que estou tendo na Globo.com, onde atuo como team member de uma equipe desde que adotamos o Scrum oficialmente.

Algumas pessoas, em um primeiro contato com o Scrum, podem apresentar um certo receio sobre uma das prerrogativas propostas pelo framework, que é a disseminação de conhecimento por todo time, com o objetivo de reduzir as chamadas “ilhas de conhecimento” nas equipes. Isto é excelente do ponto de vista da empresa, porém, infelizmente alguns profissionais que detém um conhecimento específico pensam que seu emprego estará “garantido” enquanto ele for o único a dominar determinado assunto. Entretanto, a disseminação do conhecimento por todo time é extremamente positiva para o desenvolvimento profissional de cada um, uma vez que o conhecimento específico de cada membro é compartilhado, estabelecendo uma “via de mão dupla”.

Além disso, cada componente do time é livre para executar qualquer tarefa, seja ele ou não o especialista no assunto. Desta forma, esta transferência de conhecimento pode ser realizada de acordo com a vontade de cada um, até o ponto que o desenvolvedor irá fazer tarefas simples de design, e o designer irá implementar trechos simples de código.

Outro benefício bastante importante é a existência um escopo claro e bem definido daquilo que deve ser realizado, o que evita uma série de transtornos. Ninguém vira a noite se matando para implementar uma funcionalidade não prevista, ou alterando o que foi feito pois houve uma mudança de idéia. No Scrum existe um “compromisso público” que define o que será realizado, não existe margem para alterações não aprovadas pelo próprio time. Além disso, a existência de um backlog priorizado permite uma visão mais clara daquilo que deverá ser realizado, qual é a estratégia e os objetivos existentes.

A existência de reuniões diárias (daily meetings), também ajuda bastante no processo de comunicação entre os membros do time, sendo que cada um sabe exatamente o que o outro fez, e o que irá fazer, e isto é extremamente importante para todos tenham uma visão bem clara do que está sendo feito, quais foram os desafios e como eles foram superados. Finalmente, ao término de cada ciclo (sprint), cada um pode expressar o que foi bom ou ruim no último sprint o que facilita bastante a resolução de problemas de qualquer natureza.

Em suma, o Scrum pode ser bastante positivo também para os profissionais, basta saber aproveitar as novas oportunidades abertas por este modelo de desenvolvimento, em vez de ficar com medo das mudanças que naturalmente vão acontecer.

Keep it Simple

De uns tempos pra cá, desde que começamos a utilizar o Scrum na Globo.com, venho a cada dia reforçando minha idéia de que quanto mais simples, melhor. Muitas vezes, principalmente nós, engenheiros, queremos implementar as soluções mais mirabolantes para problemas muitas vezes não tão complexos, pela simples capacidade criativa que existe em nós. No caso específico de desenvolvimento de software, as vezes ficamos horas e horas tentando otimizar cada linha, cada processo, literalmente escovando bits, para ganhar um mínimo de performance. O problema é que o mercado de internet é extremamente rápido, e existe uma pressão imensa para inovação. Neste cenário, gastar tempo em pontos pouco críticos pode ser desastroso, a medida que a busca por uma solução perfeita pode literalmente impedir que novas funcionalidades sejam implementadas.

Sempre fui adepto do “bom é inimigo do ótimo”, ou seja, a busca ininterrupta por uma solução ótima pode inclusive destruir uma solução suficientemente boa. Entretanto, quando falo “Keep it Simple”, quero dizer: uma vez diante de um problema, tente simplificá-lo ao máximo, crie atalhos nos processos e limite-se naquilo que atende suas necessidades. Não tente criar um canhão para matar uma formiga. Uma solução simples, no meu ponto de vista, é muito mais elegante e melhor que uma solução aparentemente genial. No caso específico de software, quanto mais simples for a solução, mais fácil é o handover para outros membros do time, perde-se menos tempo em desenvolvimento e em manutenção, mais fácil é o teste, existe uma menor quantidade de pontos de falha. Note que ao contrário do que parece, as soluções simples não abrem mão da qualidade em nenhum momento, pelo contrário, elas contribuem para o ganho de qualidade, principalmente à longo prazo. Implementar uma solução simples não significa desenvolver fora dos padrões ou não utilizar as best pratices conhecidas, tanto que, em alguns momentos, ela será mais trabalhosa.

A medida que os membros do time  compartilham esta idéia de simplicidade,  a velocidade do time aumenta, sem comprometimento da qualidade, e os débitos técnicos causados por problemas de implementação tendem a reduzir, uma vez que fica mais fácil integrar novas funcionalidades. No time em que faço parte (time voltado para o produto Globo Vídeos), acredito que todos já tem este mindset, de que entregar muitas coisas simples é melhor do que entregar poucas coisas muito complexas. Por isso, “keep it simple”,  e você vai ver o quanto as soluções simples podem ser extremamente eficientes.