Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anterior Revisión previa Próxima revisión | Revisión previa | ||
|
cap:scrum [2017/05/06 12:38] user [Transición de métodos tradicionales a SCRUM] |
cap:scrum [2018/02/20 09:13] (actual) |
||
|---|---|---|---|
| Línea 18: | Línea 18: | ||
| =====Transición de métodos tradicionales a SCRUM===== | =====Transición de métodos tradicionales a SCRUM===== | ||
| - | La transición consiste en un cambio de paradigmas, un cambio en la manera de pensar sobre como se hacían y como se deben de hacer las cosas, cosiste en entender que ya no se esta trabajando a un cliente como tal, que no le estas vendiendo un producto, en que ya no existe esa barrera de Cliente-Proveedor, con acuerdos legales y clausulas de lo que se debe hacer y no se debe hacer. | + | Para adaptarse a SCRUM es necesario cambiar: |
| - | Es mas un estilo de vida donde el interés de ese grupo de gente que requiere un producto para maximizar su desempeño, es el mismo interés que compartimos por darle ese producto que tanto anhela, que independientemente del lado en el cual se esté trabajando nuestros esfuerzos van enfocados mas allá de ofrecer un simple producto si no de alcanzar aquellas metas por las cuales hemos estado trabajando tanto tiempo. Ya no somos mas un grupo de consultores que viene a venderle ideas sobre como hacer las cosas, somos un grupo de colaboradores que venimos a reforzar ese esfuerzo por lograr los objetivos que tenemos enfrente. | + | * **Los paradigmas sobre el levantamiento de análisis** - En metodologías agiles lo importante es la tendencia al cambio, debemos entender procesos, necesidades, prioridades, valores. Esto es fundamental para aceptar los cambios. |
| - | + | * **La manera en como se ve a un cliente** - Ya no existe el cliente, existen colaboradores que requieren maximizar su rendimiento, productividad, eficiencia, eficacia, y nosotros nos convertimos en un colaborador mas que trabaja con ellos para hacer esto posible. | |
| - | Cuando realmente tenemos interés por dar el máximo rendimiento solemos eliminar cosas que no son de suma importancia, aun así es importante cuidar el orden de las cosas que queremos hacer, SCRUM no es una metodología rígida, y si su principal ventaja es la adaptación al cambio, SCRUM también aplica ese principio a sí misma, podemos adaptar SCRUM a nuestra necesidad para ofrecer el máximo rendimiento, pero para esto necesitamos primero haber masticado, comido, hablado, dormido y soñado SCRUM. | + | * **El creer que se vende un producto** - El producto no es lo importante, lo importante es la colaboración que existe entre todos los involucrados orientados a un mismo objetivo, son los lazos que se generan en pro de hacer esto posible, el producto es el resultado de los esfuerzos de colaboración entre los equipos de alto rendimiento. |
| + | * **La barrera de Cliente-Proveedor** - Dejan de existir acuerdos legales, cláusulas, penalizaciones y todo aquello que hacen doloroso la colaboración, ya que no debe de existir obligación jurídica, más bien debe existir corresponsabilidad y participación activa. | ||
| + | No sólo la manera de pensar es lo que debe de cambiar, también cambian los documentos ya que SCRUM, elimina la carga de trabajo hacia estos y deja sólo aquellos que son realmente importantes y que generan valor para el proceso de desarrollo de software. | ||
| ==== Los Documentos ==== | ==== Los Documentos ==== | ||
| + | |||
| + | En un modelo tradicional se tienen los siguientes documentos: | ||
| + | |||
| + | **Acta de negocio**.- Es el documento con el cual se da inicio al ciclo de vida de desarrollo del software, refleja la necesidad y justificación del cliente por obtener un producto y define las reglas iniciales sobre las cuales se gestionará este desarrollo. | ||
| + | |||
| + | **Acta de requerimiento**.- Es el documento donde se detallan los requerimientos tanto funcionales como no funcionales, declara quiénes son los usuarios claves del proyecto tanto de las áreas de negocio cómo de las áreas de sistema, también declara la matriz de comunicación que se utilizará durante el proyecto, así como los involucrados que deberán ser considerados para la ejecución del mismo, pueden existir varias actas de requerimiento para una acta de negocio. | ||
| + | |||
| + | **Documento de análisis**.- Es el resultado del análisis realizado de acuerdo a la necesidad estipulada en la acta de negocio, este documento contiene las reglas de negocio, los roles involucrados, los casos de uso, los procesos que afectan, los procesos con los cuales tiene relación, su impacto tanto vertical como horizontal, entre otros datos, tiene una relación directa con los requerimientos funcionales declarados en el acta de requerimiento, pueden existir varios documentos de análisis por cada acta de requerimiento. | ||
| + | |||
| + | **Solicitud de cambio**.- Es el documento que declara el inicio del proceso de desarrollo, define quiénes son los involucrados que participarán en el proyecto y los roles que cada uno ejecutará, también define las fechas de las diferentes reuniones que se realizarán y declara qué requerimientos funcionales del acta de requerimiento serán desarrollados en este proceso, pueden existir varias solicitudes de cambio por acta de requerimiento. | ||
| + | |||
| + | **Casos de prueba**.- es el documento en el cual se comprueba que cada uno de los flujos definidos en el análisis fueron desarrollados conforme a los requerimientos dados y que cumple en todos los aspectos con el control de calidad definido por la organización, deberían de existir tantos casos de prueba cómo casos de usos estén definidos. | ||
| + | |||
| + | **Aprobación de QA**.- Este documento es generado por el Departamento de aseguramiento de calidad y eso aprobación de que cumple con todos los estándares definidos así como el proceso que está definido. | ||
| + | |||
| + | **Solicitud de cambio a producción**.- este documento contiene la información técnica necesaria, es decir, archivos que sufrieron cambios, archivos nuevos, archivos eliminados, configuración, servidores y ambientes que afectan y las distintas aprobaciones que se requieren para que el cambio sea publicado, además especifica la fecha deseable en la cual deberá ser publicado el cambio y define los mecanismos de retroceso en caso de fallos. | ||
| + | |||
| + | **Bitácora de liberación**.- este documento lleva un control de las liberaciones realizadas, así como de los fallos que se han presentado Al momento de ejecutar las liberaciones. | ||
| + | |||
| + | En un modelo ágil sólo se definen los documentos que son necesarios para cubrir las necesidades de la empresa sin entorpecer la velocidad de desarrollo. | ||
| + | |||
| + | **Minuta de Sprint planning**.- Este documento es la evidencia de todo aquello acordado durante el proceso de Sprint planning, entre los datos que podemos ver se encuentran los siguientes: | ||
| + | * número de iteraciones. | ||
| + | * duración de cada iteración. | ||
| + | * calendario de la reunión diaria. | ||
| + | * duración de la reunión diaria. | ||
| + | * calendario de presentación de avances. | ||
| + | * duración de la presentación de avances. | ||
| + | * calendario del Sprint review. | ||
| + | * duración del Sprint review. | ||
| + | * calendario de Sprint retro. | ||
| + | * duración del Sprint retro. | ||
| + | * involucrados en el proyecto. | ||
| + | * rol de cada involucrado. | ||
| + | * herramientas a utilizar. | ||
| + | |||
| + | **Sprint backlog**.- este documento es la priorización por iteración de las historias usuario a desarrollar, es el resultado del Sprint planning. | ||
| + | |||
| + | **Minuta de reunión diaria**.- este documento es la evidencia de todo lo que se vio en la reunión diaria, entre los datos que podemos ver se encuentran los siguientes: | ||
| + | * tareas terminadas. | ||
| + | * tareas no terminadas. | ||
| + | * causa de las tareas no terminadas. | ||
| + | * tareas a trabajar en este día. | ||
| + | * tareas a terminar en este día. | ||
| + | * cambio de prioridades de historias de usuario. | ||
| + | * justificación del cambio de prioridades de historias de usuario. | ||
| + | * impedimentos que ponen en riesgo la terminación de alguna tarea. | ||
| + | |||
| + | **Minuta de Sprint review**.- este documento es la evidencia de lo que se vio en el Sprint review, entre los datos que podemos ver se encuentran los siguientes: | ||
| + | * historias de usuario terminadas. | ||
| + | * oportunidades de mejora. | ||
| + | * necesidades para el siguiente Sprint. | ||
| + | * decisión del product owner sobre la liberación del producto. | ||
| + | |||
| + | **Bitácora de liberación**.- este documento lleva un control de las liberaciones realizadas, así como de los fallos que se han presentado Al momento de ejecutar las liberaciones. | ||
| + | |||
| + | **Minuta de Sprint retro**.- este documento es la evidencia de lo que se vio en el Sprint retro, entre los datos que podemos ver se encuentran los siguientes: | ||
| + | * riesgos detectados en la iteración que terminó. | ||
| + | * plan de mitigación de los riesgos detectados. | ||
| + | * oportunidades de mejoras para el siguiente Sprint. | ||
| + | |||
| ==== Los Levantamientos ==== | ==== Los Levantamientos ==== | ||
| ==== Las Herramientas ==== | ==== Las Herramientas ==== | ||
| + | |||
| + | ==== Tú ==== | ||