Академический Документы
Профессиональный Документы
Культура Документы
Propuesta Técnica.
Versión: 1.0
Fecha: 20/12/2015
SEIDOR establece que los contenidos de este documento son CONFIDENCIALES y podrían causar daño a la empresa
si es dada a conocer a sus competidores. Los datos presentados contienen secretos técnicos, comerciales y/o
información financiera privilegiada y confidencial. Tales datos se usarán únicamente para propósitos de evaluación de
la propuesta por parte del cliente, esto incluye estructura, ideas, consejos y sugerencias de la solución propuesta.
Queda entonces prohibida su reproducción, transmisión, trascripción, grabado en algún otro sistema recuperable, o
traducción a otro idioma, ya sea en forma total o parcial, sin el consentimiento escrito de SEIDOR.
Oficinas y Contactos:
Versión. 1.0.
REVISIONES.
Fecha de Modificación.
Versión. 1.0.
Descripción de la Modificación.
8.6.- ROLES............................................................................................................................27
8.6.1.- SCRUMMASTER.............................................................................................................28
La Coordinación Nacional de Tecnología, en adelante CNT y la División de Educación General, en adelante DEG, requieren
la Contratación por “Proyecto”, para el desarrollo, capacitación e instalación de una Plataforma de Gestión de Información,
para el Sistema de “Plan De Mejoramiento Educativo – PME 2017.
El “Plan De Mejoramiento Educativo – PME 2017” debe permitir el registro, la implementación y la evaluación de un proceso
de mejora continua en los establecimientos tendiente a mejorar los procesos de enseñanza y aprendizaje.
Para ello esta plataforma deberá contar con los siguientes módulos:
Módulo 1: “Planificación Estratégica”, el cual se busca en identificar la realidad del establecimiento, definir los
objetivos de este y la estrategia para alcanzarlos dentro del periodo de cuatro años de PME.
Módulo 2: “Planificación Anual”, El cual debe realizar la definición de actividades a realizar durante un ciclo anual
de PME definiendo acciones y presupuestos asociados.
Módulo 3: “Implementación”, el cual debe permitir implementar el seguimiento de la ejecución de lo planificado.
Módulo 4: “Evaluación”, en el cual se deben identificar brechas de cumplimiento, e identificar el grado de
cumplimiento de los objetivos estratégicos de acuerdo a las actividades realizadas.
Requerimientos No Funcionales.
El proyecto será abordado con un enfoque iterativo y ágil generando entregables en cada una de sus iteraciones.
Un factor clave para el éxito de cualquier proyecto es la gestión del mismo, por eso nosotros ponemos énfasis en la gestión
siguiendo los lineamientos del PMI para llevar a cabo una gestión acorde a las necesidades de cada servicio. Nuestra oficina
de PMO, da el apoyo necesario a nuestros jefes de proyectos para aplicar las buenas prácticas de gestión y lograr el control
y éxito de los proyectos.
Seidor es una Consultora Tecnológica líder dedicada a ofrecer soluciones integrales en el ámbito de la consultoría de software
y servicios informáticos, estrategia IT, desarrollo (soluciones móviles, BPM, SOA, Content Management), operaciones,
infraestructura, mantenimiento de aplicaciones, soluciones Cloud y Outsourcing, entre otras.
Con más de 30 años de trayectoria en el mercado, conocimiento tecnológico de vanguardia, especialización sectorial, cercanía
y equipo de expertos certificados por los principales fabricantes, Seidor es una compañía sólida, estable y en expansión,
focalizada en simplificar a sus clientes el acceso a tecnologías emergentes y gestionar sus negocios de una forma más rápida,
sencilla y asequible.
La alianza estratégica de Seidor con los principales y más importantes desarrolladores y fabricantes de tecnología
internacionales (Oracle, IBM, SAP, Microsoft, Dell, Quest Software, Red Hat, etc) es su principal garantía para ofrecer la
solución que mejor se ajusta a la necesidad específica de cada cliente.
3.1.-ASPECTOS NO TÉCNICOS.
Nosotros como empresa estamos convencidos que los pilares para una buena relación de largo plazo y éxito en un proyecto
son:
Transparencia.
Confianza.
Compromiso.
Seriedad.
Comunicación.
Empatía.
Visión de negocio.
Transferencia de conocimiento.
Nuestra permanencia en el mercado Chileno y en Latinoamérica en general durante todos estos años se debe, más allá de
nuestra capacidad técnica, al reconocimiento por todos los valores antes señalados.
La empatía con las necesidades y desafíos de nuestros clientes, el compromiso por cumplir los objetivos y las metas más allá
de las dificultades que puedan existir, ser transparente y asumir sin temor las responsabilidades que nos quepan y asumir el
compromiso de solucionar los problemas que puedan existir, ganando la confianza del cliente para seguir trabajando con
nosotros.
3.2.-ASPECTOS TÉCNICOS.
El Ministerio de Educación de Chile, también conocido por su acrónimo MINEDUC, busca contribuir a elevar los estándares
de educación en la población, desarrollando sistemas de mejoramiento, centrados en las personas, fortalecer el control de los
factores que puedan afectar la educación y reforzar la gestión del plan nacional de educación.
Realizar un sistema que se ajuste al nuevo modelo de mejoramiento continuo del MINEDUC y remplace al actual
sistema de Plan de Mejoramiento Educativo.
Flexibilizar la gestión de los componentes del proceso de mejoramiento educativo, en casos de excepción.
Crear herramientas de comunicación entre los diversos actores del sistema que interactúan en la creación PME.
Mejorar la capacidad de análisis de resultados, obtenidos durante los procesos de mejoramiento.
Mantener en constante actualización la información proveniente desde entidades externas al MINEDUC (Agencia
de Calidad, Superintendencia de Educación, DEMRE).
Reportar sobre el proceso a todos los actores involucrados en los temas de gestión y mejora educativa
(Sostenedores, MINEDUC, Agencia de Calidad y Superintendencia de Educación)
Contar con una herramienta que apoye los cambios de práctica en los procesos de registro y gestión de los procesos
de mejora en la escuela.
Implementar una solución tecnológica con la capacidad de cumplir con todos los requerimientos planteados por el
MINEDUC.
Trabajar bajo los parámetros de construcción y arquitecturas establecidas por el MINEDUC.
Respetar y resguardar la confidencialidad de la información que pueda ser recibida desde el MINEDUC o
participantes externos, y que sea útil para el desarrollo del sistema.
Simplicidad del sistema, con interfaces de fácil uso para minimizar errores.
Utilizar los mecanismos de seguridad definidos por el MINEDUC para proteger la información y datos de acceso no
autorizado.
Construir una aplicación robusta, modular y mantenible, que sea escalable, segura, capaz de centralizar errores y
de manejar alta concurrencia.
Proveer altos estándares de seguridad acorde a las definiciones hechas por el Ministerio de Educación.
Se proporcionará la construcción de una plataforma web para todos los actores que participan en las operaciones del Plan de
Mejoramiento Educativo a nivel nacional. Aproximadamente 12.000 establecimientos, 3.000 sostenedores, 700 supervisores
42 encargados provinciales MINEDUC, 15 seremis, 200 funcionarios MINEDUC, agencia de calidad y superintendencia.
El sistema estará dividido en 2 fases Macro: Fase Estratégica (etapa 1) y Plan Anual (etapa 2), siendo 4 años la duración del
nuevo plan, ambos independientes entre sí en el aspecto de la finalización de las fases. Estas fases estarán estructuradas
de la siguiente forma:
Mantenedor de Usuarios
Mantenedor de Roles/Perfil
Modulo Inicio Sesión usuarios Internos y Externos
Fase Estratégica
Análisis Estratégico
Definición de Sellos Educativos
Fortalezas y Debilidades
Planificación Estratégica
Definición de Objetivos y Metas
Registro de Actividades
Plataforma de comunicaciones
Proceso de Apertura
Sistema que permita la modificación de datos de periodos anteriores en algún punto del flujo con el objetivo
de ajustar las estrategias según la actualización de la información.
Sistema de Reportes
En el diagrama presentado se identifican claramente las capas y sus componentes, que en ambiente de producción se
recomienda un desplegué de la siguiente forma.
Se utilizará la arquitectura indicada y propuesta por Mineduc respectando los estándares establecidos, detallados a
continuación.
Capa que contendrá páginas dinámicas y formularios. A esta capa se le propagará las credenciales de autenticación.. Esta
capa tiene el objetivo de contar con un diseño acorde a lo esperado, cumpliendo con las características básicas de las
aplicaciones Web que deben ser intuitiva para el usuario y definida por Mineduc.
Frente a la opción de utilizar 2 tipos de servidores para realizar los desarrollos escogemos la utilización de Apache con Java
1.6 rigiéndonos según de lo que de la especificación de arquitectura se desprende:
“La aplicaciones serán montadas sobre OS Centos versión 6.2, la versión de Java es Java. 1.6 (puede sufrir modificaciones)
y la versión de tomcat es 6 (puede sufrir modificaciones), adicionalmente se está utilizando la versión de apache 2.2.15 (puede
sufrir modificaciones).”
4.4.3.- FRAMEWORK.
El Framework a utilizar es el provisto por Mineduc basado en Spring 3.1.1, siendo característica del desarrollo realizado con
Patrón de diseño MVC.
Como política del Mineduc se debe cumplir con un 97% de cumplimiento de Reglas definidas por Mineduc donde se utiliza
SonarQube para generar informes de cumplimento de las reglas definidas.
5.- ALCANCES.
El alcance de la propuesta se rige según el documento de especificaciones Funcionales y No funcionales sobre las cuales
estamos de acuerdo y se adjuntan a continuación:
Levantamiento de
Requerimientos.docx
Guia Estandares QA
v3.2.docx
El alcance de las actividades del proyecto, está delimitado por las fases del mismo. De acuerdo a los requerimientos del
negocio, la naturaleza y características de los componentes existentes y los requerimientos señalados anteriormente, se
plantea lo siguiente:
5.4.- ENTREGABLES
En esta sección deben definirse de forma clara, completa y explícita cuáles serán las condiciones de aceptación de los
servicios de SEIDOR TECHNOLOGIES. Estas condiciones deben definirse en conjunto con el cliente y no deben contemplar
ambigüedades, no deben estar sujetas a diferencias de opinión ni subjetividades y deben ser concretas, simples y medibles.
Se proponen inicialmente las siguientes condiciones de aceptación:
6.1.- RIESGOS.
Se reconocen como riesgos aquellas situaciones que de producirse afectarán negativamente de manera directa o indirecta la
ejecución del proyecto.
El objetivo de este apartado es construir con el cliente una visión común de los posibles problemas que deberán enfrentarse
en la implementación de la solución propuesta, en términos de probabilidad de ocurrencia, impacto del problema en el
proyecto, y diferentes formas de evitar el riesgo o al menos reducir su impacto.
Dado que el proyecto requiere participación y El cliente debe arbitrar los medios para que el personal propio
compromiso parte de personal del cliente, involucrado en el proyecto tenga la dedicación necesaria.
Alto.
puede ser que esta participación no se cumpla
si no se planifican los recursos con tiempo.
En relación con el alcance funcional y no Se plantea una fase de inicial para el proyecto. Durante la
funcional del proyecto, dado que no se tiene misma se obtendrá una línea base de la funcionalidad de los
total claridad de la información y su procesos a implementar.
complejidad. En caso de manifestarse este En caso de aparecer divergencias entre la estimación
riesgo bajo la aparición de requerimientos cotizada y la línea base, se analizarán con el cliente las
Alto.
ambiguos o no identificados en un comienzo, el acciones a seguir, siendo las posibilidades:
esfuerzo y la duración del proyecto pueden - Reducción de la funcionalidad (conservando el costo)
verse afectados. - Generación de una extensión del proyecto (previa
cotización)
- Generación de una release adicional (previa cotización)
Demora en las aprobaciones de la Asignar los recursos el tiempo necesario para poder realizar
documentación por parte del cliente impactan Alto. la revisión de los documentos dentro de los plazos
en los hitos de pago. establecidos.
La siguiente es la lista de los supuestos del proyecto. Todo lo expuesto en la propuesta ha sido desarrollado asumiendo que
estos supuestos son verdaderos. El hecho de que algún supuesto no se cumpla, puede llegar a tener impacto en el plan de
proyecto y deberá ser analizado en cada caso.
La implementación de la solución queda sujeta a las características, capacidades y performance por default de la
herramienta/arquitectura con la cual se implementa la solución.
La estimación presentada es tentativa de acuerdo a lo especificado por el cliente y considerado como alcance
funcional.
Cualquier información no incluida explícitamente en estos documentos no formará parte del alcance del proyecto.
Todo nuevo requerimiento o modificación al alcance inicial detectado en la fase de análisis será considerado un
control de cambio y debe ser estimado, cotizado y aprobado por el cliente para su implementación, caso contrario
no será incluido en el proyecto.
El cliente deberá proveer documentación y los artefactos de software que sean requeridos de las aplicaciones
existentes.
Todos los procedimientos almacenados o servicios web necesarios para implementar los procesos deben ser
provistos por el cliente al inicio del proyecto.
Todas las interfaces de ingreso deben estar definidas y el cliente debe entregar:
o Todos sus campos especificados.
o Todos los formatos de datos de cada campo.
o Todas las reglas de negocio que aplican a cada campo.
o La relación o reglas de negocio entre los campos de una misma pantalla o entre campos de diferentes páginas.
Cualquier integración en esta propuesta que se requiera realizar con los sistemas actuales del cliente, será
responsabilidad del cliente desarrollar dicha integración y disponerla para su uso.
El cliente debe proveer todos los datos necesarios para la fase de desarrollo y pruebas del sistema al inicio del
proyecto.
El cronograma de implementación será definido por el equipo implementador de acuerdo al plan general de proyecto
de común acuerdo.
Para aquellos trabajos que sean necesarios realizar en el cliente, este facilitará todos los recursos humanos y
tecnológicos (servidores, puestos de trabajo, conexión a internet, VPN, etc) necesarios para poder llevar a cabo las
tareas en forma exitosa.
Deberán respetarse las fechas fijadas para la celebración de reuniones, y se deberá documentar el resultado de
cada reunión, lo que se transformará en documentación del proyecto en lo que respecta a decisiones que se tomen
en dichas reuniones.
Por cada reunión existirá una minuta de reunión con las decisiones tomadas.
El cliente asume el compromiso de colaborar con SEIDOR TECHNOLOGIES para que éste pueda prestar los
servicios objeto del presente Contrato, incluyendo asuntos tales como facilitar la información y documentación que
sean necesarias para realizar el proyecto en los plazos establecidos en la Carta Gantt, dar las aprobaciones que
SEIDOR TECHNOLOGIES precise en los plazos establecidos en la carta Gantt, revisar informes y realizar aportes
en relación con los mismos en el momento que sea necesario acorde a los plazos establecidos en la carta Gantt en
cada etapa del proyecto.
El cliente se obliga a responder y aclarar todas las dudas o interpretaciones de toda la información entregada por el
mismo para este proyecto, como así también se hace responsable de especificar todo aquello que no estando
especificado debidamente al inicio del proyecto se considere parte de las especificación de los alcances de este
proyecto y que no signifique un cambio de alcance. Todo lo anterior debe ser realizado dentro de los plazos
acordados en la planificación.
Una vez efectuado un requerimiento por parte de SEIDOR TECHNOLOGIES, el cliente deberá dar respuesta dentro
de los plazos establecidos en la carta Gantt. En caso de que el cliente no pudiere dar respuesta a dicho
requerimiento dentro del plazo antes señalado, se encontrará obligado a dar por aprobados los artefactos
entregados (documento, producto de software u otro) y aceptada la interpretación o entendimiento del problema por
parte de SEIDOR TECHNOLOGIES, relacionado con el requerimiento solicitado.
El cliente procurará que SEIDOR TECHNOLOGIES tenga acceso en el menor plazo posible, no superior a los plazos
establecidos en la planificación, al personal relacionado con este proyecto.
Se asume que en las reuniones que se traten temas que requieran de decisiones inmediatas participarán los
funcionarios que puedan decidir durante la reunión los temas en cuestión para evitar cualquier atraso en el plan de
proyecto.
SEIDOR TECHNOLOGIES se reserva el derecho de cambiar los miembros del equipo de proyecto en caso de ser
necesario.
El cliente debe asignar como mínimo el siguiente equipo al proyecto, según la planificación que se defina:
o Jefe de Proyecto: 25%.
o Responsable de tecnología o plataformas: 50%.
o Responsable de negocio: 50%.
Seidor – Propuesta Técnica. 16
6.2.3.- INFRAESTRUCTURA DEL PROYECTO.
EL HW para todos los ambientes debe ser provisto por el cliente dimensionado de acuerdo a los requerimientos
mínimos recomendado por las plataformas a utilizar como solución.
El pasaje entre ambientes (desarrollo, QA, producción) es de responsabilidad del cliente, pero SEIDOR
TECHNOLOGIES brindará todo el apoyo que sea necesario en el proyecto.
Existirá un tiempo límite (2 días) para la revisión por parte del cliente de la documentación entregada por SEIDOR
TECHNOLOGIES, pasado ese tiempo, la documentación será considerada como aceptada.
El tiempo límite para presentar objeciones o correcciones sobre la documentación entregada por SEIDOR
TECHNOLOGIES se considera de 2 (dos) días hábiles, aunque podrán existir excepciones que serán acordadas
entre SEIDOR TECHNOLOGIES y el cliente en el caso de documentación muy extensa.
SEIDOR TECHNOLOGIES utilizará los templates propios para la confección de los documentos solicitados por el
cliente. En caso de que el cliente quiere trabajar con sus propios templates, estos deben ser acordados al inicio del
proyecto.
El plan de proyecto detallado y acordado con el cliente es parte del proceso inicial de la metodología de trabajo propuesta. El
plan de proyecto se divide en distintas fases iterativas e incrementales desde la definición o revisión de los requerimientos
(en este caso la revisión de los requerimientos) hasta la liberación parcial de cada una de sus funcionalidades.
La división del proyecto en fases o etapas claramente marcadas, con resultados visibles y concretos permitirá facilitar la
administración y gestión del proyecto.
El siguiente gráfico ejemplifica el modelo ágil e iterativo a trabajar para la implementación de los requerimientos:
El plan general del proyecto involucra las grandes fases que se requieren, como se indica en el siguiente gráfico:
Lo siguiente es un ejemplo de las tareas que se deben considerar en el primer sprint de trabajo y en un sprint cualquiera del
proceso de desarrollo.
Spike Sprint.
Kickoff inicial y Spring Planning meeting.
Análisis detallado de los requerimientos y situación actual.
Relevamiento Arquitectura actual y Sistemas.
identificación, organización y documentación de los requerimientos.
Definición de supuestos y riesgos iniciales.
Elaboración de los casos de uso y los casos de prueba iniciales.
Diseño de la solución.
Elaboración Documentación técnica y requisitos para la fase de desarrollo.
Sprint Review.
Elaboración del ProductBacklog y Sprint Baklog.
Sprint n.
Sprint Planning meeting.
Revisión del Sprint Backlog, priorización alcance y re-estimación.
Ajuste de casos de usos y casos de pruebas.
Desarrollo funcionalidades priorizadas.
Testing unitario y Rework.
Teesting Integral y Rework.
Certificación y Rework.
Aprobación Sprint.
Sprint Review.
Jefe Proyecto
Arquitecto Analista
Funcional
Desarrolladores Analista QA
Los profesionales de SEIDOR TECHNOLOGIES poseen una amplia experiencia en proyectos de desarrollo y son capacitados
en forma continua.
8.- METODOLOGÍA.
Los procesos de desarrollo son fundamentales para trabajar eficientemente y poder evitar incidentes que llevan a que un gran
porcentaje de proyectos se terminen sin éxito. El objetivo de un proceso de desarrollo es aumentar la calidad del software (en
todas las fases por las que pasa) y que sea repetible, a través de una mayor transparencia y control sobre todo el proceso.
Hay que producir lo esperado en el tiempo esperado y con el costo esperado, es labor entonces, del proceso de desarrollo
hacer que éstas medidas sean reproducibles en cada desarrollo y garantizar su cumplimiento.
No todos los proyectos y las necesidades son iguales, por esto, Seidor trabaja con RUP como proceso de desarrollo formal
para proyectos de gran envergadura y SCRUM incorporando prácticas de XP y perfeccionado para trabajo en contextos
distribuidos, como proceso Ágil de desarrollo de software. Cada uno personalizado para el cliente y tipo de proyecto, es parte
de nuestro valor agregado decidir cuál es el proceso que mejor se adapta a la situación concreta a la que se enfrenta un
proyecto, para minimizar la inversión requerida, obtener los resultados esperados y garantizar al cliente alcanzar la meta
propuesta.
Basándose en gestión adaptiva y en las lecciones aprendidas de los fracasos de la crisis del software, la industria desarrolla
durante los 90 y consolida en 2011 un conjunto de prácticas y recomendaciones que a la fecha se conocen como el “Manifiesto
Ágil”. En este documento se plasman las mejores ideas y conceptos probados en proyectos altamente exitosos.
Las prácticas comunes de cualquier metodología ágil son:
Gestión iterativa: el proyecto se desglosa o subdivide en mini-proyectos conocidos como iteraciones de duración
estrictamente fija no mayor a 30 días, siendo 15 días lo más común. Se hacen tantas de estas iteraciones como
1
Historia del manifiesto ágil - http://agilemanifesto.org/history.html.
Seidor – Propuesta Técnica. 20
sean necesarias para tener software que de valor al negocio, pero el empresario es quien finalmente decide cuando
terminar las iteraciones. Cada una de las iteraciones se concluye con software funcionando y potencialmente listo
para ser usado. Es decir, al final de cada iteración se tiene software que se puede ver y usar.
Equipos pequeños y multi-disciplinarios: El trabajo es realizado por equipos no más grandes que 8 personas
incluyendo los expertos del negocio, formando parte integral del equipo. Todos hacen de todo y lo hacen todo el
tiempo.
Inspección frecuente: El esfuerzo del proyecto se inspecciona diariamente por el equipo y demás interesados.
Gestión de productividad y calidad: Se aplican prácticas enfocadas a la productividad y la calidad. Es casi automático
duplicar la productividad y no es difícil multiplicarla 3 o 4 veces. La calidad del producto es controlada y mantenida
mediante un proceso continuo de pruebas automatizadas a lo largo del proyecto. No se hacen las pruebas al final,
se prueba todos los días muchas veces por día de forma casi automática.
Mejora continua: A lo largo de todo el proyecto se inspecciona el proceso para encontrar oportunidades de mejorar
productividad, calidad y satisfacción del cliente.
Con la aplicación de agilidad al desarrollo de software se obtienen los siguientes resultados para la empresa:
8.4.1.- VISIÓN
Esta es la primera actividad del proceso, donde los máximos responsables establecen dónde quieren estar a futuro, qué se
quiere lograr, a fin de transmitir al equipo, y poder enfocar las acciones en esa dirección.
PERSONAS AFECTADAS.
Product Owner.
Stakeholders.
TAREAS.
Identifica todas las metas y objetivos del proyecto.
Plasma la estrategia de la organización para cumplir metas y dar mayor valor al negocio.
Anticipa el ROI, releases e hitos.
El product backlog es el corazón del proceso, básicamente es una lista priorizada de requerimientos, features, store users,
etc. Cosas que el cliente quiere, descritas utilizando la terminología del cliente.
PERSONAS AFECTADAS
Product Owner.
Stakeholders.
Esta reunión consiste en la selección y planificación de los ítems del sprint a implementar.
Previo a esta reunión DEBE establecerse el tiempo que durará el Sprint. En el tiempo del sprint NO se considera el tiempo
insumido para esta reunión (Sprint planning meeting) ni de las reuniones de Sprint Review y Sprint Retrospective.
PERSONAS AFECTADAS.
Product Owner.
ScrumMaster.
Team.
DURACIÓN
Un (1) día completo.
TAREAS
El product Owner debe haber preparado con antelación el Product Backlog.
Consta de dos partes: seleccionar el backlog tentativo para el sprint y planificarlo.
(3) El team explora cada ítem del Sprint Backlog en mayor detalle.
(4) Para lo cual debe valerse la especificación del requerimiento detallada (o lo más detallada posible).
(5) El team idea estrategias para la construcción de los ítems del sprint backlog.
(6) El team define las tareas de cada ítem del Sprint Backlog y estima las tareas.
Caso práctico
Utilizar el método Delphi para realizar la estimación o Contabilizar la cantidad de horas por recurso disponibles para el Sprint.
Es decir contabilizar la cantidad de horas / días disponibles para el proyecto, tener en cuenta si las personas tienen planificado
tomarse vacaciones, licencias, días de examen, etc. o estén afectados a otros proyectos o tareas, por ejemplo reuniones de
ventas semanales. VALIDAR CON PLANIFICACION LA DISPONIBILIDAD DE LOS RECURSOS.
Para cada una de las tareas se realiza una asignación inicial. Para este punto tener en cuenta la disponibilidad del recurso.
Confeccionar un documento para el cliente especificando los ítems que se realizarán en el Sprint, junto a los costos asociados
a cada uno de los ítems. Para los costos, se tomará la suma de los tiempos de cada tarea multiplicado al costo del perfil de
la persona al que se le asignó la tarea.
Se carga el Sprint backlog, asignando el tiempo estimado del escenario óptimo a cada tarea.
PERSONAS AFECTADAS.
ScrumMaster.
Team.
DURACIÓN.
Típicamente 15 minutos.
TAREAS
Sobre la información que realizó el día anterior, se solicita también cuanto tiempo le insumió, ésta información se transcribe
(se documenta) en el Sprint backlog.
Sobre a qué se compromete a realizar en el día y las necesidades se transcribe en un documento de seguimiento diario.
Las conversaciones adicionales deberán posponerse.
Esta reunión se realiza el día posterior a la finalización del sprint. En este momento el equipo tiene la oportunidad de mostrar
su avance al product owner y los usuarios clave (stakeholders).
PERSONAS AFECTADAS.
Product Owner.
Stakeholders.
Seidor – Propuesta Técnica. 25
ScrumMaster.
Team.
DURACIÓN.
TAREAS.
PERSONAS AFECTADAS.
ScrumMaster.
Team.
Product Owner (opcional).
DURACIÓN.
Cerca de medio (½) día.
TAREAS.
Cada miembro del Team responde 2 preguntas:
Seidor – Propuesta Técnica. 26
o ¿Qué fue bien durante el Sprint?
o ¿Qué podemos mejorar para el siguiente Sprint?.
o SAMOLO – Same As, More Of, Less Of.
El ScrumMaster registra y resume las respuestas.
El Team prioriza los puntos de mejora.
Identifican la lista de impedimentos encontrados.
8.5.- ARTEFACTOS.
8.5.1.- VISIÓN.
Este artefacto, representa una “fotografía” del futuro, generalmente a mediano / largo plazo. Establece hacia dónde nos
dirigimos, qué se quiere lograr; sin visión, no podemos enfocar nuestras acciones. La visión es crítica para toda organización,
empresa o equipo, y es necesaria para sobrevivir como organización y le da vitalidad.
Aquí se identifican las metas totales del proyecto, las estrategias para lograrlas y define la inversión y el compromiso de
recursos.
En la práctica este artefacto generalmente es un documento que tiene que estar presente SIEMPRE por todas las
componentes involucrados (Product owner, ScrumMaster y Team).
El product backlog es el corazón del proceso, básicamente es una lista priorizada de requerimientos, features, store users,
etc. Cosas que el cliente quiere, descritas utilizando la terminología del cliente.
El sprint backlog está conformado por los ítems del product backlog que fueron seleccionados para que sean desarrollados
en un sprint.
8.6.- ROLES.
El foco del Product Owner o dueño del producto es el ROI. Ordena el proyecto, Sprint por Sprint, para proporcionar mayor
ROI y valor a la organización.
8.6.1.- SCRUMMASTER.
El Scrum Master es el responsable del éxito del proyecto, y él o ella ayuda a aumentar la probabilidad del éxito, ayudando al
product owner a armar un product backlog de mayor valor y ayudar al equipo transformar ese product backlog en funcionalidad.
8.6.2.- EL EQUIPO.
El equipo es responsable de manejarse y tiene la autoridad completa para hacer cualquier cosa a fin de satisfacer la meta del
Sprint dentro de las pautas, de los estándares, y de las convenciones de la organización y de Scrum.
Hasta 10 participantes.
Selecciona los objetivos del SPRINT.
El fin justifica los medios (dentro del proceso).
Organiza su tiempo y su trabajo.
Responsables de su trabajo.
Realiza el DEMO al Product Owner.
El equipo conduce el producto de una perspectiva táctica.
Responsable de las estimaciones de tamaño de los ítems del product backlog.
Confirma los ítems del sprint backlog. Planificacion de las tareas y estimación.
Seidor – Propuesta Técnica. 28
Toma decisiones de diseño e implementación.
Responsable de los estándares y prácticas.
Se compromete a entregar incrementos de software - y lo entrega.
Utónomo y auto-organizado, pero responsable ante el product owner para entregar según lo prometido.