¿Cómo desarrollar un excelente software con métodos ágiles?

El modelo de satisfacción del cliente de Kano define diferentes clases de características del producto. Entre ellos están

1. Cualidades imprescindibles: si no se implementan, el cliente no aceptará el producto.

2. Cualidades atractivas (deleites): características que el cliente a menudo ni siquiera espera en primer lugar, pero que causan emoción y deleite al ser descubierto.

Las cualidades atractivas obviamente tienen mucho valor comercial. Hacen que la gente compre un Ferrari por 500.000 cuando un Fiat usado por menos de 5.000 cumpliría con todos los requisitos obligatorios.

Sin embargo, todos los procesos ágiles que conozco favorecen los requisitos imprescindibles. Estos siempre obtienen la máxima prioridad. Ni siquiera parece haber un lugar para cualidades atractivas en ágil.

Creo que los procesos ágiles son muy útiles en el desarrollo de software. Pero, ¿cómo se pueden aplicar para crear productos de software de alta calidad y no solo el mínimo que apenas cumple con los requisitos obligatorios?

Anexo: Como las dos primeras respuestas han señalado, tiene sentido dar a los requisitos obligatorios la máxima prioridad. Pero, ¿nosotros (y el cliente) realmente siempre sabemos de antemano cuáles son los requisitos obligatorios? He hecho la experiencia varias veces de que los requisitos a los que se les dio alta prioridad al principio resultaron ser mucho menos importantes, si no inútiles, más tarde. Por lo tanto, creo que uno no debe centrarse servilmente en los requisitos obligatorios.

La respuesta formal es que usted entendió mal ágil, ágil no dicta requisitos, las partes interesadas lo hacen. El núcleo de Agile no es tallar sus requisitos en piedra, sino que surjan a medida que avanza, en estrecho contacto con su cliente, beneficiándose de conocimientos progresivos.

Pero eso es todo teoría. Lo que ha presenciado es un rasgo común de muchas líneas de producción de software que adoptaron una forma ágil de trabajar.

El problema es que escuchar al cliente y responder rápidamente a las necesidades del cliente a menudo pronto termina en no pensar en el producto ni en hacer ningún diseño. Lo que solía ser un proceso proactivo alimentado por la visión y la experiencia puede, y a menudo se deteriorará, en un proceso pasivo y completamente reactivo alimentado por los deseos del cliente. Esto conducirá a hacer las necesidades básicas que "harán el trabajo".

El automóvil nunca se habría inventado si los fabricantes en ese momento hubieran sido "ágiles" porque todo lo que los clientes pedían era un caballo más rápido.

Sin embargo, esto no hace que Agile sea malo. Es un poco como el comunismo. Una gran idea que casi nunca funciona bien porque las personas son personas que hacen cosas de personas. Y el método / ideología / religión los lleva a la idea de que les está yendo bien siempre y cuando sigan los movimientos y / o sigan las reglas.

[editar]

Slebetman:

Es irónico entonces que ágil evolucionó fuera de la industria automotriz (a saber, Toyota).

¿Recuerdas la regla de oro de la automatización? "Primero organizar, luego automatizar". Si automatiza un proceso interrumpido, lo mejor que podría suceder es que acelere todo lo que sale mal. La gente de Toyota no era idiota.

La razón típica para adoptar una nueva metodología es que las cosas no van bien. La gerencia lo reconoce, pero es posible que no entiendan los problemas centrales. Entonces contratan a este gurú que da un discurso elocuente sobre Agile y Scrum. Y a todos les encanta. Por sus propios motivos.

Los desarrolladores pueden pensar "Oye, esto podría funcionar. Estaríamos más involucrados con los problemas del negocio y podríamos proporcionar información para llenar este retraso. Esto podría ser una oportunidad para que las ventas y el servicio al cliente entiendan lo que hacemos, por qué es necesario, y nos los quitaríamos del pelo mientras quemábamos de manera transparente lo que acordamos ". No más "deja de hacer lo que estás haciendo, esto debe hacerlo ahora" por un tipo que no quieres posponer apareciendo en tu escritorio.

Las ventas, el servicio al cliente o el propietario, por otro lado, pueden verlo como una forma de obtener el control (posterior) sobre esta caja negra de un departamento que presumiblemente está haciendo las cosas que son necesarias. No ven lo que está sucediendo allí, pero están bastante seguros de que el núcleo del problema está enterrado en algún lugar allí. Entonces, presentan Scrum, instalan el propietario de un producto de su elección y, de repente, tienen todo el control, todas las cadenas están en sus manos. ¿Y ahora qué? ... Ehrr ...

El problema real es a menudo que la tienda no estaba bien organizada en primer lugar y esto no ha cambiado. A las personas se les han asignado responsabilidades que no pueden manejar, o tal vez sí, pero el Sr. Boss está constantemente interfiriendo y arruinando lo que hicieron, o (lo más frecuente en mi experiencia), no se han reconocido o asignado responsabilidades cruciales a nadie.

A veces, con el tiempo, surgirá una organización informal entre las líneas formales. Esto puede compensar en parte la falta de una estructura formal. Algunas personas terminan haciendo lo que son buenos, ya sea que tengan una tarjeta de presentación para demostrarlo o no. La introducción contundente de Agile / Scrum puede arruinar eso instantáneamente. Porque ahora se espera que la gente juegue según las reglas. Sienten que lo que solían hacer no es apreciado, obtienen pequeños papeles amarillos con pequeñas historias en su lugar, el mensaje será: "lo que sea que estuvieras haciendo, a nadie le importó". No hace falta decir que esto no será particularmente motivador para esas personas. En el mejor de los casos, comenzarán a esperar órdenes y ya no tomarán ninguna iniciativa.

Entonces las cosas empeoran y la conclusión será que Agile apesta.

Agile no apesta, es ideal para proyectos de mantenimiento e incluso puede ser bueno para nuevos desarrollos si se aplica con cuidado, pero si las personas equivocadas no lo entienden o lo adoptan por los motivos equivocados, puede ser más destructivo.

Ni siquiera parece haber un lugar para cualidades atractivas en ágil.

Estas comparando manzanas y naranjas. En la cascada tradicional, si sus requisitos dicen que necesita los artículos imprescindibles, obtiene un Fiat. Si los requisitos dicen que tiene que ser de primera categoría, obtienes un Ferrari.

Lo mismo sucede en Agile. Si sus requisitos se detienen en los artículos imprescindibles, obtendrá un Fiat. Si tienes historias de excelencia, obtienes un Ferrari. Todo lo que ágil realmente impone es que primero hagas los must haves . No construir un spoiler súper genial durante dos años y luego perder la fecha límite para el motor.

Tan larga historia corta: obtienes lo que necesitas. Si planeas un auto deportivo, obtienes un auto deportivo. Ágil no cambia eso en absoluto. Si su proceso ágil presenta requisitos para un Fiat, no culpe a ágil, culpe a los chicos que solo requieren un Fiat.

Sin embargo, todos los procesos ágiles que conozco favorecen los requisitos imprescindibles. Estos siempre obtienen la máxima prioridad.

Como deberían: mire su modelo Kano nuevamente: si no se cumplen los requisitos obligatorios, el cliente no aceptará el producto. Y luego tus deleites no importan.

Ni siquiera parece haber un lugar para cualidades atractivas en ágil.

Nada mas lejos de la verdad.

Los procesos ágiles suelen enfatizar estos puntos:

• Entrega frecuente de un producto funcional sobre el que puede obtener comentarios.
• Divida las funciones en partes pequeñas que se pueden completar en poco tiempo.
• Implemente esas partes en orden de prioridad.

Nada le impide otorgar características de "deleite" de alta prioridad. Depende completamente de las personas que están a cargo de determinar las prioridades.

Ahora es cierto que muchas de esas personas prefieren no correr riesgos y, por lo tanto, pueden no dar altas prioridades a los "deleitadores". Pero en un proyecto no ágil, ese sería el caso.

Agile no dice nada sobre lo que debe hacerse primero, solo que el código debe escribirse de manera incremental y mantenerse en un estado liberable con la mayor frecuencia posible, en lugar de planearse que no se pueda usar durante meses hasta el próximo estado liberable.

He trabajado tanto en un proceso Agile como en un BDUF (Big Design Up Front), y aunque definitivamente puedes obtener características innovadoras y atractivas de ambos procesos, en BDUF, como era de esperar, tienes que planificarlos por adelantado. Eso significa que las innovaciones generalmente tienen que ser propuestas o al menos patrocinadas por personas con influencia en el proceso de diseño.

Esto se debe a que tiene seis meses (o lo que sea) hasta el próximo lanzamiento, y los gerentes de proyecto están estresados ​​sobre lo que está pasando en ese lanzamiento, porque si su función no entra, pasarán otros seis meses hasta el próximo . Por lo tanto, hay una lista repleta de características en un calendario repleto, y si el bajo rango se encuentra trabajando durante dos o tres días en algo interesante, simplemente piensan que al cliente le gustará, y no está en el lista, arriesgan todo el horario y habrá un infierno que pagar.

En un proceso ágil, nos esforzamos por mantener el software en un estado liberable, y los gerentes de proyecto están menos estresados ​​porque si su característica se desliza, pueden obtenerlo en dos semanas. Entonces, si un desarrollador regresa de una conferencia con una idea genial y pasa un par de días en algo, no está poniendo en peligro un calendario de seis meses escrito en sangre.

Básicamente, cosechas lo que siembras. Si fomenta la innovación y le da a los equipos suficiente autonomía para entregar, la obtendrá. Si constantemente exige atajos para cumplir con los plazos, obtendrá un software que coincida, sin importar su metodología.

El excelente software proviene de dos cosas:

• Dar al cliente lo que necesita.

• Ser un profesional

Hay todo tipo de principios a seguir al desarrollar software. SECO, legible, SÓLIDO, etc. que no tienen nada que ver con los requisitos del cliente. El cliente solicitó un auto deportivo. Si el cliente entendiera lo que se necesita para hacer un auto deportivo increíble, no lo necesitaría. Depende de usted descubrir qué más es importante.

Parte de nuestro trabajo es mantener estándares que el cliente nunca experimenta a menos que las cosas salgan terriblemente mal.

Si lo estás haciendo bien, entonces ágil tiende hacia el fiat solo cuando eso es lo que el cliente realmente quiere. No cuando eso es lo que creen que tienen que conformarse.

La cascada es diferente porque una vez que se ha solucionado un malentendido sobre un requisito de automóvil deportivo de alta gama, tiende a quedarse. Agile puede hacer frente a nueva información y adaptarse si resulta que lo que realmente necesitan es una bicicleta de bala.

La cascada todavía está en uso en muchas tiendas hasta el día de hoy. Estas tiendas tienen éxito porque sus requisitos cambian menos del 2% en un año.

Su trabajo no es simplemente darle al cliente lo que quiere. También es para ocuparse de cosas por las que sabe que no obtendrá ningún crédito. Cosas que el cliente nunca mencionará a menos que deje que las cosas salgan terriblemente mal. Es mejor que estas cosas estén bien elegidas o tomarás mucha basura por perder el tiempo con ellas.

Cualquier idiota puede construir un puente con un presupuesto ilimitado. Un profesional construye un puente que casi nunca se cae.

Por lo tanto, creo que uno no debe centrarse servilmente en los requisitos obligatorios.

Claro que deberías Excepto al estimar tu tiempo. Porque esos requisitos obligatorios no son la única consideración.

Okay,

En Agile, el programador puede crear el software, pero al final es el propietario del producto el que crea el producto. (mediante el uso de los desarrolladores de software).

Entonces, sobre las "cualidades atractivas", eso depende del propietario del producto.

Si el propietario del producto exige un "diseño sexy", eso puede ser un requisito. El desarrollador no debería tener que preocuparse por estas opciones.

Además, el software es tan diferente de los productos físicos reales que creo que gran parte del modelo Kano no se aplica. Por ejemplo, ¿por qué escribo en Facebook? Única razón: porque mis amigos lo hacen. Cómo poner eso en el próximo sprint ........ Y también, una de las cualidades más atractivas del software, es que realmente hace lo que se supone que debe hacer. (Y ahí es donde ágil ayuda mucho: P)

Mi experiencia concuerda con los comentarios anteriores: no hay nada inherente en Agile que impida el desarrollo de un excelente software, sin embargo, hay varios aspectos de cómo Agile se practica a menudo (mal) que conducen a un software que solo es "suficientemente bueno" ".

• Agile pone énfasis en hacer que algo funcione lo antes posible; sin embargo, esto significa hacer suposiciones simplificadoras y atajos, particularmente en la infraestructura no visible para el usuario. No hay nada intrínsecamente incorrecto en esto, si el costo de corregir los supuestos simplificadores es bajo; sin embargo, con demasiada frecuencia, esta "deuda técnica" no se elimina antes de que un producto entre en producción;
• Agile predica que al final de un sprint, siempre debe tener algo lo más cercano a lo que se puede enviar, para que los interesados ​​y los gerentes de proyecto puedan decidir que "lo que tienen" es lo suficientemente bueno como para presionar producción. De nuevo, nada inherentemente malo con esto, siha liquidado toda su "deuda técnica" (o ha hecho las paces con la cantidad que tiene y dónde está). Sin embargo, en mi experiencia, demasiada deuda técnica entra en producción con la promesa de un gerente de que "nosotros Lo limpiaremos una vez que la presión para enviar se haya apagado ", que rápidamente se convierte en" está en producción, tenemos que tener mucho cuidado con lo que cambiamos ahora ", que finalmente se convierte en" ¡Nunca me dijiste que teníamos esa exposición! ¡Tenemos que hacer un mejor trabajo la próxima vez! " La lección de Ben Frankin sobre "La amargura de la mala calidad permanece mucho después de que se olvida la dulzura del bajo precio" parece que nunca se aprende;
• Sin embargo, incluso con los directores de confianza y desarrolladores bien disciplinados, existe el problema común que simplemente demasiado poco adecuado análisis, diseño y revisión del diseño se produce antes del inicio de la carrera en la que se espera que la aplicación para ser iniciado y terminado. La incapacidad de considerar cuidadosamente la alternativaLas metáforas y los diseños de la interfaz de usuario son grandes; por lo general, es demasiado costoso revisar esto significativamente después de que se inicia un proyecto; el hecho de que los equipos junior no estudien cuidadosamente los productos de su competencia, o no den prioridad a la definición e implementación de tecnologías de infraestructura como I18N, marcos de notificación, registro, seguridad y estrategias de versiones de API (por ejemplo) significa que finalmente tendrán errores más altos, menor productividad, y acumulará más deuda técnica, que si hubieran pasado los primeros 2-5 sprints por adelantado haciendo la capacitación, el análisis, el diseño y la creación de prototipos necesarios. En resumen, los equipos ágiles deben resistir la licencia para hackear;
• Tuve un gerente de segundo nivel (de más de 100 desarrolladores) que desanimó a sus desarrolladores de tomarse el tiempo para escribir sus diseños planificados, incluso en el nivel más básico. Su razonamiento: "Quiero que las personas hablen entre sí", fue irónico porque estaban en 5 zonas horarias diferentes y en 3 países. No hace falta decir que hubo muchos señalamientos sobre qué equipo iba a tener que trabajar muchas noches y fines de semana al final del proyecto una vez que descubrieron que todos pensaban que el otro era responsable de implementar alguna funcionalidad (o reimplementar porque los diseños del proveedor y del consumidor simplemente no encajaron).

Realmente todo se reduce a si el gerente del proyecto y las partes interesadas desean entregar un producto de alta calidad. Si se comprometen a hacerlo, Agile lo habilitará. OTOH, debido a que Agile pone la toma de decisiones del cronograma únicamente en manos de la parte interesada y el gerente del proyecto, Agile dificulta que un equipo de desarrollo entregue un excelente proyecto sin ese apoyo. En resumen: la responsabilidad de la calidad del producto recae casi exclusivamente en los pies de los gerentes del proyecto.

TL; DR

De hecho, el desarrollo ágil lo ayuda a aumentar la calidad del software, mantener al cliente satisfecho y entregar un producto altamente valioso.

El desarrollo ágil fue introducido por algunos tipos inteligentes para abordar los problemas que enfrentan muchos proyectos de software en los procesos tradicionales.

Los valores clave del desarrollo ágil según lo definido por el manifiesto ágil (1) son,

• Individuos e interacciones sobre procesos y herramientas
• Software de trabajo sobre documentación completa
• Colaboración del cliente sobre la negociación del contrato
• Responde al cambio sobre el siguiente plan

Por lo tanto, el desarrollo ágil no le impide crear software de alta calidad. El desarrollo ágil lo ayuda a entregar software de alta calidad.

Pero, ¿nosotros (y el cliente) realmente siempre sabemos de antemano cuáles son los requisitos obligatorios?

Ese es todo el punto. Al centrarse en las personas, el cliente, el software de trabajo y los cambios en los requisitos, el desarrollo ágil le ayuda a descubrir qué quieren los clientes antes de entregar el producto final.

Esa es una razón por la cual los marcos ágiles como Scrum tienen ciclos de iteración cortos cuyos resultados son productos que funcionan. Ya puede validar su trabajo en una etapa temprana contra las expectativas del cliente y ajustar los objetivos / requisitos a pedido. Un desarrollo ágil le ayuda a asegurarse de darse cuenta de la calidad que debe tener un producto.

En el pasado, todavía es cierto hoy en día, muchos proyectos de software desarrollados en enfoques tradicionales fallaron, no tuvieron éxito o causaron disgustos a los clientes porque no se alcanzó la calidad que debe ser .

Además, el desarrollo ágil también lo ayuda a alcanzar una calidad atractiva . Reflejar el producto después de cada iteración ilumina nuevos requisitos que el cliente no tenía en cuenta al inicio del proyecto (cualidades atractivas). Esto mantiene al cliente satisfecho.

También me gustaría mencionar la calidad inversa , atributos que conducen a la insatisfacción, del modelo Kano.

En cada proyecto hay requisitos que parecen ser buenas ideas al comienzo del proyecto. Después de un tiempo cambian a lo contrario y causan decepciones.

En un proceso de desarrollo de software tradicional, reconocerá dichos requisitos en el producto final después de una larga ejecución del proyecto. Demasiado tarde para evitar decepciones de los clientes y cambiarlos es necesario un proyecto de seguimiento.

El desarrollo ágil le ayuda a identificar los requisitos no funcionales o insatisfactorios temprano y a cambiarlos durante el proyecto.

Como dije, el desarrollo ágil lo ayuda a aumentar la calidad del software, mantener al cliente satisfecho y entregar un producto muy valioso.

Llego bastante tarde a esta fiesta, pero me gustaría compartir otro ángulo sobre este tema:

Pero, ¿cómo se pueden aplicar para crear productos de software de alta calidad y no solo el mínimo que apenas cumple con los requisitos obligatorios?

Hay un aspecto temporal en el desarrollo de software ágil que resulta del enfoque iterativo y de la opinión de los clientes , que son dos elementos importantes de la metodología ágil. Ejemplo: Las características que se identifican como calidad atractiva en la iteración t podrían convertirse en una calidad imprescindible en la próxima iteración t + 1.

La aplicación de métodos ágiles puede cambiar dinámicamente la categoría de calidad de una característica. Si compara las características planificadas de la iteración t con las características terminadas de alguna iteración posterior t + n, experimentará exactamente lo que mencionó:

He hecho la experiencia varias veces de que los requisitos a los que se les dio alta prioridad al principio resultaron ser mucho menos importantes, si no inútiles, más tarde.

Con este aspecto temporal en mente, es plausible que los métodos ágiles puedan producir productos sofisticados de alta calidad mientras se concentran en lo mínimo . El enfoque iterativo junto con los comentarios de los clientes cambia las reglas del juego con el tiempo.

Conclusión

¿Cómo desarrollar un excelente software con métodos ágiles?

Aplique un enfoque iterativo y escuche los comentarios de los clientes . Elimine uno de estos elementos y obtendrá una forma menos exitosa de desarrollo de software ágil.

   > How to develop excellent software with agile methods?

• Al producir un software individual específico del cliente :
  • encuentre un cliente donde el costo no importe porque la función "encantadora" cuesta dinero extra y el cliente tiene que decidir si quiere pagar por esto.
• Al producir productos de software :
  • Las características "encantadoras" son buenas para atraer nuevos clientes y el costo de implementar una característica "encantadora" no es tan importante si el producto se vende más de 1000 veces.
• En un entorno donde "lo suficientemente bueno (lo más barato) es lo mejor", no obtendrá el dinero para implementar características "encantadoras"

En un equipo Scrum, el propietario del producto es responsable de elegir qué características implementar. Por lo tanto, depende de él (y de su presupuesto) definir un software "suficientemente bueno" o "excelente"

Subes algunos buenos puntos. Pero no creo que estos problemas estén restringidos a procesos / metodologías ágiles.

Hay diferentes opiniones sobre lo que es esencial frente a las características no esenciales. Para usar su ejemplo, alguien que compre un automóvil podría considerar que llamar la atención como una característica esencial y, por lo tanto, considerar que un Fiat no cumple con este requisito imprescindible.
De manera más realista, un producto de software podría necesitar cierta funcionalidad para satisfacer las necesidades de sus usuarios finales reales ... pero también podría necesitar ciertas otras características para poder ser vendido. Porque la persona que autoriza la compra no suele ser un usuario final.
Por lo tanto, una característica "no esencial" para el usuario o usuarios finales podría ser esencial para vender el producto ... y, por lo tanto, también esencial para la empresa que lo crea.

Todo lo cual se reduce al hecho de que es crucial contar con un buen equipo de desarrollo de productos para establecer los requisitos y prioridades de manera adecuada. Pero eso no solo es cierto para las tiendas ágiles.

También es importante tener propietarios o partes interesadas del producto que estén autorizados para tomar decisiones. Si las decisiones de su propietario del producto son constantemente anuladas por otra persona, yo sería el primero en aceptar que es un problema, pero nuevamente, no es un problema con Agile.

Hay otras cosas que desea en los propietarios de sus productos ... una descripción que he escuchado es "CRACK" (colaboración, representante, autorización, compromiso y conocimiento). El propietario de un producto que carece de cualquiera de estas áreas puede significar problemas para un proyecto. Pero escuché por primera vez este acrónimo en un entorno de cascada, por lo que claramente el dolor de los malos clientes / propietarios de productos no se limita a las tiendas ágiles.

Lo que puede hacer (ayuda) ágil es sacar a la superficie algunos de estos problemas.

Por ejemplo, la literatura de XP es bastante explícita sobre que el "cliente" tiene conocimiento, es accesible para el equipo y está autorizado para tomar decisiones. El término "propietario del producto" implica cierto nivel de conocimiento, compromiso y autoridad.

Si se encuentra en una situación en la que la mayor parte de la funcionalidad entregada consiste en deleitadores en lugar de características imprescindibles, es mucho más fácil plantear ese problema (y mucho más fácil determinar la causa) cuando entrega software que funciona o casi funciona 2-3 semanas que cuando las entregas están separadas por meses o años.

Si está trabajando en pequeñas iteraciones, y revisando el trabajo atrasado con frecuencia (incluida la revisión de la priorización), eso le brinda al equipo la oportunidad de aprender de los errores anteriores. "Esto parece realmente importante ahora, pero ¿recuerdas la navegación dinámica que estábamos seguros de que necesitábamos y que no terminamos usando?" Como otros han señalado, esas discusiones son mucho menos probables si todo se ha planeado por adelantado.

Por el contrario, la metodología de diseño inicial supone (por defecto) que la comprensión del producto y las características es estática. Esa no ha sido mi experiencia: tener algo tangible para trabajar casi siempre cambia la comprensión del problema por parte de los empresarios. De ahí el énfasis en la retroalimentación rápida. (La comprensión de los desarrolladores también cambia, pero eso no va a afectar las prioridades).

Aplazar parte de la planificación también le permite responder a los cambios en las necesidades comerciales. "¿Conoces el sitio web que estás construyendo? Realmente necesitamos que sea una aplicación móvil, capaz de funcionar sin conexión". Esto no es algo que se le haya preguntado específicamente ... pero ¿no le gustaría que su proceso sea capaz de responder a los cambios en el panorama empresarial (al menos en teoría)?

Ágil no dice "no compile características no esenciales". Dice "permitir que la empresa decida qué características (no) construir".
... e (igualmente importante) "permite que los técnicos le digan cuánto tiempo llevará construir una característica que desea".

1. Must-be qualitiesA menudo son difíciles de determinar. La gente los tiene en la subconsciencia. Las iteraciones ágiles y la participación del cliente ayudan a encontrar la mayoría de los artículos imprescindibles. Ese es el poder de ágil y es una tontería descuidarlo .
2. One-dimensional qualitieseso significa que las promesas que deben cumplirse son respaldadas por la cascada OK, hasta que no cambien. Aquí ser ágil solo ayuda, pero no tan poderosamente.
3. Attractive qualitiesSon buenas características. Podrían convertirse en imprescindibles en la próxima generación. Pero en la generación actual ni siquiera están en el acuerdo, o de lo contrario serían cualidades unidimensionales. Esos métodos ágiles que suponen una participación representativa del cliente respaldan estas cualidades muy bien. Porque podemos cambiar el alcance a la ligera durante el trabajo. Podemos negociar mejoras en un lugar para obtener alguna compensación en otro. En cascada es prácticamente imposible. Sin una gran demora organizativa, solo pudimos AGREGAR funciones de forma gratuita. Es posible, si previamente se asigna algo de tiempo extra al presupuesto.

Por lo tanto, los procesos ágiles pueden soportar el modelo Kano, algunos de ellos lo hacen en gran medida, y definitivamente mucho mejor que los mejores proyectos en cascada.

Para hacerlo en gran medida, debe establecer procesos ágiles con un participante representante del cliente responsable.