Estimados les aviso de un nuevo curso en la UNSL.
Se dictará en la semana del 22 al 27 de Junio de 2009, en el aula de
posgrado del Departamento de Informática. Bloque II, 1er. piso.
CURSO 1: Sistemas Multi-cluster para Computación Eficiente de Altas
Prestaciones. Contenidos minimos descriptos al final de este e-mail.
CURSO 2: Tolerancia a fallos en Sistemas de Cómputo de Altas Prestaciones.
Contenidos minimos descriptos al final de este e-mail.
Cada curso comprende 16 horas presenciales, las cuales seran distribuidas
de acuerdo a la disponibilidad de los asistentes interesados.
Los cursos serán dictados, por el Dr. Luque Emilio y la Dra. Dolores
Rexarch, profesores invitados del Dto. de Informática. Ambos profesores
son integrantes del Departamento de Arquitectura de Computadores y
Sistemas Operativos (DACSO-CAOS) de la Universidad Autónoma de Barcelona
de la Universidad (http://caos.uab.es/)
Contacto e inscripciones: mprinti@unsl.edu.ar
-----------------------------------
PROGRAMAS
CURSO 1: Sistemas Multi-cluster para Computación Eficiente de Altas
Prestaciones (16 horas)
1. Computadores paralelos
2. Sistemas Multicluster
3. Predicción de prestaciones y Sintonización en Entornos Multicluster
para Aplicaciones M/W
4. Caracterización de las Aplicaciones. Software Probes
5. La "signatura" de aplicaciones paralelas
CURSO 2: Tolerancia a fallos en Sistemas de Cómputo de Altas Prestaciones
(16 horas)
1. Introducción. Conceptos básicos.
2. Métricas. Medidas de fiabilidad
3. Técnicas de Prevención y Redundancia.
4. Modelos, terminología y aspectos generales del rollback-recovery.
Protocolos de rollback-recovery basados en Checkpoint y Log.
5. Verificación. Métodos de Inyección de Fallos.
6. Redundancia de información. Sistemas de discos. Replicación de datos.
7. Arquitectura Paralela Tolerante a fallos: RADIC.
15 may 2009
Metodologia agiles - entrando en detalles
Scrum, una metodología Ágil (II)
Estructuración de la metodología
Tres fases fundamentales: una breve fase de planificación, en la cual se realizan las labores básicas de una planificación breve: visión general del proyecto (estimación muy general, viabilidad del sistema) y construcción del Backlog. por un lado y por otro el desarrollo de la arquitectura al detalle; otra de desarrollo, en la cual tienen lugar los famosos Sprints, y otra final de entrega y balance de los éxitos y fracasos logrados.
La fase fundamental de la metodología, la que realmente tiene interés para nosotros, es la fase de Sprint. Las otras dos no difieren mucho con las fases de Planificación y Entrega de otras metodologías. El desarrollo en la fase Sprint es iterativo, en uno o más Sprints (¿cuántos? ¡los que haga falta!), hasta que el proyecto se da por finalizado por el ProductOwner. De este modo acometemos el problema de la variabilidad de los requisitos. No hay una estimación prematura fiable: los requisitos probablemente cambiarán y nuestra metodología está preparada para ello.
Reuniones, toma de decisiones
Existen cuatro tipo de reuniones durante el desarrollo de un proyecto con Scrum:
- Encuentro de Planificación (4 horas): Al comienzo de un Sprint se decide qué parte del Backlog global del proyecto se implementará en este Sprint. Una vez decididas las funcionalidades a implementar, en base a estimaciones de tamaño, tiempo, esfuerzo, etc., el Sprint Backlog no se toca durante todo el Sprint, bajo ninguna circunstancia. Si algo falla, el ScrumMaster podrá cancelar el Sprint y comenzar otro.
- Encuentro Diario (15 minutos): Diariamente el equipo se reúne en un rápido encuentro, de unos 15 minutos, para responder, individualmente, a 3 preguntas básicas: ¿qué hiciste ayer? ¿qué vas a hacer hoy? ¿qué te está impidiendo alcanzar tus objetivos? Si nos fijamos, de este modo se realiza el control del proyecto y el seguimiento de los posibles riesgos.
- Encuentro de Revisión (4 horas): Al final del Sprint, se realizará una reunión con el ProductOwner y otros clientes (gallinas) para exponer la funcionalidad desarrollada junto con las posibles preguntas y ampliaciones del Backlog que se les pueda ocurrir a los diferentes stakeholders (clientes+ejecutivo). Con esto logramos un ‘feedback’ con el cliente, que ve cómo el producto progresa.
- Encuentro Retrospectivo (4 horas): Reunión del ScrumMaster con el Team para revisar cómo fue el Sprint: qué se consiguió realizar bien y cómo se podría mejorar. Si nos fijamos detenidamente, esto no es más que una revisión de lecciones aprendidas y un intento de recabar información histórica del propio proyecto (Software Estimation, Steve McConnell), útil para futuras estimaciones y Sprints.
Desarrollo de la fase Sprint
Cada Sprint tendrá una duración aproximada de unos 30 días (en algunas fuentes se habla de entre 2 y 6 semanas); se entiende que esta cantidad de tiempo es suficiente como para desarrollar algo entregable y funcional al ProductOwner. Se comprende como jornada laboral aquella que dura 8 horas. No se contempla, bajo ningún concepto, por lo dañino y lo poco productivo, la realización de horas extra (Peopleware, deMarco y Lister).
El Sprint comienza con un Encuentro de Planificación en el cual se decide qué se va a desarrollar del Backlog general y se elabora el Sprint Backlog. A la hora de seleccionar las funcionalidades a desarrollar se tendrá en cuenta la prioridad de los requisitos, establecida por el ProductOwner. Se descomponen los requisitos en tareas simples, realizables en poco más de una jornada laboral de 8 horas como máximo. Como se ha indicado, una vez decidido el Sprint Backlog éste no se toca en absoluto y bajo ninguna circunstancia durante el Sprint. Las funcionalidades seleccionadas NO se asignan a los miembros del Team, sino que cada miembro ELIGE qué desea desarrollar (Peopleware). Una vez comenzado el Sprint, el ScrumMaster no se implicará lo más mínimo en el Team; realizará sus labores de planificación, estimación, control y gestión y solamente contactará con el Team en los Encuentros Diarios. Aparte de esto solamente tratará con algún miembro del Team cuando éste desee preguntarle algo o solicitar algún tipo de ayuda. Libertad de desarrollo para el equipo (Peopleware); que no significa ausencia de control o anarquía, ni mucho menos. El ScrumMaster tratará de favorecer el flow o máxima productividad de su Team (Peopleware) y tratará de crear un clima en el cual se pueda trabajar sin interrupciones (Peopleware).
Cada miembro se responsabilizará de entregar la parte que se ha comprometido a realizar en el plazo fijado. Si es incapaz de ello hablará con el ScrumMaster para solicitar ayuda o detener el Sprint, de forma muy excepcional. Si el Sprint Backlog se termina antes de tiempo, se puede dialogar con el ProductOwner para añadir más funcionalidad al Sprint.
El avance Sprint a Sprint se visualiza mediante un artefacto o diagrama de burn down que representa la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo ideal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el prinicipio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.
Conclusiones
Algo que no se ha dicho es: en la explicación de la fase Sprint se ha supuesto que existía un solo equipo. ¿Qué ocurre cuando tenemos varios equipos? Aquí entra en juego un añadido a la metodología Scrum, el concepto de Scrum of Scrums, que consiste en realizar un Scrum diario con un representante o portavoz de cada equipo, el cual explicará al resto los avances diarios que está realizando su grupo (responderá a las 3 preguntas antes mencionadas).
Según la opinión de los propios autores, utilizar Scrum permite entregar al cliente un producto que le satisface, que cumple mejor los requisitos que él pedía, y con la calidad adecuada. Además el equipo es productivo y trabaja más a gusto, se compromete con el proyecto y la organización haciendo lo que más le gusta. Por otro lado, el uso de Scrum permite reducir la estimación temporal hasta en un 40%, debido precisamente a este aumento en la productividad, fruto de los rápidos desarrollos en los Sprints y los compromisos adquiridos por los miembros del equipo.
Debido a su alto carácter iterativo y variable, no es en absoluto necesario realizar complejas planificaciones iniciales con Pert o diagramas de Gantt.
Existen algunas ideas más que aquí no he querido introducir, por simplicidad, como por ejemplo algún detalle más de la fase de Planificación, Entrega, u otros conceptos como el burn down chart. Sin embargo, creo que con lo aquí expuesto, libre de detalles menos importantes, uno puede hacerse una idea bastante fidedigna de qué es Scrum y qué trata de observar y tener muy presente. Para más información consulte el apartado de Fuentes. Para la elaboración de este documento se recopiló información de las distintas fuentes mencionadas, dando un resumen final bastante personal del autor sobre qué ideas merece la pena concretar un poco más y qué detalles son más superfluos.
Fuentes de información
Fuentes bibliográficas principales
- Agile Software Development with Scrum, Ken Schwaber : el libro “oficial” de Scrum. Realmente Scrum no da como para escribir un libro de más de 20 páginas. Tan simple es. Por lo tanto, K. Schwaber rentabilizó su idea con un libro que incluye todo lo básico para conocer Scrum en el primer capítulo y los apéndices finales. Los otros 8 capítulos son experiencias del autor en la aplicación de Scrum en entornos reales. Batallitas del abuelo, vamos.
- http://es.wikipedia.org/wiki/Scrum: la primera fuente que tuve como acercamiento a Scrum. Posteriormente tuve que modificar la parte en la que se explica el concepto de informe “burn down”, ya que era errónea.
- www.agilealliance.org y www.controlchaos.com, donde se encuentran los siguientes documentos:
- Agile Processes and Self-Organization, SCRUM Development Process, Controlled Chaos : Living on the Edge, Agile Processes - Emergence of Essential Systems, Controlled-Chaos Software Development, Best Practices in Scrum Project Management and XP Agile Software Development.
- http://video.google.com/videoplay?docid=-7230144396191025011: Conferencia de Ken Schwaber sobre Scrum al personal de Google; 5 de Sept. de 2006. En inglés, por supuesto.
Fuentes bibliográficas secundarias
- Peopleware - Productive Projects and Teams, Tom deMarco y Timothy Lister. Ya hemos hablado de este libro mucho aquí. Es fundamental para todo buen Gestor de Proyectos. Aunque no lo dice en ningún sitio, estoy completamente seguro de que Ken Schwaber se basa en muchas de las premisas aquí indicadas, sobre todo en la definición del rol ScrumMaster.
- SW Estimation, Demystifying the Black Art, Steve McConnell. El autor es muy conocido por este y otros libros de Estimación y Gestión de Proyectos. Este libro incluye un buen número de buenas prácticas, en forma de 118 consejos, para realizar estimaciones de tamaño, de esfuerzo, de temporización y de funcionalidad en los proyectos.
Más información en:
http://luixrodriguezneches.wordpress.com
Suscribirse a:
Entradas (Atom)