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

Así que tengo un programa en el que trabajé en 2011 y durante todo 2012, pero el último lanzamiento fue en diciembre de 2011 . He estado trabajando activamente en él, pero la característica arrastrada atrajo su cabeza fea y ahora está llena de toneladas de características inacabadas.

Lo malo es que a medida que implemento una característica, aparece una nueva. ¿Qué puedo hacer para evitar la característica en el futuro para poder lanzar una versión en más de un año ?

El proyecto se basa en iOS y solía tener lanzamientos alrededor de cada actualización de versión de iOS, pero la última regresó con 5.1 (2011). Me gustaría poder recuperar ese ciclo de liberación constante, pero ha resultado demasiado difícil.

En mi experiencia, es más fácil si puedes tener una cadencia de desarrollo y lanzamiento que no se interponga en lo que quieres hacer. Así es como lo hice:

1. Anote las características y califíquelas para reflejar cuánto desea trabajar en ellas y cuánto cree que beneficiará al usuario (puede ser posible involucrar a los usuarios reales para esto). Luego escríbelas en ese orden.
2. Antes de registrar / enviar una función, asegúrese de tener una compilación estable y desplegable (tenga en cuenta un sistema de CI para facilitar eso).

De esta manera, puede presionar un lanzamiento después de cada función si lo desea ... o esperar un paquete acumulativo 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, pero no puede interrumpir a la que está trabajando). Puede venir después pero nunca ahora . Eso significa que cuando pases de ahora en adelante, tendrás la oportunidad de cortar una versión de lanzamiento si lo deseas.

La respuesta es trillada y con frecuencia imposible: rechazar agregar características adicionales.

En mayor profundidad, la respuesta realmente se reduce a lo que hace que una nueva característica caiga en el contenedor de desplazamiento de características. Si suponemos que las características que se arrastran son aquellas que se agregan a un proyecto a pesar del hecho de que su funcionalidad es tangencial para el uso previsto del proyecto y que las características de arrastre son útiles, no superfluas, la respuesta es moverlas para separarlas , pero herramientas relacionadas. Use la filosofía de Unix de construir herramientas ortogonales y pegarlas juntas.

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. Estime las características y corte lo suficiente como para cumplir el plazo. Si hay partes interesadas involucradas además de usted, haga que elijan lo que más les importa.

Puede encontrar una buena descripción general de la programación en Joel on Software:

http://www.joelonsoftware.com/articles/fog0000000245.html

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

Lo que generalmente sucede es que un desarrollador agrega características. Eso a su vez inspira más ideas. Entonces se agregan más funciones. Esa es, 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 lanza.

El hábito en el que desea entrar es dejar de pensar en términos de un lanzamiento / versión como un proyecto 'terminado'. Más bien, mire 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, un lanzamiento / versión es solo una instantánea de dónde se encuentra en el proceso a largo plazo ... una instantánea que ha sido bien redondeada y probada.

Lo que puede hacer, en el aspecto práctico, es sentarse y especificar su próximo lanzamiento. No tiene que ser terriblemente minucioso. Anote los nuevos 3-5 principales piezas de funcionalidad usted 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 cambios menores en la interfaz gráfica de usuario ). Si se te ocurren otras ideas, está bien ... solo toma notas e impleméntalas en la siguiente versión. Cuando completes esos 3-5 elementos, tu lanzamiento estará listo para la versión beta.

Cuando inicio 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.

Resumen:

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

Use un sistema de control de versiones en el que sea económico crear una rama para alguna idea, y manténgala fuera de su ruta de lanzamiento. Por ejemplo git, en , puedes "arrastrar" alguna idea y luego git stasheliminarla. Más tarde, puede revisar estos escondites y seleccionarlos en el orden que le parezca interesante.

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

Con los escondites y las ramas, puede hacer un balance de sus ideas, priorizarlas y establecer un alcance para los lanzamientos de su proyecto en solitario, al igual que un proyecto de equipo administrado.

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