Pair Programming labrega :D, unha coña, pero non é tan coña

Diálogo entre 2 cabaleiros (sin cabalo) sobre o pair programming ;P

cabaleiro A
"Pair programming aplicado á sementeira das patacas"
cabaleiro B
jajjjajaja
cabaleiro A
O pair programing xa o inventou meu avó .. que cando me vía co sacho xa me estaba enriba: "así non, ho .... dalle como che digo eu ..."
cabaleiro B
jajjajaj..
andas de coña
pero precisamente é iso
a programación é algo artesano
cabaleiro A
si
cabaleiro B
un artesano mestre (que ten un montón de experiencia, non unha certificación de 160 horas), explícalle un artesano panduriño, como facer as cousas
i este último, debería ser humilde e aproveitar para aprender
cabaleiro A
Exacto
eu protestaballe sempre .. pero ben que tomaba nota para os meus adentros :-D
cabaleiro B
jajjaja..

Martes 13 de Outubro de 2009: Primeiro Café Áxil. Absteñanse supersticiosos

Pois si, o primeiro "café áxil" que celebramos caíu a martes 13, pero non houbo ningunha incidencia negativa que reseñar (todos levabamos un allo no bolsillo por si las moscas :P).

¿Que se fixo nese encontro?

• Presentar ós asistentes a iniciativa "axil-mente": Contámos ós asistentes, como surxíu o tema, en que estábamos interesados e que ferramentas tiñamos actualmente: páxina web[1], blog[2] e lista de correo[3]. Polo dagora temos pouca actividade, no blog un par de entradas e na web a páxina de recursos.
  


• Contamos tamén que é isto dos "cafés áxiles" e porque xurdiron. Tamén se explicou a proposta de funcionamento de ditos "cafés": ás persoas que puxemos isto en marcha interésanos o tema do axilismo e, como se dixo no punto anterior, puxemos cousas en marcha pero temos moi pouca actividade. Por outra banda, temos contactos cun grupo máis potente vinculado a este tema, Agile Spain [4],[5], i eles anímanos a formar parte da súa asociación como Agile Spain Galicia, pero para iso fai falta ter algo de actividade. O tema é que esta xente queda logo do curro unha vez ó mes ou así para facer reunións temáticas, etc, pero nós non podemos ir tan alá (motivos persoais varios, aínda que no futuro xa se verá). Como alternativa, surxíu a idea dos "cafés áxiles", que funcionan da seguinte maneira. Unha vez cada 15 días facemos un café áxil. Na lista de correo anúnciase, pedindo suxerencias para hora e lugar e tamén para propoñer temas. Hai unha semana para esta proposición de temas. Cando remata esta, envíase unha mensaxe resumo cós temas "recolectados" para que o personal vote. Na reunión trátase un tema único (só son 30 minutos). Tratarase o tema gañador da votación. Para a votación hai 3 ou 4 días. Unha vez seleccionado o gañador, quedan 2 ou 3 días que se recomendan para ler algunha historia relacionada para non ir "sin idea" á reunión, pero isto é claramente opcional. Os temas de debate que non gañaron quedan na lista e súmaselles automáticamente 1 punto, para que non quede ningún tema que "sempre perda" por surxir outros máis interesantes para a maioría (desta maneira consideramos ás minorías). Faise o café áxil e ponse no blog unha entrada resumo.
  


• Tamén se falou do aperturismo da lista de correo [3]: pódese apuntar quen queira, o grupo está configurado para iso. Ademáis, que se esté apuntado non significa que se teña que participar dos encontros e actividades. É un tema totalmente voluntario e pódese estar suscrito á lista, simplemente por "escoitar" :D. Ou sexa, que llo podedes comentar a quen queira suscribirse, non ten que pedir permiso nin nada semellante, iso si, sendo educados eh :D. O que sí é certo é que, si somos moitos no "cafesito áxil", igual hai que ir en dúas tandas :P, xa veremos.
  


• Recursos "punto de partida": recomendamos como "punto de partida" simplemente 2 recursos, os vídeos de "Introducción a Scrum" que fixeron os membros do Agile-Spain Madrid [6], e ler o libro "Scrum y XP desde las trincheras"[7]
  


• Pablo explicou a súa entrada Seguimento diario das tarefas e fixemos debate. Conclusións: non houbo consenso, polo que se vai transformar nun fío de debate na lista de correo para profundizar un pouco máis.
  


• O mesmo coa súa entrada Documentación xerada: informes: aquí non houbo debate, simplemente escoitamos, será porque os demáis non facemos nada :P. De todas maneiras faranse fíos de debate na lista de correo para ir recollendo as opinións da xente.
  


• Fíxose a proposta de construir na web un "esqueleto" sobre cada un dos términos e conceptos de scrum onde se enlace a entradas que expliquen cómo o estamos implementando cada un deles a nivel local e porqué, é dicir, qué nos levou a facer as cousas dunha maneira concreta (serán entradas do blog).

Tarefas especiais

Situación: Normalmente podemos ter certas tarefas especiais ás ke deberemos atender. Estas tarefas son de varios tipos:

Tarefas técnicas: akelas ke proceden do ekipo ou responsable técnico, son exemplos: actualización aos estándares, mellora de rendemento, revisión accesibilidade e usabilidade,...
Tarefas latentes: son as ke consideramos ke deben estar presentes no sprint aínda ke non se cheguen a iniciar. O típico exemplo pode ser “saída a produción” (ke lóxicamente englobaría varias subtarefas) ke depende dunha data ke nos debe dar o funcional.... pero ke poder non ser desta aínda.
Tarefas de planificación: elaboración de informes, actualizar backlog,...
Erros: erros ou incidencias en produción.

Solución: o tratamento ke nos lle damos ven sendo o seguinte (hai moitas solucións na literatura)
Tarefas técnicas: méteas o ekipo no backlog e priorizanse como unha historia máis. A importancia negóciase co funcional (polo de agora ke é razonable e acepta os criterios ke lle damos).
Tarefas latentes: a tarefa está presente nos sprints ke faga falla ata ke se remate polo ke temos unha reserva de tempo para ela en cada sprint na ke se poida dar. Ao incorporar estas tarefas deberemos ter en conta ke se non se desencadena imos dispoñer dese tempo polo ke haberia ke ter tarefas de reserva para facer no sprint.
Tarefas de planificación: non se reflexan de ningunha maneira... forma parte do traballo do scrum master e polo de agora non teñen impacto significativo.
Erros: aínda ke non temos esa sorte (non é ke non falle a aplicación senon ke aínda non saímos jejjee) de seguro ke reservaremos tempo de adicación dos recursos a esas incidencias separándoas da liña de desenvolvemento (ao estilo de proxectos distintos).