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

La respuesta formal es que usted malinterpreta ágil, ágil no dicta requisitos, los interesados lo hacen. El núcleo de Agile no es tallar sus requisitos en piedra, sino hacer que surjan sobre la marcha, en contacto directo con su cliente, beneficiándose de información progresiva.

Pero eso es todo teoría. Lo que ha presenciado es, de hecho, 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 por no pensar en el producto o hacer ningún diseño. Lo que solía ser un proceso proactivo alimentado por la visión y la experiencia puede, y con frecuencia se deteriorará, en un proceso pasivo, totalmente reactivo, alimentado por los deseos del cliente. Esto llevará a hacer solo 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 todos los clientes pedían 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 simplemente personas, que hacen cosas a las personas. Y el método / ideología / religión los adormece en la idea de que lo están haciendo bien, siempre y cuando sigan los movimientos y / o sigan las reglas.

[editar]

Slebetman:

  

Es irónico que Agile haya evolucionado fuera de la industria de la automación.   (a saber, Toyota).

¿Recuerdas la regla de oro de la automatización? "Primero organiza, luego automatiza". Si automatiza un proceso roto, lo mejor que podría suceder es que acelere todo lo que sale mal. Las personas en Toyota no eran idiotas.

La razón típica para adoptar una nueva metodología es que las cosas no van bien. La gerencia lo reconoce, pero puede que no entiendan los problemas centrales. Entonces contratan a este gurú que da un discurso resistente sobre Agile y Scrum. Y todo el mundo lo ama. Por sus propias razones.

Los desarrolladores pueden pensar "Oye, esto podría funcionar. Estaríamos más involucrados con los asuntos de negocios y podríamos proporcionar información para completar esta acumulación. Esta podría ser una oportunidad para hacer que las ventas y el servicio al cliente entiendan lo que hacemos, por qué es necesario, y los tendríamos fuera de nuestro cabello mientras estamos quemando de manera transparente lo que acordamos ". No más "detén lo que estás haciendo, esto debe hacerse ahora" por un tipo que no quieres postergar en tu escritorio.

Las ventas, el servicio al cliente o el propietario, por otra parte, pueden verlo como una forma de obtener (atrás) el control 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í. Así que presentan Scrum, instalan un producto propietario 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 se organizó bien en primer lugar y esto no ha cambiado. A las personas se les han asignado responsabilidades que no pueden manejar, o quizás sí, pero el Sr. Boss está constantemente interfiriendo y arruinando lo que hicieron, o (la mayoría de las veces en mi experiencia), las responsabilidades cruciales no han sido reconocidas o asignadas a nadie en absoluto. p>

A veces, con el tiempo, una organización informal surgirá entre las líneas formales. Esto puede entonces compensar en parte la falta de una estructura formal. Algunas personas simplemente terminan haciendo lo que hacen bien, ya sea que tengan una tarjeta de presentación para demostrarlo o no. La introducción directa de Agile / Scrum puede arruinar eso al instante. Porque ahora se espera que la gente juegue según las reglas. Sienten que lo que solían hacer no se aprecia, reciben 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 no tomarán ninguna iniciativa.

Las cosas empeoran y la conclusión es 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 las razones equivocadas, puede ser muy destructivo. p>     

  

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

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

Lo mismo sucede en ágil. Si tus necesidades se detienen en los artículos imprescindibles, obtienes un Fiat. Si tienes historias por excelencia, obtienes un Ferrari. Todo lo que Agil realmente aplica es que usted debe hacer lo primero . No construir un spoiler super cool durante dos años y luego faltar el plazo para el motor.

En pocas palabras: obtienes lo que necesitas. Si planeas un auto deportivo, obtienes un auto deportivo. Agile no cambia eso en absoluto. Si su proceso ágil presenta los requisitos para un Fiat, no culpe a los ágiles, culpe a los que solo requieren un Fiat.

  

Sin embargo, todos los procesos ágiles que conozco favorecen fuertemente los requisitos que deben ser. Estos siempre tienen la más alta prioridad.

Como deberían, mire su modelo Kano nuevamente: si no cumple con los requisitos, el cliente no aceptará el producto. Y luego tus encantadores no importan.

  

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

Nada podría estar más lejos de la verdad.

Los procesos ágiles suelen enfatizar estos puntos:

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

Nada le impide dar a las funciones de "deleite" una prioridad alta. Depende completamente de las personas que están a cargo de determinar las prioridades.

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

Agile no dice nada acerca de qué se debe hacer primero, solo ese código se debe escribir de manera incremental y se debe mantener en un estado liberable con la mayor frecuencia posible, en lugar de planearlo para que no se pueda utilizar durante meses hasta el próximo estado liberable.

He trabajado tanto bajo un proceso Agile como BDUF (Big Design Up Front), y aunque definitivamente puede obtener características innovadoras y atractivas de ambos procesos, en BDUF, como era de esperar, tiene que planificar para ellos 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 la próxima versión, y los gerentes de proyecto están estresados por lo que se incluirá en esa versión, porque si su función no se incluye, pasarán otros seis meses hasta el siguiente. Por lo tanto, hay una lista repleta de funciones en un calendario repleto, y si la baja clasificación y el archivo quedan atrapados trabajando durante dos o tres días en algo genial, solo piensan que al cliente le gustará y no está en la lista. Lista, arriesgan todo el horario y habrá un infierno que pagar.

En un proceso Agile, nos esforzamos por mantener el software en un estado de liberación, y los gerentes de proyectos están menos estresados porque si sus características se deslizan, solo pueden obtenerlo en dos semanas. Entonces, si un desarrollador regresa de una conferencia con una buena idea y pasa un par de días en algo, no está poniendo en peligro un programa de seis meses escrito en la sangre.

Básicamente, cosechas lo que siembras. Si fomenta la innovación y otorga a los equipos suficiente autonomía para entregar, la obtendrá. Si constantemente exige atajos para cumplir con los plazos, obtendrá un software que se corresponderá, independientemente de su metodología.

El excelente software proviene de dos cosas:

• Darle al cliente lo que necesita

• Ser un profesional

Hay muchos principios a seguir cuando se desarrolla un software. SECO, legible, SÓLIDO, etc., que no tiene nada que ver con los requisitos del cliente. El cliente pidió un coche deportivo. Si el cliente entendiera lo que se necesita para hacer que un auto deportivo sea asombroso, no lo necesitarían. Depende de usted averiguar 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 Agile tiende hacia el fiat solo cuando eso es lo que el cliente realmente quiere. No cuando eso es lo que piensan que tienen que conformarse.

La cascada es diferente porque una vez que un malentendido acerca de un requisito de autos deportivos de gama alta se ha asentado, tiende a quedarse. Agile puede hacer frente a la nueva información y adaptarse si resulta que lo que realmente necesitan es una bala.

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

Tu trabajo no es simplemente dar al cliente lo que quiere. También es para cuidar de cosas que sabes que no obtendrás ningún crédito. Cosas que el cliente nunca mencionará a menos que dejes que las cosas salgan horriblemente mal. Es mejor que estas cosas estén bien elegidas o tendrás mucha basura por perder el tiempo en ellas.

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

  

Por lo tanto, creo que uno no debería centrarse de manera servil en los requisitos imprescindibles.

Claro que deberías. Excepto cuando estes estimando tu tiempo. Porque esos requisitos imprescindibles no son la única consideración.

Ok,

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 "cualidades atractivas", depende del propietario del producto.

Si el propietario del producto exige un "diseño atractivo", se puede hacer 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é me facebook? Solo 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 Agile ayuda mucho: P)

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

• Agile pone énfasis en que algo funcione lo antes posible; sin embargo, esto significa hacer suposiciones simplificadas y recortes, especialmente en la infraestructura no visible para el usuario. No hay nada intrínsecamente erróneo 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 que sea lo más cercano a lo que se puede enviar, para que las partes interesadas y los gerentes de proyectos puedan decidir que "lo que tienen" es lo suficientemente bueno para empujar a la producción. Nuevamente, no hay nada malo con esto, si ha liquidado toda su "deuda técnica" (o al menos ha hecho las paces con cuánto tiene y dónde está). Sin embargo, en mi experiencia, mucho demasiada deuda técnica entra en producción con la promesa de un gerente de que "lo limpiaremos una vez que se elimine la presión para el envío", que se convierte rápidamente en "está en producción, tenemos que tener mucho cuidado con lo que cambiamos ahora ", que eventualmente se convierte en" ¡Nunca me dijiste que teníamos esa exposición! ¡La próxima vez tenemos que hacer un mejor trabajo! " La lección de Ben Frankin sobre "La amargura de la mala calidad permanece mucho tiempo después de que se olvida la dulzura del bajo precio" parece que nunca se aprende;
• Sin embargo, incluso con gerentes de confianza y desarrolladores bien disciplinados, existe el problema común de que simplemente el análisis, el diseño y la revisión de diseño simplemente demasiado poco se produce anterior a inicio del sprint en el que se espera que se inicie y se complete la implementación. El hecho de no considerar cuidadosamente las metáforas y diseños de IU alternativa es grande. Por lo general, es muy costoso revisar esto significativamente después de que se inicie un proyecto. el hecho de que los equipos junior no hayan estudiado cuidadosamente los productos de sus competidores, o que hayan dado prioridad a la definición e implementación de tecnologías de infraestructura como I18N, marcos de notificación, registro, seguridad y estrategias de control 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 a 5 sprints por adelantado realizando 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 piratear;
• He tenido un administrador de segundo nivel (de más de 100 desarrolladores) que desalentó a sus desarrolladores a tomarse el tiempo para escribir sus diseños planeados, 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 3 países. No hace falta decir que hubo muchos indicios sobre qué equipo iba a tener que trabajar muchas noches y fines de semana al final del proyecto una vez que se dieron cuenta de que todos pensaban que el otro chico era responsable de implementar alguna funcionalidad (o reimplementar porque los diseños del proveedor y del consumidor simplemente no encajaron)

En realidad, todo se reduce a si el gerente del proyecto y las partes interesadas ofrecen un producto de alta calidad. Si se comprometen a hacerlo, Agile lo habilitará. OTOH, debido a que Agile pone el cronograma en la toma de decisiones únicamente en manos de los interesados y el gerente del proyecto, Agile hace que sea difícil para un equipo de desarrollo entregar un excelente proyecto sin ese apoyo. En resumen: la responsabilidad por la calidad del producto se encuentra casi exclusivamente a los pies del (de los) gerente (s) 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 de gran valor.

Algunos chicos inteligentes introdujeron el desarrollo ágil para abordar los problemas a los que se enfrentan muchos proyectos de software en los procesos tradicionales.

Los valores clave del desarrollo ágil definidos por el manifiesto ágil (1) son,

• Personas e interacciones sobre procesos y herramientas
• Software de trabajo sobre documentación completa
• Colaboración del cliente sobre la negociación del contrato
• Respondiendo al cambio sobre seguir un plan

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

  

Pero, ¿nosotros (y el cliente) siempre sabemos de antemano lo que   Los requisitos imprescindibles son.

Ese es el punto entero. Al centrarse en los individuos, el cliente, el software en funcionamiento y los cambios en los requisitos, el desarrollo ágil le ayuda a descubrir qué quieren los clientes antes de que se entregue el producto final.

Esa es una razón por la que los marcos ágiles como Scrum tienen ciclos de iteración cortos cuyos resultados son productos de trabajo. 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 que se da cuenta de la calidad de los productos de un producto.

En los tiempos pasados, todavía es cierto en la actualidad, muchos proyectos de software desarrollados en enfoques tradicionales fracasaron, no tuvieron éxito o causaron descontento a los clientes debido a que no se alcanzó la calidad necesaria .

Además, el desarrollo ágil también le ayuda a alcanzar Calidad atractiva . Al reflejar el producto después de cada iteración, se ilustran 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 los Calidad inversa (atributos que conducen a la insatisfacción) del modelo Kano.

En cada proyecto hay requisitos que parecen ser buenas ideas al inicio del proyecto. Al cabo de un rato cambian al contrario y provocan desilusiones.

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

El desarrollo ágil le ayuda a identificar los requisitos que no funcionan o que no son satisfactorios a tiempo 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 de gran valor.

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 lo mínimo que apenas cumple con los requisitos necesarios?

Hay un aspecto temporal en el desarrollo de software ágil que resulta del enfoque iterativo y considerando comentarios 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 pueden convertirse en una calidad imprescindible en la siguiente iteración t + 1.

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

  

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

Teniendo en cuenta este aspecto temporal, es plausible que los métodos ágiles puedan producir productos de software de alta calidad mientras que se concentren en el mínimo . El enfoque iterativo combinado con comentarios de los clientes cambia las reglas del juego a lo largo del tiempo.

Conclusión

  

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

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

   > How to develop excellent software with agile methods?

• Cuando se produce un software individual específico para el cliente :
  • encuentre un cliente donde el costo no importe porque la característica "encantadora" cuesta dinero extra y el cliente debe decidir si quiere pagar por esto.
• Al producir Softwareproducts :
  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 (más barato) es lo mejor", no obtendrá el dinero para implementar características "encantadoras"

En un equipo de Scrum, el Producto-Propietario es responsable de elegir qué funciones 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 se limiten a procesos / metodologías ágiles.

Hay diferentes opiniones sobre cuáles son las características esenciales frente a las no esenciales. Para usar su ejemplo, alguien que compre un auto podría considerar que llamar la atención es una característica esencial y, por lo tanto, considera que un Fiat no cumple con este requisito indispensable. 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 otras características para poder ser vendido. Debido a que la persona que autoriza la compra con frecuencia no es un usuario final.
Por lo tanto, una característica que no es esencial para el usuario final puede ser esencial para vender el producto ... y, por lo tanto, también es esencial para la compañía que crea el producto.

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 las prioridades de manera adecuada. Pero eso no solo es cierto para las tiendas ágiles.

También es importante tener un propietario (s) / partes interesadas del producto que estén autorizados para tomar decisiones. Si las decisiones de su dueño del producto son constantemente rechazadas por alguien más, yo sería el primero en aceptar que eso es un problema, pero nuevamente, no es un problema con agile.

Hay otras cosas que desea en el (los) propietario (s) de su producto ... una descripción que escuché es "C.R.A.C.K." (colaborativo, representativo, autorizado, comprometido y bien informado). El propietario de un producto que carece de cualquiera de estas áreas puede significar problemas para un proyecto. Pero primero escuché 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 (ayuda) hacer ágil es traer algunos de estos problemas a la superficie.

Por ejemplo, la literatura de XP es IIRC bastante explícita acerca de que el "cliente" tenga conocimiento, sea 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ía de las funciones entregadas consisten en delicias 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 está entregando trabajo o casi. software operativo cada 2-3 semanas que cuando las entregas son meses o años aparte.

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

Por el contrario, la metodología de diseño inicial asume (de forma predeterminada) 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 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 desconectarse". Esto no es algo que se haya preguntado específicamente ... pero ¿no querría que su proceso sea capaz de responder a los cambios en el entorno empresarial (al menos en teoría)?

Agile no dice "no construir características no esenciales". Dice "permitir que la empresa decida qué características (no) construir".
... e (igualmente importante) "permita que los técnicos le digan cuánto tiempo tardará en construirse una característica que desea".

1. Los Must-be qualities son a menudo 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 las cosas que deben ser. Ese es el poder de Agile y es tonto ignorarlo .
2. One-dimensional qualities que significa promesas que deben cumplirse, son compatibles con la cascada OK, hasta que no estén cambiando. Aquí ser ágil solo ayuda, pero no tan poderosamente.
3. Attractive qualities son buenas características. Podrían convertirse en seres 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 la participación del representante del cliente apoyan estas cualidades muy bien. Para que podamos cambiar el alcance ligeramente durante el trabajo. Podemos negociar una mejora en un lugar para una compensación en otro. En cascada es prácticamente imposible. Sin un gran retraso en la organización, solo podríamos AGREGAR funciones de forma gratuita. Es posible, si previamente se asigna algún tiempo adicional al presupuesto.

Entonces, 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 comprenderlo en gran medida, debe establecer procesos ágiles con un representante responsable del cliente.