Sí

Echa un vistazo a PXP o Personal Extreme Programming.

Http://portal.acm.org/citation.cfm?id=1593127

Resumen del documento:

La Programación Extrema Personal (PXP) es un proceso de desarrollo de software para equipo de una sola persona. Se basa en la valores de la Programación Extrema (XP) es decir, simplicidad, comunicación, retroalimentación y coraje. Funciona mantener los aspectos importantes de XP y refinando los valores para que puede caber en un programador solitario situación. PXP todavía se puede refinar y mejorado. Está en la tradición de profesionales de XP para variar XP a abarca lo que funciona. Esperamos que PXP hereda estos pragmáticos raíces, también. Renunciar a los principios de XP al igual que la programación de pares no es necesariamente una tragedia. Todavía creo que seguir XP estrictamente es una forma más efectiva de perseguir proyectos multipersonales. Pero también estamos convencido de que muchos de los XP se pueden aplicar prácticas y métodos al trabajo individual. El PXP enfoque trata de equilibrar entre la "demasiado pesado" y el "demasiado ligero" metodologia. PXP inyectará el la cantidad correcta de rigor para el situación sin sobrecargar la equipo con burocracia innecesaria.

Sí - es posible hacer muchas prácticas ágiles como individuo.

Si ya sabes cómo hacerlo, puedes hacerlo como desarrollador único:

• desarrollo basado en pruebas-un gran lugar para comenzar
• refactorización
• integración continua
• haciendo lo más simple que podría funcionar (y evolucionando a través de la refactorización)
• despliegue automatizado
• reuniones de planificación (un equipo de one plus cliente)

Cosas que no puedes hacer por tu cuenta:

• programación de pares
• Talleres CRC/RRC (... tendrías que hablar contigo mismo bastante)

Algunos aspectos se pueden hacer solos: ejecutar un backlog de producto y usar un tablero de tareas vienen a la mente. Ver lo que el secretGeek está haciendo.

Por supuesto, algunos no pueden: emparejar programación, scrums, etc...

La programación por pares sería difícil de esta manera:)

Vamos a comprobar Principios ágiles :

• Individuos e interacciones {[9] } sobre procesos y herramientas
• Software de trabajo {[9] } sobre documentación completa
• Colaboración con el cliente sobre la negociación del contrato
• Respondiendo al cambio sobre seguir un plan

Puedes hacer todas esas cosas incluso mientras trabajas solo en algún proyecto personal. Puedes use también GTD mientras trabaja solo, puede desarrollar su producto a través de iteraciones, puede adoptar timeboxing, puede pedir a algunos familiares o amigos que hagan pruebas de usabilidad con usted (y esto funciona muy bien).

Como conclusión, realmente puedes obtener toneladas de experiencias ágiles solo. Le recomiendo encarecidamente que lea algunos libros primero, ya que algunos de los principios pueden malinterpretarse fácilmente.

Recientemente interrumpí un gran proyecto. Era un proyecto de software médico. Mientras trabajaba en él, me di cuenta de algunos patrones sobre la programación en solitario. Quiero compartir mis experiencias aquí:

1. La lógica de trabajo de su software siempre debe reflejar el mundo real. Pescas peces con caña de pescar, no con bate de béisbol; así que olvídalo.
   
2. Siempre comience a compilar desde el elemento project al que se refieren todos los demás elementos. Eso tiene sentido si usted piensa que como la función en un proyecto de software que se llama a lo sumo. Eso podría ser modelado de base de datos. Sería inútil modelar la capa de acceso a datos primero, antes de modelar la base de datos.
   
3. No importa cambiar los nombres de las variables. Esa es la entrada más escrita en el diario de un programador; así que no hay necesidad de avergonzarse.
   
4. La metodología cambia el mundo. Haz que valga la pena. Haga cada proceso lógico con una función o procedimiento. Cuando el proyecto se hace enorme, comprenderás que eso es lo mejor manera.
   
5. Si no está diseñando un compilador de lenguaje en ensamblado no dude en usar enormes cadenas de llamadas de procedimientos en las que uno llama a otro y ese llama a otro y así sucesivamente. Use métodos en todas partes, casi se asemeje a cada entidad con clases y sea modular.
   
6. La modularidad lo es todo. Establece la modularidad como tu objetivo principal. He dicho que es todo mientras tanto?
   
7. Última palabra para comenzar el proyecto. Si está construyendo un apartamento, instale main entrada al fin. Pero al usar, entras en el edificio desde la entrada. Sé consciente.
   

Estos son algunos de mis principios de diseño que aprendí y aprendí día a día. Espero haber sido útil. Haz lo mejor que puedas.

Si bien algunas prácticas ágiles están dirigidas directamente a equipos de más de una persona, son solo prácticas, son solo un medio, no un fin. Quiero decir, Agile es no sobre hacer programación de pares, reuniones de pie, etc. Agile se trata de maximizar el valor del cliente mientras se minimiza el desperdicio para proporcionar el ROI más óptimo. Agile está orientado al negocio, las prácticas son solo una forma de lograr este objetivo en un contexto determinado. Así que, de vuelta a la pregunta inicial, es definitivamente es posible adoptar prácticas ágiles (que tengan sentido en su contexto) para maximizar el valor entregado: planificación continua, limitar el Trabajo En Progreso, Cultura Stop-the-Line, boxeo de tiempo, alta calidad, especificaciones suficientes, documentación suficiente y justo a tiempo, etc, etc.

Definitivamente. Agile es muy flexible en términos de cuántas personas están involucradas. Algunas metodologías, como Scrum, se centran principalmente en hacer todo lo posible en un tiempo limitado, como dos semanas (sprints). Eso incluye lo que quieras. Si su equipo requiere QA, entonces eso es parte de ello. Como solitario, tú decides lo que quieres incluir.

Después del scrum sprint, miras lo que podrías haber hecho de manera diferente para hacer más, y pasas a la siguiente.

Algún otro las metodologías se centran más en obtener características en cada iteración, por ejemplo, tres pequeñas características desarrolladas, probadas y refactorizadas.

Como puedes ver, hay un montón de maneras de aplicar agile a cualquier proyecto. Tú decides qué aspectos quieres. Aunque obviamente una parte integral es hacer las cosas en pequeños incrementos.

Sí

XP/TDD escala de uno a mil. La programación de pares es opcional.

SÍ.

Agile es más un estado de ánimo que solo una metodología de desarrollo de software como waterfall. Scrum es una de las metodologías ágiles más populares. Puede estudiar a continuación los aspectos de scrum en detalle:

1. Beneficios de Scrum / Agile sobre Waterfall
2. ¿Cómo puedes crear mejores "productos" con Scrum/Agile
3. ¿Cuáles son los tipos de proyectos más adecuados para Scrum
4. Pros y contras de Scrum
5. Los rituales Scrum y por qué son necesarios (Qué ventaja hacen ellos bring)
6. Diferentes roles en scrums y sus responsabilidades (Scrum Master, Propietario del Producto y Equipo de Desarrollo)

Después de tener una buena comprensión del funcionamiento de scrum y sus beneficios, intente crear un proyecto mascota. Tendrás que jugar todos los papeles tú mismo. Puede tratar de distinguir entre el papel que está jugando actualmente usando sombreros de diferentes colores para cada papel.

Ejemplo:

Propietario del producto: Piensa desde perspectiva del producto, cuáles deberían ser las características del producto y por qué serían importantes para sus usuarios, etc. Luego proceda con todas las prácticas de scrum.

Scrum Master: Sigue comprobando si estás siguiendo todos los rituales scrum en el sentido y espíritu correctos y si eres capaz de obtener beneficios de ello.

Habrá limitaciones,por ejemplo, no puede tener una reunión diaria de stand-up, obviamente porque usted es la única persona en el proyecto. Pero si sigues arriba, debe ser bueno para asegurar un trabajo y desempeñar su parte bien en el equipo.