agile - metodologias - ¿Puede una persona adoptar técnicas ágiles?
metodologias agiles lean (10)
Buscando trabajo en este momento, veo muchos lugares que solicitan la experiencia Agile, pero hasta que consiga un trabajo con un equipo que usa Agile, sospecho que nunca obtendré la experiencia.
¿Es posible adoptar metodologías ágiles con una sola persona?
Como respondiendo a mi propia pregunta, hay preguntas similares en: -
(Supongo que debería mejorar en la búsqueda.)
Sí
XP / TDD escala de uno a mil. La programación de pares es opcional.
Algunos aspectos se pueden hacer solos: viene a la mente la acumulación de un producto y el uso de un panel de tareas. Mira lo que está haciendo el secretGeek .
Por supuesto, algunos no pueden: emparejar programación, scrums, 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 todo lo que quieras. Si su equipo requiere control de calidad, eso es parte de él. Como solitario, tú decides lo que quieres incluir.
Después del sprint del scrum, observa lo que podría haber hecho de manera diferente para hacer más, y pasa al siguiente.
Algunas otras metodologías se centran más en hacer que las funciones se realicen en cada iteración, por ejemplo, tres características pequeñas desarrolladas, probadas y refactorizadas.
Como puede ver, hay muchas maneras de aplicar ágil a cualquier proyecto. Tú decides qué aspectos quieres. Aunque obviamente una parte integral es hacer las cosas en pequeños incrementos.
Hace poco interrumpí un gran proyecto. Fue un proyecto de software médico. Mientras trabajaba en ello, me di cuenta de algunos patrones sobre la programación en solitario. Quiero compartir mis experiencias aquí:
- La lógica de trabajo de su software siempre debe reflejar el mundo real. Atrapas peces con caña de pescar, no con un bate de béisbol; así que olvídalo.
- Siempre comience a construir desde el elemento del proyecto al que se refieren todos los demás elementos. Eso tiene sentido si piensa que le gusta la función en un proyecto de software que se llama a lo sumo. Eso podría ser el modelado de base de datos. Sería inútil si primero modela la capa de acceso a datos, antes de modelar la base de datos.
- No importa cambiar nombres de variables. Esa es la entrada más escrita en el diario de un programador; así que no hay necesidad de avergonzarse.
- La metodología cambia el mundo. Haz que valga la pena. Realiza cada proceso lógico con una función o procedimiento. Cuando el proyecto se haga grande, entenderás que es la mejor manera.
- Si no está diseñando un compilador de lenguaje en ensamblaje, no dude en utilizar enormes cadenas de llamadas de procedimientos en las que uno llama a otro y eso llama a otro y así sucesivamente. Use métodos en todas partes, casi se asemeje a cada entidad individual con clases y sea modular.
- La modularidad lo es todo. Establecer modularidad tu objetivo principal. ¿He dicho que es todo mientras tanto?
- Última palabra para comenzar el proyecto. Si está construyendo un apartamento, instale por fin la entrada principal. Pero cuando lo usas, entras en el edificio desde la entrada. Estar atentos
Estos son algunos de mis principios de diseño que aprendí y aprendí día a día. Espero haber sido útil. Haz tu mejor esfuerzo.
La programación en pares sería difícil de esta manera :)
Veamos los principios ágiles :
- Individuos e interacciones sobre procesos y herramientas.
- Software de trabajo sobre documentación completa.
- Colaboración del cliente en la negociación de contratos.
- Respondiendo al cambio siguiendo un plan.
Puedes hacer todas esas cosas incluso mientras trabajas en algún proyecto personal solo. También puede usar GTD mientras trabaja solo, puede desarrollar su producto a través de iteraciones, puede adoptar el timeboxing , puede pedir a algunos miembros de la familia o amigos que hagan pruebas de usabilidad con usted (y esto funciona realmente bien).
Como conclusión, realmente puedes obtener toneladas de experiencias ágiles solo. Te recomiendo que leas algunos libros primero, ya que algunos de los principios pueden ser fácilmente malinterpretados.
Parece que vienes a esto desde el punto de vista de la experiencia laboral; Si está buscando construir una experiencia relevante para conseguir un trabajo en un proyecto ágil, probablemente lo pensaría un poco más lateralmente.
Primero, ¿podrías trabajar con otros, tal vez en un proyecto de código abierto? Esa sería una buena oportunidad para probar métodos ágiles con otros que pueden tener más experiencia.
En segundo lugar, puede considerar el uso de algunas de las técnicas o herramientas comunes, incluso si se trata de aprender cómo funcionan las herramientas; por ejemplo, puede configurar un servidor de integración continua para ejecutar compilaciones y pruebas unitarias cuando ingresa el código. Si trabaja por su cuenta, no ganará mucho en términos de productividad al hacer esto, pero ganaría algunas habilidades y tendría algo relevante que decir a los futuros empleadores, lo que indicaría que está comprometido con el estilo ágil.
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 muy populares. Puedes estudiar a continuación los aspectos del scrum en detalle:
- Beneficios de Scrum / Agile sobre cascada
- ¿Cómo puedes crear mejores "productos" con Scrum / Agile?
- ¿Cuáles son los tipos de proyectos más adecuados para Scrum?
- Pros y contras de Scrum
- Rituales de Scrum y por qué son necesarios (¿Qué ventaja traen?)
- Diferentes roles en scrums y sus responsabilidades (Scrum Master, propietario del producto y equipo de desarrollo)
Una vez que haya entendido bien cómo funciona Scrum y sus beneficios, intente crear un proyecto para mascotas. Tendrás que jugar todos los papeles tú mismo. Puedes tratar de distinguir entre el rol que estás jugando actualmente usando sombreros de diferentes colores para cada rol.
Ejemplo:
Propietario del producto: piense desde la perspectiva del producto, cuáles deberían ser las características del producto y por qué serían importantes para sus usuarios, etc. Luego continúe con todas las prácticas de scrum.
Scrum Master: siga comprobando si está siguiendo todos los rituales de scrum en el sentido y espíritu correctos y si puede obtener beneficios de ello.
Habrá limitaciones, por ejemplo, no puede tener una reunión diaria, obviamente porque usted es la única persona en el proyecto. Pero si sigues el ejemplo anterior, deberías ser bueno para asegurar un trabajo y desempeñar bien tu papel en el equipo.
Sí
Echa un vistazo a PXP o Personal Extreme Programming.
http://portal.acm.org/citation.cfm?id=1593127
Resumen del artículo:
La Programación personal extrema (PXP) es un proceso de desarrollo de software para un equipo de una sola persona. Se basa en los valores de Programación Extrema (XP), es decir, simplicidad, comunicación, retroalimentación y valor. Funciona manteniendo los aspectos importantes de XP y refinando los valores para que puedan encajar en una situación de programador solitario. PXP todavía puede ser refinado y mejorado. Es una tradición de los profesionales de XP variar XP para abarcar todo lo que funciona. Esperamos que PXP también herede estas raíces pragmáticas. Renunciar a los principios de XP como la programación en pares no es necesariamente una tragedia . Todavía creemos que seguir la XP estrictamente es una forma más efectiva de perseguir proyectos de varias personas. Pero también estamos convencidos de que muchas de las prácticas y métodos de XP se pueden aplicar al trabajo individual. El enfoque PXP trata de equilibrar las metodologías "demasiado pesada" y "demasiado ligera". PXP inyectará la cantidad correcta de rigor para la situación sin sobrecargar al equipo con una burocracia innecesaria.
Sí, es posible hacer muchas prácticas ágiles como individuo.
Si ya sabe cómo hacer esto, puede hacerlo como único desarrollador:
- Desarrollo impulsado por pruebas: excelente lugar para comenzar
- refactorización
- integración continua
- haciendo lo más simple que podría funcionar (y evolucionando a través de refactorización)
- despliegue automatizado
- reuniones de planificación (un equipo de un cliente más)
Cosas que no puedes hacer por tu cuenta:
- programación de pares
- Talleres CRC / RRC (... tendrías que hablar mucho contigo mismo)
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 no tiene que ver con la programación de pares, reuniones de pie, etc. Agile tiene que ver con maximizar el valor del cliente y minimizar el desperdicio para proporcionar el ROI más óptimo . Agile está orientado a los negocios, las prácticas son solo una forma de lograr este objetivo en un contexto dado. Así que, volviendo a la pregunta inicial, es definitivamente posible adoptar prácticas ágiles (que tienen sentido en su contexto) para maximizar el valor entregado: planificación continua, limitación del trabajo en curso, cultura de parada en la línea, boxeo temporal, alta calidad, Especificaciones suficientes, documentación suficiente, justo a tiempo, etc., etc.