Una cosa es decir que las metodologías ágiles son buenas en entornos donde los requisitos se entienden mal o que hay una novedad significativa . Pero, ¿debería aplicarse donde se requiere una innovación absoluta? Si es así, ¿cómo?
Si lo que está contemplando es desconocido en la industria, o incluso se piensa que es imposible, puede ser difícil concebir las historias de los usuarios y las tareas relacionadas. Por ejemplo, ¿se habría beneficiado Albert Einstein (o un empleador hipotético al que informa) haber ideado la teoría de la relatividad general al dividirla en epopeyas, sprints y tareas? Si la respuesta es "sí", ¿qué adaptaciones especiales deberían haberse incorporado para ayudar a que un enfoque ágil funcione mejor con la forma de Einstein de lograr una visión revolucionaria?
Para dar un ejemplo de software específico, imagine que el año es 2008 y le gustaría usar WCF para proporcionar capacidades de tipo COMET o " larga votación ". Toda su investigación del "trabajo previo" no da resultado, e incluso lees a un blogger de MSDN que dice que no es posible.
Nuevamente, ¿qué ajustes o "sabor" podrían introducirse en las historias y tareas de los usuarios para acomodar la inventiva (o audacia?) De este esfuerzo? ¿O sería mejor concluir que el esfuerzo es tan innovador (en 2008) que es mejor dejarlo como un ejercicio de grupo de expertos no dirigido?
El innovador que opera bajo sprints de dos semanas ciertamente no quiere ser derribado cada vez que abandona una tarea sin salida y comienza a trabajar en una tarea recién descubierta que no se imaginó cuando se definió el sprint. Del mismo modo, cuando finaliza el sprint y no se entregan códigos de trabajo o enfoques de trabajo, el innovador no debe ser derribado por la gerencia. Es necesario que haya una forma de etiquetar el esfuerzo como "éxito" incluso en estas circunstancias. En quizás uno o tres sprints más de este tipo de actividades de "callejón sin salida", el innovador podría finalmente encontrar algo que funcione.
¿Cómo permite Agile a la gerencia saber que cada sprint estuvo "bien" a pesar de los retrocesos innovadores? ¿Cómo se maneja esto para que el gráfico de quemado no parezca absurdo?
Respuestas:
La pregunta del título, donde la innovación se refiere a avances creativos a menor escala en un equipo que ya está funcionando bien en Agile.
La mejor respuesta se resume en este artículo sobre "Gold Card Days" .
Resumen (parafraseado y con mis propias interpretaciones que pueden no reflejar las intenciones del autor) :
Hay algunos otros puntos (no en ese artículo) en relación con la aplicación de "tarjetas de oro":
La pregunta sustancial, donde la innovación se refiere a la investigación (meses a años de trabajo horrible) que tienen un riesgo real de no encontrar ninguna solución útil.
Esta pregunta anterior, ¿Qué técnicas de programación extrema son apropiadas para usar en un entorno de investigación? cubre gran parte del terreno de esta pregunta.
(Descargo de responsabilidad: escribí una de las respuestas a esa pregunta, aunque no la seleccionada).
El resumen es que el trabajo de investigación de software puede ser acelerado; requiere que sus participantes prioricen con base en nueva información (absorbiendo ideas descubiertas / aprendidas y sintetizando otras nuevas). Da la apariencia de ser "lento" solo porque es "lento para mostrar los frutos del éxito, y solo si fue exitoso".
Esta pregunta sobre Project Management Beta: ¿cuáles son los pros y los contras de incorporar un gerente de proyecto en un equipo de investigación? - también cubre los mismos motivos.
En espíritu, sí.
Como se señala en la respuesta de Mouviciel , el espíritu de investigación de software está en línea con el espíritu del Manifiesto Ágil. Lo que argumentaré a continuación es si la investigación de alto riesgo puede encajar en Agile como organización o metodología de gestión ("Agile en la práctica").
En la práctica, debe responder algunas preguntas.
Esta lista no es exhaustiva...
Tenemos que rastrear un poco sobre cómo nace la metodología ágil.
La metodología ágil se usa generalmente cuando hay un patrocinador del proyecto. Además, la disposición del patrocinador para financiar el proyecto es limitada; espera ver que algún software de calidad utilizable (potencialmente transportable) se entregue regularmente después de financiar el proyecto durante algún tiempo.
El tipo de trabajo de investigación en esta pregunta se refiere a "esfuerzos potencialmente no solucionables". En otras palabras, la naturaleza misma de este tipo de trabajo implica un riesgo de que finalmente pueda fallar, a pesar de todas las intenciones y diligencia de las personas involucradas.
Esta no es una lista de verificación de estilo ScrumButt.
Esta es más una lista de verificación previa que predice si uno está mejor "Que Sera, Sera"
1. Transparencia por adelantado. ¿Se dice al patrocinador del proyecto la verdad sobre la naturaleza riesgosa del proyecto?
2. Voluntad del patrocinador. ¿El patrocinador es consciente del riesgo y está dispuesto a continuar con la financiación?
El patrocinador debe tener una aceptación de riesgo que sea mayor que los proyectos comerciales típicos o los proyectos de software / TI / Agile típicos. No todos los patrocinadores cumplen con este criterio. Si no encaja, sería bueno para un profesional retirarse del proyecto.
3. Transparencia en todo el proyecto. ¿Se informa regularmente al patrocinador sobre el verdadero estado del proyecto?
Esto es para frustrar los intentos de ocultar contratiempos o fallas inminentes en el proyecto haciendo un mal uso del lapso de tiempo entre las actualizaciones de estado.
4. Participación activa del patrocinador. ¿El patrocinador está interesado en conocer los detalles esenciales, los altibajos, las promesas y las limitaciones de cada intento?
El problema con la investigación de software es que puede haber muchas pistas falsas, tanto falsos positivos (creer que un enfoque funcionaría pero no resultó exitoso) como falsos negativos (afirmar que algo no es posible, solo para ser refutado por otra persona) .
Los proyectos ágiles permiten que el equipo (incluidos los patrocinadores y las partes interesadas) asuma riesgos calculados. "Calculado" significa que los tomadores de riesgos están completamente informados. Si el patrocinador no está dispuesto a conocer los detalles esenciales del proyecto, entonces el patrocinador no tendrá información completa para calcular (juzgar) el riesgo por su cuenta.
Incluso si un patrocinador está dispuesto a asumir el riesgo financiero, si no está dispuesto a participar también en los riesgos de toma de decisiones (y acepta las consecuencias de sus propias elecciones), entonces el patrocinador tampoco es apto para tales proyectos de investigación de alto riesgo.
5. ¿Puede el equipo de investigación mostrar (demostrar) su progreso en forma de ejecución de software, en lugar de diapositivas de presentación?
Esta pregunta es apropiada para proyectos de investigación donde se espera que el resultado final ejecute software. Las diapositivas de presentación podrían ser útiles para explicar las teorías de CS, pero también podrían usarse de forma incorrecta para ocultar los contratiempos en la implementación del software (o la total falta de). Una demostración de software tiene la intención de frustrar tales usos incorrectos.
6. ¿Puede el equipo de investigación entregar un producto de software parcialmente valioso, incluso si el patrocinador decide detener la financiación en cualquier momento del proyecto?
Esta pregunta solo es relevante caso por caso. Algunos proyectos de investigación son incrementales; pueden tener múltiples hitos y entregables. Requiere un equipo de investigación para priorizar sus enfoques para favorecer "las frutas que cuelgan más bajas primero", o el "enfoque de menor costo para demostrar la viabilidad".
Algunos proyectos de investigación no son incrementales: para ofrecer un avance tecnológico único y muy específico. Es un éxito o error. Para este tipo de proyectos, los únicos resultados incrementales son el trabajo de investigación y creación de prototipos, y tal vez las publicaciones académicas. Estos entregables incrementales "no consumibles" son valiosos para algunos tipos de patrocinadores, a saber, universidades, agencias de financiación de la investigación y grandes corporaciones que esperan construir buena voluntad académica.
Sin embargo, los proyectos de investigación que tienen tales características también podrían favorecer el enfoque de "codificación de vaquero", como se discute más adelante. Estos se denominan adecuadamente "hacks", y ocurren en la academia.
Debido a la escala de tiempo de la mayoría de las investigaciones académicas, los fondos de investigación de estilo académico generalmente se proporcionan con un compromiso de uno o más años; La financiación de la investigación médica (académica y comercial) puede comprometerse por períodos aún más largos. Por otro lado, la investigación típica financiada comercialmente puede finalizarse sin previo aviso, o sus recursos (mano de obra) pueden reasignarse por completo a otros proyectos.
7. ¿Cómo mide el equipo de investigación en la escala de silo vs. multifuncional?
Algunos tipos de equipo de investigación están muy aislados. A menudo, esto sucede en proyectos "multidisciplinarios": participa exactamente un miembro de cada disciplina. Como resultado, ningún miembro puede hacerse cargo de la tarea de otro miembro, ni siquiera las más pequeñas, porque sus conocimientos y habilidades no se superponen. La dificultad también se extendería a las definiciones de comunicaciones y tareas.
Los equipos extremadamente aislados aún se beneficiarán de algunos rituales de Scrum, como una reunión diaria de pie, pero aparte del "ritual" puede que no haya mucha interacción. Se necesitaría un entrenador ágil altamente socializador para que el equipo hable y genere confianza.
8. Si hay un entrenador ágil, ¿el entrenador prescribe ciclos cortos de iteración, boxeo de tiempo y proporciona estimaciones de tiempo?
Cada una de estas prácticas ágiles plantea dificultades para ciertos tipos de proyectos de investigación. Sin embargo, se informó que algunos grupos de investigación expertos pudieron aplicar estas prácticas en la investigación avanzada . Dado que no hay detalles sobre cómo ocurre el coaching ágil dentro de estos equipos de expertos, es posible que no podamos saber cómo se pueden superar cada una de estas dificultades.
9. ¿Vota el equipo de investigación por unanimidad para adoptar el estilo de desarrollo Solo en lugar de cualquier otra metodología?
Editado: una versión anterior usa la frase "codificación de vaquero", que alude a la falta de profesionalismo. Sin embargo, existe una diferencia entre el desarrollo en solitario y la codificación de vaqueros, y las circunstancias en este elemento de la lista de verificación pueden hacer que el desarrollo en solitario sea una opción legítima.
Esta pregunta muestra que hay programadores que prefieren poseer una gran parte del desarrollo. Si el equipo de investigación está compuesto principalmente por este tipo de programadores, dado que el conjunto de habilidades de los miembros del equipo es insustituible (refiriéndose al punto anterior del silo de habilidades), entonces los miembros del equipo pueden tener que recibir lo que desean, a cambio por sus habilidades y trabajo.
La principal diferencia entre el desarrollo en solitario y la codificación de vaqueros es que en el desarrollo en solitario, uno puede adoptar las prácticas enumeradas en The Joel Test: 12 pasos para mejorar el código , como el uso del control de versiones, la automatización de compilación y la corrección de errores antes de agregar nuevas características .
Algunas circunstancias favorecerán que cada miembro lleve a cabo el desarrollo en solitario, mientras que algunas circunstancias favorecerán la codificación de vaqueros.
La codificación del vaquero se ve favorecida si el objetivo final es "hacer un punto", al mostrar que algo es tecnológicamente posible. No hay requisitos de entrega, ni calidad, aparte de una buena presentación en el próximo DEF CON ® .
Pregunta final Si las circunstancias no permiten que un equipo ágil lleve a cabo una investigación innovadora, ¿cómo hacen uso de tecnología innovadora?
Lo de siempre. Deje que otras compañías (o académicos, individuos o equipos de piratas informáticos , startups, etc.) aborden primero el problema difícil y luego les compren o les licencian la tecnología. La industria del software ha estado funcionando con estos principios durante muchas décadas.
El énfasis en mostrar prototipos de trabajo tempranos en la metodología Agile obliga al equipo a buscar primero las soluciones existentes, lo cual es bueno porque puede salvar al equipo de un trabajo redundante.
fuente
Volver al Manifiesto Ágil :
Nada en estos valores prohíbe la innovación. En realidad, la innovación tiene un mejor nido con Agile que con Waterfall.
Sin embargo, puede suceder que las implementaciones habituales de Agile impongan algunas limitaciones a un proyecto de software que limitan la innovación, como los plazos (el plazo de un sprint es un plazo) o el costo. Pero esto no es un problema con Agile, es un problema con las organizaciones de trabajo actuales.
fuente
No creo que lo haga. Agile se trata de comer elefantes de chocolate: tomar una tarea grande y dividirla en trozos manejables que no solo se puedan entregar, sino que se entreguen regularmente.
Los proyectos de tipo de investigación no encajan en esto, a menos que su proyecto se pueda dividir en pequeños trozos que se puedan demostrar cada quince días (o más), en ningún momento Agile dice que 2 semanas es el tiempo que debe tomar su sprint, el mejor proyecto ágil que haya tenido trabajado en sprints de 6 semanas)
Aunque no lo intentaría. Tomaría las herramientas ágiles que crees que funcionarían para ti e ignoraría las que no. Mucha gente piensa que Ágil significa "debes hacer todo lo que el tutorial de scrum dice que debes hacer y nunca se permite discreción", ese enfoque es muy poco ágil.
fuente