Tan solo con romper la toma de decisiones vertical y la mejora iterativa en ciclos cortos, el mensaje que nos deja es enorme (por supuesto, lo mismo aplica a las técnicas/herramientas de gestión de proyectos).
La conclusión de que 'el agile en sí no aportó nuevas perspectivas y se caricaturiza a todos los que lo defienden como fanáticos ciegos del agile' me parece excesiva.
Sí, yo también pensé que quizá habría alguna idea nueva, así que revisé el texto original, pero ¿qué es esto...
En vez de arrancar con cosas básicas como que la memoria es cara y por eso se usa disco, o la estabilidad operativa en producción, o la atomicidad, se ponen de golpe a comparar velocidades, y la verdad da hasta risa.
“Vendemos DB, pero eso no significa que siempre necesites una DB”. No sé si quieren hacer marketing al dejar un artículo así y decir esto con tanta soltura... Aunque intente verlo de forma positiva, a veces me pongo algo cínico.
Lo leí con mucho interés. También lo que escribió en su blog. No sé si la analogía sea del todo adecuada, pero me hace pensar que la razón por la que el primer tutorial de los lenguajes suele ser Hello World!, y el proceso de aprender desarrollo web construyendo un tablero de anuncios y una tienda en línea, al final van por la misma línea que lo que usted plantea. Antes yo pensaba algo así: si uno tiene la técnica suficiente como para construir un tablero de anuncios y una tienda en línea, entonces puede implementar la mayoría de los sitios web. Y, en última instancia, la programación no es más que entrada y salida.
Creo que la conclusión es un poco exagerada. La comercialización o la excesiva formalización pueden ser el problema, pero eso no significa que herramientas como los sprints o el backlog hayan dejado de ser útiles. También ayudaron a que se estableciera una cultura de reuniones más horizontal y centrada en objetivos. Es cierto que SDD se ha vuelto más importante, pero como esa especificación puede redactarse rápido y de forma colaborativa con IA, sigue siendo ágil. Lo único es que el sprint de 2 semanas se acortó a unas cuantas horas; la esencia de iterar y pulir repetidamente me parece que sigue siendo la misma.
Es un texto bastante tonto. La clave es que la spec. misma debe escribirse de forma ágil... Agile se trata de adaptarse rápidamente a los cambios en los requisitos del cliente.
Es por personas que tienen este tipo de malentendidos y fantasías superficiales sobre Agile que tanto Agile como la cultura de desarrollo terminan yéndose por mal camino.
Según algunos criterios, hoy en día todos son ágiles. No sé si antes hubo una época en la que se desplegara tan rápido y se recibiera retroalimentación como ahora.
Como no es que nunca haya que leer código, desde esa perspectiva parece válida la idea de que el código está por encima de la documentación; y como la documentación, en tanto conjunto de instrucciones, debe ser leída por el LLM que realiza la implementación, desde ese punto de vista también estoy de acuerdo. Por eso, mi conclusión es que al final ambos son importantes al mismo tiempo.
Ahora mismo, el problema de los productos creados con LLM es la deuda que se va acumulando en la etapa de operación. Para un funcionamiento continuo, los desarrolladores tienen que involucrarse con el código, y para que eso sea posible, creo que por ahora el código todavía debe poder sustituir a la documentación.
No es que libhwp fuera la razón decisiva, sino que el problema era más bien ese grupo basura. No hay sujeto en la frase; si te enojas al leerlo, eso es cosa tuya.
¡Este artículo en sí no es ágil!
Coincido.
Tan solo con romper la toma de decisiones vertical y la mejora iterativa en ciclos cortos, el mensaje que nos deja es enorme (por supuesto, lo mismo aplica a las técnicas/herramientas de gestión de proyectos).
La conclusión de que 'el agile en sí no aportó nuevas perspectivas y se caricaturiza a todos los que lo defienden como fanáticos ciegos del agile' me parece excesiva.
Ojalá que codex también soporte tokens OAuth como Claude.
Sí, yo también pensé que quizá habría alguna idea nueva, así que revisé el texto original, pero ¿qué es esto...
En vez de arrancar con cosas básicas como que la memoria es cara y por eso se usa disco, o la estabilidad operativa en producción, o la atomicidad, se ponen de golpe a comparar velocidades, y la verdad da hasta risa.
“Vendemos DB, pero eso no significa que siempre necesites una DB”. No sé si quieren hacer marketing al dejar un artículo así y decir esto con tanta soltura... Aunque intente verlo de forma positiva, a veces me pongo algo cínico.
Supongo que al menos nos quedó un benchmark.
Lo leí con mucho interés. También lo que escribió en su blog. No sé si la analogía sea del todo adecuada, pero me hace pensar que la razón por la que el primer tutorial de los lenguajes suele ser
Hello World!, y el proceso de aprender desarrollo web construyendo un tablero de anuncios y una tienda en línea, al final van por la misma línea que lo que usted plantea. Antes yo pensaba algo así: si uno tiene la técnica suficiente como para construir un tablero de anuncios y una tienda en línea, entonces puede implementar la mayoría de los sitios web. Y, en última instancia, la programación no es más que entrada y salida.Creo que la conclusión es un poco exagerada. La comercialización o la excesiva formalización pueden ser el problema, pero eso no significa que herramientas como los sprints o el backlog hayan dejado de ser útiles. También ayudaron a que se estableciera una cultura de reuniones más horizontal y centrada en objetivos. Es cierto que SDD se ha vuelto más importante, pero como esa especificación puede redactarse rápido y de forma colaborativa con IA, sigue siendo ágil. Lo único es que el sprint de 2 semanas se acortó a unas cuantas horas; la esencia de iterar y pulir repetidamente me parece que sigue siendo la misma.
Es un texto bastante tonto. La clave es que la
spec.misma debe escribirse de forma ágil... Agile se trata de adaptarse rápidamente a los cambios en los requisitos del cliente.Es por personas que tienen este tipo de malentendidos y fantasías superficiales sobre Agile que tanto Agile como la cultura de desarrollo terminan yéndose por mal camino.
¿Qué demonios es esta estupidez? ¿Creen que la base de datos se usa por rendimiento?
Parece que el enlace está apuntando por error al dominio
.comEste es el enlace al aviso relacionado
[Aviso] 04/16 (jue) Ocurrió un problema de acceso al servicio ▶ Resuelto
Se puede vivir sin refrigerador, pero sería incómodo.
No hay razón para no usarlo si puedes hacerlo.
Así es, no es Apache 2.0.
¡¡Gracias!!
Esto tiene una licencia distinta a la de
gemma4, que es el original.Terriblemente, parece ser lo que veo con más frecuencia...
Vaya, cuando lo vi en 2020 no había muchas bibliotecas que pudieran manejar HWP, pero últimamente han aumentado de forma explosiva.
Qué lástima que otra vez sea solo para macOS... T_T Tengo muchos servidores sin usar, pero todos están basados en Linux...
Según algunos criterios, hoy en día todos son ágiles. No sé si antes hubo una época en la que se desplegara tan rápido y se recibiera retroalimentación como ahora.
Increíble, wow
Como no es que nunca haya que leer código, desde esa perspectiva parece válida la idea de que el código está por encima de la documentación; y como la documentación, en tanto conjunto de instrucciones, debe ser leída por el LLM que realiza la implementación, desde ese punto de vista también estoy de acuerdo. Por eso, mi conclusión es que al final ambos son importantes al mismo tiempo.
Ahora mismo, el problema de los productos creados con LLM es la deuda que se va acumulando en la etapa de operación. Para un funcionamiento continuo, los desarrolladores tienen que involucrarse con el código, y para que eso sea posible, creo que por ahora el código todavía debe poder sustituir a la documentación.
No es que
libhwpfuera la razón decisiva, sino que el problema era más bien ese grupo basura. No hay sujeto en la frase; si te enojas al leerlo, eso es cosa tuya.