Paso mucho tiempo trabajando en proyectos en los que soy el único desarrollador, gerente de proyecto, diseñador, persona de QT (Sí, lo sé ... ¡Mal!), Y a veces incluso soy el cliente.

He intentado casi todo para planificar proyectos y administrarme, desde solo sentarme y trabajar en estilo libre hasta que el proyecto esté terminado por el tiempo que sea necesario, hasta una versión de scrum para una sola persona en la que realicé una reunión de progreso conmigo mismo durante una -Hombre quemar tabla cada mañana (no es broma).

Para aquellos de ustedes que pasan mucho tiempo trabajando solos, ¿cuál es la mejor manera de organizarse, administrar proyectos grandes (para una persona) y mantener la productividad lo más alta posible?

Mantener una lista clara de sus objetivos es vital. Es fácil para el arrastramiento de funciones hacerse cargo de un proyecto autogestionado. El enfoque TDD "se hace cuando funciona" también es útil. Esto te impide convertirte 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. A menudo soy capaz de "avergonzarme" a causa de un código incorrecto, o volver a la pista si el horario se está acabando.

Aquí tienes ... http://xp.c2.com/ExtremeProgrammingForOne.html

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 y elegir la más alta.
• definir los criterios de aceptación (cómo se ve) y codificarlo en una prueba ejecutable
• A continuación, defina las tareas de ingeniería para realizar
• Escriba pruebas unitarias, haga lo más simple (YAGNI) y refactorice todo el tiempo. El objetivo es hacer pasar la prueba de aceptación externa
• Timebox cada sesión. Para una gestión eficaz del tiempo, también puede observar la técnica de Pomodoro .
• Utilice el control de versiones y configure un servidor CI / un archivo por lotes para crear una instalación o zip de su software
• Demo con frecuencia. Dirija los comentarios a la hoja de cálculo original y vuelva a priorizar

Lo único que no podría hacer en un equipo de uno es la programación de pares.

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

1. Haga el menor trabajo posible de bajo nivel. Use tanta biblioteca y herramientas como sea posible, incluidas las cosas que cree que puede codificar fácilmente (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 use trabajos de investigación de la comunidad académica que ya se ha probado. Solo necesita codificar su algoritmo.
4. Diseñe su sistema para que pueda cambiar libremente las cosas tanto como sea posible. (incluyendo copiar y pegar algún código de aquí para allá). El propósito es ahorrarle tiempo cuando se dé cuenta de que cometió un error. Intente minimizar la cantidad de trabajo que tiene que tirar cuando comete un error. Un código que debe desecharse (en lugar de copiar y pegar aquí y allá) es la equivalencia de tiempo que perdió escribiendo ese código.
5. Realice muchas pruebas automáticas para que pueda realizar pruebas de regresión cada vez que realice un cambio.
6. Separe las responsabilidades de su diseño (es decir, reduzca el acoplamiento). Hacer las cosas lo más modular posible
7. Use un depurador para depurar y use la búsqueda binaria para encontrar defectos.
8. Refactorice constantemente su código para reducir el acoplamiento (explícito) y la exposición a métodos públicos (acoplamiento implícito).
9. Nada en realidad. Esto está aquí por si acaso puedo llegar a algo nuevo: P

Revisiones de código.

Estos son particularmente útiles ya que explicará el código a alguien que no ha trabajado en el mismo proyecto para que no tenga ninguna de sus suposiciones sobre cómo debería funcionar.

También tendrán el beneficio adicional de compartir el conocimiento de la empresa, por lo que cuando alguien más tenga que trabajar en el proyecto (debido a que las personas están ocupadas en otro lugar, enfermas, renunciaron o fueron despedidas) no tendrán que comenzar desde cero .

Lancé mi propia versión de Agile que se basa en historias, interacción intensa con el cliente, lanzamientos frecuentes y desarrollo basado en pruebas. Utilizo un wiki para rastrear historias, involucrar al cliente lo más posible al escribirlas y hacer que el cliente trabaje conmigo para priorizar y organizar los lanzamientos. Yo uso TDD para conducir el diseño y la implementación. Configuré un servidor de control de calidad donde el cliente puede probar lanzamientos frecuentes (a veces diariamente a medida que se desarrollan nuevas funciones) para que pueda recibir comentarios rápidamente. Raramente hago más de 3 iteraciones sin un lanzamiento a QA. El cliente puede decidir cuándo la versión de control de calidad tiene suficientes características para activarse, y si no es necesario desarrollar más funciones de la lista.

En mi empresa, nuestro grupo trabaja en el mismo proyecto, pero en partes relativamente independientes del mismo. 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, agarras a alguien más y discutes los pros y los contras antes tu procedes. Si espera hasta que considere que su código terminó para hacer una revisión, generalmente ya ha invertido demasiado tiempo para considerar cambios arquitectónicos importantes, aunque ciertamente se descubren muchos defectos en las revisiones de código.

Además, me doy cuenta de que Test Driven Development está un poco saturado últimamente, pero puede ser de gran ayuda para los desarrolladores en solitario porque proporciona un control de calidad a medida que avanzas, y cuando las pruebas se vuelven difíciles de escribir, sabes que probablemente necesites un poco de reestructuración código. También ayuda a los mantenedores posteriores a no romper accidentalmente el código en formas difíciles de detectar.

Te sugiero lo siguiente:

1. Desarrollo guiado por pruebas
2. Siempre use "TODO: tenga en cuenta aquí" en su código cuando vea algo que no puede hacer de inmediato, y vuelva a ellos cuando tenga tiempo para permanecer en Facebook esperando que su cliente le devuelva la llamada
3. Escriba su código ya que su cliente lo comprará mirando el código, no solo el resultado, imagine a su cliente como presidente de una revisión de código.
4. Rellene su código de afirmaciones

Me gustaría poder decir que pude practicar lo que predico el 100% del tiempo, pero BDD parece ser un buen enfoque para tomar en su situación:

Aquí hay un enlace con más información: http://en.wikipedia.org/wiki/Behavior_driven_development

Estoy en un bote muy similar. Intento seguir los principios ágiles (así como 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.

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

En términos de metodologías reales, es difícil que un solo desarrollador se quede con una en particular. Soy un consultor que generalmente trabaja solo y me resulta más fácil para mí y para el cliente utilizar un proceso ágil. Normalmente trato de hacer 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 ti mismo 3 meses más adelante!

filosofía: XP / TDD + GTD

bosquejo general:

• entrevistar a los interesados
• maquetas de pantalla, tutoriales, prototipos en papel (según sea necesario)
• lluvia de ideas / reportajes (con y sin partes interesadas)
• lluvia de ideas en casos de prueba (con y sin partes interesadas)
• tiempo total de diseño / arquitectura (según sea necesario)
• planificación de iteraciones (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 de la cantidad de personas en el proyecto. Elija uno a la vez y vea cómo puede aplicar y asignar a su dominio, y medir sus éxitos.

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

Y la clave que se destaca para mí es el control de código fuente (sí, esa es una herramienta, pero es parte de su flujo de trabajo, también un proceso). Es posible que las personas se sientan tentadas a dar este pase ya que "no necesitan admitir que varias personas editen 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 una persona que algo como SVN.

Si es desechable, el código podría ser un poco flojo con las 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 el siguiente chico que lea, no tú ... sé amable con él / ella. Incluso el código de "descartar" permanece para siempre.

Ágil

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 entregar el trabajo entre iteraciones.

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

Estoy de acuerdo con ser ágil y dejar un rastro ágil de historias y pruebas que otros puedan seguir, pero no creo que ni ningún otro proceso o metodología se mantenga mientras las personas trabajan en solitario.

Creo que las revisiones de código son un buen comienzo, pero me gusta cuando es informal y divertido, como hacer una revisión de código de par o programar un par para abordar un determinado problema / problema o alguna mejora (por ejemplo, cambiar el código heredado para cumplir con los 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 un almuerzo formal / informal y discutir sesiones para hablar sobre lo que hizo individualmente o en grupo, por ejemplo, mencionar un nuevo patrón que utilizó o las nuevas tecnologías ¿cómo se resolvió un problema?