𝘚𝘋𝘋 𝘷𝘪𝘯𝘰 𝘢 𝘤𝘢𝘮𝘣𝘪𝘢𝘳 𝘯𝘶𝘦𝘴𝘵𝘳𝘰 𝘧𝘭𝘶𝘫𝘰 𝘥𝘦 𝘥𝘦𝘴𝘢𝘳𝘳𝘰𝘭𝘭𝘰 🤯

⁣⁣Hace unas semanas tuvimos una iniciativa en el trabajo donde nos enseñaron el flujo de 𝐒𝐃𝐃 con ̲𝙶̲̲𝚒̲̲𝚝̲̲𝚑̲̲𝚞̲̲𝚋̲ ̲𝚂̲̲𝚙̲̲𝚎̲̲𝚌̲ ̲𝚔̲̲𝚒̲̲𝚝̲, 𝘧𝘶𝘦𝘳𝘰𝘯 𝘥𝘰𝘴 𝘴𝘦𝘮𝘢𝘯𝘢𝘴 𝘣𝘪𝘦𝘯 𝘪𝘯𝘵𝘦𝘳𝘦𝘴𝘢𝘯𝘵𝘦𝘴, el primer día hicimos el setup en nuestras máquinas y nuestros repos -𝘥𝘢𝘥𝘰 𝘲𝘶𝘦 𝘩𝘢𝘣í𝘢𝘯 𝘢𝘳𝘤𝘩𝘪𝘷𝘰𝘴 𝘲𝘶𝘦 𝘴𝘦 𝘵𝘦𝘯í𝘢𝘯 𝘲𝘶𝘦 𝘴𝘶𝘣𝘪𝘳, 𝘥𝘦 𝘤𝘰𝘯𝘧𝘪𝘨𝘶𝘳𝘢𝘤𝘪ó𝘯 𝘱𝘢𝘳𝘢 𝘢𝘨𝘦𝘯𝘵𝘦𝘴- empezamos a entender los comandos de 𝐆𝐢𝐭𝐇𝐮𝐛 𝐒𝐩𝐞𝐜𝐊𝐢𝐭: /𝗌𝗉𝖾𝖼𝗄𝗂𝗍.𝖼𝗈𝗇𝗌𝗍𝗂𝗍𝗎𝗍𝗂𝗈𝗇, /𝗌𝗉𝖾𝖼𝗄𝗂𝗍.𝗌𝗉𝖾𝖼𝗂𝖿𝗒, /𝗌𝗉𝖾𝖼𝗄𝗂𝗍.𝗉𝗅𝖺𝗇 , /𝗌𝗉𝖾𝖼𝗄𝗂𝗍.𝗍𝖺𝗌𝗄𝗌 𝗒 /𝗌𝗉𝖾𝖼𝗄𝗂𝗍.𝗂𝗆𝗉𝗅𝖾𝗆𝖾𝗇𝗍; 𝐜𝐮á𝐥 𝐞𝐫𝐚 𝐞𝐥 𝐟𝐥𝐮𝐣𝐨 𝐝𝐞 𝐒𝐃𝐃 𝐲 𝐭𝐚𝐦𝐛𝐢é𝐧 𝐞𝐥 𝐨𝐫𝐝𝐞𝐧 𝐲 𝐞𝐥 𝐨𝐛𝐣𝐞𝐭𝐢𝐯𝐨 𝐝𝐞 𝐜𝐚𝐝𝐚 𝐜𝐨𝐦𝐚𝐧𝐝𝐨. ⁣⁣
⁣⁣
Y ya cuando íbamos a partir con nuestra épica a desarrollar, 𝐧𝐨𝐬 𝐝𝐢𝐦𝐨𝐬 𝐜𝐮𝐞𝐧𝐭𝐚 𝐪𝐮𝐞 𝐚ú𝐧 𝐧𝐨𝐬 𝐟𝐚𝐥𝐭𝐚𝐛𝐚 𝐢𝐧𝐟𝐨𝐫𝐦𝐚𝐜𝐢ó𝐧 𝐝𝐞 𝐪𝐮é 𝐪𝐮𝐞𝐫í𝐚𝐦𝐨𝐬 𝐡𝐚𝐜𝐞𝐫 𝐲 𝐜ó𝐦𝐨, 𝐩𝐚𝐫𝐚 𝐩𝐨𝐝𝐞𝐫 𝐜𝐫𝐞𝐚𝐫 𝐥𝐚𝐬 𝐒𝐩𝐞𝐜𝐬 𝐚𝐬í 𝐪𝐮𝐞 𝐝𝐢𝐦𝐨𝐬 𝐮𝐧 𝐩𝐚𝐬𝐨 𝐚𝐭𝐫á𝐬. ⁣⁣
⁣⁣
Dejamos el IDE de lado y nos reunimos todo el equipo, a como después lo llamé “𝐟𝐮𝐥𝐥-𝐭𝐞𝐚𝐦-𝐟𝐮𝐥𝐥-𝐭𝐢𝐦𝐞” por un día y medio, 𝐭𝐨𝐝𝐨𝐬 𝐧𝐮𝐞𝐬𝐭𝐫𝐨𝐬 𝐜𝐞𝐫𝐞𝐛𝐫𝐨𝐬 𝐣𝐮𝐧𝐭𝐨𝐬: 𝘗𝘳𝘰𝘥𝘶𝘤𝘵 𝘔𝘢𝘯𝘢𝘨𝘦𝘳, 𝘗𝘳𝘰𝘥𝘶𝘤𝘵𝘰 𝘋𝘦𝘴𝘪𝘨𝘯𝘦𝘳𝘴 𝘺 𝘱𝘦𝘳𝘴𝘰𝘯𝘢𝘴 𝘥𝘦 𝘐𝘯𝘨𝘦𝘯𝘪𝘦𝘳í𝘢-𝘋𝘦𝘴𝘢𝘳𝘳𝘰𝘭𝘭𝘰 a hacer un discovery acompañado también de una lluvia de ideas. ⁣⁣
⁣⁣
Intentando responder las preguntas ¿𝐡𝐚𝐜𝐢𝐚 𝐝ó𝐧𝐝𝐞 𝐪𝐮𝐞𝐫𝐞𝐦𝐨𝐬 𝐥𝐥𝐞𝐠𝐚𝐫? ¿𝐂𝐮á𝐥𝐞𝐬 𝐬𝐨𝐧 𝐥𝐚𝐬 𝐟𝐫𝐢𝐜𝐜𝐢𝐨𝐧𝐞𝐬 𝐨 𝐩𝐮𝐧𝐭𝐨𝐬 𝐝𝐞 𝐝𝐨𝐥𝐨𝐫 𝐪𝐮𝐞 𝐲𝐚 𝐜𝐨𝐧𝐨𝐜𝐞𝐦𝐨𝐬 𝐝𝐞 𝐧𝐮𝐞𝐬𝐭𝐫𝐨 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐨? ¿𝐐𝐮é 𝐜𝐨𝐬𝐚𝐬 𝐚𝐲𝐮𝐝𝐚𝐫í𝐚𝐧 𝐚 𝐥𝐚𝐬 𝐩𝐞𝐫𝐬𝐨𝐧𝐚𝐬 𝐃𝐞𝐯𝐬 𝐚 𝐮𝐭𝐢𝐥𝐢𝐳𝐚𝐫 𝐦á𝐬 𝐲 𝐦𝐞𝐣𝐨𝐫 𝐧𝐮𝐞𝐬𝐭𝐫𝐚 𝐩𝐥𝐚𝐭𝐚𝐟𝐨𝐫𝐦𝐚? ¿𝐇𝐚𝐜𝐢𝐚 𝐝ó𝐧𝐝𝐞 𝐢𝐦𝐚𝐠𝐢𝐧𝐚𝐦𝐨𝐬 𝐪𝐮𝐞 𝐩𝐨𝐝𝐫í𝐚 𝐜𝐫𝐞𝐜𝐞𝐫 𝐞𝐥 𝐚𝐥𝐜𝐚𝐧𝐜𝐞 𝐝𝐞 𝐧𝐮𝐞𝐬𝐭𝐫𝐨 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐨? Y en ese día y medio, intentamos encontrar esas respuestas para luego bajar al nivel de implementación y plantearnos cómo podíamos hacer para crear soluciones y mejorías para que las respuestas a nuestras preguntas se vieran reflejadas en el “makeover” de nuestra plataforma. ⁣⁣
⁣⁣
𝐓𝐞𝐧𝐢𝐞𝐧𝐝𝐨 𝐮𝐧 𝐦𝐞𝐣𝐨𝐫 𝐞𝐧𝐭𝐞𝐧𝐝𝐢𝐦𝐢𝐞𝐧𝐭𝐨 𝐲 𝐦á𝐬 𝐩𝐫𝐨𝐟𝐮𝐧𝐝𝐨, 𝐝𝐞𝐥 𝐪𝐮é 𝐲 𝐜ó𝐦𝐨, 𝐧𝐨𝐬 𝐚𝐲𝐮𝐝ó 𝐚 𝐚𝐯𝐚𝐧𝐳𝐚𝐫 𝐦𝐞𝐣𝐨𝐫 𝐜𝐨𝐧 𝐥𝐚𝐬 𝐒𝐩𝐞𝐜𝐬, 𝐜𝐨𝐧 𝐦á𝐬 𝐝𝐞𝐭𝐚𝐥𝐥𝐞, 𝐦á𝐬 𝐜𝐨𝐦𝐩𝐥𝐞𝐭𝐚𝐬 𝐲 𝐚 𝐥𝐚 𝐯𝐞𝐳 𝐦á𝐬 𝐠𝐫𝐚𝐧𝐮𝐥𝐚𝐫𝐞𝐬, 𝐟𝐮𝐢𝐦𝐨𝐬 𝐩𝐨𝐫 𝐥𝐨 𝐦á𝐬 𝐩𝐞𝐪𝐮𝐞ñ𝐨, 𝐜𝐚𝐝𝐚 𝐢𝐦𝐩𝐫𝐨𝐯𝐞𝐦𝐞𝐧𝐭, 𝐜𝐚𝐝𝐚 𝐟𝐮𝐧𝐜𝐢𝐨𝐧𝐚𝐥𝐢𝐝𝐚𝐝, 𝐛𝐢𝐞𝐧 𝐩𝐞𝐪𝐮𝐞ñ𝐨 𝐲 𝐝𝐞𝐭𝐚𝐥𝐥𝐚𝐝𝐨, 𝐭𝐚𝐦𝐛𝐢é𝐧 𝐫𝐞𝐜𝐨𝐫𝐝𝐚𝐧𝐝𝐨 𝐪𝐮𝐞 𝐞𝐬 𝐩𝐫𝐢𝐦𝐞𝐫𝐚 𝐯𝐞𝐳 𝐪𝐮𝐞 𝐞𝐬𝐭á𝐛𝐚𝐦𝐨𝐬 𝐜𝐨𝐧𝐨𝐜𝐢𝐞𝐧𝐝𝐨 𝐲 𝐬𝐢𝐠𝐮𝐢𝐞𝐧𝐝𝐨 𝐞𝐬𝐭𝐞 𝐟𝐥𝐮𝐣𝐨 𝐝𝐞 𝐒𝐩𝐞𝐜 𝐃𝐫𝐢𝐯𝐞𝐧 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭. ⁣⁣
⁣⁣
Intentamos hacerlo con “𝘨𝘳𝘦𝘦𝘯 𝘧𝘪𝘦𝘭𝘥” -𝘶𝘯 𝘳𝘦𝘱𝘰 𝘯𝘶𝘦𝘷𝘰, 𝘷𝘢𝘤í𝘰 𝘺 𝘱𝘢𝘳𝘵𝘪𝘳 𝘥𝘦𝘴𝘥𝘦 𝘤𝘦𝘳𝘰, 𝘵𝘪𝘱𝘰 “𝘦𝘯 𝘣𝘭𝘢𝘯𝘤𝘰”- así como también con “𝘣𝘳𝘰𝘸𝘯 𝘧𝘪𝘦𝘭𝘥” -𝘤𝘰𝘯 𝘦𝘭 𝘳𝘦𝘱𝘰 𝘢𝘤𝘵𝘶𝘢𝘭 𝘲𝘶𝘦 𝘺𝘢 𝘵𝘦𝘯í𝘢 𝘯𝘶𝘦𝘴𝘵𝘳𝘰 𝘱𝘳𝘰𝘥𝘶𝘤𝘵𝘰- y con esa experiencia, el explorar cuál era la mejor alternativa, luego de avanzar con el repo nuevo decidimos pivotear al original y trasladar esos avances, ese aprendizaje sobre las Specs hacia el repo original.
⁣⁣
⁣⁣
𝐀𝐩𝐫𝐞𝐧𝐝𝐢𝐦𝐨𝐬 𝐦𝐮𝐜𝐡𝐨, ¿𝐟𝐮𝐞 𝐮𝐧𝐚 𝐬𝐞𝐦𝐚𝐧𝐚 𝐢𝐧𝐭𝐞𝐧𝐬𝐚? 𝐓𝐚𝐦𝐛𝐢é𝐧. Así como todo lo nuevo “incomoda” también compartimos esos aprendizajes y esta “nueva forma de hacer el código” nos llevó a algunas reflexiones: ⁣⁣
⁣⁣
👉 𝐄𝐥 𝐟𝐥𝐮𝐣𝐨 𝐝𝐞 𝐝𝐞𝐬𝐚𝐫𝐫𝐨𝐥𝐥𝐨 𝐪𝐮𝐞 𝐥𝐥𝐞𝐯á𝐛𝐚𝐦𝐨𝐬 𝐜𝐨𝐧 𝐈𝐀 𝐲 𝐕𝐢𝐛𝐞 𝐂𝐨𝐝𝐢𝐧𝐠, 𝐜𝐚𝐦𝐛𝐢𝐚𝐧 𝐭𝐨𝐭𝐚𝐥𝐦𝐞𝐧𝐭𝐞 𝐜𝐨𝐧 𝐒𝐃𝐃⁣⁣
👉Ya no es que tomemos una tarea, que venga con el “qué se espera” desde al área de producto y desde el área de Ingeniería-Desarrollo decidamos o descubramos el cómo, haciendo un ping pong con el agente de IA, pidiendo que haga un análisis de posibilidades, que implemente una solución, que la mejore, la refactorice, haga los test, etc.. 𝐀𝐡𝐨𝐫𝐚 𝐭𝐞𝐧𝐞𝐦𝐨𝐬 𝐪𝐮𝐞 𝐭𝐞𝐧𝐞𝐫 𝐞𝐬𝐨 𝐜𝐥𝐚𝐫𝐨 𝐃𝐄𝐒𝐃𝐄 𝐔𝐍 𝐂𝐎𝐌𝐈𝐄𝐍𝐙𝐎, 𝐭𝐚𝐧𝐭𝐨 𝐥𝐚 𝐯𝐢𝐬𝐢ó𝐧 𝐝𝐞 𝐃𝐢𝐬𝐞ñ𝐨, 𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐨 𝐞 𝐈𝐧𝐠𝐞𝐧𝐢𝐞𝐫í𝐚-𝐃𝐞𝐬𝐚𝐫𝐫𝐨𝐥𝐥𝐨, 𝐚𝐬í 𝐭𝐞𝐧𝐞𝐫 𝐮𝐧𝐚𝐬 𝐒𝐩𝐞𝐜𝐬 𝐬ó𝐥𝐢𝐝𝐚𝐬 𝐲 𝐜𝐨𝐦𝐩𝐥𝐞𝐭𝐚𝐬, 𝐪𝐮𝐞 𝐫𝐞𝐟𝐥𝐞𝐣𝐞𝐧 𝐞𝐬𝐭𝐚 𝐯𝐢𝐬𝐢ó𝐧 𝐝𝐞 𝐟𝐨𝐫𝐦𝐚 𝐭𝐫𝐚𝐧𝐬𝐯𝐞𝐫𝐬𝐚𝐥⁣⁣
👉 ̲𝙽̲̲𝚞̲̲𝚎̲̲𝚜̲̲𝚝̲̲𝚛̲̲𝚘̲ ̲𝚏̲̲𝚕̲̲𝚞̲̲𝚓̲̲𝚘̲ ̲𝚍̲̲𝚎̲ ̲𝚝̲̲𝚛̲̲𝚊̲̲𝚋̲̲𝚊̲̲𝚓̲̲𝚘̲ ̲𝚌̲̲𝚊̲̲𝚖̲̲𝚋̲̲𝚒̲ó, el proceso que llevábamos se cambió por uno diferente⁣⁣
👉 𝐀ú𝐧 𝐬𝐞𝐠𝐮𝐢𝐦𝐨𝐬 𝐚𝐩𝐫𝐞𝐧𝐝𝐢𝐞𝐧𝐝𝐨 𝐲 𝐝𝐞𝐬𝐜𝐮𝐛𝐫𝐢𝐞𝐧𝐝𝐨, el alcance, los límites, las posibilidades, las mejoras de este flujo y también de el Toolkit de GitHub Speckit ⁣⁣
⁣⁣
𝘌𝘯𝘵𝘰𝘯𝘤𝘦𝘴, ¿𝘢𝘩𝘰𝘳𝘢 𝘲𝘶é? 𝐀 𝐬𝐞𝐠𝐮𝐢𝐫 𝐚𝐩𝐫𝐞𝐧𝐝𝐢𝐞𝐧𝐝𝐨 𝐲 𝐜𝐨𝐦𝐩𝐚𝐫𝐭𝐢𝐫 𝐞𝐬𝐭𝐨𝐬 𝐚𝐩𝐫𝐞𝐧𝐝𝐢𝐳𝐚𝐣𝐞𝐬 𝐞𝐧 𝐞𝐥 𝐜𝐚𝐦𝐢𝐧𝐨, ver cuáles son las mejores alternativas y también 𝐞𝐯𝐚𝐥𝐮𝐚𝐫 𝐥𝐨𝐬 𝐫𝐞𝐬𝐮𝐥𝐭𝐚𝐝𝐨𝐬 que este nuevo flujo nos trae a nuestro día a día 🤝⁣⁣
⁣⁣
Así que decidí hacer este post (𝘥𝘦𝘴𝘥𝘦 𝘲𝘶𝘦 𝘩𝘢𝘣𝘭𝘦 𝘥𝘦 𝘈𝘨𝘦𝘯𝘵 𝘚𝘬𝘪𝘭𝘭𝘴 𝘤𝘰𝘯 𝘊𝘭𝘢𝘶𝘥𝘦) cuando hice mención al archivo ̲𝚌̲̲𝚘̲̲𝚗̲̲𝚜̲̲𝚝̲̲𝚒̲̲𝚝̲̲𝚞̲̲𝚝̲̲𝚒̲̲𝚘̲̲𝚗̲.̲𝚖̲̲𝚍̲ donde almacenamos las reglas no negociables de nuestro repo, el que NO debe hacer y el que SI O SI debe hacer -𝘱𝘶𝘴𝘦 𝘶𝘯𝘰𝘴 𝘦𝘫𝘦𝘮𝘱𝘭𝘰𝘴 𝘦𝘯 𝘭𝘢𝘴 𝘴𝘭𝘪𝘥𝘦𝘴- así como también la importancia de este documento y la ventaja que trae: no tienes que recordárselo, cada trozo de código que modifique, mejore o cree será con estas reglas de base, sin que tengas que repetírselo como instrucción en un Prompt una y otra vez. ☝️🤓⁣⁣
⁣⁣
Cuéntame si ya has utilizado o si conocías este flujo y qué cosas te han parecido interesantes 💡✨⁣⁣
También hice este post en instagram con algunos conceptos y pasos del flujo de SDD con Github SpecKit
Les leo! 👀⁣⁣