2009-06-12 51 views
13

Después de aprender sobre el control de código fuente, lo primero que hice fue hacer un proyecto con svn. Después de aprender sobre git, lo usé en un proyecto personal. Después de aprender sobre UML/Patrones de diseño/Principios de diseño/TDD, los apliqué a un proyecto personal. ¿Cómo puedo hacer lo mismo con el desarrollo ágil? ¿Es ágil solo para equipos y grandes proyectos? ¿Cómo configuro estas iteraciones?¿Cómo aplicar ágil a proyectos personales?

Respuesta

16

Creo que Agile definitivamente no es solo para proyectos de equipo. Agile defiende un conjunto de valores que se aplican igualmente bien a muchos tipos de proyectos, incluso personales. Estuve exactamente en su situación hace un tiempo, tratando de aplicar el desarrollo ágil a un proyecto universitario personal, y aprendí mucho en el proceso. Algunas cosas útiles que la mentalidad ágil que puede dar incluyen:

  • trabajo en cosas que aporta un valor añadido al producto final. Haga una acumulación de funciones y priorícelas como si fuera el cliente. Luego, cuídate de ti mismo para trabajar en funciones basadas en su valor para el producto en lugar de lo que quieres hacer en este momento. Esto podría salvarlo de una gran cantidad de código innecesario y sobre diseñado que no usará. Si tienes una fecha límite, es incluso más importante.

  • Ten un diseño evolutivo: comienza con Lo más simple que podría funcionar y refactorizar sin piedad.

  • Posponga las decisiones hasta el último momento responsable.

  • Timebox en sprints o iteraciones (MUY importante en proyectos universitarios).

  • ...

Si usted se pasa de algunas de las metodologías ágiles de nuevo, creo que encontrará un montón de valores y prácticas que se puede aplicar por sí mismo.

Mientras escribía esta respuesta, aparecieron al menos otras 3 respuestas y me gané. Estoy de acuerdo con todos ellos. :)

+0

Con qué proyecto universitario has probado esto. Me gustaría hacer esto en mi proyecto de 4to año con puede ser entre (8 ti 16 meses). – kthakore

+1

El mío era mucho más pequeño, solo un par de meses. Creo que para proyectos más largos sería más valioso. Una buena cosa que puede hacer es conseguir que alguien juegue como cliente, y proporcionarles una "demo de lanzamiento" cada mes o dos; eso lo forzaría a entrar en una mentalidad sensata y de valor para el cliente, y tendrá una pronta respuesta. Tal vez pueda hacer que otro alumno juegue como cliente para usted y le devuelva el favor; en última instancia, ambos se beneficiarán de ello. – Avish

+0

¡Bonita idea! Además, ¿qué significa posponer las decisiones hasta el último momento razonable? ¿Eso es hasta el final de los sprints? – kthakore

0

Por ejemplo, no tenga miedo de refactorizar su propio código, incluso si funciona, si el resultado es más flexible y robusto.

+0

¿Entonces refactor en las iteraciones? o desarrollo algunas características primero, luego repito y luego continúo? – kthakore

+0

Unidad prueba tu código. * Entonces * toma el consejo y el refactor de kmarsh. A menudo, el cálculo para una tarjeta en particular se da para tener en cuenta el tiempo necesario para refactorizar el área de código que toca la nueva característica. – JeffH

2

Es realmente difícil aplicar la codificación ágil a proyectos individuales porque muchos de sus beneficios están dirigidos a equipos pequeños en los que puede colaborar rápidamente en áreas enfocadas.

Dicho esto, se puede adoptar algunas de las técnicas:

  • lanzamiento menudo
  • enfoque en las necesidades de los usuarios
  • dude desviarse de los principales planes de versión - que puede cambiar de dirección cada vez que se siente la necesidad
  • Pase menos tiempo configurando los principales frameworks y obtenga algo trabajando tan pronto como sea posible. A continuación, vuelva y refactorice para cumplir sus necesidades originales (si aún se aplican)
+0

Muchos de los desarrolladores de solo probablemente sigan una técnica ágil de todos modos ya que no tienen la carga de otras personas dependiendo de la estructura de sus códigos que tengan el mismo aspecto de un día para otro. La mayor diferencia es al comienzo de un proyecto. Todavía necesita planear cosas, pero obtener * algo * que funcione CUANTO ANTES tiene más enfoque que otras metodologías (es decir, cascada) – Oli

3

Haga una lista de las tareas y características que desee en su aplicación. Toma esas tareas y ponlas en card wall.

No puedes tener una reunión por tu cuenta, pero a la mañana decidir qué harás por el día y qué hiciste con éxito ayer. Toma esas tareas, hazlas y luego pasa a la siguiente. Asegúrese de que en cada punto esté entregando continuamente software integrado que funcione y actualice su acumulación de trabajo. Es posible que tengas "días de errores de fallas" donde solo corrijas errores. Eso sería un scrum de un solo hombre. :)

+0

es la metodología para crear las tarjetas para las historias? TDD? ¿Dónde se hace el diseño y la arquitectura? – kthakore

+1

Para un proyecto de una sola persona, diría Feature Driven. El diseño se realiza después de saber qué función está creando. –

1

Es posible utilizar Scrum para proyectos one man.

  • Crear atraso
  • momento óptimo para un sprint de medio día es

Viernes crear plan para la próxima semana y cada media burndowns de actualización para cada día proyectos.

0

algunas reflexiones sobre esta

:
  • Las iteraciones son tan largas como desee que sean
  • IPM son todavía posibles en el que elegir lo que quieres hacer durante ese período de tiempo
  • Las demos al final siguen siendo útiles para ver la funcionalidad de trabajo de una manera un tanto profesional en lugar de su pequeña área de depuración que puede no ser tan limpia u ordenada
  • Las retrospectivas son útiles para ver qué funciona y qué no para ti en un punto donde puedes ver e el bosque para los árboles en cierto sentido

Es bastante posible ser ágil en un proyecto personal individual, IMO.

0

Todos los consejos aquí son buenos, pero hay un aspecto importante de Agile que generalmente no se menciona: la supervisión.

Agile le pide que eche un vistazo a lo que ha hecho, a lo que está haciendo, a dónde se dirige y, si es necesario, realice las correcciones correspondientes.

Creo que las tablas Visibles y Burndown/Burnup son tan útiles, escribí un programa, Task Analytics, para hacer estos gráficos fácilmente. Es perfecto para proyectos pequeños o de un solo hombre.

Buena suerte.

+0

Proyecto bonito. ... No uso Outlook ... lo siento. Se ve bien, aunque voy a construir algo similar y espero que sea de código abierto para otras personas. – kthakore

2

Aparte del desarrollo de pares, puede hacer el resto de las prácticas si está dispuesto a desempeñar múltiples roles. Si tiene a alguien que esté dispuesto a trabajar con usted, también puede hacer el desarrollo en pareja.

Primero crearía una acumulación de producto. Esta sería una lista priorizada de características o fichas que desea desarrollar. Ninguna carta debe ser más grande que el trabajo que puede completar en una sola iteración o sprint. Si tus sprints son de una semana o dos, eso determinará el tamaño de las características o las fichas en tu cartera de pedidos de productos priorizados. Como propietario del producto, puede cambiar la prioridad de la acumulación de productos para cada iteración. De la acumulación de productos, puede crear sus planes de iteración y lanzamiento.

Dado que está desempeñando múltiples roles, deberá dejar tiempo para que usted cree la tarjeta de la historia. La tarjeta de historia debe esbozar la GUI, describir los flujos de trabajo primarios y secundarios y, lo más importante, tener criterios de aceptación.

Una vez que haya firmado la tarjeta de historia escrita, puede comenzar el desarrollo en la tarjeta. Utilizaría TDD (desarrollo impulsado por prueba) para escribir primero la prueba, luego el código. Deberías repetir hasta que la tarjeta esté lista.Los criterios de aceptación lo ayudarían a decidir qué pruebas unitarias escribir.

Una vez que haya finalizado el desarrollo de la tarjeta, deberá escribir las pruebas funcionales automatizadas. Puede usar Quick Test Pro, FIT, Cucumber o alguna otra herramienta favorita de prueba unitaria automatizada. Me mantendría alejado de las funciones de reproducir y grabar, ya que eso puede acelerar el trabajo en el futuro a medida que se refactoriza.

Una vez que la unidad de prueba se ha completado y los pases de tarjetas, se puede añadir a todos los demás prueba de funcionamiento automatizado y se puede ejecutar por lo menos diariamente, si no en cada registro de entrada.

Al final de la iteración y antes de mover su software en funcionamiento a la producción, puede realizar las Pruebas de aceptación del usuario.

Como desarrollador debe utilizar la integración continua, las compilaciones automáticas se iniciaron con cada uno de los controles frecuentes en su sistema de control de código fuente.

Después de que se haya escrito la historia y antes de desarrollar las tarjetas para la iteración, puede enmascararlas (es decir, proporcionar estimaciones para cada una de las tareas necesarias para desarrollar la tarjeta). Puede determinar si se puede completar alguna refactorización dentro de su presupuesto o si necesita crear una nueva tarjeta de historia que capture la deuda técnica que identificó.

Como puede ver, puede llevar a un equipo ágil de un solo miembro muy lejos. Dado que las prácticas de gestión ágil ayudan a la colaboración e identifican lo que es importante, también puede beneficiarse de esas prácticas. Dado que las prácticas de ingeniería (XP) permiten que el código permanezca saludable y, por lo tanto, sea compatible con el ritmo sostenible, el código seguirá siendo flexible, contará con una unidad sólida y un arnés de prueba automatizado funcional y le permitirá continuar el desarrollo a un ritmo sostenible indefinidamente.

Cuestiones relacionadas