Blog

El significado y origen de la "deuda técnica" La metáfora de la deuda técnica (TD) en el contexto del software fue acuñada por Ward Cunningham, quien en ese momento estaba trabajando en la codificación de un sistema financiero. Usó la metáfora para explicar a sus colegas financieros el razonamiento para refactorizar y reescribir partes de códigos a medida que evolucionaba el conocimiento de los requisitos. "Al tomar atajos y entregar código que no es del todo adecuado para la tarea de programación del momento, un equipo de desarrollo incurre en TD. Esta deuda disminuye la productividad. Esta pérdida de productividad es el interés del TD". La explicación original de Ward era bastante [...]

A continuación se ofrecen algunas ideas sobre el valor de encontrar defectos en los requisitos antes del diseño o la codificación. Para un equipo de desarrollo de software es muy valioso encontrar defectos tempranamente. Aún mejor es evitar los defectos por completo. Los requisitos excelentes son una forma eficaz de prevención de defectos y prevención de retrabajo. Un requisito ambiguo puede dar lugar a un esfuerzo desperdiciado sustancial. Los defectos surgen antes de que comience la codificación Los defectos surgen en los requisitos y la arquitectura incluso antes de que comience la codificación. Imaginemos que estamos en un negocio de seguros y los empresarios han decidido que un sistema nuevo (o modificado) [...]

División de la historia: refinamiento hasta una granularidad óptima Una historia aparentemente pequeña puede resultar mucho más grande de lo esperado. Sólo mediante el refinamiento o la división de la historia se puede descubrir esto. La división de la historia se puede realizar temprano o justo antes del sprint anterior. Recomendamos hacerlo lo antes posible para evitar sorpresas tardías. Consideramos que la "división de la historia" y el "refinamiento de la historia" son actividades muy similares. Se trata de optimizar la granularidad de la historia de usuario escrita. ¿Qué son las historias de usuario? Para aquellos equipos que pueden ubicarse, la historia de usuario puede ser solo un recordatorio de una conversación. [...]

La obtención de requisitos consiste en descubrir los requisitos reales del negocio y los requisitos del sistema de cualquier proyecto de software. Se trata primero de descubrir lo que se necesita y luego de articular los descubrimientos destilados en artefactos que puedan usarse como base para describir lo que se necesita hacer. Es inusual que los requisitos reales del negocio (y los requisitos subsiguientes del sistema) puedan encontrarse rápidamente. Aunque a veces se hace referencia a la obtención de requisitos como a recopilación de requisitos, esta es una frase engañosa. Los requisitos reales se parecen más a un tesoro enterrado en un campo que a cultivos que se pueden cosechar. A veces una indicación de [...]

Veamos cómo y por qué podríamos querer garantizar la calidad de las historias de los usuarios. Las malas historias de usuarios conducen a reuniones innecesarias, desperdicio y retrabajo. Mejorar la historia del usuario lo antes posible en el ciclo de vida de desarrollo es una forma eficaz de minimizar el desperdicio y el retrabajo. El aseguramiento de la calidad es un enfoque sistemático para determinar si un "producto" cumple con criterios aceptables. Para el control de calidad de las historias de usuarios, primero debemos definir qué es lo bueno. ¿Cuál es la diferencia entre una buena historia de usuario (y un conjunto de historias de usuario) y una mala calidad? Para el desarrollo ágil de software tendemos a [...]