Animación al 5º hackathon de la UGR

Presentación para los proyectos participantes en el 5º Hackathon

Transcript

1. 5º Hackathon CUSL-UGR: Notas JJ Merelo dirosl@ugr.es
2. ¿Qué es un hackathón? Una experiencia de trabajo colaborativo para ayudar a proyectos de desarrollo de software
3. ¿Para qué sirve? Para dar un empujón a todos los proyectos granadinos participantes en el CUSL
4. ¿Cómo se usa? Vayamos por partes
5. Atraer al colaborador Tenéis diez minutos para contar de qué va el proyecto y atraer a colaboradores (traductores e informáticos casi a partes iguales, algunos de otras carreras)
6. Educar al colaborador Explicadle lo necesario para que comiencen a participar en el proyecto. Nunca será todo lo necesario. Preved sesión de coaching personal.
7. Incluir al colaborador No todos van a ser informáticos, ni van a tener el mismo nivel. Aún así, deberéis tener una tarea para él o ella. Especialmente para los (generalmente las) traductoras.
8. Ayuda de la OSL Haced a psicobyte y jjmerelo administradores de vuestro proyecto en la forja y pasadnos los nombres de usuario para que los añadamos (y alguna otra tarea en la que podamos ayudar)
9. Tareas para todo el mundo Analizar, programar, pero también probar, diseñar, documentar, escribir manuales, traducir, buscar modelos de negocio, plan de comunicación, diseñar casos de uso...
10. Y vosotros en todas Cada tarea debe supervisarse por algún miembro del proyecto, que supervise el commit.
11. Más vale que sobre, que no que falte Es mejor que tengáis que dejar de hacer alguna tarea, a que vuestra parroquia se aburra sin nada que hacer.
12. Previo al hackathón ¡Liberad ya el código y subidlo a la forja! (Si no lo habéis hecho)
13. Guía de prácticas Nombres de clases, de variables, dónde van las llaves, quién es la persona que decide lo que va en el código o no, hashtag propio, plantillas para la documentación...
14. Incorporación de código Tened un procedimiento claro de incorporación de código: qué condiciones debe cumplir, qué tests debe pasar, quién lo aprueba, quién lo integra, qué pruebas debe pasar una vez integrado.
15. Buscad una metodología de trabajo SCRUM, programación por parejas... lo que más os convenga, pero tened una.
16. Cread una lista de tareas En principio para 6-7 personas x 24 horas, pero puede haber más (o menos). Recordad: no todos son informáticos (son casi minoría, de hecho)
17. No planifiquéis ningún trabajo para vosotros mismos Tendréis bastante con ir apagando fuegos, explicando cosas, integrando lo que hagan otros y ayudando a la gente
18. Recuerda que hay un fin de semana por medio Estaremos en Cocorocó Coworking: http://cocoroco.es
19. ¡Usad tickets! Github y el resto de las plataformas tienen un método fácil de asignar tareas.
20. Gran poder conlleva gran responsabilidad Tened en cuenta los créditos. Si alguien no hace nada, por favor decídnoslo y no se le da el certificado. En cualquier caso, se ve en la forja.
21. El hackathón es programación + comunicación Designad fotógrafo Flickero/Picasero+ instagramero + YouTubero + twittero + bloguero + Facebookero + Tuentiero + cronista (puede ser un colaborador)
22. #5hackathon + (#|@)[proyecto]
23. El lunes día 11 queremos ver versiones x+1 (o +2) de todo. Obtened un resultado tangible
24. El hackathón no termina el lunes Tratad de conservar a los colaboradores hasta el final del concurso (y más allá)
25. Preguntas, sugerencias y comentarios
26. 5º Hackathon CUSL-UGR: Notas JJ Merelo dirosl@ugr.es
27. ¿Qué es un hackathón? Una experiencia de trabajo colaborativo para ayudar a proyectos de desarrollo de software
28. ¿Para qué sirve? Para dar un empujón a todos los proyectos granadinos participantes en el CUSL
29. ¿Cómo se usa? Vayamos por partes
30. Atraer al colaborador Tenéis diez minutos para contar de qué va el proyecto y atraer a colaboradores (traductores e informáticos casi a partes iguales, algunos de otras carreras) No os van a faltar usuarios, pero tratad de atraer a todo el mundo. Las razones por la que una persona elige un proyecto u otro son sólo técnicas en una enésima parte (que puede ser la cuarta)
31. Educar al colaborador Explicadle lo necesario para que comiencen a participar en el proyecto. Nunca será todo lo necesario. Preved sesión de coaching personal.
32. Incluir al colaborador No todos van a ser informáticos, ni van a tener el mismo nivel. Aún así, deberéis tener una tarea para él o ella. Especialmente para los (generalmente las) traductoras.
33. Ayuda de la OSL Haced a psicobyte y jjmerelo administradores de vuestro proyecto en la forja y pasadnos los nombres de usuario para que los añadamos (y alguna otra tarea en la que podamos ayudar)
34. Tareas para todo el mundo Analizar, programar, pero también probar, diseñar, documentar, escribir manuales, traducir, buscar modelos de negocio, plan de comunicación, diseñar casos de uso...
35. Y vosotros en todas Cada tarea debe supervisarse por algún miembro del proyecto, que supervise el commit. Y siempre debéis dar permiso a los usuarios para que hagan el commit. En el trabajo colaborativo todos las colaboraciones deben estar acreditadas. Como casi todos tenéis github, decidles simplemente que se descarguen los clientes de GitHub en su ordenador.
36. Más vale que sobre, que no que falte Es mejor que tengáis que dejar de hacer alguna tarea, a que vuestra parroquia se aburra sin nada que hacer. Pero, evidentemente, tampoco mandéis tareas por mandar...
37. Previo al hackathón ¡Liberad ya el código y subidlo a la forja! (Si no lo habéis hecho) O haced el último commit, incluyendo un TODO con mucho DO.
38. Guía de prácticas Nombres de clases, de variables, dónde van las llaves, quién es la persona que decide lo que va en el código o no, hashtag propio, plantillas para la documentación...
39. Incorporación de código Tened un procedimiento claro de incorporación de código: qué condiciones debe cumplir, qué tests debe pasar, quién lo aprueba, quién lo integra, qué pruebas debe pasar una vez integrado. Si no sabéis lo que es la integración continua, quizás este es el momento de aprenderlo http://about.travis-ci.org/docs/user/getting-started/. Usad también la metodología SCRUM que os van a enseñar (o la que os apetezca) para ir integrando los cambios.
40. Buscad una metodología de trabajo SCRUM, programación por parejas... lo que más os convenga, pero tened una. Programación por parejas http://en.wikipedia.org/wiki/Pair_programming
41. Cread una lista de tareas En principio para 6-7 personas x 24 horas, pero puede haber más (o menos). Recordad: no todos son informáticos (son casi minoría, de hecho) Ahora mismo hay 106 personas inscritas, pueden aparecer entre 40 y 50.
42. No planifiquéis ningún trabajo para vosotros mismos Tendréis bastante con ir apagando fuegos, explicando cosas, integrando lo que hagan otros y ayudando a la gente
43. Recuerda que hay un fin de semana por medio Estaremos en Cocorocó Coworking: http://cocoroco.es Pero puede que haya gente que llegue tarde o se quede en su casa. Prevé una forma fácil de comunicación: tickets en la forja, hangout, lo que sea
44. ¡Usad tickets! Github y el resto de las plataformas tienen un método fácil de asignar tareas. GitHub, además, permite fácilmente cerrar o referenciar tareas desde los commits.
45. Gran poder conlleva gran responsabilidad Tened en cuenta los créditos. Si alguien no hace nada, por favor decídnoslo y no se le da el certificado. En cualquier caso, se ve en la forja.
46. El hackathón es programación + comunicación Designad fotógrafo Flickero/Picasero+ instagramero + YouTubero + twittero + bloguero + Facebookero + Tuentiero + cronista (puede ser un colaborador) El colaborador puede diseñar un plan de comunicación, por ejemplo, y coordinar a quien se encargue de todo eso.
47. #5hackathon + (#|@)[proyecto]
48. El lunes día 11 queremos ver versiones x+1 (o +2) de todo. Obtened un resultado tangible
49. El hackathón no termina el lunes Tratad de conservar a los colaboradores hasta el final del concurso (y más allá)
50. Preguntas, sugerencias y comentarios