Metodologías del ciclo de vida del software para equipos de un solo hombre [cerrado]

Estoy creando un sistema de software para mi proyecto de maestría y estaba buscando asesoramiento sobre metodologías particulares que se adapten a un "equipo de un solo hombre" ...

Me gano la vida como un "arma de software de alquiler" de un solo hombre que trabaja principalmente desde casa, así que me muero por escuchar lo que otras personas tienen que decir sobre esto.

Aquí hay algunas cosas que he encontrado importantes:

• Como dice Denis, el control de la fuente es vital, pero SVN no es la única opción. Principalmente uso Perforce, y git es una buena alternativa. Me gusta un modelo de desarrollo "mainline"; eso me permite hacer experimentos en ramas de código, fusionarlos en la línea principal cuando funcionan y desecharlos si no lo hacen.
• Utilizo un cuaderno para notas y un programa para el seguimiento de tareas. Actualmente uso Redmine para este último; antes de eso, usé Fogbugz. También me gusta Redmine porque tiene un wiki incorporado muy bueno, que puedo usar para notas persistentes y enlaces a sitios importantes.
• También es vital hacer un seguimiento de lo que estoy haciendo, y establecer algún tipo de límites razonables para que pueda hacer lo suficiente sin quemarme, ver a continuación.

Mis otras técnicas han evolucionado a lo largo de los años y las modifico según el proyecto y el cliente. La gente me paga por el código de trabajo, no perder el tiempo con el proceso, por lo que trato de mantener el proceso ligero y fuera de la cara de mis clientes. Pero creo que algunas técnicas ágiles funcionan muy bien para mí:

• Uno de mis clientes actuales tiende a soltar grandes funciones sobre mí para implementar, y no me molesta hasta que terminan. Así que creo que trabajar en esos en Scrum sprints es genial. Supongo que eso puede funcionar para un proyecto de maestría a menos que su asesor de investigación sea un fanático del control.
• Mi otro cliente actual tiende a tener más emergencias de un tipo de "deja de trabajar en esto y arregla ese". Intenté hacer eso con Scrum y me di por vencido después de un sprint. Así que estoy haciendo eso usando Kanban, y funciona mucho mejor.

El otro problema de trabajar por su cuenta es que no tiene a nadie que le diga qué hacer o cuándo, o si está haciendo lo suficiente, o cuándo dejar el trabajo porque ha hecho lo suficiente, por lo que debe hacerlo eso por ti mismo. Personalmente, prefiero Scrum porque puedo hacer un seguimiento de cómo me va con respecto a mis objetivos de sprint. Para los proyectos de Kanban, puedo hacer un seguimiento de la cantidad de tiempo que dedico, pero no me gusta tanto como algo más basado en objetivos.

Algunos amigos míos juran por Pomodoro como una forma de mantenerlos enfocados en las tareas y rastrear la eficiencia personal, y estoy pensando en probarlo.

También tengo un proceso formal para liberar código a mis clientes para asegurarme de que lo que están obteniendo es "correcto", pero eso probablemente esté fuera del alcance de lo que están preguntando.

Use SVN por encima de lo demás, versione todo. Para el seguimiento, el cuaderno lo hará para proyectos más simples, si es necesario, tiene muchas aplicaciones gratuitas de seguimiento de tareas / errores (Redmine es genial). Ágil / XP / Integración continua / otros sería un poco exagerado en mi opinión.

Aparte del proceso de software personal , no he encontrado mucho sobre los modelos de procesos formales diseñados para ser utilizados por un solo desarrollador. El PSP es bastante pesado en la documentación y el papeleo (en su forma cruda, de todos modos), sin mucho que decir sobre técnicas particulares para realizar el trabajo (en cambio, el PSP se centra en la recopilación de datos para encontrar áreas para mejorar), pero es un comienzo punto para desarrollar un proceso personal que pueda usar en proyectos pequeños a medianos.

Creo que el mejor curso de acción sería simplemente seguir algunas de las mejores prácticas ampliamente aceptadas (basadas en sus necesidades y el proyecto) ampliamente aceptadas de una serie de modelos de proceso. Eche un vistazo a los métodos para rastrear el trabajo realizado / el trabajo restante, la gestión de requisitos, el control de versiones, las pruebas (particularmente las pruebas de unidad y aceptación), la integración continua, los estándares de codificación, No lo necesitará, etc. Si no lo ha hecho, le sugiero leer Code Complete y The Pragmatic Programmer y practicar sus consejos.

Lo más importante de trabajar individualmente es que, aparte de las restricciones que te imponen las fuerzas externas, todo depende de ti. No necesita acomodar a nadie más que trabaje junto a usted, por lo que es más fácil elegir técnicas que le permitan trabajar de la manera más eficiente posible. Con los años, probablemente haya descubierto cómo trabaja mejor, por lo que sería un buen punto de partida. Luego aplique las "mejores prácticas" conocidas además de eso para mejorar sus habilidades y técnicas.

El tipo pregunta acerca de metodologías específicas y la gente responde "usar software X / Y". NO es una cuestión de herramientas, en realidad hay muchas metodologías y parece que todavía no hay un informe de validación para ellas: ágil, iterativo, espiral, cascada, XP, modelo V, TDD.