Etiquetas
No sé si os pasa a todos, yo creo que sí, pero tenía serios problemas de organización y productividad en el desarrollo de Menéame. Quizás sea un caso especial, es un sistema complejo:
- software relativamente grande y soy básicamente el único programador responsable de todos los módulos,
- diversidad de lenguajes, PHP para la web, Python para scripts y programas «off line», Perl por herencia de hace años,
- base de datos grande e imposible de hacer alteraciones de las tablas por el tamaño de las mismas (ya veremos con el MySQL 5.6),
- mucha manipulación de datos en la base de datos,
- interacciones complejas de usuarios,
- muchos controles de entradas y acciones de usuarios «externos»,
- los usuarios piden muchas modificaciones, correcciones y detectan bugs que ni se te pasaron por la cabeza que podían ocurrir,
- cada vez que se implementa una nueva característica (cada vez más complejas), aparecen nuevos bugs y sobre todo, los usuarios demandan muchas modificaciones y ań nuevas características complementarias.
Con todo esto, a veces me ocurría que me bloqueaba porque no sabía por dónde comenzar, o que pasos seguir, o cuál era el trabajo pendiente, cuáles son importantes, cuáles son urgentes, y cuáles secundarios que pueden esperar hasta tener ese momento de inspiración. Soy bastante desorganizado, y odio profundamente usar programas (los tipos «gestión de tickets») para esto. Ya demasiado tengo con ventanas de editores, consolas de administración y páginas de manuales para encima tener que estar buscando una ventana perdida para ir leyendo y apuntando lo que estoy haciendo.
Así que hice lo natural para mí, la pantalla del ordenador es para las herramientas fundamentales para programar, la gestión «personal» fuera de la pantalla. Eso es, gestionarla con papel y boli, que siempre tengo al lado del teclado y me resulta más cómodo y hasta me ayuda mucho a ordenar las ideas. Hace unas pocas semanas me metí en un trabajo muy gordo, programar los subs de usuarios y decidí ser estricto en apuntar todo. Pero no sabía cómo hacerlo, hasta que se me ocurrió una idea sencilla y que la practiqué rigurosamente. Tengo un cuaderno y apunto allí dos secciones diferentes.
En la primera voy apuntando todas las funcionalidades que debo implementar. Éstas no dejan de crecer, fundamentalmente por lo que piden los usuarios. El orden es estricto, siempre a continuación. Apunto qué debo implementar y luego agrego marcas o comentarios al margen sobre su urgencia, dependencias, es importante (esto es con una flecha), etc. Escribo con letras grandes y dejando suficiente espacio, no me entran más que unas 5 a 8 notas por página.
Es muy importante que cada tarea a hacer sea autocontenida y que no requieran más de unas pocas horas de programación. Si requieren más de 4 u 8 horas, las especifico con menor granularidad. Cada día releo la lista completa, y voy tachando las que he terminado (no sólo ayuda a organizar, también motiva y hace sentir bien el ir eliminando las tareas). Esto no tiene nada de especial con lo que se hace en cualquier software de tareas o tickets, salvo que está en papel y no en la pantalla. No sé al resto de la gente, pero nunca pude gestionar estas listas con programas.
Lo importante es lo siguiente. Al sentarme a programar selecciono qué tarea hacer, y en el siguiente folio a la lista de tareas apunto:
- una pequeña subdivisión de lo que debo programar (si es complejo),
- qué debo verificar (por ejemplo «controlar asignación variable x», «ver dependencias con top-link.py», «probar funcionalidad x», etc.),
- cualquier duda que tengo sobre lo que estoy haciendo,
- tachar lo escrito como pendiente o que tenía dudas y las he solucionado,
- si tengo que interrumpir el trabajo por alguna razón, apunto qué estabas mirando en ese momento,
- arranco el folio del cuaderno una vez acabado el trabajo.
Al hacerlo en la página siguiente a la lista de tareas pendientes me obligo a no hacer crecer esa lista hasta que haber acabado la actual (o al menos a no agregar más allá del espacio libre que te queda en el folio). Al apuntar las dudas y problemas evito introducir (aún más) bugs porque me olvidé de verificar algo, o de tener en cuenta las dependencias. El apuntar lo que estaba haciendo antes de alejarme del ordenador es de gran ayuda para, junto con las otras notas anteriores, ubicarme rápidamente en lo que estabas haciendo.
Cuando acabo tarea, arrancar el (o los folios) es un gran motivador y «golpecito en la espalda», es como quitarte un peso de encima y me hace sentir bien por el trabajo hecho. Es serio, lo de arrancar el folio es clave. Además, ahora puedo volver a mirar la lista de tareas pendientes, tachar lo que acabo de hacer y decidir la siguiente.
Algunos podrán pensar que es una desventaja tener que recorrer varios folios (tampoco debes permitir tener más de unos pocos) hasta encontrar la nota que debes tachar cuando la has acabado, pero para mí es una ventaja: me obliga a leer las cosas pendientes, y me sirve otra vez para priorizar y darme cuenta en dónde estoy.
Bueno, quizás esto sea una tontería, pero después de muchos años programando, encontré un sistema que no me molesta, que me ayuda a organizar y a concentrarme cuando me vuelvo a sentar a programar, y que me hace sentir bien al acabar cada trabajo. Y es muy fácil, sólo un cuaderno de los pequeños, el overhead es mínimo, muy útil y eficiente, y no te vuelve loco con tanta pantalla y demoras para abrir programas o cargar desde sitios remotos.
Además, cuando estoy agobiado, puedo leerlo y hacer anotaciones en el baño. Es más útil que tuitear 😉
Ricardo Galli, de software 
Vaya, yo trabajo igual. Pero no arranco las hojas, sino que las tacho con un rotulador verde fluorescente.
Las pequeñas tareas autocontenidas es la clave, de tu sistema y de scrum. Lo de usar papel o JIRA ya depende del tamaño del equipo.
Uff, te van a salir multitud de comentarios explicando métodos que usamos cada uno.
Al papel le veo una gran pega: la búsqueda.
En mi caso me gusta/necesito encontrar cómo solucioné tal problema o con qué nuevos me encontré, y con una libreta (varias al cabo de años..) como que no …
En mi caso lo resolví con una miniweb chapuza hecha por mi, alojada en un servidor mini (guruplug) de mi casa, y siempre trabajando con ficheros de texto. Vamos todo muy propio que SOLO me sirve para resolver MIS necesidades. Con esto quiero decir que cada cual tendrá que encontrar su solución….
http://iwre0.wordpress.com/2012/12/17/mi-todo_list-y-sobre-todo-mi-done_list/
Aparte de todo esto, ¿no usas tests automatizados? ¿integración continua?
Hay que mejorar esa letra! (^_^)
Entiendo que consideres engorrosa una herramienta tipo Jira, sobre todo si estás prácticamente solo, pero Trello es muy similar a como haces las cosas en papel. Si no lo has probado creo que deberías darle una oportunidad, ya verás que es muy ágil.
No parece una metodología muy académica y me alegra que sea así. Yo también voy en plan solitario con proyectos que me exceden y utilizo un sistema similar, solo que en lugar de cuaderno tengo folios y suelo escribir a lapiz.
En lugar de arrancar hojas las tiro a la papelera una vez haya quedado superada o obsoleta (una nueva hoja) También procuro no poner asuntos que no se puedan abordar en media jornada, si creo que voy a tardar más divido objetivos.
La ventaja del papel y mano alzada es que puedes “documentar” con un formato muy libre, de forma rápida y en cualquier lugar.
***
Yo pensé que “meneame” era una labor de equipo con bastantes programadores. Felicito a su autor, no por el trabajo sino por su capacidad de superar la soledad.
Gracias por compartirlo! Muy interesante! Lo probaré a ver qué tal. Me gusta el enfoque a programación para un sólo desarrollador y proyecto (porque te ahorras todo el caos de la gestión de varias listas por grupo i proyecto,… además todos acabamos tarde o temprano solos ante el código o Diox…).
Yo llevo probando un montón de cosas en la web (rememberthemilk,wunderlist,tareas del gmail,…), i en papel porque me sirve de apoyo mejor que la pantalla por parecidos motivos: apunto más rápido en papel que en pantalla, i porque puedo mantener la pantalla sin cambiar de ventana i lo mismo vale para leer tanto de la pantalla como del papel a la vez).
Método “aquí i ahora” para los que tenemos el síndrome de Diógenes acumulando listas infinitas de cosas i toneladas de notas caóticas:
He probado a trabajar por ejemplo grapando 2 papeles A4. El primer papel lo divido en plan #, en 6 rectángulos iguales (2 filas por 3 columnas):
primera fila (estrategia): col 1 (tareas del dia a hacer), col 2: tareas a posponer, col 3: tareas a aplazar/archivar para más adelante.
segunda fila (operativa):col 1 desarrollo paso a paso de la tarea del dia 1, col 2 desarrollo paso a paso de la tarea 2 del día, col 3: desarrollo paso a paso de la tarea 3.
El resto de tareas se desarrollan en 3 columnas el anverso de la hoja 1, de forma análoga..
El segundo papel A4, es para el desarrollo i las notas mientras vas trabando (yo voy apuntando ideas, números de línea, nombres funciones…todo’s..comprovaciones pendientes…
También he usado libretas i el problema es que genero demasiadas notas, me pulo la libreta en poco tiempo, i luego me pierdo por las paginas buscando..
En mi caso, este sistema que planteo (muy mejorable seguro), me sirve para tener rápidamente la foto del día y organizarme con un histórico muy pequeño o inexistente, de manera que me centra mucho.
Un saludo!
Perell
Interesante! creo que aplicaré tu método de gestión a mis desarrollos, creo que me serviría de mucho cuando tenga muchos pendientes, y eso de “arrancar las hojas” sospecho que debe ser muy liberador! xD
Utilizo el mismo sistema, viejuno pero efectivo. Siempre empiezo las microlistas por la segunda página, primera a la izquierda, para tener dos páginas a la vista por tema/hito de desperezarme. Además te recomiendo las libretas que permite arrancar las hojas sin pelearte con la anilla.
Yo usaba un sistema parecido. Ahora solo tengo la libreta de apoyo. El ‘To Do’ puro y duro lo he pasado a Asana, ya que me pareció brillante la sencillez de la plataforma.
A mi me encanta Trello, sea para organizarme con alguien o para tener mi propia lista de tareas. Y para aquello de «toco algo y no sé si he roto algo distinto» el empezar a tener muy en cuenta el testeo automático desde hace años me ha hecho cambiar la forma de programar, creo que para bien. Y es mejor que tener comentarios en el código.
El comentario es, al fin y al cabo, código que hay que mantener, porque si se actualiza el código real se ha de modificar el comentario de forma acorde. Pero no el comentario acaba siendo mejor no tenerlo que tenerlo. En cambio, un test automático es claro cuando ha de ser mantenido, eliminado o actualizado, ya que al ser formal, deja de funcionar si el código que testea ha cambiado. Por otro lado, uno acaba buscando los tests de los módulos en los que hace tiempo que no trabaja para ver cómo funciona, ya que se convierten en la documentación perfecta: código usando un módulo tal y como el desarrollador se lo imaginó.
Saludos.
Suena similar al sistema ‘Autofocus’ http://lifehacker.com/5704856/the-autofocus-productivity-method-stop-maintaining-to-do-lists-and-start-getting-stuff-done Que vamos, será por metodologías para mejorar la productividad. Al final cada cual usa su versión : )