Dojo-UFRGS 15/9
Ontem fizemos outro coding dojo no campus do Vale da UFRGS !! Desta vez convidamos: todo o pessoal da graduação via lista interna da faculdade; todo o pessoal do dojo-poa (que ninguém pode ir por causa de horários e etc 😦 ); agregados (em particular, do mestrado da UFRGS) que ficaram sabendo do dojo e compareceram o/
|
|
| De Dojo UFRGS 15.9 |
As demais fotos do evento estão aqui como cortesia do Cristiano Dalbem =D
Desta vez, o pessoal se animou a atacar um problema maior: os números Romanos, usando a linguagem C/C++ (tipicamente, um .cpp sem classes) e com a framework de testes (exemplificada pelo nosso guru particular, o Lucas Fialho, aqui) !! No início tudo estava indo bem, baby-steps funcionando, silêncio no vermelho, tempo cronometrado…. mas cometi (ou cometemos) um erro fatal: ao dizer o enunciado do problema, não paramos para fazer um brainstorming para que o pessoal se familiarizasse com soluções possíveis.
Acabou que cada piloto que entrava tinha uma idéia diferente de “como resolver o problema”, pois pequenos grupinhos estavam se formando na platéia para solucioná-lo separadamente lol. Fica aqui relatado o aviso para realizarmos brainstormings nos próximos dojos, para que o pessoal tenha uma solução mais ou menos coesa desde o início.
Fora isso, as quase 20 pessoas que compareceram aproveitaram bastante o Dojo. Fica a promessa de todos voltarmos semana que vem o/
Pontos Positivos:
- Interação com o pessoal+++
- TDD
- Bastante Gente
- Pessoal se comportou no vermelho
Pontos Negativos:
- Falta de definição da abordagem “padrão”… várias soluções diferentes, fazendo perder tempo com “consenso” +++
- Não conseguimos terminar
- Poucos testes sendo rodados no meio-rpo-fim do Dojo, sem testar limites ++++
- Faltou café e comida +++++++++++++++++
- Pessoal “do fundão” começou a fazer ruído
- Piloto e co-piloto não se comunicavam com a platéia
Comentários:
- Utilizar problemas menores
- Combinar um algoritmo prévio para resolução do problema
- Usar auditórios (vermelho/azul), para fazer o grupo ficar mais condensado ++
O Dojo na UFRGS acontece toda quarta-feira, as 17h, no campus do Vale, sala 104 do “prédio novo” (quem conhece sabe do que estou falando… quem não conhece e quiser participar, me mande um email ou comente o post que eu faço o mapinha 😉 ). Se mudarmos o local, aviso por aqui para que todos saibam onde nos achar o/
DoJoPoA 
Bacana Gabriel. Parabéns pela iniciativa!
Duas coisas:
– O motivo dos problemas serem simples é exatamente por isso;
– Lembre-se não tem necessidade de terminar o problema;
Ok. São três coisas.
– A questão de ter um planejamento prévio, pode ser boa, mas também traz um malefício, que é a possibilidade de inibir a linha de raciocínio de algum participante que pode se tornar bastante interessante para o aprendizado do grupo. Sugiro que ao invés disso, se tome bastante atenção para que o piloto e o co-piloto relatem tudo o que pretendem e o que estão fazendo. E, além disso, que o processo de refatoração (quando estiver na fase verde) seja utilizado.
[]’s e sucesso nos dojos URFGS! =D
Pois então, a fase de planejamento prévio seria, pela minha opinião, seria feita nos momentos inicias do dojo, bem um brainstorming mesmo. Tinha muita gente que nem sabia algarismos romanos, por não se lembrar mesmo.
A idéia surgiu por que, com a ausência desse brainstorming, 20 pessoas formaram grupinhos fuzzy e ficaram fazendo sluções diferentes, então acabamos que tínhamos 3 soluções diferentes, e cada piloto quando assumia “programava a sua”, ao invés de tentar agir em cima do código que ele recebeu.
Podemos ainda abrir uma discussão de o que é permitido no processo de refatoração. Pelo o que fizemos, o céu era o limite, então códigos eram criados e deletados na fase refactor, quando os testes tavam verdes, de forma bem libertina lol.
Entendo. Neste caso realmente, pelo menos uma explicação do problema a ser abordado é interessante.
Quanto a questão da refatoração, creio que se for feita somente a partir da fase verde, o objetivo é alcançado: alguém já mostrou o caminho que seguiria e outro mostra uma melhoria, mas não desfazer e fazer tudo do zero. Além disso, aprenderemos diferentes abordagens. 😉
A parte do sinalizador vermelho/verde tá em falta mesmo, provideciaremos =)
Show de bola Gabriel, parabéns, e foi uma baita galera!
Só um detalhezinho, será que não terem conseguido terminar chega a ser um ponto negativo? Já que foi um problema grande acho que o foco seria mesmo o desenvolvimento, talvez tenhamos que nos policiar pra não termos essa necessidade de terminar o problema, o que acha?
Muito bom meu velho, grande abraço!
Concordo contigo. Pra mim, o default é “não terminar o problema”, afim de que, quando finalmente terminarmos um problema, saiamos do dojo nos sentindo um máximo =P
A questão dos pontos negativos/positivos/etc foram feitas por 20 pessoas falando praticamente 5 ao mesmo tempo. Eles refletem opiniões de maioria, ou seja, opiniões que não teve ninguem pra falar (alto o suficiente) que aquilo não deveria estar ali lol.
Ó a Soraya lá! ^_^
Parabéns a todos pela iniciativa!
Sobre os “problemas” que vocês tiveram, acho normal: nem sempre todos concordam com a mesma solução. Já aconteceram sessões de Coding Dojo aqui no Rio onde vários grupos dovergiam e tentamos várias soluções – e nem sempre encontrávamos uma que agradava a todos, mas podíamos testar e discutir todas, gerando aprendizado, o que é justamente o foco do Coding Dojo. 🙂 Enfim, não acho que isso seja um problema!
Com relação a fazer algo antes, não acho que seja a melhor solução. Algo que funciona bem é definir explicitamente a entrada e a saída do software/classe/função/etc. que o grupo está se propondo a fazer para resolver o problema. Tendo escolhida a linguagem dá pra definir se as entradas/saídas serão strings, arrays e por aí vai – acho que isso está bastante ligado ao problema e nem tanto à solução, e essa definição incial também *pode mudar* durante a sessão caso alguém descubra alguma maneira melhor e todos concordem.
Esse lance de definir bem a entrada e a saída (e, se possível, deixar isso escrito em um quadro branco para que a galera que chegou atrasada ou está com dúvidas possa consultar) ajuda muito na dinâmica das sessão, fazendo com que o problema consiga ser resolvido com mais fluidez.
[]s
Mas com várias soluções diferentes, que política usar para que o piloto da solução A não disfaça o que foi feito seguindo o pensamento da solução X ?
Gabriel, nesse caso depende bastante. Em alguns casos, quando estamos no verde, a galera discute e geralmente chega a algum “acordo”, mas de acordo com as regras do Dojo, o piloto é quem comanda e pode fazer o que quiser lá na frente – já aconteceu várias vezes em Dojos aqui da plateia discordar e o piloto fazer mesmo assim. Em algumas, foi bom, em outras, a galera modificou (os outros pilotos). Enfim, varia. 🙂