El Camino DevOcho

Nos apasiona entregar un gran software. Nuestro equipo tiene experiencia trabajando con casi todos los tamaños y tipos de empresas, desde pequeñas y medianas empresas hasta empresas Fortune 500. Con más de 25 años de experiencia y cientos de proyectos completados, nuestro fundador ha desarrollado una forma infalible de entregar un gran software. Lo llamamos "El Camino DevOcho".

Cuando asocias con DevOcho para ampliar tu equipo y entregar proyectos, estás contratando un grupo de personas que saben cómo hacer las cosas. Esto se debe en gran parte a nuestro proceso "DevOcho Way". Creemos que esto realmente nos diferencia en la industria.

No vamos a revelar todos nuestros secretos comerciales aquí, pero aquí tiene un adelanto de cómo entregamos un proyecto exitoso. Esto ayudará a establecer sus expectativas de lo que es trabajar con nosotros.

Creemos que Agile Scrum es una excelente manera de organizar el trabajo. También creemos que puede ser algo improductivo sin unas directrices que ayuden a mantenerlo encaminado. Hemos tomado el manifiesto Agile estándar + las directrices de Scrum.org y hemos añadido algunos elementos que creemos que nos dan una ventaja sólida al entregar proyectos complejos.

Sabemos que hay personas que aman Scrum y piensan que es perfecto. También sabemos que hay personas que lo odian absolutamente. Y hay un espectro completo de personas que están en algún punto intermedio. Hemos desarrollado una versión ligeramente modificada que encaja muy bien para construir proyectos complejos rápidamente. Nuestro secreto es añadir dos ceremonias formales al proceso estándar de Scrum. Añadimos una Ceremonia de Planificación de Características y una Ceremonia de Aprobación de Características. Al llevar a cabo estas ceremonias una sprint antes de que se necesiten las historias de usuario, mantenemos un registro de producto muy ordenado para el Equipo Scrum. Esto reduce el tiempo del Desarrollador, DevOps y QA en las reuniones de planificación (que les encanta) y los mantiene enfocados en la construcción.

Ejecutamos los dos bucles anteriores en paralelo. El Planificación de Características lleva a la Desarrollo de Características por un sprint. Durante el sprint, el Scrum Master, UI/UX y Líder Técnico de tu proyecto trabajará con tu equipo para planificar las características que el equipo construirá en el próximo sprint. Este proceso crea un enfoque de planificación constante, justo a tiempo, que garantiza que estamos planificando con la última retroalimentación del usuario y la mejor oportunidad para diseñar las características que son mejores para el usuario.

Esto también permite que la planificación de Sprint se mantenga en gran medida enfocada en los aspectos técnicos de las Historias de Usuario, para que los Desarrolladores, DevOps y QA se mantengan comprometidos. Lo que tiene el beneficio adicional de hacer que estas reuniones sean más rápidas.

Hay mucha más sutileza aquí, por ejemplo, tenemos formas muy específicas de crear tickets, wireframes, maquetas, documentación técnica, etc., pero estos son los detalles que rápidamente te enamorarás cuando nos contrates. Somos muy consistentes en cómo documentamos nuestro trabajo.

Las tres áreas que creemos que serán interesantes para las personas que son "nerd de procesos" como nuestro fundador.

En cada proyecto, comenzamos con una sprint dedicada a la planificación. El objetivo es que el cliente tenga un buen comienzo en un Plan de Producto y para que nuestro equipo lo entienda. Preferimos llevar esto como una sesión de planificación de dos semanas donde bloqueamos a todos en una sala y elaboramos un plan preliminar. Si este proyecto es una prioridad para la empresa, esto normalmente es posible. Si este proyecto es más un añadido agradable, tendremos que ser más flexibles con el tiempo de los interesados.

Creemos que las rutas de producto son documentos vivos que cambiarán a medida que el producto madure y aprendamos más sobre las necesidades de los usuarios y del mercado en general. No estamos buscando la perfección en esta etapa, solo los componentes principales.

Típicamente, los miembros de los Desarrolladores, DevOps y QA no forman parte de esta reunión. Utilizan este tiempo para configurar la base de código, crear las líneas de CI/CD automatizadas (que les ahorrará tiempo más adelante) e instalar y configurar cualquier software o herramienta específica que su proyecto requiera.

Salida

• Versión inicial del plan de producto
• Código base, herramientas y configuración para tu Proyecto

Mantenemos un sprint paralelo al sprint del desarrollador. Lo llamamos el "Sprint de Planificación de Características". Aquí es donde el cliente, el Scrum Master, los líderes del equipo de Desarrollo y los miembros del equipo de UI/UX planifican y documentan Historias de Usuario para el Backlog del Producto. El cliente elegirá los elementos de mayor prioridad del Roadmap y el equipo entonces los desglosará en unidades de trabajo más pequeñas llamadas "Historias de Usuario". De esta manera, el cliente establece la prioridad y el equipo es capaz de documentar los requisitos y los wireframes necesarios para llevar a cabo el trabajo antes de que los desarrolladores se involucren por completo.

Somos capaces de hacer esto porque tenemos líderes técnicos fuertes. Se unen a esta sesión de planificación para asegurarse de que el trabajo solicitado sea posible y ayudan a guiar el tamaño de cada unidad de trabajo para asegurar que se ajuste al proceso.

Salida

• Historias de usuario
• Tickets de tareas (típicamente relacionados con DevOps)
• Lista de Producto Actualizada
• Hoja de ruta actualizada

Aquí es donde se realiza el trabajo. Los desarrolladores, QA, UI/UX y DevOps tomarán trabajo del Producto Prioritario y lo colocarán en el Backlog del Sprint. Desde allí, dividirán y conquistarán. Cada miembro del equipo se enfocará en el trabajo que se comprometió a completar en el plazo del Sprint. Normalmente hacemos sprints de dos semanas, pero ocasionalmente extendemos esos hasta sprints de 4 semanas si tiene sentido para nuestro cliente. Extraemos trabajo de la parte superior del backlog para que las prioridades del cliente se mantengan.

Nuestro objetivo en cada sprint es lanzar software funcional. Normalmente no esperamos hasta el final del sprint porque preferimos trabajar en un modelo de Entrega Continua, pero nos adaptamos a las necesidades regulatorias y de cumplimiento de nuestros clientes.

Salida

• Software funcionando