Dos miradas sobre cómo presentarle a los clientes en qué se estuvo trabajando. Random Google Image Antes de comenzar quiero aclarar que en este artículo no estoy hablando puntualmente de una “Review meeting” tal cual plantean frameworks como SCRUM. Simplemente son dos formas de llevar a cabo una demostración del trabajo realizado a un tercero. Es razonable que cada tanto nuestros clientes quieran ver el progreso, así como también lo es, que nosotros, orgullosos desarrolladores, queramos mostrar en lo que hemos estado trabajando. No importa la metodología utilizada: si es ágil o no; si es por iteraciones cortas o largas; en algún momento debemos interactuar con el cliente para que éste…
-
-
Lo que quiero vs Lo que obtengo
¿Cuántas veces recibiste algo y te diste cuenta que no es lo que pediste?, o tal vez debería decir ¿… y te diste cuenta que no es lo que esperabas? Random Google Image Cuando uno avanza en su carrera es normal que le den la responsabilidad de coordinar o revisar el trabajo de otros. Este trabajo por hacer son los requerimientos del sistema en el que estamos trabajando y dependiendo de cómo sea el entorno de cada equipo, estos requerimientos pueden estar mejor o peor definidos, o más bien, mejor o peor documentados. Últimamente me suele pasar que lo que yo esperaba ver en el momento de la revisión no era…
-
Ser ágil es …
Si hay algo que aprendí en el último año es que la frase con la que titulé esta entrada es una de las cosas más difíciles de explicar que me encontré en el último tiempo. Estas semanas estuvimos hablando mucho en el trabajo sobre agilidad, equipos, ser ágiles, Scrum, etc; y algo que he notado es que cada uno interpreta diferentes cosas sobre el qué y el cómo. Y en general me es muy difícil explicar la “particular” mirada que tengo actualmente de lo que entiendo por “ser ágil”. Sacada de http://pragmaticprojectleadership.com/agile-mindset-deciding-work/ Hasta hace poco mi definición más corta para responder a esta pregunta era “ser ágil es responder rápido al…
-
¡No experimentes!
http://www.picserver.org/images/highway/phrases/experiment.jpg En las empresas de sistemas nos caracterizamos por ser mayormente gente analítica, matemática (por no decir “cuadrada”) y que tenemos muy presente el método científico. Sin embargo cuando vamos creciendo y teniendo más responsabilidades nos vamos encontrando un cierto rechazo o miedo a la palabra “experimento”. Hace unas semanas luego de volver del Agile Open Camp 2017 decidí que era hora de hacer algunas cambios en un proyecto en el cual colaboro más desde lo organizacional que desde lo técnico. Volví con un montón de ideas para mejorar la forma de trabajar del equipo, pagar la deuda técnica acumulada, ser más robustos a futuro y muchas otras cosas. ¡Es…
-
“Funciona” no es suficiente.
No es raro en esta profesión, al revisar el trabajo de otro encontrarse con algo que no es del todo semánticamente correcto o que puede escribirse de mejor manera. Tampoco es raro que nos digan “pero así funciona”. Funciona no es, o no debería al menos, ser suficiente. En el desarrollo de software existen muchos otros factures a considerar a futuro que no siempre tienen que ver con el funcionamiento actual de la aplicación : ¿el código se entiende?, ¿es eficiente?, ¿es fácil de extender si debemos agregar funcionalidades?. Quizás el aspecto más importante desde el punto comercial es que tanto cuesta corregir un error detectado, ya que en códigos escritos…