About me: I have been working in startups since 2004. I spent 10 years at Apontador/MapLink and was part of Creditas (fintech last valued at $4.8bi) from its early days. Initially, as an Advisor, I hired the first software engineers for Creditas. As the business developed, I joined the project full-time as VP. I scaled the technology team to 150 people and later led international expansion and new product initiatives. I left in 2022 and, after a sabbatical, started working as an independent consultant in 2023.
Un ejemplo real de estándares claros
|
Un lector de la newsletter y amigo de hace muchos años, Renato Viço, me envió una muy buena respuesta sobre el texto de estándares claros y consistencia (compartida con permiso). Antes que nada, vale reforzar: las buenas prácticas siguen vigentes, y quizá son aún más importantes ahora. Aquí va su respuesta, íntegra: Creo que un punto que podría aportar a la discusión es que lo básico necesita estar muy bien hecho: una suite de tests funcional y un CI/CD con pipeline corriendo correctamente. Sigo algo similar aquí, además de la documentación que mencionaste.
Hoy mantengo una carpeta de documentos estructurada con features, integraciones, archivos base, assets y especificaciones técnicas de módulos complejos. Como utilizamos Copilot Enterprise, cada repositorio tiene configuraciones específicas y "memories" compartidas entre todo el equipo. También aplico configuraciones a nivel enterprise para garantizar prácticas como código modular en todo el equipo.
El punto más importante ha sido reforzar que las especificaciones y las unidades deben escribirse antes de la funcionalidad, utilizando escenarios de Cucumber/Gherkin (soy adepto del BDD). Con esto, las funcionalidades suelen “auto-generarse” a partir de comandos simples, manteniendo la consistencia entre todos los desarrolladores.
Con el CI configurado, al subir una especificación ocurre un auto-review vía Copilot. Si se detectan problemas o “flakes”, un agente basado en Claude actúa en la corrección. Para coordinar todo esto, tanto localmente como en el CI, utilizo Tidewave.ai.
Me pareció un excelente ejemplo de cómo estándares, tests y automatización empiezan a trabajar juntos. No solo como soporte, sino como parte activa del desarrollo. Si tienes prácticas similares o diferentes que estén funcionando en tu equipo, respóndeme a este correo. Leo todas las respuestas y puedo compartirlas aquí con los demás lectores. |
Leo Andreucci - CTO Mentor
About me: I have been working in startups since 2004. I spent 10 years at Apontador/MapLink and was part of Creditas (fintech last valued at $4.8bi) from its early days. Initially, as an Advisor, I hired the first software engineers for Creditas. As the business developed, I joined the project full-time as VP. I scaled the technology team to 150 people and later led international expansion and new product initiatives. I left in 2022 and, after a sabbatical, started working as an independent consultant in 2023.
Leitor da newsletter e amigo de longa data Renato Viço me mandou uma resposta muito boa sobre o texto de padrões claros e consistência (compartilhado com permissão) Antes de qualquer coisa, vale reforçar: as boas práticas continuam valendo, e talvez sejam ainda mais importantes agora. Aqui vai a resposta dele, na íntegra: Acredito que um ponto que poderia agregar à discussão é que o básico precisa estar muito bem feito: uma suíte de testes funcional e um CI/CD com pipeline rodando...
En el texto anterior, comenté que las especificaciones empiezan a ganar espacio como fuente de la verdad.Pero eso aún puede parecer abstracto. En la práctica, esto empieza a aparecer en algo bastante simple: archivos que describen cómo tu equipo construye software. Cosas como: README guías de código decisiones de arquitectura patrones de organización del sistema instrucciones sobre cómo contribuir Y, más recientemente, esto también aparece en formatos como: constitutions system prompts skills...
No texto anterior, falei que especificações começam a ganhar espaço como fonte da verdade. Mas isso ainda pode parecer abstrato. Na prática, isso começa a aparecer em algo bem simples: arquivos que descrevem como o seu time constrói software. Coisas como: README guidelines de código decisões de arquitetura padrões de organização do sistema instruções de como contribuir E, mais recentemente, isso também aparece em formatos como: constitutions system prompts skills e playbooks para agentes O...