¿Cómo evito el avance de características en un proyecto individual?

En mi experiencia, es más fácil si puedes tener un desarrollo y una cadencia de lanzamiento que no interfiera con lo que quieres hacer. Así es como lo he hecho:

1. Anote las funciones y asigne una calificación que refleje cuánto desea trabajar en ellas y cuánto cree que beneficiará al usuario (puede ser posible involucrar a usuarios reales para esto). Luego escríbelos en ese orden.
2. Antes de registrar / presionar una función, asegúrese de tener una compilación estable e implementable (considere seriamente un sistema CI para facilitar eso).

De esta manera, puede presionar un lanzamiento después de cada función si desea ... o esperar un resumen que ofrezca el valor que desea que tenga un lanzamiento.

Nota:

• A una función nunca se le puede dar una prioridad más alta que la que está trabajando (o puede hacerlo, pero no puede interrumpir la función en la que está trabajando). Puede venir siguiente pero nunca ahora . Eso significa que cuando pase de ahora al siguiente, tendrá la oportunidad de cortar una versión de lanzamiento si lo desea.

La respuesta es trivial y, con frecuencia, imposible: rehusarse a agregar funciones adicionales.

Con más profundidad, la respuesta realmente se reduce a lo que hace que una nueva característica caiga en el contenedor de arrastre de características. Si asumimos que las características que se arrastran son aquellas que se agregan a un proyecto a pesar del hecho de que su funcionalidad es solo tangencial al uso previsto del proyecto y que las características de arrastramiento son útiles, no superfluas, la respuesta es moverlas a partes separadas. , pero las herramientas relacionadas. Utilice la filosofía de Unix de construir herramientas ortogonales y unirlas.

Desde el punto de vista de la gestión de proyectos, la respuesta es comparable. Decida cuánto tiempo está dispuesto a dedicar a la próxima versión y establezca una fecha límite. Estimar las características y cortar lo suficiente para hacer la fecha límite. Si hay partes interesadas involucradas además de usted, hágales elegir lo que más les importa.

Se puede encontrar una buena descripción general de Programación en Joel en Software:

enlace

Una de las lecciones más importantes en el desarrollo es saber cuándo es el momento de detenerse.

Lo que suele suceder es que un desarrollador agrega funciones. Eso a su vez inspira más ideas. Así que se añaden más características. Es decir, como dijiste, una de las formas en que un proyecto se convierte en vaporware. El desarrollador nunca ve el proyecto como "terminado", por lo que nunca se libera.

El hábito en el que quieres entrar es dejar de pensar en términos de un lanzamiento / versión como un proyecto 'terminado'. Más bien, mira el desarrollo como un proceso a largo plazo. Piense en los lanzamientos como hitos en el camino hacia lo que algún día espera que sea el programa. Por lo tanto, una versión / lanzamiento es solo una instantánea de donde se encuentra en el proceso a largo plazo ... una instantánea que se ha completado y probado.

Lo que puede hacer, en el lado práctico, es sentarse y especificar su próxima versión. No tiene que ser terriblemente minucioso. Escriba las 3-5 nuevas funciones de major que cree que son esenciales para la próxima versión. ( el número real de funciones puede variar según el tipo de aplicación, sin contar las correcciones de errores o los cambios menores en la interfaz gráfica de usuario ). Trabaja en ellas. Si se te ocurren otras ideas, eso está bien ... solo toma notas e implementalas en la siguiente versión. Cuando termines esos 3-5 elementos, tu lanzamiento estará listo para la versión beta.

Cuando comienzo una nueva aplicación, normalmente pienso en la 'visión' final de la aplicación. Eso, para mí, es lo que quiero en la versión 3 de la aplicación. Con ese punto de referencia, tengo una idea de lo que hará que la versión 1 sea sólida: solo lo básico.

Summary:

Cada versión no tiene que ser la 'visión' finalizada del proyecto. Solo un hito hacia esa visión.

Use un sistema de control de versiones en el que sea barato crear una rama para una idea y manténgalo fuera de su ruta de lanzamiento. Por ejemplo, en git , puede "crear" alguna idea y luego git stash desaparecer. Más tarde, puede revisar estos alijos y seleccionarlos en el orden que le parezca interesante.

Para funciones más grandes, cree una rama real (para que pueda hacer múltiples confirmaciones). Caso en cuestión: cuando quise agregar apoyo generacional al recolector de basura, hice una rama. Los alijos capturan muy bien las pequeñas cosas que distraen. Las funciones grandes pueden comenzar como escondites, luego convertirse en ramas y finalmente fusionarse cuando estén listas.

Con escondites y sucursales, puede hacer un balance de sus ideas, priorizarlas y establecer un alcance para los lanzamientos de su proyecto en solitario, como un proyecto de equipo administrado.

Mira, cuando tienes una idea, tiene que ir a algún lugar , y el mejor es el código : el repositorio. Las características progresivas son mejores que olvidar las buenas ideas. Pero, por supuesto, si arrastra todas sus funciones a la misma línea principal, seguirá demorando el lanzamiento, a menos que corte los lanzamientos desordenados llenos de cosas a medio hacer que los usuarios no deben usar.