documentation - tareas - slack create list

¿Cuáles son algunos consejos y procesos de administración de proyectos para un equipo de un solo desarrollador? (10)

Creo que todavía puedes seguir algunas prácticas ágiles, aunque podrías doblegar las reglas un poco, pero en realidad no creo que eso importe. Si sus proyectos son lo suficientemente pequeños, tal vez seguir procesos similares a los de Scrum le ayuden. Mantenga un retraso en las prioridades y divida su trabajo en sprints. No creo que necesariamente tenga reuniones consigo mismo :-), pero los conceptos de mantenerse enfocado en objetivos prioritarios durante un período de tiempo determinado valdrían la pena.

También puedes seguir las prácticas de desarrollo basadas en pruebas.

Por lo general, tengo algún proyecto que puedo hacer solo, que demora entre 6 meses y 1 año. Siempre intento tener una fecha de "lanzamiento" y escribir algunos documentos (externos al código).

Mi pregunta es, ¿qué tipo de gestión utilizas cuando no tienes un equipo contigo pero estás solo?

Por ejemplo, estaba pensando en la Programación Ágil PERO no estoy seguro de si realmente puedes decir que eres Ágil cuando estás solo. ¿Que usas?

Después de haber estado en una posición similar durante años, baso mi enfoque en cómo estoy facturando el proyecto: basado en proyectos o tiempo / materiales.

Si hago una facturación basada en proyectos , entonces tiendo a ser un poco más formal. Lo que significa que mi contrato establece las principales características del proyecto, así como las posibles limitaciones, etc. Lo reviso en detalle antes de firmar, luego se convierte en mi modelo.

Permito cambios en el camino, pero también los hago un poco más formales con formularios de solicitud de cambio firmados que describen el cambio y los costos del proyecto modificado.

En un contrato de 6 meses a 1 año, puedo mostrar el progreso aproximadamente una vez cada 3 a 4 semanas; o en desarrollos de hitos en los que hago facturación incremental. Esto es probablemente más cercano a ser un enfoque de cascada que cualquier otra cosa.

Si estoy facturando por tiempo y materiales , tiendo a ser mucho más flexible y tengo mucha más comunicación con el cliente. Es posible que esté mostrando algo nuevo todos los días, o al menos, una vez a la semana. Básicamente intento mostrar el resultado de cada tarea que termino. El tipo de clientes que desean facturar por hora tiende a preferir este formato. Esto tiende a estar más cerca de un enfoque ágil.

Al final del día solo tienes que ir con lo que funciona mejor en tu situación.

Esto es lo que hice la última vez que tuve una tarea como esta:

Desarrollo iterativo donde cada iteración fue de dos semanas.
El jueves de la semana 2, me aseguraría de tener un sistema de trabajo integrado y listo para conversar con el cliente (es cierto, con solo algunas de las funciones completas).
El viernes de la semana 2, revisaría el sistema con el cliente (con una demostración si fuera necesario), presentaría una lista de características completadas, características planificadas, cambios en mi plan y capturaría cualquier variación de requisitos (descubierta, modificada, lo que sea) desde la última discusión.
Todo esto fue capturado en una hoja de cálculo que enumera las características individuales, mi fecha de finalización planificada (en no más de 2 semanas de granularidad), prioridad y estado (no iniciada, iniciada o completa).

Me gusta este tipo de proceso porque:

Es una ceremonia muy baja (para mí o para el cliente) y podría implementarse sin costosos paquetes de planificación de proyectos.
El cliente vio un sistema que era mensurablemente mejor que la última iteración cada dos semanas.
Sabía exactamente en qué se suponía que debía trabajar.
Sabía exactamente lo que había hecho hasta ahora.
El cliente tenía puntos de entrada incorporados en los que podía cambiar prioridades, refinar requisitos, descubrir nuevos, etc.
Incluso si el cliente o yo nos desviamos por completo de un cambio de requisitos, solo tuvimos dos semanas de vulnerabilidad (es decir, solo podíamos equivocarnos tanto antes de solucionar el problema).
Me quedé con un proceso personal refinado que podría llevar conmigo a mi próximo trabajo.

Por cierto, este proceso personal se inspiró en el capítulo de Peter Coad sobre el desarrollo impulsado por características en Java Modeling In Color With UML .

Para proyectos como ese, he usado más de un estilo de lista de verificación para la administración, lo que quiero hacer y cuándo. Recomiendo utilizar buenas prácticas de desarrollo, como control de fuente y seguimiento de problemas, incluso con un desarrollador.

He tomado demasiados proyectos que comenzaron con un desarrollador, pero el proyecto creció y ahora es necesario que haya dos o tres desarrolladores trabajando en el proyecto. Siempre es difícil hacer la transición, más aún cuando hay una lista de verificación básica, control de versiones y seguimiento de problemas.

También puede usar algún tipo de sistema de notificación de tareas (por ejemplo, MS Outlook) para que cree un agente externo que le notifique acerca de un scrum diario, progreso de la tarea, etc. Le da la ilusión de un equipo; solo el resto de ellos son abrir cuadros de mensaje y alertas de ding!

Una gran parte de Agile se trata de comunicación en el equipo, por lo que no podrías seguir eso a menos que te vuelvas loco y comiences a hablarte a ti mismo :)

Por otro lado, Agile se trata de procesos adecuados y cierta mentalidad, y esta parte podría y debería usarse en su proyecto, incluso si está solo.

Dedicar algún tiempo a la organización y configuración correctas definitivamente lo ayudará. Y luego, cuando considere agregar a alguien más y trabajar en equipo, la transición será mucho más fluida. Lo mismo aplica para pasar su trabajo a otra persona para apoyo y mantenimiento.

Supongo que estás haciendo este proyecto para un usuario final. Aquí hay una lista de lo que probablemente estarían buscando y cómo puede satisfacer esas necesidades.

Lista de nuevas características u otros cambios: una narrativa simple que describe estos cambios que se le entregaron con algún tipo de aprobación formal o informal
Un protocolo básico para el proyecto que incluye administración de cambios, gestión de hitos, cuándo pueden comenzar a ver partes del código, lista de entregas (código, documentación, lista de errores conocidos en el producto final, etc.)
enfoque de desarrollo - Personalmente, me gustaría hacer algo entre ágil y cascada, donde hay algunos hitos intermedios que contienen algún subconjunto de funcionalidad cada X semanas. Esto también debe incluir la administración del código fuente, enfoque de prueba de unidad, estrategia de QA (qué plataformas, pruebas especializadas como seguridad, usabilidad, rendimiento, etc., qué es ''aceptable'' en términos de resultados de prueba)

Si estás haciendo esto por ti mismo, entonces solo la última viñeta de arriba es realmente necesaria. Sin embargo, si no presta atención a las dos primeras balas, puede terminar nunca terminando o no entregando un sistema coherente.

Mi consejo:

No olvide las prácticas básicas de SCM. << Obtenga un BUEN sistema de control de revisiones (Subversion, Git (?)). Un buen sistema de SCC te ahorrará mucho tiempo. Crea archivos de compilación No haga una implementación manual de Compile-Copy. Pruebe la integración continua (CruiseControl? /CruiseControl.NET?). Cuanto más automatice el trabajo de seguimiento de los cambios y la creación de su software, mejor será la utilización que obtendrá de su propio tiempo.

Cuando el proyecto es personal, no tengo ninguna guía. Si es para otra persona, trato de ir con la iteración para obtener algunos comentarios de los usuarios. Me gusta tener iteraciones de 2 semanas.

La diferencia es con la documentación que tiendo a escribir menos, pero yo también estoy atrás con Unit Testing porque estoy solo y es la forma de "protegerme".

Puedes probar esto: la tesis de mi maestría - Metodología de programación de vaqueros Me asusta publicar mi tesis aquí, pero bueno ...

Básicamente, analicé este problema exacto con mi tesis: cómo los equipos de desarrolladores individuales usan prácticas y métodos ágiles para producir un buen software.

Ah, y comienza a leer el capítulo 4: los primeros tres son bastante cojos (para las personas que leen este blog).