¿Cuánto proceso debe seguir un solo desarrollador? ¿Es demasiado un proceso formal?

Question

Dado que no hice un buen trabajo escribiendo la última pregunta, y la mayoría de las respuestas fueron buenas, pero no en la dirección en que pretendía que fuera la pregunta, la eliminé y rehice esta pregunta.

Soy un desarrollador solo en mis propios proyectos, generalmente cosas muy pequeñas, pero tengo algunas ideas que pueden convertirse en proyectos de FOSS. Creo en la documentación (en diversos grados, según el proyecto específico y el usuario final), el control de origen y la gestión de proyectos (incluido el seguimiento de fallos, la gestión del tiempo, etc.). Sin embargo, no estoy seguro de la cantidad de formal process que debería seguir.

Quizás basta con guardar un README, los documentos de requisitos/diseño asociados y los comentarios dentro del código bajo el control de la fuente es suficiente. O tal vez hay un proceso ágil que es adecuado para un solo desarrollador a seguir. O tal vez debería tomar un modelo de cascada de la vieja escuela para cada proyecto.

¿Qué tipos de procesos existen o se pueden adoptar para un desarrollador individual, incluso si necesito un proceso formal?

---

EDIT: Me doy cuenta de que hay tareas que estoy haciendo para estar haciendo como documentación y control de fuente. Sin embargo, no estoy seguro de cómo parte de la pregunta. Como desarrollador solo, ¿debería adoptar un enfoque más ágil (en caso afirmativo, qué "rama" de Agile - XP? ¿Scrum? RAD?) O un enfoque más convencional (¿cascada o espiral?)?

Answer 1

Incluso si no necesita proceso para promover una buena comunicación entre los miembros del equipo, el proceso puede ayudarlo a compensar el hecho de que no es tan sobrehumano como pensaba cuando tenía 18 años :) El tipo y cantidad de "papeleo" que decida hacer depende de sus propias fortalezas y debilidades. ¿Mala memoria? Escriba sus diseños y pensamientos diariamente. Bueno viendo árboles pero no bosques? Asegúrese de tener mucho cuidado con sus requisitos y diseños. Bueno viendo bosques pero no árboles? Las listas de tareas detalladas, las estimaciones de tiempo y los resultados frecuentes son su amigo.

Se reduce a: lo que es probable que estropee, y qué procesos ayudan con su forma particular de trabajar.

Answer 2

Sigue a tu corazón.

Answer 3

Recuerda que si bien puedes estar solo ahora, esos proyectos pueden ser lo suficientemente exitosos como para que otros te acompañen. Así que aunque no necesite todas esas cosas extra ahora, eventualmente podría desear tener alguna documentación de diseño e instrucciones para construir cosas, administrar el repositorio de código fuente, etc.

También recuerde que esas "otras personas" pueden ser usted en unos años, cuando haya olvidado todo lo que sabe ahora. (Eres joven, todavía no sabes cuán rápido desaparecen los recuerdos). Piensa en lo que te gustaría grabar para el beneficio de tu ser futuro.

Answer 4

Definitivamente necesita un proceso, hay una gran cantidad de datos sin código que se dedican a la administración y el soporte de un proyecto. Sin un proceso, usted estará sufriendo rápidamente, volviendo a generar ideas de diseño porque olvidó todas esas buenas razones para no hacer algo o para volver a aprender cómo ramificar svn b/c, solo lo hace una vez al mes.

La documentación sobre el diseño, las decisiones de diseño, las operaciones, etc. es vital para cualquier proyecto importante.

Y las pruebas, el control de fuente, etc. son todas buenas prácticas de desarrollo y se deben hacer independientemente del tamaño del proyecto.

Answer 5

Esta es una pregunta muy amplia, pero quizás pueda ayudar compartiendo una experiencia mía. Trabajé durante casi 5 años en un proyecto de codificación de juegos de hobby con un par de amigos míos. Un grupo de desarrolladores muy sólido, usualmente arrastramos nuestras máquinas a un solo departamento durante un fin de semana para desarrollar el proyecto. Mi punto aquí es que podría compararse con un esfuerzo de una sola persona, ya que todos estábamos allí para decidir sobre las decisiones importantes de diseño, y así sucesivamente. '¿Proceso?' No, ninguno lo puedo identificar, incluso en retrospectiva.

Lo único que mantuvo la fuente en control fue seguir un paradigma de 'desarrollo ágil' que decidimos implementar desde el principio: refactor sin piedad. Lo hicimos, y el infierno santo rompió todo el juego todo el tiempo. Pero hizo mantener la fuente limpia, y cuando decidimos ir a 'versiones estables' de vez en cuando, todo parecía suceder.

Answer 6

Haciendo referencia a la página a la que vinculó, digo seguir los procesos. Soy un desarrollador en solitario y sigo estos procesos. No puede escribir software sin conocer sus requisitos y requisitos previos. Como han dicho otros, conozca cómo trabaja y sus puntos débiles & debilidades. Además, a veces se queda atascado & obtener un poco de ayuda exterior. Nadie sabe todo.

Todo el proceso lleva tiempo (a menudo nunca termina) y he matado a demasiadas células cerebrales a lo largo de los años para almacenar cada detalle en mi cabeza. Los mapas mentales, diagramas de flujo y cosas como OneNote son buenos para la memoria no codificada a largo plazo. Trate de mantener la mayor parte de ella en un solo lugar o al menos unida entre sí para que no tenga que tratar de recordar dónde buscarla.