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

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.