Es vital mantener una lista clara de sus objetivos. Es fácil para las funciones que se apoderen de un proyecto autogestionado. El enfoque "ya está hecho cuando funciona" de TDD también es útil. Esto evita que te conviertas en un perfeccionista.

Una cosa que realmente me ayuda es imaginar lo que diría otro ingeniero o un gerente de proyecto en cualquier situación dada. A menudo soy capaz de "avergonzarme" de un código incorrecto, o volver a encarrilarme si el calendario se está deslizando.

Aquí tienes ... enlace

XP se reduce muy bien ya que es óptimo para equipos pequeños enfocados.

• Puede crear una hoja de cálculo de solicitudes de funciones, priorizarlas & elige la que está más arriba.
• defina los criterios de aceptación (qué aspecto tiene) y codifíquelo en una prueba ejecutable
• A continuación, defina las tareas de ingeniería para terminar
• Escriba pruebas unitarias, haga la cosa más simple (YAGNI) y refactorice todo el tiempo. El objetivo es hacer que la prueba de aceptación externa pase
• Timebox cada sesión. Para una gestión del tiempo eficaz, también puede consultar la técnica Pomodoro .
• Usa control de versiones & Configure un servidor CI / un archivo de proceso por lotes para crear una instalación o un zip de su software
• Demo con frecuencia. Envíe los comentarios a la hoja de cálculo original y vuelva a priorizar

Lo único que no puedes hacer en un equipo de uno es PairProgramming.

Si estás trabajando solo. Aquí están los consejos:

1. Haz el menor trabajo de bajo nivel posible. Use toda la biblioteca y las herramientas que pueda, incluidas las cosas que cree que puede codificar (no lo haga, solo use la biblioteca).
2. Tome el enfoque de arriba hacia abajo. Solo codifique las cosas que realmente necesita.
3. Cuando vea un problema en términos abstractos, busque en Google y utilice documentos de investigación de la comunidad académica que ya se ha demostrado. Solo necesitas codificar su algoritmo.
4. Diseñe su sistema para que pueda cambiar las cosas libremente tanto como sea posible. (Incluyendo copiar y pegar algún código de aquí para allá). El propósito es ahorrarle tiempo cuando se da cuenta de que cometió un error. Trate de minimizar la cantidad de trabajo que tiene que desechar cuando comete un error. Un fragmento de código que debe desecharse (en lugar de copiar y pegar de aquí para allá) es la equivalencia de tiempo que perdió al escribir ese código.
5. Tenga muchas pruebas automatizadas para que pueda hacer pruebas de regresión cada vez que realice un cambio
6. Separe las responsabilidades de su diseño (es decir, reduzca el acoplamiento). Haga las cosas lo más modulares posible
7. Use un depurador para depurar y use la búsqueda binaria para encontrar el defecto.
8. Refactorice constantemente su código para reducir el acoplamiento (explícito) y la exposición de los métodos públicos (acoplamiento implícito).
9. Nada realmente. Esto está aquí solo en caso de que se me ocurra algo nuevo: P

Revisiones de código.

Esto es particularmente útil ya que le explicarás el código a alguien que no haya trabajado en el mismo proyecto para que no tengan ninguna de tus suposiciones sobre cómo debería funcionar.

También tendrán el beneficio adicional de compartir el conocimiento en la empresa, de modo que cuando alguien más tenga que trabajar en el proyecto (debido a que la gente está ocupada en otro lugar, enferma, ha renunciado o ha sido despedida) no tendrá que hacerlo. empezar de cero.

En mi empresa, nuestro grupo trabaja en el mismo proyecto, pero en partes relativamente independientes. Una cosa que hacemos mucho por aquí es cuando algo que estás haciendo parece un poco complicado, o estás en una bifurcación en el camino con más de una forma de implementar algo, atrapas a alguien más y hablas de los pros y los contras antes usted proceda Si espera hasta que considere que su código ha terminado para hacer una revisión, generalmente ya ha invertido demasiado tiempo para considerar cambios arquitectónicos importantes, aunque en las revisiones de código se descubren muchos defectos.

También, me doy cuenta de que el desarrollo de Test Driven es una pequeña palabra de moda saturada últimamente, pero puede ser de gran ayuda para los desarrolladores en solitario porque proporciona un control de calidad sobre la marcha, y cuando las pruebas se vuelven difíciles de escribir, sabes que probablemente necesites algo Reestructuración de su código. También ayuda a los mantenedores posteriores a no romper accidentalmente el código en formas difíciles de detectar.

Presenté mi propia versión de Agile que se basa en historias, una gran interacción con el cliente, lanzamientos frecuentes y desarrollo basado en pruebas. Utilizo un wiki para rastrear historias, involucrar al cliente tanto como sea posible en la redacción de las mismas, y hacer que el cliente trabaje conmigo para priorizar y organizar los lanzamientos. Yo uso TDD para impulsar el diseño y la implementación. Configuro un servidor de control de calidad en el que el cliente puede probar lanzamientos frecuentes (a veces diariamente a medida que se desarrollan nuevas funciones) para recibir comentarios rápidamente. Rara vez hago más de 3 iteraciones sin un lanzamiento a QA. El cliente tiene que decidir cuándo la versión de control de calidad tiene suficientes funciones para funcionar, y si no es necesario desarrollar más funciones de la lista.

Te sugiero lo siguiente:

1. Desarrollo dirigido por pruebas
2. Eavy usa "TODO: anota aquí" en tu código cuando veas algo que no puedes hacer de inmediato, y regresa a ellos cuando tengas tiempo para quedarte en Facebook esperando que el cliente te devuelva la llamada
3. Escriba su código ya que su cliente lo comprará mirando el código, no solo por el resultado, imagine a su cliente como presidente para una revisión del código.
4. Rellene su código de afirmaciones

Ojalá pudiera decir que pude practicar lo que predico el 100% del tiempo, pero el BDD parece ser un buen enfoque para su situación:

Aquí hay un enlace con más información: enlace

Estoy en un barco muy similar. Intento seguir los principios ágiles (en la medida en que los entiendo) tanto como sea posible. Probablemente no estoy haciendo las cosas "correctamente", pero he tenido un gran éxito en mis proyectos al tratar de seguir principios ágiles. Se necesita una gran cantidad de disciplina, ya que no hay un equipo para asegurarse de que no solo comience a tomar atajos.

Encuentro que el uso de herramientas de formato de código como ReSharper garantiza que, al menos visualmente, el código sea fácil de recoger para otros desarrolladores.

En términos de metodologías reales, es difícil para un solo desarrollador mantener una en particular. Soy un consultor que generalmente trabaja solo, y me parece más fácil para mí y para el cliente usar un proceso ágil. Normalmente intento que mis clientes ingresen directamente sus requisitos en una herramienta como Trac (o lo haré, en su nombre). ¡Esto no solo ayuda a otros desarrolladores a identificar el propósito del código, sino también a usted mismo 3 meses después de la línea!

filosofía: XP / TDD + GTD

esquema general:

• entrevistar a las partes interesadas
• maquetas de pantalla, tutoriales, prototipos de papel (según sea necesario)
• lluvia de ideas de características / historias (con y sin partes interesadas)
• lluvia de ideas de casos de prueba (con y sin partes interesadas)
• tiempo de reflexión general de diseño / arquitectura (según sea necesario)
• planificación de iteración (con partes interesadas)
• iteraciones
• revisión de procesos, capacitación, planificación de mantenimiento, etc. (según sea necesario)

Cualquier metodología apropiada ayudará, independientemente del número de personas en el proyecto. Así que elija uno a la vez y vea cómo puede aplicar y mapear su dominio, y mida sus éxitos.

Quizás lo más interesante es preguntar qué metodologías no se deben desechar porque solo hay 1 persona trabajando en el proyecto.

Y la clave que me llama la atención es Source Control (Sí, eso es una herramienta, pero es parte de su flujo de trabajo, también un proceso). La gente podría estar tentada a dar este paso porque "no necesitan admitir a varias personas que editan el código al mismo tiempo".

Irónicamente, encuentro que una solución de control de versiones de distribución como GIT es mejor para un individuo que algo como SVN.

Si es un código desechable, podría ser un poco flexible con metodologías, pero cualquier cosa importante y diría que su forma de tratarlo como un proyecto de equipo con una persona es muy agradable y disciplinado.

Escribe tu código para que lo lea el siguiente chico, no tú ... sé amable con él. Incluso el código de "tirar" permanece para siempre.

Agile

las características, historias y casos de prueba son mucho más instructivos que la documentación más formal, y un conjunto de pruebas de trabajo es mejor para demostrar cómo usar algo o cómo funciona algo que cualquier cantidad de árboles muertos

También es más fácil repartir el trabajo entre iteraciones.

Como consultor, yo sugeriría que encuentre la manera de que siempre haya al menos dos desarrolladores en cualquier tarea.

Estoy de acuerdo en ser ágil, y en dejar un rastro ágil de historias y pruebas que otros puedan seguir, pero no creo que ningún otro proceso o metodología se mantendrá mientras la gente esté trabajando en solitario.

Creo que las revisiones de Código son un buen comienzo, pero me gusta cuando se hace informal y divertido, como hacer una revisión de código de Par o una programación de par para abordar un determinado problema o alguna mejora (por ejemplo, cambiar el código heredado para cumplir nuevos estándares de codificación). A veces, dos pares de ojos son mejores que uno y también es divertido, siento que compartir y discutir parece más abierto. También podría tener como almuerzo formal / informal y discutir sesiones para hablar sobre lo que hizo individualmente o en grupo, por ejemplo. ¿Menciona sobre un nuevo patrón que usó o nuevas tecnologías cómo se resolvió un problema?