¿Cuál es mejor, la metodología Agile o Waterfall para la implementación del software CRM?

Los gerentes de proyecto de las compañías de desarrollo han discutido qué escuela de pensamiento es mejor, pero la verdad es que un método puede ser mejor que otro en ciertas situaciones y viceversa. Los elementos de estos dos enfoques se pueden combinar y utilizar para un rendimiento óptimo.

CASCADA

Como enfoque clásico para la gestión de proyectos, las etapas de este método siempre están en el mismo orden: Análisis – Diseño – Codificación – Pruebas – Despliegue. Este proceso debe usarse para un cliente que desea documentación de cada paso en el camino y para proyectos muy detallados que requieren mucha documentación. Esto no significa que mezclar elementos del enfoque ágil esté fuera de los límites, sino que el Método de la cascada debería ser la base sobre la cual se gestiona el proyecto.

ÁGIL

Este proceso se concentra en lanzar el producto final rápidamente y es más indulgente con los cambios en el camino. Requiere colaboración y reorganización a lo largo del curso del proyecto. Un momento apropiado para usar esta forma de gestión de proyectos sería cuando un cliente necesita su producto final en el mercado rápidamente.

Aquí en la ruta escalable nos encanta el método ágil y lo preferimos a la cascada, sin embargo, sin un estilo de planificación en cascada por adelantado, es difícil ver el panorama general y saber en qué se está metiendo desde una perspectiva de tiempo y dinero. Aconsejamos a nuestros clientes que se tomen el tiempo para pensar y explicar sus ideas de productos utilizando un simple Documento de requisitos del producto antes de construir su producto con Agile.

La combinación de estas dos metodologías ayuda a superar muchos de los desafíos que a menudo enfrentan los equipos de desarrollo y las empresas, que incluyen:

a. Expectativas falsas o poco realistas.

si. Falta de tiempo y / o hitos poco realistas.

do. Requerimientos hinchados o insuficientes.

re. Falta de fondos.

El uso de la metodología de desarrollo de software Scrum, que se ajusta dentro del marco Agile, es un motor para superar estos obstáculos. Scrum como metodología es simple y sus métodos son repetibles, pero su práctica disciplinada y diaria no es necesariamente tan fácil. Uno de nuestros objetivos principales en el camino escalable es utilizar Scrum como una metodología verdaderamente relevante para impulsar los proyectos hasta su finalización y ofrecer la satisfacción del cliente.

¿Qué hace que Scrum sea tan efectivo? Scrum facilita la comunicación creando bucles de retroalimentación. Queremos que los desarrolladores se mantengan sincronizados entre sí y queremos que el cliente se mantenga en contacto con el equipo de desarrollo. También queremos crear ciclos de desarrollo en los que el cliente pueda ver resultados tangibles y dar su opinión con anticipación.

No hay nada como trabajar en una fecha límite durante meses solo para descubrir que el cliente estaba anticipando un resultado diferente. Los métodos de Scrum están diseñados para ayudar a eliminar las brechas en la comprensión del equipo de desarrollo de lo que un cliente quiere para que los objetivos del proyecto se alcancen de manera rápida y transparente.

Aquí hay algunos consejos específicos sobre cómo usar los métodos Scrum con éxito:

1. ACLARAR, ACLARAR, ACLARAR

Estás en una reunión y la conversación va y viene. Todos los demás dicen “Genial, tiene sentido para mí”. El problema es que no tiene sentido para ti, pero no quieres ser “ese tipo”, ¿verdad? Bueno, no te avergüences y no te dejes engañar pensando que tiene sentido para todos los demás. La claridad es el trabajo de todos y obtener claridad más tarde suele ser más costoso. Una vez que tenga claridad, documente la decisión .

2. UTILICE LAS HERRAMIENTAS CORRECTAS

Todos tienen su bolsa de trucos, sus herramientas de referencia. Personalmente, me gusta la combinación de JIRA Agile combinada con Stash, pero hay muchas otras herramientas excelentes que te ayudarán a hacer lo mismo. Si es posible, encuentre algo que le permita visualizar el estado de un sprint como un tablero Kanban. Las herramientas para las revisiones de código también son muy importantes. Si es demasiado difícil de hacer, no sucederá. El software adecuado no tiene que costar una fortuna, pero puede marcar una gran diferencia en el éxito de un proyecto.

yo. Use JIRA, Podio y alternativas para la revisión de código

ii) Usa Git para el desarrollo y la colaboración remota

iii) Utilice Slack para la comunicación y las integraciones (la integración de JIRA con Slack ha facilitado todas nuestras vidas)

iv. Use GoToMeeting / Google Hangouts, aparezca. En para la comunicación remota

3. ESCRIBE BUENAS HISTORIAS

No asuma que todos recordarán cada objetivo y fijarán cada característica discutida en una reunión. Después de hablar sobre una función, es fácil alejarse y olvidar los detalles sobre la decisión que se tomó. Puede parecer obvio, pero generalmente no se hace bien. Esto vuelve al consejo # 1 , la falta de claridad es uno de los mayores problemas que puede tener. Así que escribe buenas historias y mantenlas actualizadas.

4. TIMEBOX TUS SPRINTS

Cuando decides la duración de un sprint para tu equipo, es mejor cumplir con la duración acordada (1 a 4 semanas como máximo). No solo estire la longitud de todas formas. Si son dos semanas, no extiendas el sprint a tres semanas porque una determinada característica necesita salir. El sprint es tu cadencia, tu sección de ritmo. Ayuda a mantener el impulso. Un sprint también conlleva cierto grado de carga mental. Ahora, si estás empezando a tartamudear porque crees que me estoy perdiendo un punto muy importante sobre lanzamientos y plazos, quédate conmigo, ahí es donde entra mi próximo consejo.

5. DESACUPAR LA IDEA DE UN SPRINT Y UNA LIBERACIÓN

¿Es un sprint lo mismo que un lanzamiento? Es fácil pensar en ellos como lo mismo, pero ¿con qué frecuencia liberas un hotfix a mitad del sprint? ¿O qué pasa con la implementación continua? Ciertamente puede desplegar más de una vez en un sprint. Realmente se reduce al control de calidad, y si planea hacer lanzamientos rápidos, probablemente necesitará invertir en la automatización de su prueba.

6. BEBE EL KOOL-AID

Escribir software es un desafío. Es especialmente difícil cuando los desarrolladores y las partes interesadas de la compañía tienen ideas completamente diferentes sobre cómo debería hacerse. Scrum es una herramienta que funciona mejor cuando todos aceptan comprar el proceso y beben el Kool-aid juntos. Una forma que puede ser útil para obtener la aceptación es que las personas en varios puestos de la empresa tomen la capacitación Scrum. Puede parecer un gasto costoso, pero en realidad es bastante razonable y más rentable que crear software que nadie quiere.

Incluso con las mejores metodologías, las mejores herramientas y las mejores personas, su éxito como profesional de Scrum no es una garantía. Las personas correctas y la idea correcta no siempre y automáticamente se traducen en éxito. Crear productos exitosos es una combinación de gran talento, cultura correcta y líneas claras de comunicación. A menudo es más arte que ciencia. Las personas a menudo tratarán de cambiar la metodología porque no está funcionando, pero a veces el problema es mayor con el negocio y sus procesos. Esos procesos pueden ser rotos y disfuncionales. Ha habido casos en los que el CEO no quería que los desarrolladores tuvieran mucho que decir sobre las cosas que perjudicaban su trabajo y, como resultado, creaba estrés y productos de calidad inferior. Dejó al equipo profundamente frustrado con un mal gusto, una mala experiencia y, en última instancia, un producto fallido.

Al comprometerse y configurar su próximo proyecto de desarrollo, asegúrese de haber abordado los problemas que podrían afectar ese proyecto desde una perspectiva comercial. Arregle sus procesos comerciales para permitir que Scrum funcione.

Si bien puede encontrar dos enfoques “rivales”: Waterfall y Agile, nos sentimos cómodos con algo intermedio que es Water-Scram-Fall.

Algo así

Como empresa de outsourcing, generalmente necesitamos aportes adicionales y más tiempo para conocer los objetivos del cliente, siempre y cuando no podamos comunicarnos con frecuencia o el cliente no pueda simplemente pasar y hablar con nosotros.

Otra limitación es que el 90% de nuestros primeros clientes conocidos desean especificaciones estrictas y un presupuesto exacto. Afrontemos el hecho: nadie está dispuesto a dar su dinero por una promesa y seguir el modelo de precios de Time & Material con un extraño.

Por lo tanto, las dos primeras partes del ciclo de vida del desarrollo se realizan utilizando el modelo Cascada.

  1. Evaluación de riesgos.
  2. Claro especificaciones.
  3. Planificación rigurosa.
  4. Casos de uso claros.
  5. etc.

Pero cuando se trata de casos de uso, surgen preguntas adicionales sobre la funcionalidad y la programación. Incluso con un PM profesional hay numerosas dudas e incertidumbres. Para algunas de las preguntas, el cliente no puede responder de antemano porque necesita tiempo para realizar la prueba. Esto es cuando puede ser cauteloso.

Por lo tanto, tomamos métodos ágiles como Scram y dividimos la parte de desarrollo en sprints mucho más pequeños para hacer un almuerzo rápido del prototipo o MVP, para que el cliente pueda resolver las cosas y tomar una decisión.

El enfoque de Scram también ayuda enormemente a los miembros de nuestro equipo a conocer a los clientes comerciales y autoorganizados. A partir de este momento, PM se convierte en un proxy entre el cliente y el equipo autoorganizado.

En las últimas etapas, después de ganar la confianza del cliente, el proyecto generalmente cambia a Kanban (si necesita mantenimiento) o Scram (si el proyecto está creciendo rápidamente). + Precios de tiempo y material.

Puede encontrar más acerca de las metodologías de desarrollo de software en esta publicación de blog: Cómo mejorar el modelo de desarrollo de software en cascada con enfoques ágiles

Por cierto estrictamente hablando, Agile es una mentalidad, no es una metodología de desarrollo de software.