Analista de sistemas. Una breve guía de la profesión. Parte 5. Metodologías de desarrollo. Cascada y ágil
En este artículo, aprenderá sobre las principales metodologías de desarrollo de software ampliamente utilizadas, como Waterfall y Agile (Scrum, Kanban), y se familiarizará con sus principales funciones, artefactos y procesos.
Este texto es artículo de revisión y está dirigido a recién llegados a la industria TI, destinado a quienes quieran familiarizarse con la profesión, conocer sus contenidos, principios básicos, prácticas y herramientas utilizadas en la misma.
Enfoque del proyecto. Cascada
Dividir todas las metodologías de gestión de proyectos en ágiles y no ágiles es una forma generalmente aceptada de clasificar los enfoques para organizar el proceso de desarrollo de software.
Cascada (modelo en cascada/cascada): un modelo del proceso de desarrollo de software en el que el proceso de desarrollo se ve como un flujo, pasando secuencialmente por las fases de análisis de requisitos, diseño, implementación, prueba, integración y soporte.
Normalmente, el modelo en cascada se utiliza en equipos que trabajan en un paradigma de enfoque de proyectos.
Los procedimientos y procesos básicos para la gestión de proyectos se describen en la norma. PMBOKbasado en el concepto de gestión de proyectos a través de un grupo de procesos estándar. Buen artículo sobre Habré.donde podrás saber más sobre qué es y por qué.
Ventajas: El modelo en cascada es simple y comprensible, y también es aplicable en presupuesto y plazos fijos.
Contras: Sin embargo, sus desventajas son falta de flexibilidad para cambiarlo que conlleva grandes riesgos: la aparición de errores en las últimas etapas puede provocar el incumplimiento de los plazos o un aumento del presupuesto de desarrollo.
Metodologías ágiles. Ágil
Ágil es una familia de metodologías flexibles de gestión de proyectos. Agile incluye los marcos principales: Scrum, Kanban, Lean, LeSS, SAFe.
La esencia de Agile está contenida en sus cuatro puntos manifiesto:
Las personas y sus interacciones son más importantes que los procesos y las herramientas.
Un producto funcional es más importante que una documentación completa.
La cooperación del cliente es más importante que los términos del contrato.
Responder al cambio es más importante que seguir un plan.
Principales ventajas Ágil es una alta flexibilidad para cambiar, velocidad para introducir nuevas funciones y riesgos reducidos debido al desarrollo iterativo y la capacidad de recibir comentarios sobre el producto a medida que se desarrolla.
Principales desventajas son las dificultades para planificar los cronogramas y presupuestos de desarrollo.
Melé
Con Scrum, el producto no se desarrolla de una vez, sino en partes: cada una de ellas se implementa en el marco de un sprint.
Guía de scrum Describe claramente la composición del equipo necesaria para desarrollar el producto. Cada participante tiene su propio rol, cada uno es responsable de su parte del trabajo para poder satisfacer eficazmente las necesidades del negocio.
El equipo Scrum incluye: Product Owner, Scrum Master, equipo de desarrollo.
Propietario del producto – una persona responsable del producto en su conjunto. Supervisa cómo se desarrollará el producto, establece prioridades, supervisa los plazos y se comunica con las partes interesadas.
Maestro de scrum — la persona responsable de adherirse a los principios de Scrum en el equipo y ayuda a mantener el proceso de trabajo.
equipo de desarrollo – un grupo de personas (normalmente hasta 10 personas) que desarrollan un producto, por ejemplo: diseñadores, analistas de sistemas, desarrolladores e ingenieros de pruebas.
Atributos de comandoque funciona según Scrum:
Cartera de productos – una lista ordenada de tareas mantenida y actualizada por el propietario del producto.
Incremento de producto — una parte terminada de un producto que satisface una necesidad del usuario.
Sprint — este es el intervalo de tiempo (normalmente dos semanas) durante el cual se desarrolla la funcionalidad del producto.
Sprint de cartera de pedidos — una lista ordenada de tareas planificadas para el sprint actual.
tablero de desarrollo — visualización visual de las tareas del equipo de desarrollo en el sprint actual con estados (generalmente: Trabajo pendiente, En progreso, Pruebas, Hecho).
El equipo Scrum participa regularmente en varios actividades:
Trabajar con la cartera de productos y la planificación de sprints — el equipo debe decidir el objetivo del sprint y seleccionar las tareas del trabajo pendiente del producto que deben realizarse para el próximo sprint. Antes de esto, es necesario evaluar todas las tareas y ordenarlas por prioridad. Los más importantes deben tomarse primero.
A diario (diario – diario) – durante el sprint, el equipo se reúne para reuniones diarias – diariamente. En estas reuniones, los miembros del equipo comparten los resultados de su trabajo y hablan sobre los problemas que encontraron.
Aseo (groom – comb), también conocido como refinamiento de la cartera de productos (PBR, refinamiento de la cartera de pedidos): durante el sprint, el equipo reúne y analiza las tareas existentes o emergentes.
Demostración (demostración): el equipo demuestra los resultados de su trabajo a los usuarios o clientes. Así es como obtiene retroalimentación. (Generalmente se hace al final del sprint, pero a menudo en la realidad, antes de lanzar cualquier funcionalidad a la etapa de prueba).
Retrospectivo (retro) – Antes de comenzar un nuevo sprint, el equipo realiza una retrospectiva. Una retrospectiva es un evento en el que todo el equipo discute los aspectos positivos y negativos de trabajar juntos durante el sprint anterior.
En Scrum, existen dos tipos de criterios para las tareas:
Definición de listo — el criterio de preparación de una tarea para que pueda pasar del backlog al sprint, por regla general, es la presencia de una descripción de la tarea y sus dependencias, una determinada prioridad de la tarea y una complejidad estimada; .
Definición de hecho — una lista de criterios mediante los cuales el equipo determina la finalización exitosa de la tarea.
Kanban
Kanban no dicta reglas claras para la composición, roles y funciones del equipo de desarrollo. Kanban ofrece un conjunto de herramientas y prácticas que ayudan a mejorar el desempeño del equipo.
Kanban es una metodología que se enfoca en visualizar las tareas en las que el equipo está trabajando actualmente. Dependiendo de las prioridades, es posible que lleguen nuevas tareas y se realicen cada día.
Las principales herramientas en el trabajo de un equipo Kanban son tablero kanbanque consta de columnas con estados, normalmente: Hacer (planificado) – En curso (en curso) — En control de calidad (en pruebas) – Hecho (hecho).
En Kanban también puedes monitorear las prioridades de las tareas y usar una escala para esto:
Bajo (Las tareas de baja prioridad, por regla general, no tienen ningún impacto en el producto).
Medio (tareas planificadas que afectan al producto).
Alto (tareas que afectan al producto y que deben realizarse primero).
bloqueador (tareas que afectan al producto, bloqueando trabajos paralelos o posteriores).
La principal diferencia entre Kanban y Scrum es la siguiente:
Un equipo Scrum trabaja en sprints, cada uno de los cuales suele durar dos semanas, mientras que con Kanban el trabajo es continuo.
Kanban le permite responder rápidamente a los cambios, es decir, asumir nuevas tareas inmediatamente cuando el equipo de desarrollo las tenga, y Scrum le permite planificar el trabajo del equipo para el siguiente sprint para que las nuevas tareas no entren en el foco del equipo hasta que termina.
Entonces, en un equipo ágil flujo de trabajo del analista de sistemas en la mayoría de los casos se parece a esto:
requisitos recopilados;
describió los requisitos (requisitos comerciales, requisitos funcionales y no funcionales);
acordado con las partes interesadas (stakeholders);
diseñado DAN (diseño de alto nivel);
discutido con el equipo;
LLD diseñado (arquitectura de solución, integración);
discutido con el equipo: descompuso las tareas y estimó los plazos;
entregado al desarrollo – participó en las pruebas y aceptación de los resultados.
Matriz de Responsabilidad
Al diseñar o cambiar procesos, es necesario organizar las responsabilidades y relaciones entre los roles involucrados en el proceso.
existe método (matriz) FRESCOque es un medio conveniente y visual para identificar la participación de varios roles en procedimientos y procesos. Suele ser conveniente mantener una lista de roles para evitar confusiones en las comunicaciones cuando se trabaja en un proyecto o tarea.
El término RACI es un acrónimo de:
R – Responsable (realiza);
A – Responsable (respuestas);
C – Consultar antes de hacer (consultas);
I – Informar después de hacer (informado).
En cada trámite a cada rol se le debe asignar una u otra letra, mientras que Responsable debe ser solo una, Responsable debe estar disponible para cada trámite, cada trámite debe tener Responsable y Responsable.
En este artículo, conoció las principales metodologías de desarrollo de software más utilizadas, como Waterfall y Agile (Scrum, Kanban), y se familiarizó con sus principales funciones, artefactos y procesos.
Este artículo es el último de una serie sobre los conceptos básicos de la profesión de analista de sistemas.
Espero que te haya resultado útil y hayas podido aprender algo nuevo por ti mismo y tal vez incluso elegir esta profesión.
Puede encontrar este y otros artículos sobre análisis de sistemas y arquitectura de TI en mi pequeño y acogedor canal de Telegram: Notas de un analista de sistemas
