💾 Archived View for gmi.osiux.com › 2022-08-02-osiux-wip-flow.gmi captured on 2023-07-10 at 14:26:14. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
[1]
A principio del año 2021, en plenas vacaciones, como todos los años, reflexiono sobre qué espero hacer todo el año, ya desistí de titularlo *"objetivos"* porque en el fondo sé que me voy a desviar de lo *"planificado"* y por ello intento registrar un punteo de ideas que puedo desarrollarlas o abandonarlas, pero que están ahí para no ser olvidadas, esperando a que las continué de alguna manera en algún momento...
Sin dudas el 2020 fue un año atípico para todo el planeta, yo no logré escribir al menos 1 *post* en todo el año y por ello comencé el 2021 con un `desafío compartido` ^1[2] que dio muy buenos resultados por 2 meses y luego volví a abandonar una vez más mi *blog*... `:)`
A un mes de terminar el 2021 vuelvo a mi lucha interna y recordé ese punteo que hice hace 11 meses:
Estas definiciones de acciones estuvieron latentes en mi mente y voy a intentar desarrollarlas o al menos esbozarlas para que empiecen a encajar unas con otras y ver si con una definición concreta se convierten en una suerte de guía metodológica para iniciar un nuevo año un poco menos caótico.
Haciendo una suerte de revisionismo histórico sobre mis años de trabajo como `"Developer vs SysAdmin GNU/Linux"` comprobé una vez más mi falta de disciplina y llegué a aceptar que `"amo el orden pero soy un caos"`
El pegamento que une estas acciones es otro intento para completar las tareas (luego de *"fracasar"* repetidamente con *GTD* ^2[3], *AutoFocus* ^3[4], *SCRUM* ^4[5], etc) pero esta vez pensando que en algún momento no voy a estar para continuar lo abandonado y con la esperanza de que alguien retome las tareas inconclusas o que al menos sirvan de inspiración o como guía de todo lo que esta mal `:P`
No estoy inventando nada nuevo, esto es solo un *remix* muy mezclado de todo lo aprendido, pero "ordenado" de otra manera, tal vez como una `"definición de terminado"` a obtener en solo 7 pasos. `:)`
Lo más importante es `tener clara la tarea a realizar` y sus implicancias:
En fin, podríamos resumir en todo esto en simplemente `Analizar` pero sería minimizarlo en cierto punto, porque si no las escribo de manera clara en un *gestor de tareas* o al menos en un *archivo de texto*, no voy a poder contrastarlas para luego poder sistematizarlas, es decir, encontrar qué tienen de similares entre si y con respecto a tareas anteriores, para así definir un mínimo factor en común a establecer de ahora en más y tener mas clara la dependencia de unas con otras.
Cientos de ideas para agregar, corregir, modificar y mejorar todas compitiendo entre sí, no hacen otra cosa que llegar a un estado interminable. Si no priorizo, avanzo sin rumbo.
Mantener un sistema es complejo y más aún cuando el sistema es complicado, grande o simplemente tiene mucho tiempo de uso y nada mejor que dividir el problema, modularlo permite corregir y mejorar pequeñas partes de manera mas acotada y simple de mantener en el tiempo.
Es vital contar con métricas para entender cómo funciona y dónde convendría optimizar y no solo se trata del funcionamiento de la solución, registrar el progreso del desarrollo es vital para detectar y mejorar todo el proceso a futuro.
Teniendo clara la tarea, el primer paso es automatizar, la premisa básica para delegar el conocimiento es contar al menos con un *script* que resuelva un problema de la manera mas automatizada posible, es decir una pieza de código limitada pero completamente funcional en resolver algo puntual a la `UNIX Way` ^5[6].
Sin documentación básica nos atamos a nuestros desarrollos y no permite independizar a las personas que intentan usar eso que hicimos y terminamos gastando tiempo valioso en soporte técnico innecesario.
De nada sirve contar con un programa muy *"monono"* que solo vive en mi `localhost`. Hace poco en *gcoop* ^6[7] me hicieron un *Merge Request* de algo que ya había resuelto, pero que ni siquiera hice el *commit* y el problemita estaba ahí latente, bastó que alguien más se topara con él para intentar resolverlo y compartirlo, por este motivo me recordaron *la ley de Linus* ^7[8], `Libera rápido, libera seguido`
Además de compartir soluciones a problemas, liberar sirve para visibilizar que se estuvo trabajando en resolver un problema o mejorar una solución, hacerla mas elegante y/o *"performante"*, pero por sobre todo sirve para tener un registro visible de a qué le estamos dedicando tiempo para no duplicar esfuerzos.
Entre la realidad y la percepción hay un abismo! No es fácil ser coherente, una cosa es *creer* que puedo solucionar algo, otra cosa es lo que puedo "hacer" para solucionarlo y finalmente muy distinto puede ser lo que "obtengo" como resultado.
Para contrarrestar estas incoherencias, nada mejor que `Compartir la solución`, aunque este incompleta y llena de errores, porque puede ser el punto de partida para una solución funcional con el aporte de alguien o de toda una comunidad!
18 meses después que comencé este *post* hoy termino de esbozarlo aunque no deja de ser un `Work in Progress`, aunque incompleto me completa `<3`
1: file:img/osiux-wip-flow.png
2: https://osiux.com/2021-02-26-30-dias-de-posts-por-la-birra.html
3: https://osiux.com/gtd-gething-this-done.html
4: http://markforster.squarespace.com/spanish/
5: https://proyectosagiles.gmi/que-es-scrum/
8: https://es.wikipedia.gmi/wiki/Ley_de_Linus
9: https://gitlab.com/osiux/osiux.gitlab.io/-/commit/7971db335b63f09eafd9d51ffe635cab1a47cd9c
10: https://gitlab.com/osiux/osiux.gitlab.io/-/commit/bf3a61526ad2a73cecb77a18995f1d63494e3664
11: https://gitlab.com/osiux/osiux.gitlab.io/-/commit/4aa5043ada468cb91f7756f6dda85c4fd4139223
12: https://gitlab.com/osiux/osiux.gitlab.io/-/commit/198eeb2f93e0b5edea11e6f78f1bdefa20dbc9d0
13: https://gitlab.com/osiux/osiux.gitlab.io/-/commit/bf3976eea3282d44624c331b6b47c60228626b89
![[IMG]](/kennedy.gemi.dev/archive/cached?url=gemini%3a%2f%2fgmi.osiux.com%2ftmb%2fosiux-wip-flow.png&t=638245959740000000&raw=False){kind=link}
