¿Puede un profesional independiente utilizar el desarrollo ágil?

Quiero mejorar la forma en que desarrollo el software. ¡Quiero desarrollar más rápido y un gran código! Hoy uso el método de cascada como freelance, escribiendo cosas web (sitios, sistemas, etc.). ¿Hay alguna manera de usar el desarrollo ágil (XP, SCRUM, etc.) trabajando de esta manera? No sé nada sobre desarrollo ágil, ¿por dónde debería comenzar? Muchas gracias.

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

En serio, también soy un profesional independiente y uso técnicas ágiles tanto como puedo. A mí me funciona muy bien. Hago un gran uso de TDD,

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

Lo que más me falta es la programación de pares. La forma en que superas eso es

1. Ir a muchas reuniones de grupos de usuarios.
2. Encuentra un par de personas a las que respetes como desarrolladores.
3. Pídales que se reúnan con usted para tomar un café o algo para escribir el código. Otorgue ocasionalmente parte de su salario por hora si considera que es necesario o simplemente responde en especie para trabajar en su código.
4. Asista o cree un Hack Club como este: http://www.DallasHackClub.org .

Aquí hay algunos recursos que uso:

• Programación extrema : una guía rápida pero exhaustiva en línea a través de XP.
• Una gran descripción de Scrum .
• Fantástico y breve libro . ¡Perfecto para ti!

Entonces diría que hay tres "puntos increíbles" principales para usar Agile como profesional independiente:

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: logró su objetivo). Sé (por experiencia) que no puedo estimar bien más de unas pocas semanas, y el pago por iteración también mantiene el flujo de efectivo entrando. No es divertido estar en el mes 6 de un proyecto de 3 meses y esperar para terminar el proyecto para que puedas bil ...

2. Ágil significa que el cambio ocurre. He realizado una tonelada de proyectos de oferta fija (que cree que puede hacer con cascada) que me han perdido dinero, debido a una solicitud del cliente en la mitad del ciclo. El cambio ocurre: el cliente puede desestabilizar un boleto para realizar algún otro trabajo más rápido, o tal vez usted tiró mal y no hizo 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 Conducido por el Comportamiento derivados de las expectativas del cliente. Le envío esto al cliente y le digo "¿Es esto correcto?". Se asegura de que todos estén en la misma página.

4. La cosa más simple que podría funcionar. Es algo a tener en cuenta mientras trabaja: no tenga 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 un correo electrónico a mis clientes 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 después?", "¿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 programador único. Mis "estimaciones con historias de BDD en ellas" me ayudan a alimentar este proceso.

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

Simplemente tenemos 3 carriles:

1. Nuestras tareas pendientes o atrasados
2. En qué estamos trabajando o EN CURSO
3. Cosas que completamos o HECHOS.

Este simple flujo de trabajo ágil es una excelente manera de comenzar.

En términos de codificación, recomendaría usar el desarrollo basado en pruebas (TDD). Incluimos muchos enlaces excelentes 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 gran recurso para el desarrollo basado en pruebas.
• JamesShore.com - Otro gran desglose de TDD
• Net Tuts - ¡Una divertida introducción a TDD que me gusta!
• Artima - Entrevista con Martin Fowler
• Juegos desde dentro : un buen caso de estudio de TDD
• DaniWeb - Introducción a TDD para desarrolladores
• Mark Levison - Artículo sobre TDD

Como eres un individuo, es mejor que abordes las metodologías ágiles como algo que está ahí para ayudarte a descubrir qué funciona mejor para ti . Están allí para ayudarlo a alcanzar esa meseta de "no hay cuchara", pero cómo exactamente va a suceder eso depende totalmente de usted y lo que se le ocurra al final se superpondrá en gran medida con algunas metodologías en varios niveles, sin embargo Será algo completamente tuyo.

Dado que está tratando de encontrar su propia manera de hacer cosas para mejorar su efectividad general, aquí hay algunos consejos que pueden ayudarlo al menos a no cometer los mismos errores que cometí:

Olvídese de todas las soluciones de software dirigidas exclusivamente a metodologías ágiles, durante el mayor tiempo posible.

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 encajonas de una manera de hacer las cosas y luego esperas que adoptarlo funcione de la mejor manera. No lo hace, solo te frustra. Primero encuentra su manera de hacer las cosas y luego busca una solución de software adecuada. Terminé usando pizarras blancas (comencé con una, pero ahora tengo dos en mi habitación) para seguir / desarrollar historias y la Técnica Pomodoro | Para hacer hoy lista para realizar un seguimiento de mis tareas de desarrollo y es friggin 2011. Se adhieren a los conceptos básicos hasta que consigamos algunas interfaces, tales como los de Iron Man 2 o coches voladores comienzan a aparecer.

Reflexión, reflexión, reflexión.

Esto fue lo que llegué a entender como la parte más importante de cualquier metodología para un individuo. Se trata de desarrollar este flujo de trabajo que le brinde una visión holística de su proyecto para que pueda realizar un seguimiento de lo que debe hacerse y de una manera que sea fácilmente manejable y donde rara vez se toman malas decisiones y se destaquen para que puedan modificarse rápidamente antes de que causen algún daño ... pero no puedes simplemente sacarlo del estante. Comience desde algún lugar, en cualquier lugar. Te quedas con él mientras funcione. Invierta en rastrear lo bueno, lo malo y lo regular. Mejore sus suposiciones, luego ajuste la forma en que hace las cosas en consecuencia. Esa es la única forma en que vas a mejorar.

Piense en los plazos, concéntrese en la rapidez con la que hace las cosas

Probablemente era como el próximo chico cuando comencé, persiguiendo citas. Burnout charts? Solía ​​pensar en ellos como una forma de visualizar mi camino de desarrollo en función de 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 tonto para representar la distancia antes de impedir los plazos. La realidad es que las cosas se hacen cuando se hace y su metodología debería dar cuenta de eso.

Desviarse en consecuencia

Al final, ¿quién dice que tiene que usar historias de usuarios, o cualquier cosa que sepamos? No pienses así. Si te sientes más cómodo pensando en las características, desafía a la comunidad de desarrollo global y hazlo a tu manera, porque hacer las cosas es todo lo que importa al final del día. Si termina sintiendo que está haciendo algo mal, felicidades, acaba de concluir que es hora de saltar a otra cosa. Se trata de lo que es, no de los 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 mayores problemas 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, cumplir / adaptarse 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 un desarrollo ágil, hay una gran cantidad de recursos en línea. Me gustaría ver en AUP (Agile Unified Process) que incorpora TDD (Test Driven Development). Esto puede ser extremadamente útil al construir / administrar grandes sistemas escalables.

No existe una metodología de "talla única" y esta es la razón principal de la gran cantidad de enfoques diferentes. Comenzaría a pensar dónde cree que están los cuellos de botella en su proceso de desarrollo actualmente y luego trataría 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 requisitos causan una importante reurbanización? ¿Requiere el negocio que se presenten sistemas de trabajo regulares? Echa un vistazo: Introducción ágil , iterativa y ágil .