Con el propósito de generar metodólogas que impulsaran un software acorde a las necesidades del cliente y responder de mejor manera a los cambios que pudieran surgir a lo largo del desarrollo del mismo es que surgen alternativas a los procesos de desarrollo de software tradicionales. En este contexto se reúnen una serie de profesionales dedicados al área y surge el manifiesto ágil.
El manifiesto ágil consta de 4 valores y 12 principios.
Valores
- Valorar a las personas y las interacciones entre ellas por sobre los procesos y herramientas
- Valorar el software funcionando por sobre la documentación detallada.
- Valorar la colaboración con el cliente por sobre la negociación de contratos.
- Valorar la respuesta a los cambios por sobre el seguimiento estricto de los planes.
Principios
- Satisfacer al cliente con entregas tempranas y frecuentes de software.
- Aceptar el cambio incluso en etapas tardías del software.
- Entregar software funcionando en forma frecuente.
- Expertos del negocio y desarrolladores deben trabajar juntos.
- Construir proyectos en torno a personas motivadas. Generando el ambiente necesario.
- Promover las conversaciones cara a cara para la propagación dela información.
- Principal métrica de progreso : Software funcionando.
- Promover desarrollo sostenible.
- Atención continua a la excelencia técnica y buenos diseños para incrementar la agilidad.
- Simplicidad
- Equipos auto-organizados para las mejores arquitecturas, requerimientos y diseños.
- Equipo reflexiona acerca de como volverse mas efectivos , mejorando y ajustando su comportamiento.
Scrum es un marco de trabajo que utilizan los equipos para organizarse y trabajar para alcanzar un objetivo en común, no es una metodología.
Principios de Scrum:
1. Individuos e interacciones por sobre procesos y herramientas. Scrum se apoya en la confianza hacia las personas, sus interacciones y los equipos.
2. Software funcionando por sobre documentación exhaustiva. Scrum requiere que al final de cada sprint (se explicará más adelante qué es esto) se entregue producto funcionando. El progreso del proyecto se mide en base al producto funcionando que se entrega iterativamente.
3. Colaboración con el cliente por sobre la negociación de contratos.
4. Respuesta al cambio por sobre el seguimiento de un plan.
Valores de Scrum:
1. Foco
2. Coraje
3. Apertura
4. Compromiso
5. Respeto
Roles en Scrum
Product Owner
El Product Owner es el responsable del éxito del producto desde el punto de vista de los stakeholders. Dentro de sus responsabilidades están:
- Determinar la visión del producto, hacia dónde se dirige el equipo de desarrollo.
- Gestionar las expectativas de los stakeholders.
- Recolectar los requerimientos.
- Determinar y conocer las características funcionales de alto y bajo nivel.
- Generar y mantener un plan de entrega (release plan): fechas de entrega y contenido de cada una.
- Maximizar la rentabilidad del producto.
- Cambiar las prioridades según avanza el proyecto.
- Aceptar o rechazar el producto. Debe proporcionar feedback.
- Participar en la revisión del sprint junto a los miembros del equipo de desarrollo.
- Priorizar tareas.(PBIs)
- Velar por el correcto empleo y evolución de Scrum.
- Responsable de la asistencia del equipo a las distintas reuniones (daily, reviewa y retrospectivas)
- Asegurar que el equipo de desarrollo sea multifuncional y eficiente.
- Proteger al equipo de desarrollo de trabas o distracciones.
- Detectar y remover impedimentos.
- Asegura la cooperación y comunicación dentro del equipo.
- Lo conforman todas las personas necesarias para la construcción de software, personalmente he trabajado en equipo de hasta 5 desarrolladores con distinto niveles de experiencia, junior, semi-senior, senior.
- Es auto-organizado. Lo que quiere decir que el equipo determina la forma en que realiza el trabajo y como resuelve los problemas que se le presenten. Por eso y aunque no le mencione el texto es importante contar con miembros capacitados y con experiencia. En lo personal, mientras estudiaba no decían esto, y yo pensaba que al entrar al mundo laboral se me exigiría demasiado, pero rara vez esperan que un junior resuelva mucho. Un junior es un desarrollador con poca experiencia por lo general, solo meses , 1 año como máximo.
- Priorización por valor de negocio de cada PBI
- Priorización por retorno de la inversión (ROI) de casa PBI
Ahora, y más importante, mi opinión luego de trabajar en varias empresas es que pocas aplican el marco de trabajo como se debiera. Por lo general, la responsabilidad (e insisto, de acuerdo a mi experiencia) recae completamente sobre los desarrolladores. El Scrum Master poco conoce a su equipo y sus capacidades, y, por lo general, el Product Owner, si es que lo hay, sabe poco sobre lo que quiere porque la comunicación con los stakeholders es nula o escasa. Así que esto suena muy bonito teóricamente, pero en la práctica jamás lo he visto funcionar bien. Por otro lado, las empresas, sobre todo las consultoras o startups, no siempre contratan a las personas adecuadas para ahorrarse en salario, lo que lleva a veces a trabajar con personas que no cuentan con las capacidades necesarias, ni las habilidades ni la preparación.
Pd: ojala nadie que me vaya a contratar en el futuro lea estas ultimas líneas jajaja.
No hay comentarios:
Publicar un comentario