¿Cómo funciona el desarrollo? ¿Cómo se compara con otras empresas de tecnología? ¿Se consideran ciertos procesos como los «mejores» para mí y para mi trabajo? Aunque no puedo responder a estas preguntas en su totalidad, puedo compartir mis experiencias en la transición hacia el trabajo como artesano del software y cómo mis puntos de vista han cambiado durante ese proceso.
Mi camino para convertirme en un programador profesional es único y siento que le da un contexto a la materia. En lugar de seguir una carrera de Ciencias de la Computación, tengo una licenciatura en Física, pero sorprendentemente, fue la física la que me llevó a la programación. Mientras trabajaba en el programa de física, también trabajaba a tiempo completo para una compañía local de tecnología como agente de soporte técnico. Cuando estaba a la mitad del programa, me pidieron que tomara dos clases introductorias de CS, como introducción a la programación básica. Después de completar esos cursos, decidí ingenuamente solicitar un puesto junior en el departamento de desarrollo de la empresa en la que trabajaba y, sorprendentemente, obtuve el puesto. Mirando hacia atrás, me doy cuenta de que era casi imposible para mí obtener ese puesto con tan poca experiencia, pero a pesar de ello, tenía el pie en la puerta y quería aprender todo lo que pudiera de mis nuevos compañeros de trabajo. Comparto estos antecedentes para ayudar al lector a entender que hasta los tres años de mi quinto año como desarrollador, los procesos y paradigmas de esa empresa eran todo lo que conocía y en lo que creía.
Cuando empecé a trabajar en desarrollo para esa empresa, me abrí al mundo de Agile, una palabra que hasta mi primer día en el nuevo rol, nunca había escuchado antes. Esa empresa practicaba un subconjunto de Agile llamado programación extrema, comúnmente conocido como XP. Las complejidades de XP no se detallarán aquí, pero sí algunos puntos destacados para ayudar a contrastar con los procesos que se mencionan más adelante. Al practicar XP, usamos herramientas comunes para organizar nuestro trabajo como tarjetas de historia y tareas, velocidad, sprints, retrospectivas, etc.
Para destacar, teníamos una política de programación en pares en todo el código de producción. Si eres un codificador experimentado, podrías adivinar que no funcionaba como se pretendía durante mucho tiempo, y estarías en lo cierto. Por lo general, se devolvía a un codificador la codificación y a otro se le pedía que revisara el código antes de comprometerse con el «par» en él. También había una estructura jerárquica muy estricta de los desarrolladores, una en la que era una regla no escrita que nada podía hacerse con éxito sin la participación de uno de los desarrolladores de más alto nivel.Un último punto a destacar sería que gran parte del trabajo era dictado por el gerente de producto/ventas/consejero delegado.En su mayor parte, hacíamos lo que se nos pedía, sin pensar realmente fuera de la caja.
Aquí las cosas son un poco diferentes a lo que he descrito. Practicamos lo que se conoce como Programación Lean, y de nuevo, las complejidades de la cual no se detallarán aquí. Lo primero que hay que señalar es que cree firmemente en los pequeños equipos autónomos. Al tenerlos, cada equipo puede decidir qué es lo que mejor le funciona. Algunos de los aspectos más destacados aquí son generales en todo el desarrollo y algunos son específicos del equipo en el que trabajo. Menciono ambos para ayudar a contrastar las prácticas anteriores. Al practicar Lean, no tenemos ningún sprint o velocidad definidos, y aunque usamos tarjetas de historia/tarea, no se ven de la misma manera que el XP.Continuamente reflexionamos y hacemos mini retrospectivas para mejorarnos a nosotros mismos.Colaboramos con nuestro gerente de producto.Practicamos el desarrollo dirigido por pruebas (TDD).Practicamos la programación mob, una extensión de la programación por parejas.La mejor parte es que hacemos estas cosas en su totalidad, todo el tiempo.
A medida que he ido haciendo estas transiciones, también he tenido que cambiar yo mismo. Siento que soy mejor artesano y desarrollador que antes, no sólo porque he hecho la transición a un paradigma diferente, sino porque he hecho la transición a un paradigma diferente que me funciona mejor. Es común que mi equipo codifique durante 8 horas completas cada día, en comparación con las 4 ó 5 horas como mucho en las que participaba antes. Al realizar pruebas de todo el código de producción, puedo tener confianza en el código inmediatamente en lugar de después de escribir las pruebas posteriores al compromiso. Posiblemente el mayor cambio para mí es la transición a una cultura de aprendizaje en lugar de una cultura de dependencia. Como aprendiz perpetuo, tengo hambre de más conocimientos y soy libre de aprender/experimentar y lo más importante, fracasar. Antes de que todo lo que sabía era una cultura de dependencia de los más experimentados que yo, una cultura que todavía creo que funciona bien para esa empresa. Contrataron al joven más verde de los verdes en mí, por ejemplo, y siguen haciéndolo. Pero la cultura que mejor se ajusta a mí es la cultura de .
En retrospectiva, durante los primeros años, debido a la cultura en la que me encontré y al camino único que tomé para llegar allí, todo lo que sabía de prácticas, paradigmas y herramientas era la experiencia que había tenido hasta ese momento, empecé a darme cuenta de que hay muchas maneras de hacer el trabajo. Cada una con sus propios beneficios y mejores aplicaciones. El truco que he encontrado es encontrar lo que impulsa tu hambre interior como artesano y desarrollador.
Para mí, y sus procesos/cultura se ajustan mejor que los que dejé recientemente. Para mí lo son, pero lo mejor para mí puede no ser lo mejor para cada lector. Creo firmemente en la búsqueda del aprendizaje y la experimentación. Encuentra lo mejor para ti. Aplícalo, y si no se ajusta, encuentra otra cosa para probar. El desafío para todos nosotros es seguir aprendiendo e intentando, sin conformarnos nunca con algo que puede funcionar, pero que no funciona bien.
Categorías: cultureTags: agile, lean