Preparando el escenario: Agiles y Scrum #scrum enero 26, 2012
Posted by arevalomaria in Metodologías Ágiles.add a comment
Como mucha gente, nos entusiasma la adopción de Metodologías Agiles cuando trabajamos con proyectos de desarrollo de software, en particular la adopción de Scrum.
Para quienes hemos participado como Gerente de Proyectos con metodologías tradicionales para aplicar lineamientos de seguimiento y control, podremos observar que Scrum hace que el equipo de desarrollo de software alcance mejores rendimientos y niveles de productividad, debido Scrum nos enseña cómo dar unos pasos atrás para reflexionar sobre lo que hacemos y aprender a mejorar nuestras técnicas y procesos con nuevas ideas y conceptos.
Scrum nos ayuda a superar obstaculos, en forma ágil a traves del aprendizaje, todo cambio es dificil si no se gestiona adecuadamente, pero un buen manejo de las dificultades puede convertirse en oportunidades para mejora del proyecto.
¿Qué es la Fundación de Software Ágil Desarrollo y Gestión de Proyectos?
En 2001, un grupo de expertos en software se reunieron en la localidad de Utah, Snowbird para redactar lo que se conoce como el Manifiesto Ágil (www.agilemanifesto.org):
” Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:
a. Individuos e interacciones sobre procesos y herramientas
b. Software funcionando sobre documentación extensiva
c. Colaboración con el cliente sobre negociación contractual
d. Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.”
Los doce Principios del Manifiesto Ágil:
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Aunque el Manifiesto Ágil se redactó en 2001, pocos años después de Scrum, es un hecho bien conocido entre los expertos que el manifesto tiene una gran influencia en Scrum.
Esta influencia fue evidente en el segundo libro de Ken Schwaber, Gestión ágil de proyectos con Scrum, siendo Scrum una de las metodologías ágiles con los valores y principios que se mencionan en el Manifiesto Ágil.
Es importante destacar en este momento la declaración de interdependencia realizada en el 2005 para Proyectos Agiles (http://pmdoi.org/index.html):
Los principios de esta declaración, que todo equipo de desarollo ágil debería asumir sin problemas, son:
“Nosotros…
1. Incrementamos el retorno de la inversión enfocándonos en lograr un contínuo flujo de valor.
2. Proporcionamos resultados fiables involucrando frecuentemente al cliente y compartiendo con el la propiedad del proyecto.
3. Esperamos incertidumbre y la manejamos mediante iteraciones, anticipación y adaptación.
4. Liberamos creatividad y motivación reconociendo a los individuos como la fuente última de valor y creando un entorno donde ellos puedan marcar la diferencia.
5. Impulsamos el rendimiento mediante la responsabilidad compartida en los resultados y efectividad del equipo.
6. Mejoramos la efectividad y la confianza mediante procesos, prácticas y estratégias especificas para cada situación.”
¿Como funciona Scrum?
Los Miembros del Equipo es uno de los Roles De Scrum. El equipo del proyecto es un grupo multi-funcional de personas con todas las habilidades diferentes que son necesarias para convertir los requerimientos en algo que es un incremento de una funcionalidad potencialmente productiva. Por lo tanto, usualmente consiste en:
- analistas
- diseñadores
- encargados de Calidad (QA)
- desarrolladores
- documentadores
- otras habilidades necesarias para realizar el trabajo
Este es el equipo que se compromete con el Dueño Del Producto en las tareas a realizar en cada iteración, y luego las hace. Al final de la iteración le muestran al Dueño Del Producto el resultado, de manera que pueda elegir cómo seguir.
Muchas organizacionse suelen tener un grupo de personas especializadas en distintos temas, como ser usabilidad, administradores de bases de datos, expertos en seguridad y arquitectos de sistemas. Cuando se necesita la participación de alguno de ellos, deberían pasar a formar parte del equipo. Es decir, no son parte de un grupo “externo” de expertos que dan consejos, sino que se convierten en miembros del equipo para aquellas iteraciones en las que es necesario construir una arquitectura, infraestructura o trabajar en la base de datos. Pueden estar trabajando o guiando, monitoreando a los miembros del equipo que hacen el trabajo. Se comprometen al comienzo de la iteración junto al resto del equipo, y siguen con ellos hasta el fin de la iteración. Por lo tanto se convierten en cerdos por un período corto de tiempo.
Características
- Multi-funcional.
- Tamaño del equipo de entre 5 y 9 miembros.
- Auto-Administrado, gestionado por los mismos miembros del equipo.
- Responsabilidades
Las principales responsabilidades, más allá de la auto-organización y uso de tecnologías ágiles, son las que se derivan de la diferencia entre “grupo de trabajo” y “equipo”.
Un grupo de trabajo es un conjunto de personas que realizan un trabajo con una asignación específica de tareas, responsabilidades y siguiendo un proceso o pautas de ejecución. Los operarios de una cadena, forman un grupo de trabajo: aunque tienen un jefe común, y trabajan en la misma organización, cada uno responde de su trabajo.
El equipo tiene espíritu de colaboración, y un propósito común: conseguir el mayor valor posible para la visión del cliente.
Un equipo Scrum responde en su conjunto. Trabajan de forma cohesionada y auto-organizada. No hay un gestor que delimita, asigna y coordina las tareas. Son los propios miembros del equipo los que realizan estas funciones.
En el equipo:
- Todos los miembros conocen comprenden la visión del propietario del producto.
- Aportan y colaboran con el propietario del producto en el desarrollo de la pila de producto.
- Comparten de forma conjunta el objetivo de cada sprint y la responsabilidad del logro.
- Todos los miembros participan en las decisiones.
- Se respetan las opiniones y aportaciones de todos
- Todos conocen el modelo de trabajo con Scrum.
Entonces las responsabilidades son:
- Selecciona el objetivo de la iteración y determina los resultados del trabajo
- Tiene el derecho para hacer todo lo necesario (dentro de los límites de las guías del proyecto) para alcanzar el objetivo de la iteración
- Se organiza a si mismo y a su trabajo
- Realiza demostraciones del resultado del trabajo ante el Dueño Del Producto y los stakeholders.
Planificación Del Sprint
El propósito de un Sprint es convertir un set de items del Backlog Del Producto en un incremento de funcionalidad potencialmente productiva. El Dueño Del Producto, el Scrum Master y los Miembros Del Equipo De Scrum se reunen antes de cada Sprint para determinar en qué funcionalidad del producto se seguirá trabajando. El Dueño Del Producto presenta el Backlog Del Producto y el equipo selecciona lo que cree puede ser construido durante el Sprint.
La reunión de Planificación del Sprint consiste de dos partes, cada una de las cuales puede durar hasta cuatro horas.
1. Selección del backlog (Exposición): el Dueño Del Producto presenta el backlog de mayor prioridad al equipo de desarrollo. Juntos colaboran para acordar cuántos de estos items pueden convertirse en un Incremento Del Producto potencialmente productivo durante el próximo Sprint. El equipo realiza la Estimacion Del Sprint y selecciona todo lo que crea pueda realizar.
2. Planificación de trabajo del Sprint (Resolución): el equipo define la arquitectura y el diseño de la funcionalidad que fue seleccionada, y luego define el trabajo, o tareas que conformarán el Backlog Del Sprint, para construir dicha funcionalidad durante el próximo Sprint.
El tiempo que dura la Planificación del Sprint debería estar en correspondencia con la duración misma del Sprint (donde, por ejemplo, en un sprint de 2 semanas no se deberían usar más de 4 horas en total para la planificación).
Pre-condiciones
La organización tiene determinados los recursos posibles para llevar a cabo el sprint.
El propietario del producto tiene preparado el backlog del producto: con su criterio de prioridad para el negocio, y un nº suficiente de elementos para desarrollar en el sprint.
Siempre que sea posible el propietario del producto debe haber trabajado ya previamente con el equipo. De esta forma su estimación previa de qué cantidad de backlog de producto se puede desarrollar en el sprint será bastante ajustada.
El equipo tiene un conocimiento de las tecnologías empleadas, y del negocio del producto suficiente para realizar estimaciones basadas en “juicio de expertos”, y para comprender los conceptos del negocio que expone el propietario del producto.
Entradas
- El backlog del producto
- El producto desarrollado hasta la fecha a través de los sucesivos incrementos (excepto si se trata del primer sprint)
- Circunstancias de las condiciones de negocio del cliente y del escenario tecnológico empleado.
Resultados
- Backlog del sprint.
- Duración del sprint y fecha de la reunión de revisión.
- Objetivo del sprint.
- Funciones del rol de Scrum Manager
El Scrum Manager es responsable y garante de:
- Se realiza esta reunión antes de cada sprint.
- Que antes de la reunión que el propietario del producto disponga de un backlog adecuado y suficiente para realizar el sprint.
- Que el diálogo principal de la reunión se realice entre el propietario del producto y el equipo. Otros asistentes pueden participar, pero su colaboración no puede implicar toma de decisiones ni limitar el diálogo principal.
- Que la reunión sea un trabajo de colaboración activa entre los dos protagonistas: cliente y equipo, y concluyen con un acuerdo sobre el incremento de producto que van a realizar en el sprint.
- Que el equipo comprende la visión y necesidades de negocio del cliente.
- Que el equipo ha realizado una descomposición y estimación del trabajo realistas y ha considerado las posibles tareas necesarias de análisis, investigación o apoyo.
- Que al final de la reunión están objetivamente determinados:
- Los elementos del backlog del producto que se van a ejecutar.
El objetivo del sprint.
- El backlog del sprint con todas las tareas estimadas.
- La duración del sprint y la fecha de la reunión de revisión.
- El Scrum Manager modera la reunión para que no dure más de un día. Debe evitar que el equipo comience a profundizar en trabajos de análisis o arquitectura que son propios del sprint.
Creación de historias
El Dueño del Producto presenta las historias de usuario, las cuales se escriben con títulos que el equipo comprenda en los post-it amarillos grandes. Estos post-it se pegan en la mesa para que todos los vean. Cada post-it contiene 3 datos:
1. Nombre de la historia
2. Importancia
3. Estimación
Validación
El nombre de la historia es una muy breve frase o título que describe a la historia (por ejemplo, “exportación de saldos”, “alta de usuario”, “modificación de dirección de facturación”, etc.).
La importancia es un número positivo; mientras más grande el número más importante la historia (y deberá terminarse antes que historias de menor importancia). La importancia la indica el Dueño del Producto.
La estimación en principio se deja en blanco, ya que será completada más adelante (pero dentro de la misma reunión).
La validación será la forma que el Dueño del Producto dará por aceptada la historia en la reunión de Revisión (Demo del Producto).
Así, luego de la exposición del Dueño del Producto, se tiene cierto número de historias pegadas sobre la mesa, ordenadas por importancia.
El Equipo además puede agregar historias propias, generalmente técnicas, que considera necesarias para la ejecución del proyecto (por ejemplo, la creación de un repositorio de código).
Pizarra de Trabajo
Es recomendable, que el propietario del producto emplee una hoja de cálculo, alguna herramienta similar, o el soporte de una intranet, para guardar en formato digital la pila del producto. Pero no es aconsejable emplearla como base para trabajar sobre ella en la reunión proyectándola sobre la pantalla de la sala. Es mucho mejor trabajar y manipular elementos físicos; y usar una pizarra y fichas removibles (adhesivas, con chinchetas o magnéticas).
Un ejemplo de pizarra.
La pizarra es una herramienta para facilitar la comunicación y el trabajo de la reunión. Al final de la reunión el propietario del producto registrará en la hoja de cálculo, o en la herramienta que emplee, el estado y las modificaciones en el backlog del producto. El equipo hará lo mismo con backlog del sprint. Según la distribución y espacio de la oficina de trabajo quizá se reutilice la pizarra o las notas para el seguimiento del sprint; o quizá no. Este es un ejemplo, pero la pizarra, y el resto de las formas, son técnicas que ayudan a trabajar de forma ágil; no reglas estrictas. En cada caso se pueden ajustar o modificar según las características de la organización. Algunos soportes que se suelen emplear:
- Pizarra blanca y fichas adhesivas tipo “Post-it”
- Pizarra de corcho laminado y chinchetas para sujetar las fichas.
- Pizarra de acero vitrificado y soportes magnéticos para sujetar las fichas.
- Se puede conseguir una solución práctica y económica empleando fichas adhesivas (“Post-it”) y usando como pizarra cartón pluma blanco de 5mm. fijado con puntas directamente sobre la pared. El cartón pluma es un material ligero, de acabado satinado que puede adquirirse en tiendas de materiales para bellas artes y manualidades.
- Ejemplo De Backlog Del Sprint
Daily Scrum
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama “daily standup”. El scrum tiene unas guías específicas:
La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc)
Todos son bienvenidos, pero sólo los “cerdos” pueden hablar.
La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas:
- ¿Qué has hecho desde ayer?
- ¿Qué es lo que estás planeando hacer hoy?
- ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).
Fases de una evaluación SCAMPI #CMMI enero 24, 2012
Posted by arevalomaria in CMMI.add a comment
Es importante llevar a cabo una serie de actividades a la hora de realizar una auditoría CMMI.
El método SCAMPI define varias actividades a realizar, que abarcan desde la definición de los objetivos de la auditoría hasta el reporte de los resultados de la evaluación.
A continuación se muestran las 3 fases que afectan más a la organización, con una estimación de su duración. Hay que destacar que estas duraciones se refieren a la duración temporal de cada una de las fases, no al esfuerzo necesario para realizarlas (no son días/hombre):
Fase 1: Preparación y planificación de la auditoría: en esta fase se seleccionan los objetivos de la mejora, se define el método de captura de evidencias, etc. Esta fase es realizada conjuntamente por el sponsor y el Lead Appraiser y tiene una duración aproximada de 2 jornadas.
Fase 2: Readiness-review: en esta fase se estudia si los proyectos que van a ser evaluados y la organización está preparada para la auditoría. Es necesario que esta fase se realice al menos una vez, aunque puede realizarse en más ocasiones. La duración de esta fase, que es realizada por el equipo de evaluación, es de aproximadamente 3 jornadas.
Ejecución de la auditoría y comunicación de resultados: durante esta actividad se realiza la auditoría final de concesión de un nivel de madurez de CMMI. Es realizada por el equipo de evaluación, y tiene una duración estimada de 5 jornadas para el nivel de madurez 2 y de 10 jornadas para el nivel de madurez 3.
La planificación e implementación de la Gestión del Servicio #ISO20000 enero 24, 2012
Posted by arevalomaria in ISO 20000.add a comment
Gestión y Mejora de Procesos de Gestión de Servicios de TI
La planificación e implementación de la Gestión del Servicio
Las especificaciones ISO 20000-1 dicen:
NOTA: La metodología conocida como Planificar-Hacer-Verificar-Actuar (PDCA, del inglés Plan-Do-Check-Act) puede aplicarse a todos los procesos. La metodología PDCA puede describirse del modo siguiente:
a) Planificar – Establecer los objetivos y los procesos necesarios para proporcionar resultados de acuerdo con las necesidades del cliente y con las políticas de la empresa.
b) Hacer – Implementar los procesos.
c) Verificar – Monitorizar y medir los procesos y los servicios contrastándolos con las políticas, los objetivos y los requisitos, e informar sobre los resultados
d) Actuar – Emprender las acciones necesarias para mejorar continuamente el rendimiento y comportamiento del proceso.
Se muestra el modelo de procesos completo para un proveedor de servicios al máximo nivel. Las entradas para los procesos de Gestión del Servicio son:
• Requisitos de negocio
• Requisitos del cliente
• Solicitud de servicio nuevo/modificado
• Otros procesos (negocio, suministrador, cliente)
• Registros del centro de atención al usuario
• Otros equipos (como Operaciones de TI, Seguridad)
Las salidas para los procesos de Gestión del Servicio son:
• Resultados de negocio
• Satisfacción del cliente
• Servicio nuevo o modificado
• Otros procesos (negocio, suministrador, cliente)
• Satisfacción de equipos y personas
Es posible establecer las siguientes correspondencias entre estas fases y el ciclo PDCA:
• Planificar – ¿Cuál es la visión? ¿Cuál es la situación actual? ¿Cuál es la situación deseada? (objetivos de negocio de alto nivel, valoraciones, objetivos medibles)
• Hacer – ¿Cómo conseguir la situación deseada? (mejora de procesos)
• Verificar – ¿Cómo comprobar que se han alcanzado los hitos? (medidas y métricas)
• Actuar – ¿Cómo mantener el impulso?
Competencia, concienciación y formación #ISO20000 enero 24, 2012
Posted by arevalomaria in ISO 20000.add a comment
Gestión y Mejora de Procesos de Gestión de Servicios de TI
Competencia, concienciación y formación.
Las especificaciones ISO 20000-1 dicen:
- Se deben definir y mantener todos los roles y responsabilidades de la Gestión del Servicio, junto con las competencias que sean requeridas para su ejecución efectiva.
- Las competencias y necesidades de formación del personal deben revisarse y gestionarse para permitir al personal llevar a cabo sus roles de forma efectiva.
- La alta dirección debe asegurar que sus empleados son conscientes de la relevancia e importancia de sus actividades y de cómo deben contribuir a la consecución de los objetivos de la Gestión del Servicio.
El Código de buenas prácticas ISO 20000-2 dice:
Generalidades
El personal que realiza el trabajo relativo a la Gestión del Servicio debería ser competente para esta función gracias a la educación recibida, a la formación, las habilidades y la experiencia adecuada.
El proveedor del servicio debería:
a) Determinar las aptitudes necesarias para cada rol en la Gestión del Servicio.
b) Asegurar que el personal sea consciente de la relevancia e importancia de sus actividades dentro del más amplio contexto de negocio y de cómo contribuyen a la consecución de los objetivos de calidad.
c) Mantener registros apropiados de la educación, formación, habilidades y experiencia.
d) Proveer formación o llevar a cabo otras acciones para satisfacer estas necesidades.
e) Evaluar la efectividad de las acciones realizadas.
Desarrollo profesional
El proveedor del servicio debería desarrollar y mejorar las competencias profesionales de su equipo de trabajo. Entre las medidas tomadas para conseguir esto, el proveedor del servicio debería incluir lo siguiente:
a) Contratación – con el objetivo de comprobar la validez de los detalles de los candidatos al puesto de trabajo (incluyendo su cualificación profesional) y de identificar la fortalezas, debilidades y habilidades potenciales de los candidatos frente a una descripción/perfil del puesto de trabajo, frente a los objetivos de la Gestión del Servicio y frente al conjunto de objetivos de la calidad del servicio.
b) Planificación – con el objetivo de dotar de personal a los servicios nuevos o a aquellos que se hayan ampliado (también contratando servicios), usando tecnología nueva, asignando personal de Gestión del Servicio a los equipos de desarrollo de proyecto, planificando la sucesión y rellenando los vacíos que se generen debido a rotación anticipada del personal.
c) Formación y desarrollo – con el objetivo de identificar los requisitos de formación y desarrollo dentro de un plan de formación y desarrollo y proveer su impartición en el momento oportuno y de forma efectiva.
Una parte importante del modelo de procesos de la organización consiste en garantizar que los pasos del proceso son ejecutados en todo momento por empleados competentes, cualificados y con la concienciación necesaria.
La competencia, la concienciación y la formación se basan en tres principios de la gestión de la calidad:
- Liderazgo – Capacidad de una persona para influir, motivar y habilitar a otras personas para que contribuyan a la eficacia y éxito de la organización a la que pertenecen.
- Implicación de las personas – Se deben identificar los talentos especiales de cada uno y aprovecharlos en beneficio de la organización.
- Mejora continua – Continuamente se deben desarrollar y aumentar la competencia y la concienciación de las personas.
Requisitos de Documentación enero 18, 2012
Posted by arevalomaria in ISO 20000.add a comment
Gestión y Mejora de Procesos de Gestión de Servicios de TI: Requisitos de Documentación
Las especificaciones ISO 20000-1 dicen:
Los proveedores del servicio deben facilitar documentos y registros necesarios para asegurar una planificación, operación y control de la Gestión del Servicio efectivas. Esto debe incluir:
a) Políticas y planes de la Gestión del Servicios documentados.
b) Acuerdos de nivel de servicios documentados.
c) Procesos y procedimientos documentados requeridos por esta norma.
d) Registros requeridos por esta norma.
Textualmente el Código de buenas prácticas ISO 20000-2 dice:
El responsable senior debería asegurar que las evidencias necesarias están disponibles para una auditoria de las políticas, planificaciones y procedimientos de la Gestión del Servicio y de cualquier actividad relacionada con ellos.
Gran parte de las evidencias de los planes y operaciones de la Gestión del Servicio se deberían encontrar en forma de documentos, los cuales pueden ser de cualquier tipo y estar en cualquier formato o soporte que sea adecuado para su fin.
Los siguientes documentos son considerados normalmente como válidos para servir de evidencias de la planificación de la Gestión del Servicio:
a) Políticas y planes
b) Documentación del servicio
c) Procedimientos
d) Procesos
e) Registros de control de procesos
Debería existir un proceso para la creación y gestión de los documentos para ayudar a asegurar que se satisfacen las características descritas.
La documentación se debería proteger de daños, debidos, por ejemplo, a inadecuadas condiciones del entorno donde se encuentran y a desastres en los sistemas informáticos.
La documentación se utiliza como medio para comunicar información y para compartir conocimientos. También hace que sea más sencillo mejorar el rendimiento de la organización. Sin documentación, una organización no puede tener una idea común de su propio rendimiento.
La serie ISO 9000 forma parte de los antecedentes de ISO 20000. Como se indicó anteriormente, la versión de 1994 de ISO 9001 tenía reputación de ser un “tigre de papel”. La versión del año 2000 de la serie ISO 9000 incluye una metodología de procesos, lo mismo que ISO 20000. Esto no excluye ningún tipo de trabajo de oficina o documentación, pero desplaza la atención hacia la gestión de procesos. La documentación es necesaria para demostrar el cumplimiento de la norma. Tal como se dice en la norma, la documentación puede ser de cualquier tipo, formato o soporte.
Responsabilidad de la Dirección #ISO20000 enero 13, 2012
Posted by arevalomaria in ISO 20000.add a comment
Para quienes tenemos el compromiso de desarrollar, implementar o mejorar las capacidades de Gestión del Servicio de TI considerando los requisitos del negocio y de los clientes, ISO 20000-1 nos indica que debemos:
1. Tener claro cuales son las políticas de la gestión del Servicio, los objetivos y planes.
2. Mantener informados sobre la importancia de cumplir con los objetivos de la gestión de Servicio y la necesidad de mejorar continuamente.
3. Velar porque los requisitos del cliente se determinen y se cumplan con el objetivo de mejorar la satisfacción del cliente.
4. Dentro de la Dirección debe haber un responsable para coordinar y gestionar todos los servicios.
5. Determinar y proveer los recursos para planificar, implementar, monitorizar, revisar y mejorar la provisión y la gestión de servicios, por ejemplo contratando personal apropiado o gestionando la rotación del personal.
6. Hacer los tramites necesarios para administrar los riesgos para la organización de la gestión de servicios.
A continuación el flujo de procesos asociados a la Dirección:
Tanto para ISO-20000-1 como ISO 20000-2, debemos tomar en cuenta la siguiente leyenda, expresada en notación BPM (Modelo de Procesos de Negocio):
El compromiso de la alta dirección es indispensable para una buena implementación ISO 20000, al igual que el liderazgo.
Los documentos que pueden demostrar el compromiso de la dirección son:
- Registro de la designación de un miembro responsable de la coordinación y gestión de todos los servicios.
- Documentos de políticas, objetivos y planes de gestión del servicio.
- Resultados de implementación de planes.
- Documentación de requisitos del cliente y registros de medidas de satisfacción del cliente.
- Registros de recursos.
- Registros de las revisiones de la gestión del servicio.
¿Qué es un SCAMPI™ y quién lo realiza? #CMMI diciembre 15, 2011
Posted by arevalomaria in CMMI.add a comment
Las Auditorias CMMI
Cuando una organización ha conseguido mejorar sus procesos e implantar los
correspondientes a un nivel de madurez CMMI, es común que decida que
ha llegado el momento de presentarse a una auditoría que corrobore dicha implantación por un tercero, un auditor externo. Y es ahí cuando aparecen una serie de peculiaridades, tareas y términos que suelen causar mucha confusión en el equipo de mejora.
¿Qué es un SCAMPI™ y quién lo realiza?
Se denomina así a la evaluación o auditoría final de concesión oficial de un nivel de madurez de CMMI. SCAMPI es el acrónimo de “Standard CMMI Appraisal Method for Process Improvement”. Este es un método sobre cómo evaluar los diferentes procesos de la organización, definiendo el nivel de madurez. Se distinguen tres tipos de SCAMPI (A, B ó C) en función de la formalidad y la dificultad del mismo. El más riguroso es el SCAMPI A y es el que permite obtener el nivel de madurez oficial. Una vez superado el SCAMPI A, es común que la organización reciba un diploma acreditativo que indica el nivel de madurez alcanzado.
El SCAMPI A debe ser realizado por una figura denominada Lead Appraiser. El Lead Appraiser es una persona acreditada por el SEI (Software Engineering Institute, organización propietaria del modelo CMMI) para realizar la evaluación CMMI. Finalmente, es el Lead Appraiser quién emite lo que se
conoce como “Appraisal Disclosure Statement”, documento que muestra los resultados de la evaluación.
¿Quién respalda una auditoría CMMI®?
Comúnmente se piensa que es el “Software Engineering Institute” (SEI), ya que es la organización propietaria del modelo. Sin embargo, el SEI solamente acredita a los auditores o Lead Appraiser para que puedan realizar evaluaciones CMMI. No es el SEI quien emite un certificado, sino que son
los auditores los que emiten un diploma en el que se indican los datos y resultados de la auditoría.
Son estos auditores y las empresas partner del SEI en las que trabajan los que se responsabilizan de los resultados de la evaluación. Tras la realización de un SCAMPI, el Lead Appraiser envía una serie de documentos al SEI para que este realice chequeos y controles de calidad del SCAMPI. Una vez terminados estos chequeos, el SEI envía una comunicación al sponsor y al Lead Appraiser del
SCAMPI aprobándolo para uso público. Desde este momento, los resultados se publican en el PARS (Published Appraisal Results) del SEI
Por ello normalmente se utiliza el concepto evaluación en vez de certificación cuando nos referimos a una auditoría CMMI.
¿Durante cuánto tiempo son válidos los resultados de la evaluación?
Los resultados de la evaluación son válidos durante un máximo de 3 años desde la fecha en que se emite el Appraisal Disclosure Statement.
¿Es necesario evaluar todas las áreas de proceso?
En función del nivel de madurez que se pretenda alcanzar, será necesario evaluar una serie de áreas de proceso. Todas las áreas de proceso correspondientes a un nivel de madurez son obligatorias a excepción de SAM (Supplier Agreement Management), que puede no ser aplicable a la organización y por tanto no ser evaluada. Para que esta área de proceso no sea evaluada, ha de justificarse su exclusión.
Componentes requeridos, esperados e informativos #CMMI diciembre 15, 2011
Posted by arevalomaria in CMMI.add a comment
Componentes requeridos, esperados e informativos
Los componentes del modelo se agrupan en tres categorías—requerido,
esperado e informativo— que indican cómo interpretarlos.
Componentes requeridos
Los componentes requeridos describen lo que una organización debe
realizar para satisfacer un área de proceso. Este logro se debe implementar
de forma visible en los procesos de una organización. Los componentes
requeridos en CMMI son las metas específicas y los objetivos
genéricos. La satisfacción de objetivos se utiliza en las evaluaciones
como base para determinar si un área de proceso ha sido realizada y
satisfecha.
Componentes esperados
Los componentes esperados describen lo que una organización puede
implementar para lograr un componente requerido. Los componentes
esperados guían a los que implementan mejoras o realizan evaluaciones.
Los componentes esperados incluyen las prácticas específicas y
las prácticas genéricas.
Antes de que los objetivos puedan considerarse satisfechos, las
prácticas tal como se describen o prácticas aceptables alternativas a
ellas, deberán estar presentes en los procesos planificados e implementados
de la organización.
Componentes informativos
Los componentes informativos proporcionan detalles que ayudan a las
organizaciones a comenzar a pensar en cómo aproximarse a los componentes
requeridos y esperados. Las sub-prácticas, los productos de trabajo
típicos, las ampliaciones, las elaboraciones de las prácticas genéricas,
los títulos de metas y prácticas, las notas de metas y prácticas, y las referencias
son ejemplos de componentes informativos del modelo.
El glosario de términos del CMMI no es un componente requerido
ni esperado ni tampoco informativo de los modelos del CMMI. Usted
debería interpretar los términos del glosario en el contexto del componente
del modelo en el que aparecen
Véase a continuación Gráfica con componentes del modelo CMMI:
ITIL V3, Actualizaciones al 2011 #ITIL diciembre 14, 2011
Posted by arevalomaria in Uncategorized.Tags: ITIL
add a comment
Les invito a ver el siguiente video:
http://www.youtube.com/watch?v=DdDbrGMLNQc&feature=mfu_in_order&list=UL
Que esta pasando, los cambios minimos que se han hecho en la version 3, algunas preguntas frecuentes, me parecio excelente, tomado de www.globbtv.com/cursos.aspx
Diferencias entre Metodologías Tradicionales y Ágiles #MetodologiasAgiles noviembre 15, 2011
Posted by arevalomaria in Metodologías Ágiles.add a comment
Diferencias:
|
Metodologías Tradicionales |
Metodologías Agiles |
| Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo | Basadas en heurísticas provenientes de prácticas de producción de código |
| Cierta resistencia a los cambios | Especialmente preparados para cambios durante el proyecto |
| Impuestas externamente | Impuestas internamente (por el equipo) |
| Proceso mucho más controlado, con numerosas políticas/normas | Proceso menos controlado, con pocos principios. |
| El cliente interactúa con el equipo de desarrollo mediante reuniones | El cliente es parte del equipo de desarrollo |
| Más artefactos | Pocos artefactos |
| Más roles | Pocos roles |
| Grupos grandes y posiblemente distribuidos | Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio |
| La arquitectura del software es esencial y se
expresa mediante modelos |
Menos énfasis en la arquitectura del software |
| Existe un contrato prefijado | No existe contrato tradicional o al menos es bastante flexible |
Diferencias por etapas y enfoque metodológico
|
MODELOS RIGUROSOS |
ETAPA |
MODELOS AGILES |
|
Planificación predictiva y “aislada”
|
Análisis de requerimientos
|
Planificación adpatativa:Entregas frecuentes + colaboración del cliente
|
|
Planificación
|
||
|
Diseño flexible y Extensible + modelos + Documentación exhaustiva
|
Diseño
|
Diseño Simple: Documentación Mínima + Focalizado en la comunicación
|
|
Desarrollo individual con Roles y responsabilidades estrictas
|
Codificación
|
Transferencia de conocimiento: Programación en pares + conocimiento colectivo
|
|
Actividades de control]: Orientado a los hitos + Gestión miniproyectos
|
Pruebas
|
Liderazgo-Colaboración: empoderamiento +auto-organización
|
|
Puesta en Producción
|
Diferencias por las características del Proyecto
|
Modelo de Proceso |
Tamaño del Proceso |
Tamaño del Equipo |
Complejidad del Problema |
| RUP | Medio / Extenso | Medio / Extenso | Medio / Alto |
| ICONIX | Pequeño / Medio | Pequeño / Medio | Pequeño / Medio |
| XP | Pequeño / Medio | Pequeño | Medio / Alto |
| SCRUM | Pequeño / Medio | Pequeño | Medio / Alto |
En este cuadro se presenta una comparativa de las modelos de proceso en cuanto a las características del proyecto, analizamos el tamaño del proceso, del equipo y la complejidad del problema para cada uno de los modelos. Podemos resaltar que: con un pequeño equipo de desarrollo se puede realizar grandes proyectos, de alta complejidad; es el caso de XP y SCRUM.
Diferencias Por la curva de Aprendizaje
|
Modelo de Proceso |
Curva de aprendizaje |
Herramienta de integración |
Soporte Externo |
| RUP | Lenta | Alto Soporte | Alto Soporte |
| ICONIX | Rápida | Algún Soporte Disponible | Algún Soporte Disponible |
| XP | Rápida | No mencionado | Algún Soporte Disponible |
| SCRUM | Rápida | No mencionado | Algún Soporte Disponible |
Con respecto a la curva de aprendizaje, vemos que los modelos ágiles, nos ofrecen una mayor ventaja pero con ciertas limitaciones, ya que aun no hay sido explotadas a gran escala como lo es RUP que posee alto soporte y herramientas integrales que nos guían a través del mismo, facilitando aplicar con mayor efectividad esta metodología, permitiendo aprovecharla al máximo
Cabe destacar:
- El retrasar las decisiones en un proyecto de software permite potenciar el valor del producto tanto para el cliente como al equipo o empresa que desarrolla
- Para que un grupo de desarrollo adopte una metodología ágil debe poseer experiencia trabajando con metodologías tradicionales, ya que la experiencia es la que predomina en los mementos cruciales del proyecto, además debe tener la capacidad de ser equipos auto-gestionados, altamente motivados y con gran innovación
- Las metodologías ágiles permiten disminuir costos y brindar flexibilidad a los proyectos de software donde la incertidumbre está presente
- El uso de metodologías tradicionales es esencial al inicio en un equipo de desarrollo de software
- Las metodologías ágiles se deberían aplicar en proyectos donde exista mucha incertidumbre donde el entorno es volátil, donde los requisitos no se conocen con exactitud, mientras que las metodologías tradicionales obligan al cliente a tomar las decisiones al inicio del proyecto.
