Como triunfar con tu proyecto en un hackatón
0 recomendaciones356 vistas
El documento describe cómo participar y contribuir en un hackatón, enfatizando la importancia del trabajo colaborativo y la organización de tareas. Se dan consejos sobre cómo atraer y educar a colaboradores, así como prácticas para la gestión del código y la comunicación. Además, se destaca la necesidad de integrar al equipo y mantener el proyecto activo más allá del evento.
![#hackathonugr
+ (#|@)[proyecto] + [@oslugr]](https://image.slidesharecdn.com/9hackathon-170307085910/85/Como-triunfar-con-tu-proyecto-en-un-hackaton-24-320.jpg)
Como triunfar con tu proyecto en un hackatón
- 1. 9º Hackatón Certamen UGR: Trucos y consejos para proyectos participantes JJ Merelo dirosl@ugr.es
- 2. ¿Qué es un hackatón? Una experiencia de trabajo colaborativo sobre proyectos de desarrollo de software.
- 3. ¿Para qué sirve? Para dar un empujón a los proyectos granadinos participantes en el certamen + visibilizar el software libre + los proyectos que participan.
- 4. ¿Cómo se usa? Vayamos por partes
- 5. Atraer al colaborador Tenéis unos diez minutos para contar de qué va el proyecto y atraer a colaboradores.
- 6. Educar al colaborador Explicadle lo necesario para que comiencen a participar en el proyecto. Nunca será todo lo necesario. Preved sesiones de entrenamiento personal.
- 7. Incluir al colaborador No todos van a ser informáticos, ni van a tener el mismo nivel. Aún así, deberéis preparar una tarea para él o ella.
- 8. Ayuda de la OSL Problemas con GitHub + difusión del proyecto + testeo + palmadas en la espalda + lo que se pueda.
- 9. Tareas para todo el mundo Analizar, programar, pero también probar, diseñar interfaz de usuario, documentar, escribir manuales, traducir, buscar modelos de negocio, crear iconos, crear historias de usuario, controlar la marcha del proyecto, plan de comunicación, diseñar casos de uso...
- 10. Y vosotros en todas Cada tarea, un issue, cada issue está en un milestone y debe resolverse con un commit, cada commit se refiere a un issue. Si no os fiáis, fork + pull request.
- 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 (o algo de) código y subidlo a GitHub! (Si no lo habéis hecho)
- 13. Guía de (buenas) 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. Mejor práctica: Crear un contributing.md queayudeapresentes(y ausentes) asaber quéhacefaltay cómo seañade.
- 15. 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.
- 16. Si no ha sido probado, no funciona
- 17. ¡Integración continua! ● Si no latenéis, puedeser laprimeratarea. ● Y parahacer integración continua, hacen falta tests. – Puedeser latarea0.
- 18. Buscad una metodología de trabajo SCRUM, programación por parejas... lo que más os convenga, pero tened una. Y siempre trabajar con hitos/milestones + issues.
- 19. Cread una lista de tareas == issues en GitHub. En principio para 4-5 personas x 24 horas, pero puede haber más (o menos). Recordad: no todos son informáticos.
- 20. 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.
- 21. Recuerda que hay un fin de semana por medio Tenemos espacio en la corrala de Santiago, pero podéis ir donde queráis.
- 22. Gran poder conlleva gran responsabilidad Los que asistan os están dando su tiempo. Vosotros tenéis que darles, al menos, el vuestro. + Reconocimiento + invitarlos a café o a pizza.
- 23. Hackathón := programación + comunicación Designad fotógrafo Flickero/Instagramero+ instagramero + YouTubero + twittero + bloguero + Facebookero + G+ero + Instagramero + Snapchatero + Telegramero cronista (puede ser un colaborador externo)
- 24. #hackathonugr + (#|@)[proyecto] + [@oslugr]
- 25. El lunes día 13 queremos ver versiones x+1 (o +2) de todo. Obtened un resultado tangible
- 26. El hackathón no termina el lunes Tratad de conservar a los colaboradores hasta el final del concurso (y más allá)
Notas del editor
- #6: 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). Y los colaboradores van a ser de todo tipo. No vayáis a contar si usáis este lenguaje súper raro o Gradle o Shippable. Interesarlos en EL PROYECTO. Aunque ya tengáis a algún colega que haya dicho que va a participar en vuestro proyecto, siempre le vendrá bien saber de qué va y centrarse un poco. Y, quién sabe, puede venir alguien totalmente desconocido. En particular tened en cuenta que puede que haya personas que sepan de diseño web, o de traducción, pero no necesariamente de desarrollo. También habrá diferentes personas con diferentes intereses.
- #7: Las primeras sesiones del hackatón serán en plan taller, pero preparad unas transparencias para explicar lo necesario, tanto para los técnicos como los no técnicos. Si necesitáis presentaciones sobre git, GitHub y cosas así pedidlas a la OSL. También hay bastantes presentaciones sobre temas diversos. No perdáis el tiempo preparando una presentación, buscad alguna que haya por ahí. Dedicadle tiempo a organizar el proyecto.
- #11: 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 todos tenéis github, decidles simplemente que se descarguen los clientes de GitHub en su ordenador. Todo esto también ayuda a la comunicación. Cada vez que cerréis un issue, lo ponéis por Twitter. También podéis usar los “proyectos” de Github, creando un proyecto específico para el hackatón.
- #12: Pero, evidentemente, tampoco mandéis tareas por mandar... Agrupad las tareas en hitos y comprobad de esa forma cómo se va avanzando en cada hito.
- #13: O haced el último commit, incluyendo un TODO con mucho DO.
- #14: Ayuda que creéis un CONTRIBUTING.md en el repositorio, y también una plantilla para hacer los pull requests. Normalmente los colaboradores van a ir al principio trabajando con pull requests, aunque más adelante, según avanza el hackatón, podáis añadirlos al repo como usuarios.
- #16: 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.
- #17: Los tests son muy importantes, y si tenéis que dedicar el hackatón solo a escribir tests, sea. En la carrera (casi) nadie habla de tests y son una de las omisiones más importantes de la misma. Aprended de aquí a entonces sobre marcos de test y ponedlos en práctica. A partir de los tests, la integración continua es (relativamente) trivial.
- #19: Programación por parejas http://en.wikipedia.org/wiki/Pair_programming Una vez más, se puede usar el canvas que hay en GitHub o cualquier otro, Trello, por ejemplo. Considerad también grupos de Telegram o un calan de Slack que tenga integrados los issues y otras herramientas de trabajo en grupo.
- #20: Conviene que sobornéis a vuestros colegas con pizza y cerveza para que gasten el fin de semana en esto. Nosotros daremos pegatinas.
- #21: Y también tuiteando todo el santo rato.
- #22: 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, Slack, grupo de Telegram, lo que sea. Esto también ayuda a que si la gente se queda en su casa pueda participar. Puede ser un bar que tenga la uni cerca (y llegue el WiFi) o simplemente un bar con wifi, un sótano en vuestra casa... Sí conviene que estéis en la Corrala al menos parte del tiempo, porque le objetivo del hackatón es que los proyectos os conozcáis y os ayudéis entre vosotros. También para “acoger” a quien venga espontáneamente.
- #24: El colaborador puede diseñar un plan de comunicación, por ejemplo, y coordinar a quien se encargue de todo eso.
- #26: Cerrad muchos hitos (o uno solo) y que se vea actividad en los repositorios. Haced algún release, aunque sea súper pre-alfa. Usad los releases de GitHub y ponedles nombres chulos.