¿Puede un profesional independiente usar el desarrollo ágil?

... Aparte de la programación de pares, claro. ;-)

En serio, también soy freelancer y uso técnicas ágiles tanto como puedo. Me funciona muy bien. Hago un gran uso de TDD,

Nadie en ningún lugar usa el 100% de XP o Scrum, pero todos usan partes de él, tratando de adoptar tanto como funciona para ellos. En mi opinión, cuanto más adoptes, mejor estarás.

Lo que más extraño es la programación en pares. La forma en que superas eso es

1. Vaya a muchas reuniones de grupos de usuarios.
2. Encuentra un par de personas a quienes tú respeto como desarrolladores.
3. Pídales que se reúnan con usted en un café o algo para escribir codigo Darles parte de su salario por hora ocasionalmente si sientes que es necesario o simplemente responder en especie a trabajando en su código.
4. Asista o cree un Hack Club como este: enlace .

Aquí hay algunos recursos que utilizo:

• Programación extrema - en línea Guía rápida pero completa a través de XP.
• Un excelente resumen de Scrum .
• Libro fantástico y breve . Perfecto para ti!

Por lo tanto, diría que hay tres "puntos impresionantes" principales para usar Agile como freelancer:

1. Para clientes más grandes, Trabajo / factura en iteraciones. Al final de la iteración, el cliente puede continuar trabajando en el proyecto o finalizar el proyecto (es decir, ha logrado su objetivo). Sé (por experiencia) que no puedo estimar más de unas pocas semanas, y el pago por iteración también mantiene el flujo de efectivo. No es divertido estar en el mes 6 de un proyecto de 3 meses, y esperar para finalizar el proyecto para que pueda ...

2. Agile significa que el cambio ocurre. He hecho un montón de proyectos de licitación fija (que crees que puedes hacer con la cascada) que me han perdido dinero, debido a una solicitud de un cliente a mitad del ciclo. El cambio se produce: el cliente puede dar una prioridad al boleto para que se realice otro trabajo más rápido, o tal vez se haya equivocado y no se haya hecho todo lo que esperaba.

3. Buenas herramientas de colaboración con el cliente. Mi estimación estándar (para algo más pequeño que el trabajo de una iteración) es en realidad una serie de pasos de desarrollo impulsados por el comportamiento derivados de las expectativas del cliente. Le envío esto al cliente y le digo "¿Es correcto?". Se asegura de que todos estén en la misma página.

4. Lo más simple que podría funcionar. Es algo que debes tener en cuenta mientras trabajas: no tengas miedo de volver al cliente y decir: "Esto sería mucho más simple (o más poderoso, o lo que sea) si lo hiciéramos de esta manera ... "

5. Scrum es importante. Me gusta enviar a mis clientes un correo electrónico todos los días que trabajo en su proyecto. Esto es como mi scrum para ellos: "en qué trabajé hoy", "qué / cuándo voy a trabajar en su proyecto a continuación", "¿Hay algo en mi camino?" Y "En general, ¿cómo va el progreso? ? "

6. El desarrollo basado en pruebas también es realmente útil, incluso como un solo programador. Mis "estimaciones con historias BDD en ellas" me ayudan a alimentar este proceso.

Una excelente manera de comenzar su viaje Agile es configurar su flujo de trabajo utilizando un sistema KANBAN.

Simplemente tenemos 3 swimlanes:

1. Nuestro TO-DO's o Backlog
2. En qué estamos trabajando o EN PROGRESO
3. Cosas que completamos o HACEMOS.

Este simple flujo de trabajo Agile es una excelente manera de comenzar.

En términos de codificación, recomendaría el uso de desarrollo basado en pruebas (TDD). Incluimos muchos enlaces geniales que describen TDD en nuestro artículo, pero los volveremos a copiar aquí:

Para obtener más información, consulte los siguientes recursos:

• AgileData.org : un excelente recurso para el desarrollo basado en pruebas.
• JamesShore.com : otro gran desglose para TDD
• Net Tuts : ¡una introducción divertida a TDD que me gusta!
• Artima - Entrevista con Martin Fowler
• Games From Within - Un buen estudio de caso de TDD
• DaniWeb - Introducción a TDD para desarrolladores
• Mark Levison - Artículo sobre TDD

Dado que eres un individuo, es mejor que consideres las metodologías ágiles como algo que está ahí para ayudarte a desarrollar lo que mejor funciona para tú . Están allí para ayudarlo a alcanzar la meseta de "no hay cuchara", pero cómo depende exactamente de usted depende de usted y lo que se le ocurra al final se superpondrá con algunas metodologías en varios niveles, pero Será algo completamente tuyo.

Desde que intentas encontrar tu propio camino haciendo cosas para mejorar tu efectividad general, aquí hay algunos consejos que pueden ayudarte, al menos, a no cometer los mismos errores que yo:

Renuncie a todas las soluciones de software dirigidas exclusivamente a metodologías ágiles, durante el tiempo que pueda.

El hecho de que sean más adecuados para facilitar la colaboración en equipo no viene al caso. Resistir la tentación. No te encierras en una manera de hacer las cosas y luego esperas que la adopción salga bien. No lo hace, simplemente te frustra. Primero encuentra tu manera de hacer las cosas y luego busca una solución de software adecuada. Terminé usando pizarras blancas (comenzó con una, pero ahora tengo dos en mi habitación) para rastrear / desarrollar historias y la Técnica Pomodoro | To Do Today para realizar un seguimiento de mis tareas de desarrollo y está en 2011. Manténgase en lo básico hasta que obtengamos algunas interfaces como las de Iron Man 2 o los autos voladores comienzan a aparecer.

Reflexión, reflexión, reflexión

Esto fue lo que entendí como la parte más importante de cualquier metodología para un individuo. Se trata de desarrollar este flujo de trabajo que le brinda una visión holística de su proyecto para que pueda hacer un seguimiento de lo que se debe hacer y cuándo es fácil de manejar y donde las decisiones equivocadas rara vez se toman y se destacan para que se puedan corregir rápidamente. antes de que causen daño ... pero no puedes retirarlo del estante. Comience desde cualquier lugar, en cualquier lugar. Te quedas con ella mientras funcione. Invertir en el seguimiento de lo bueno, lo malo y así sucesivamente. Mejora tus suposiciones, luego ajusta la forma en que haces las cosas en consecuencia. Esa es la única forma en que vas a mejorar.

Olvídese de los plazos, céntrese en la rapidez con la que hace las cosas

Probablemente era como el siguiente tipo cuando comencé, buscando citas. ¿Gráficos de agotamiento? Solía pensar en ellos como una forma de visualizar mi trayectoria de desarrollo en comparación con los plazos. Es un rendimiento, no un modelo de estimación. Hay tiempo para medir su efectividad al reflexionar sobre el trabajo que ha realizado dentro de un cierto período de tiempo, no solo un valor estúpido para representar la distancia antes de impedir los plazos. La realidad es que las cosas se hacen cuando están listas y su metodología debería tenerlo en cuenta.

Desviarse en consecuencia

Al final, ¿quién dice que tienes que usar historias de usuario o cualquier cosa que sepamos para esa materia? No pienses así. Si te sientes más cómodo pensando en las características, entonces desafía a la comunidad de desarrollo global y hazlo a tu manera, porque al final del día lo único que importa es hacer las cosas. Si terminas sintiendo que estás haciendo algo mal, felicidades, acabas de llegar a la conclusión de que es hora de saltar a otra cosa. Se trata de lo que es, no de cómo.

Yo respondería "¿cómo quieres mejorar la forma en que desarrollas el software?". Para su modelo de negocio, ¿cuáles son los problemas más grandes que ha encontrado al utilizar la metodología de cascada?

¿Su objetivo es un desarrollo más rápido, un código más robusto, una mayor reutilización, cumplimiento / adaptación a los requisitos cambiantes, etc.? Existen diferentes metodologías para superar diferentes problemas.

Por supuesto, adoptar una metodología de diseño que no sea Waterfall puede ser muy útil para administrar de manera efectiva el ciclo de vida de un proyecto en función de los requisitos de su negocio. Para el desarrollo ágil hay una gran cantidad de recursos en línea. Me gustaría ver AUP (Proceso Agile Unified) que incorpora TDD (Test Driven Development). Esto puede ser extremadamente útil al construir / administrar grandes sistemas escalables.

No existe una metodología 'talla única', y esta es la razón principal de la gran cantidad de enfoques diferentes. Comenzaría a pensar en dónde cree que se encuentran actualmente los cuellos de botella en su proceso de desarrollo y luego trataré de adoptar una nueva metodología para superar esto.

Por ejemplo, ¿a menudo no cumple con los plazos? ¿Las nuevas características introducen una gran cantidad de errores? ¿Los nuevos requerimientos causan una reurbanización importante? ¿El negocio requiere sistemas de trabajo regulares para ser presentado? Consulte: Agile , Iterative y Agile Intro .