Pular para o conteúdo principal

Workchopp II - Qualidade de Código

É isso aí, não satisfeitos de combinar Empresa, Sabado e Cerveja uma vez, decidimos repetir a dose.
Tudo bem que o workchopp foi dia 15/10 e estou atrasado, mas a experiência vale ainda.

Nesse segundo workchopp queríamos juntar a galera de desenvolvimento em prol da qualidade do nosso trabalho. Foram escolhidas então atividades que pudessem trabalhar a nossa visão em cima daquilo que fazemos.

Atividade 1:

A primeira atividade foi o gildedrose em Java. Dividimos os participantes em duplas e fizemos três rodadas da seguinte maneira:

     Primeira Rodada


           Cada dupla teve 5 minutos para ler e estudar o código. Depois cada dupla teve 10 minutos para trabalhar na melhoria da qualidade do código. Ao final nos reunimos e fizemos uma retrô rápida de 10 minutos. Todos acharam 10 minutos muito pouco e nada foi alcançado em cima dos códigos.

     Segunda Rodada


           Pilotos viraram copilotos de outras equipes. Novamente tivemos 5 minutos para discutir, seguidos de 10 minutos de codificação. Ao final, outra retrô de 10 minutos. Desta vez o pessoal botou a mão no código, investindo mais em "extract methods". Uma passada numa bateria de testes mostrou que muitos inseriram erros no código e as melhorias da qualidade (usando PMD) não foram significativas..

     Terceira Rodada


           Trocam os pilotos novamente. Novamente 5 minutos de preparo seguidos de 10 minutos de codificação. Desta vez, as duplas receberam a bateria de testes completa, antes da rodada. Ao final 10 minutos de retrô. Apesar de singelos os comentários, foi notório ao rodar a bateria que a qualidade do que foi modificado aumentou.

Atividade 2:


Nossa segunda atividade foi um Dojo/Handori. Começamos a codificar uma Calculadora de fórmulas em Strings. Foi um pouco corrido (só tinhamos 40 minutos) mas foi possível mostrar um pouco da prática do Dojo e deixar todos codificarem.

Conclusão


Foi um sábado muito bem aproveitado. Foi muito corrido e faltou tempo pra explorar um pouco mais ambas as atividades. Porém, na restrospectiva foi possível notar que o pessoal estava bem engajado nas discussões de evoluir a qualidade dos trabalhos.

Que venham outros workchopps.

Postagens mais visitadas deste blog

A experiência de software

Hoje em dia está muito em voga se falar sobre o desenvolvimento de produtos e serviços de software. Sendo assim as iniciativas e startups estão alta. Mas para quem está no mercado de Brasília (e de alguns outros centros do país) como eu, sabe que a prestação de serviços nas famigeradas "Software Houses" ( me recuso a chamar de Fábricas de Software ) é bem comum. Porém, este trabalho costuma ser renegado ou, como eu vejo, tratado sob um ponto de vista um pouco equivocado. Uma fábrica de software artesanal Onde se enganam tais pessoas é em que elas estão vendendo. Muitas empresas acreditam, de fato, que vendem software. Eu porém digo que isso é não de todo verdade. Se você é um prestador de serviços e constrói software sob demanda, você não vende apenas o software. Aqui não me refiro aos milhões de outros "artefatos" que são empurrados goela abaixo entregues aos nossos clientes. O que vejo é que vendemos algo que não está limitado ao software que vai pra mão (ou se

TDD como ferramenta de aprendizado

Na penúltima sessão do DojoBrasilia surgiu a seguinte questão: Será que o TDD não atrapalha no aprendizado de novas tecnologias?  A grande questão girava em torno de que o respeito estrito as regras ao TDD tornariam o aprendizado lento e enviesado. Isso por que você estaria focado em passar o teste o que estaria limitando sua velocidade no aprendizado na tecnologia, bem como a visão do objetivo final. Caso do dojoBrasília No caso da sessão que levantou a questão acho que o principal sentimento de "lentidão" se deve a grande carga de tecnologias novas que estavam envolvidas. Escolhemos iniciar um problema conhecido em não uma, mas várias tecnologias ( Backbone.js , Undescore , CoffeeScript , Jasmine , etc). Ao final da sessão a sensação de pouco avanço era justificada pelo tempo gasto compreendendo as tecnologias em questão. A sessão seguinte não obteve o avanço que muitos esperavam. Mas nela podemos ver como o uso de TDD compensou. Tínhamos apenas 4 cas

De Híbrido a 100% remoto - o caso da bxblue

A bx nasceu como uma empresa remota. Durante os primeiros 18 meses, os três fundadores --  eu, Guga e Roberto -- trabalhamos de nossas casas. Passado esse período inicial de maturação da idéia, nosso time começou a crescer, e acabamos optando por seguir um modelo híbrido. Nele tecnologia e marketing permaneceram remotos porém nosso time de atendimento e vendas ficou atrelado ao nosso escritório. Mas, como em muitas outras empresa, isso mudou nas últimas três semanas. Depois de tantos anos, nos tornamos uma empresa 100% remota. O O grande incentivo veio da situação que vivemos no mundo atualmente. Tendo o isolamento social como uma medida necessária a todos que tem o privilégio de poder fazê-lo, era nossa responsabilidade fazer tal mudança. Pois minha intenção aqui é contar um pouco tem sido essas 3 semanas que marcam o começo de um período que a ainda tem muito pela frente. Porque Híbrido? Antes, deixe-me explicar por que escolhemos o caminho de ser uma empresa híbrida, tendo na