En busca de trabajo en este momento, estoy viendo un montón de lugares que piden experiencia ágil, pero hasta que consiga un trabajo con un equipo que está utilizando ágil, sospecho que nunca voy a la experiencia.¿Puede una persona adoptar técnicas ágiles?
¿Es posible adoptar metodologías ágiles con una sola persona?
Una especie de responder a mi propia pregunta, hay cuestiones similares en: -
(. Creo que debería mejorar en la búsqueda)
Parece que viene de esto desde el punto de vista de la experiencia laboral; Si buscas construir una experiencia relevante para conseguir un trabajo en un proyecto ágil, probablemente pensaría un poco más lateralmente.
En primer lugar, ¿podría 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 puedan tener más experiencia.
En segundo lugar, podría utilizar algunas de las técnicas o herramientas más comunes, aunque solo sea para aprender cómo funcionan las herramientas, p. puede configurar un servidor de integración continua para ejecutar compilaciones y pruebas unitarias cuando ingresa el código. Si trabajas por tu cuenta, no ganarás mucho en términos de productividad al hacer esto, pero obtendrás algunas habilidades y tendrás algo relevante que decir a futuros empleadores que indicaría que estás comprometido con el estilo ágil.
Voy a marcar este como aceptado, ya que retomará el aspecto de la experiencia laboral y proporcionará consejos prácticos sobre cómo demostrarlo a los posibles empleadores –
Mientras que el código abierto podría ser una forma de adquirir experiencia, debido a su naturaleza distribuida y raramente me encuentro con personas cara a cara, no sé cuán efectivo sería trabajar con una experiencia comercial en una oficina donde es más fácil colaborar y compartir ideas con colegas. –
@greg Sure. Cosas como el scrum de mentiras o la programación de pares no funcionarán, pero otros aspectos podrían, por ejemplo, no hay razón para no hacer TDD o CI. No estoy seguro de si están estrictamente bajo la definición de "ágil", pero creo que hay una experiencia útil que tener allí. –
Algunos aspectos se puede hacer solo: me viene a la mente ejecutar una acumulación de productos y usar un tablero de tareas. Vea lo que está haciendo el secretGeek.
Por supuesto, algunos no pueden: la programación en parejas, scrums etc ...
Bueno, puedo usar bien la pizarra de mi oficina en casa en lugar de usar la pieza de A3 que sugiere. –
+1 por el enlace si me quedaban votos ... :) –
Definitivamente. Agile es muy flexible en términos de cuántas personas están involucradas. Algunas metodologías, como Scrum, se enfocan principalmente en hacer tanto como sea posible en un tiempo limitado, como dos semanas (sprints). Eso incluye lo que quieras. Si su equipo requiere QA, eso es parte de eso. Como solitario, decides lo que quieres incluir.
Después del sprint sprint, observa lo que podría haber hecho de manera diferente para hacer más cosas y pasar al siguiente.
Algunas otras metodologías se centran más en obtener funciones en cada iteración, digamos tres características pequeñas desarrolladas, probadas y refactorizadas.
Como puede ver, hay muchas formas de aplicar ágil a cualquier proyecto. Tú decides qué aspectos quieres. Aunque, obviamente, una parte integral es hacer cosas en pequeños incrementos.
Supongo que esto lleva a una pregunta posterior: ¿Cómo puedo demostrar a un posible empleador que adopto tales prácticas cuando lo hago solo? –
Explica cómo funciona tu sistema y cómo te ayudó a lograr la tarea. –
Sí
Echa un vistazo a PXP o Personal Extreme Programming.
http://portal.acm.org/citation.cfm?id=1593127
Resumen del papel:
programación extrema Personal (PXP) es un proceso de desarrollo de software para un equipo sola persona. Se basa en los valores de Extreme Programming (XP) es decir, la sencillez, la comunicación, retroalimentación, y el valor. Funciona por manteniendo los aspectos importantes de XP y refinando los valores para que puedan caber en una situación de programador solitario . PXP aún puede refinarse y mejorarse. Es en la tradición de los profesionales de XP para variar XP a abarcan lo que funcione. Esperamos que PXP herede estas pragmáticas raíces , también. Renunciar a los principios de XP como programación de pares no es necesariamente una tragedia. Todavía creemos que después de XP es estrictamente una manera más eficaz para lograr proyectos de varias personas.Pero también estamos convencidos de que muchas de las prácticas y métodos XP se pueden aplicar al trabajo individual. El enfoque PXP intenta equilibrar las metodologías "demasiado pesadas" y las "demasiado claras" . PXP inyectará la cantidad correcta de rigor para la situación sin sobrecargar al equipo con una burocracia innecesaria.
programación
Si no puede ver el papel. Intenta buscar en Google el término. La programación de pares es nula por naturaleza, pero todo lo demás funciona. Lo estoy usando en un proyecto ahora. – Finglas
Concepto interesante: ¿hay alguna manera de ver el documento sin tener un miembro de ACM? –
La tabla de comparación es mucho más grande de lo que recordaba, así que en su lugar publicaré el resumen. – Finglas
Pair sería difícil de esta manera :)
Vamos a comprobar Agile Principles:
Puede hacer todas esas cosas, incluso mientras se trabaja 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 timeboxing, puede pedirle a algunos miembros de su familia o amigos que le hagan pruebas de usabilidad (y esto funciona realmente bien).
Como conclusión, realmente puede obtener toneladas de experiencias Agile solo. Le recomiendo que lea algunos libros primero, ya que algunos de los principios pueden malinterpretarse fácilmente.
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 par, reuniones de pie, etc. Agile es aproximadamente maximizando el valor de cliente mientras minimiza 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 determinado. Por lo tanto, volviendo a la pregunta inicial, definitivamente es posible adoptar prácticas ágiles (que tengan sentido en su contexto) para maximizar el valor entregado: planificación continua, limitación de Trabajo en progreso, cultura Stop-the-Line, tiempo de boxeo, alta calidad, solo las especificaciones suficientes, la documentación suficiente y en el momento justo, etc., etc.
+1 Todo el mundo parece centrarse en la Programación de Pares, pero como usted señala, este no es el todo para Agile: de hecho, el argumento principal para PP parecía ser el de ayudar a compartir conocimientos donde se ve obstaculizado por una falta de documentación en otro lugar. –
La programación de pares proviene más de XP (que es más preceptivo) que Agile/Scrum. –
Agile! = Scrum, Agile es solo un término genérico para muchos métodos, Scrum y XP son algunos de ellos. Y mientras Pair Programming es una de las prácticas de XP (que captura muchas prácticas ** como un conjunto indivisible **), XP no tiene la exclusividad de Pair Programming, puede usarlo fuera de XP. –
Sí - es posible hacer muchas prácticas ágiles como individuo.
Si ya sabe cómo hacer esto, se puede hacer como un único desarrollador:
cosas que no se puede hacer por su cuenta:
XP/TDD escala de uno a mil. La programación de par es opcional.
Recientemente interrumpí un gran proyecto. Fue 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í:
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.
Algunos de sus puntos son anti ágiles y/o incluso atipatterns. A saber, 2, 4, 7. Podríamos comenzar desde UI y simular datos reales. Una operación lógica/de usuario se convierte principalmente en un gran conjunto de métodos, ni uno solo. En Agile, debe comenzar a crear a partir del elemento que es un elemento inicial para un usuario. – Gangnus
SÍ.
Agile es más un estado de ánimo que una mera metodología de desarrollo de software como la cascada. Scrum es una de las metodologías ágiles más populares. Se puede estudiar a continuación los aspectos de scrum en detalle:
Después de tener una buena comprensión del trabajo del scrum y sus beneficios, tratar de crear un proyecto personal. Tendrá que desempeñar todos los roles usted mismo. Puede tratar de distinguir entre qué rol está jugando actualmente usando sombreros de diferentes colores para cada rol.
Ejemplo:
propietario del producto: Pensar desde la perspectiva del producto, lo que debería ser las características del producto y por qué iban a ser importantes para sus usuarios, etc. A continuación, proceder con todas las prácticas de scrum.
Scrum Master: Controle si está siguiendo todos los rituales del scrum en el buen sentido y espíritu y puede sacarle provecho.
Habrá limitaciones, por ejemplo, no puede tener una reunión diaria stand-up, obviamente porque usted es la única persona en el proyecto. Pero si sigue lo anterior, debería ser bueno para asegurar un trabajo y desempeñar bien su papel en el equipo.
No tiene sentido agilizar a una persona. El propósito de ágil es irradiar comunicación. –
@jpartogi No estoy de acuerdo con su primer reclamo ni con su comprensión de Agile. Ambos puntos simplemente no son verdad. –
¿Los puestos de trabajo son ágiles según los requisitos o las preferencias? Tal vez necesites mostrar disposición para usar Agile y demostrar algo de autoestudio sobre el tema. – JeffO