Big Data. Parte I, el motivo

Sin animo de ser extensivo ni cubrir totalmente este tópico, presento el tema, para facilitar una primera idea.

Por Big Data entendemos un conjunto de tecnologías ideadas para procesar/almacenar una cantidad salvaje de datos. Imaginar por ejemplo una base de datos que almacene todos los tweets que se generan, o información meteorológica de temperatura en una ciudad. Este es el ejemplo típico: la base de datos de una conocida librería online de cuyo nombre no quiero acordarme..

Durante estos últimos años, se ha visto la necesidad de explotar cierta información que no es factible introducir en bases de datos relacionales, u otras derivadas: bbdd oreintadas a objetos, etc..

Para qué? Porque para ciertas empresas es interesante saber el número de clicks que se hacen  en una web, analizar los mensajes que se lanzan en las redes sociales, cruzar datos de ventas con otros factores ambientales…y todo ello no era viable con la tecnología tradicional. Por ejemplo: como se descargan y se pueden tratar los datos provenientes de millones de correos, sms, llamadas, clicks, xml de Aemet, etiquetas de fotos de Facebook,ventas de camisetas del Atleti….se necesita algo que sea capaz de procesar datos no estructurados y que sea muy rápido. Una desventaja de las bbdd relacionales es que son estructuradas, exigen un modelo de datos fijo y además no están pensadas para soportar un crecimiento de datos exponencial, si bien son buenas a la hora de cruzar datos.

Resumiendo, big data viene como necesidad de: Tratar gran Volumen de datos, a mucha velocidad y teniendo gran variedad en la topología de datos.

A propósito de esto: somos conscientes de todo los datos, de todo el rastro que dejamos en:

  • Redes sociales
  • Whatsapp
  • Entradas Twitter
  • Entradas Facebook
  • Fotos Facebook, etiquetas, rastro geográfico
  • Uso de tarjetas de pago
  • cookies: páginas visitadas
  • Links visitados
  • Videos visitados, canales subscritos

 

 

Advertisements
Posted in Big Data, Uncategorized

Brief intro to Prince2 Project Management

Prince2 TM has been recognized as a excellent Project management methodology during last ten years. It’s an international product.

Is owned for the UK Office of Government Commerce

Is accessible and helps to do de right projects in time and budget. It’s based on a customer/supplier environment.

There are two exams: foundation (multiple choices) and practitioner (more practical: 3 exercises to apply the knowledge. There are three cases with information to focus how they apply the knowledge rather than in the information that practitioners can memorize)

There are lots of training organizations that provide preparation and help getting ready candidates.

Currently, there are growing amounts of project managers that want to base and guide their projects by this serious methodology.

If you use Prince2, you will make simple the management of your project. Clearly define steps, processes with input and output, with start and end. You will define phases.

Prince2 has identified five project types:

  • Compulsory: new legislation
  • Not-for-profit: Good will in the community and the press
  • Evolving: Business decides next product during project
  • Customer/supplier. Traditional projects-clear product description
  • Multi-organizational: join projects

Main concept:

Business Case: To establish mechanisms to judge whether the project is desirable, viable and achievable to invest money on it. It’s done in the initiation phase.

The product is really needed? Why? Possible to do? Can we deliver the benefits? The project management will check the business case during the project: is investment still worthwhile?

What outputs will users use?

Later we start the delivery stages, keeping the Business Case up to date. PM must update the information in issues and risk, updating costs. Measurable benefits can be planned (how, who, when,…).

Current situation becomes the baseline

The Business Case also describes options considered: do nothing, chosen x or y , a short summary for upper management, ROI information, major risk study, responsibilities of senior users, reasons to do or not to do..

  • Outcomes: linked to new functionalities
  • Output: the final product
  • Benefits: measurable

The Business Case is responsible of Executive, but Project manager must update business case, creates plan, assist and maintains information up to date.

Tagged with:
Posted in Business Analysis, Prince2, Project management and Functional analysis

Inteligencia emocional aplicada a la empresa y la gestión de personas en proyectos.

La inteligencia como tal, como coeficiente científicamente medible no garantiza nada por si sola. De hecho hay gente que tiene un coeficiente muy alto y fracasa, ya sea en ámbito privado, su familia, matrimonio, etc.. o en el profesional, que es a lo que vamos.

Sin embargo hay personas que teniendo menos capacidad, acaban siendo felices, triunfando, en el sentido más positivo de la palabra…, dirigiendo un equipo, creando una empresa o simplemente llevando una vida satisfactoria.

No se trata de que nos leamos un libro típico de autoayuda de la tienda del aeropuerto y salgamos inspirados o alcancemos el Karma. Se trata de llegar al éxito en nuestras empresas.

Las habilidades sociales y las aptitudes sociales ayudan a controlar nuestras emociones y prevenir momentos de pánico y desequilibrio.

La mayor parte de las actividades dentro de un proyecto tienen un alto grado de “social”:

  • Entrevista con un cliente
  • Hacer una llamada de teléfono
  • Pedir un favor a un compañero
  • Defender una posición en un comité
  • Hacer una presentación de proyecto

Está claro que debemos tener un “motor” básico que procese información, para poder pensar, hacer un análisis, inventar una solución técnica. Pero son menos las tareas necesarias.

La gran parte de las tareas pasan por planificar, prever situaciones, hablar con una persona, influir sobre los demás con nuestras opiniones, crear complicidad con un miembro influyente de la empresa,..en definitiva comunicar. Seguro que muchos habéis visto la serie Big Bang Theory. Sheldon es un buen ejemplo de inteligencia pero con nula capacidad emocional.

Una persona siente, percibe, actúa. Cuando esto se desvirtúa, directamente sentimos y actuamos, sin pensar.

Muchas decisiones las tomamos antes de que realmente nuestro cerebro consciente lo sepa. Tenemos un proceso inconsciente que toma las decisiones. Luego tratamos de justificarlas de alguna manera, pero no tenemos control realmente sobre muchas decisiones que ya toma nuestro cerebro automáticamente.

Tenemos una capacidad realmente mínima de procesamiento, por eso cuanto más repetimos las cosas, cuanto menos tenemos que procesar nuevas señales, mejor hacemos las cosas. Vamos en piloto automático mucho más de lo que creemos.

Si somos capaces de aislar las emociones del pensamiento, mejor para nuestro futuro. Tratemos de que no nos venzan las emociones.

Las emociones son buenas, no se trata de ir contra ellas, sino controlarlas, canalizarlas. No es represión, sino ser consciente de la existencia de ella.

Un ejemplo sencillo: el miedo es bueno, hasta cierto punto. El pánico no, provoca caos, te arrastra. Llevado al trabajo, si uno no está seguro en su trabajo, se bloquea.

Muchas veces en un momento clave nos guiamos por la euforia o por el fatalismo para tomar una decisión que está ahí entre sí/no y por un impulso se acelera.

Las emociones básicas podrían ser: Enfado, Alegría, Miedo, Tristeza

Las emociones descontroladas nos afectan negativamente, nos hacen débiles en situaciones clave. Ejemplo, si nos enfadamos con un empleado y en vez de regañar y descontrolar tu reacción, tratas de calmar y ser firme pero sin pasar la línea de la educación evitaremos que vaya a peor o que definitivamente perdamos la batalla, lo que será peor para el proyecto.

Igual pasa si no tenemos capacidad de argumentar en público nuestra opinión. Siempre quedaremos ocultos e invisibles para nuestro jefe. A todos nos gusta ser reconocidos y relacionarnos, cuidar nuestra autoestima. Esto nos genera un estrés emocional que nos hace pasar malos momentos.

Quien no se ha sentido mal cuando está en una oficina donde todos son grupo y se van a comer juntos sin contar contigo?

Quien no se ha sentido desmotivado en su trabajo?

Quien  no ha tenido inseguridad al afrontar un nuevo proyecto? La confianza en uno mismo juega un papel importante, puede suplir otras carencias.

Todo esto hace que estemos emocionalmente inestables.

El control no hay que perderlo. La competencia de autocontrol es una de las más importantes. Se va todo al traste, perdemos la razón. Esto es un resorte que se activa en determinadas ocasiones y “saltamos”. Lo mejor, contar hasta 10 y respirar.

Un jefe de proyecto debe contemplar las expectativas de sus miembros de equipo. Habrá gente que quiera asumir retos y otros que no quieran ninguna responsabilidad adicional.

Por lo tanto debemos entrenar la capacidad de analizar las expectativas y emociones nuestras y de los demás. Si podemos analizar las relaciones que mantenemos con los demás y saber motivarnos y sacar provecho, tendremos gran parte del éxito profesional y personal garantizado. Si los demás nos ven competencias, intuyen que estamos preparados para hacer las cosas bien, confiarán más en nosotros. Esto es muy importante en el mundo de la empresa y también en la faceta personal.

Hay que estar preparado para el cambio, adaptarse. Si vamos con ideas preconcebidas no actuamos de forma inteligente. Nos chocamos con la realidad constantemente.

Que percepción queremos dar a los demás? Que autoimagen queremos proyectar? Es bueno tomar un café con los compañeros o mejor ir solo? ¿es bueno tener iniciativas?

El rol social y las motivaciones de cada miembro del equipo se van viendo con el tiempo, va mostrándose poco a poco. Seguramente se puedan sacar por algún tipo de test. Es bueno en un equipo tener perfiles distintos, para no chocar ni dejar huecos así como asignar roles adecuados a cada miembro:

  • Hay gente que busca la excelencia en su trabajo y ser reconocido
  • Hay sujetos que buscan alcanzar poder, que tiene intenciones ocultas
  • Hay personas que no quieren ser molestadas o alteradas en su trabajo, quieren una estabilidad y un horario concreto.
  • Hay personas que solo quieren llevarse bien con todos y ser felices

Una habilidad muy importante es saber entablar relaciones sociales en una organización, la empatía aplicada;  saber a quién acudir para cada cosa. Todos conocemos a alguien que se mueve y sabe siempre a quien hay que llamar. También conocemos al típico apático que no sabe ni conoce a nadie.

Todo esto es mucho más complejo, no soy médico ni psicólogo, tan solo es mi resumen personal de algo muy interesante. El que quiera más que estudie a Goleman.

Posted in Uncategorized

Introducción a COBIT

COBIT (Control Objectives for Information and Related Technology)

Es un marco de referencia para el buen gobierno de los departamentos TIC y asegurar un control adecuado.

Las empresas exitosas utilizan las tecnologías de forma adecuada. COBIT ofrece un marco de trabajo basado en procesos y lo que propugna es un enfoque sobre control de las inversiones en IT, no sobre su desarrollo mismo. Permite integración con otras metodologías.

Se intenta organizar las actividades del departamento IT mediante un modelo de procesos. Identificamos métricas, procesos de madurez, y responsabilidades. Es una guía de buenas prácticas en tecnología. Todo consultor senior debería conocerlo para saber reportar adecuadamente a la gerencia.

Destinatarios:

  • Gerentes, para saber gestionar y optimizar la inversión.
  • Auditores de Sistemas (aconsejar a la dirección proactivamente sobre la efectividad de los controles internos)
  • Usuarios, para obtener la garantía sobre los servicios de que dispone.

¿Cómo puede hacer la empresa para que su estructura IT genere la información que necesita?

Estudiando las dependencias tecnológicas, regulatorias, los recursos disponibles, definiendo objetivos de control y definiendo un vínculo entre IT y los objetivos de negocio. Todo esto se aprovecha para maximizar las ventajas competitivas y la administración de los riegos y el control de la información, como parte clave del gobierno de la empresa.

Modelo de procesos. Cada proceso puede medirse, tiene responsables y responsabilidades:

  • Medición de riesgos. Transparencia. Brechas de capacidad
  • Monitorización de procesos: implementación, despliegue, definición
  • Alineamiento objetivos estratégicos
  • Optimizar recursos y costos. Inversión óptima. El costo justifica el beneficio?

La gobernanza TI de la empresa soporta la estrategia de la empresa para lograr los objetivos finales. El éxito se entiende cuando se alcanzan los objetivos deseados y también cuando se minimizan los riesgos.

El modelo COBIT está formado por 34 procesos que se agrupan en 4 áreas fundamentales: Planificación, Construcción, Ejecución, Monitorización.

Cada proceso tiene un dueño, está documentado, se mide su desempeño, tiene metas de rendimiento, se comunica a las partes, hay planes y  hay controles.      

Hay controles de negocio y controles de aplicaciones o sistemas, cambios, procesos de negocio, autorización, validaciones manuales.

El éxito del modelo se basa en el uso correcto de Infraestructuras, personas, aplicaciones e información. Se intenta que las irregularidades sean detectadas, reportadas y corregidas.

Beneficios a nivel general

  • Alineación con negocio
  • Uso de mejores prácticas.
  • Visión entendible para gerencia de lo que hace TIC
  • Terceros que regulan y supervisan
  • Entendimiento entre todos interesados del negocio
  • Reparto de responsabilidades
Tagged with: , , ,
Posted in Uncategorized

Por qué una empresa necesita orientarse a Proyectos

Los entornos de negocio cambian constantemente. Las necesidades no son las mismas en todos los momentos, por lo que una estructura de empresa orientada a departamentos clásica, según áreas funcionales y con jerarquías no siempre da el soporte más adecuado al negocio.

 Hoy en día, donde las amenazas, las necesidades y los requerimientos de la tecnología y el software son tan cambiantes, se necesitan estructuras dinámicas de gestión, que permitan “poner el foco” en determinados puntos y dejar otros en un plano secundario.

 Si nos fijamos bien, casi todas las grandes empresas ya están siguiendo esta orientación a proyectos. Si nos centramos en los departamentos de informática, es muy común ver cómo crecen según demanda, contratando recursos externos especializados y desprendiéndose de ellos cuando ya no los requiere.

Un ejemplo claro podría ser la implantación de una nueva base de datos Oracle, más rápida y robusta para soportar las transacciones de los clientes en la web. Por ello nuestro departamento de informática no va a crear un área de implantaciones Oracle, sino que dotaremos un nuevo proyecto “implantación Oracle” con los recursos necesarios para poner en marcha el servicio.

Pero siempre se necesita una estructura fija de la empresa, que sea la que contenga el “core” del negocio. 

Una desventaja de esta organización por proyectos es que con frecuencia los proyectos se aíslan unos de otros, el conocimiento queda compartimentado y se corre el riesgo de generar servicios o productos desacoplados, es decir, que por separado son magníficos, pero que al carecer de una misma política o marco común, no tienen trazabilidad o forma correcta de conectar el uno con el otro. Esto es un problema muy común. Imaginemos por ejemplo que las interfaces que una aplicación genera sean diarias y sin embargo, otra aplicación que bebe datos de la primera, las necesita mensuales.

De aquí surge la necesidad de gobernar los proyectos de forma coordinada. De ahi la necesidad de coordinar los proyectos con una gestión de cartera y portfolio.

Tagged with: ,
Posted in Uncategorized

Application Lifecycle Management

This is a subject about software lifecycle management, from requirements to deployment, to empower software quality, maintenance and visibility. It is used by project members to coordinate and manage issues.

Generally speaking, the phases of the application lifecycle management processes are:

•Defining releases
•Specifying requirements
•Planning Tests
•Executing Tests
•Tracking Defects

Broke it into pieces

Releases can contain a set of new features (linked to requirements), a group of changes in an application that will be available at the same time. That is what you must check with customized test plans. And also you can execute several cycles during the development timeline.

Do these tests cover requirements?

Ideally, requirements result in a group of features. These features can be checked a group of tests. And tests can be linked to requirements and also with defects. The test set will meet all the requirements, ensuring that all functionalities work perfectly

Basically, you can create a set of test plans; in fact, you can build a test plan tree. Each of them can contain some test steps that check some conditions, having additionally pre-requisites and post-conditions. Steps offer ordered and detailed actions to be performed on the application, and the expected results.

Example:             Test 1: Login user Form.

Step Action Expected Result
1 Click on the text component labeled: ‘Name’. Write a user name The field allows to write a 50 max character name
2 Press tab Cursor goes to next field
3 Write a password The field allows writing a 10 max character string. It is masked for security purposes. Only shows ‘*’
4 Press button ‘Go’ If name and password are both correct, the system raises application. If not, shows an alert message.

The aim is to ensure the software does what it is supposed to do, dividing software into testing units.

Execution.

At this phase, you will execute these test sets, updating information about fails, logs, errors or success … all about test’s results. By submitting defects, it will help development team to track and repair, thus manage properly defects.

After running tests, you can analyze results and certify or revoke the software component.

Resolving Defects

Defects must be prioritized and assigned to a single person to resolve it.

Software Tools

There are some testing tools available in the market; i.e.: HP Quality Center.

For instance, we create a ‘Test Plan’ to define a functional test: steps, expected results. And we will create a ‘Test Lab’ as an instance of a single test Plan or a set of them, which can also be executed several times.

Tagged with: , ,
Posted in Project management and Functional analysis

Breve resumen sobre SCRUM

Lo siguiente es un pequeño resumen, no pretende ser definitivo ni agotar el tema.

SCRUM es un marco de trabajo (Framework) para el desarrollo Ágil de productos software (proyectos). Se basa en unos principios, prácticas y valores ágiles, no es una metodología completa como tal. No tiene demasiados artefactos o etapas cerradas.

Principio básico: entrega temprana al cliente de software (entre 2 semanas y 2 meses) con valor para su satisfacción. No se alienta la resistencia al cambio, como es la tónica habitual en los proyectos, sino que pretende aprovechar para aumentar la ventaja competitiva del cliente y su satisfacción. Por otra parte, se pretende obtener un ritmo constante de desarrollo.

Las entregas son iterativas e incrementales, aportando nuevas funcionalidades en cada iteración o sprint.

Se fomenta el trabajo en equipos  auto-organizados, la comunicación cara a cara y la colaboración entre los profesionales que saben del tema. No hay roles pre-establecidos ni jerarquías (..yo jefe de proyecto ordeno y mando y tu programador haces lo que te diga..). Se perfecciona y se busca la mejora continuamente.

Se prohíbe la ocultación de detalles de implementación al cliente, ya que se le tiene informado y presente en las reuniones.

El equipo construye aquello que el Product owner indica. El Scrum Master es un garante de la ejecución del método y un facilitador, en ningún caso es un Project Manager al uso, cuya función consiste en re-enviar mensajes con copia a, actualizar excel copia y pega de otro proyecto o manejar Gantts.

Objetivo principal: mejorar la satisfacción del cliente, la velocidad y calidad de desarrollo a través del trabajo en equipo y la transparencia.  Los requerimientos o alcance se cambian durante toda la vida del proyecto.

Se lucha contra las jerarquías de personas, los departamentos estancos y la negociación con precio, fecha, requisitos cerrados, previa mirada a la bola de cristal para saber dar una fecha exacta e ineludible en la que cerrar el documento funcional y lanzar el desarrollo…

Textualmente pego lo que dice el manifiesto Agil:

“Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”

 

Roles

Product Owner o dueño del producto. Es una sola persona. Dice que es lo siguiente más importante que se debe hacer. Será responsable de garantizar el máximo retorno posible del proyecto. Su tarea consiste en identificar las necesidades que debe cubrir el producto, priorizando las historias más importantes en primer lugar (se asesora por el equipo también) para que se aborden en los sprints por orden de prioridad y se encarga de actualizar continuamente la pila de producto con requisitos: nuevas historias, redefinir, re-priorizar y reordenar la pila. Mantiene el gráfico de burndown. Lo deseable es que sea alguien con suficiente autoridad para respaldar el proyecto y dar apoyo, y no alguien que actúa obligado por las circunstancias o como encargo marrón de otro superior.

Team members: Formado por profesionales multifuncionales que cubran todos los roles entre varios. Es autónomo y autoorganizado, no por programadores que solo programan, tester que solo realizan pruebas, etc.. Son los que mandan en el desarrollo.

Ellos deciden a lo que se comprometen y como lo hacen, así como de realizar las estimaciones de las historias.  El equipo diseña, construye, prueba y vela por la calidad interna del producto, ayudando al Product Owner a comprender tareas y requerimientos técnicos.

Mejor que sean equipos estables, que no cambien mucho. Las rotaciones en los equipos acaban lastrando el rendimiento.

Scrum Master es una sola persona que ayuda al equipo y al Product Owner a finalizar con éxito, garantizando el máximo de productividad al evitar incidentes, resolver cuellos de botella por recursos no concedidos, permisos, accesos, …burocracía en definitiva o simplemente correos no contestados, así como ejercer de guardián del método Scrum. Debe ser un profesional experimentado a nivel técnico pero con dotes de líder colega y un toque de entrenador de rugby o coaching de equipos. Este rol lo puede abordar un miembro del equipo o ser una persona a tiempo completo si el proyecto es mediano o grande.

IMPORTANTE: No dice a nadie lo que tiene que hacer o asigna tareas. No es un manager o líder técnico del equipo, sino alguien que ayuda, protege y guía en la aplicación del Scrum. Vigila que todo el mundo entienda su papel y aplique el método. Debe ser una persona enérgica y pro-activa, además de poseer también ciertas habilidades sociales.

El product Owner y el Scrum Manager no pueden ser la misma persona.

 

Conceptos básicos:

Sprint 0: es la fase inicial donde se crea el Product Backlog. Cuanto más breve mejor. A partir de ahí, comienzan los sprint. Puede durar unas semanas o un mes aprox.

Sprint: iteración corta de desarrollo entre 1-4 semanas generalmente. Se suceden uno tras otro. 

Pila de producto o Product Backlog: Lista priorizada y ordenada y estimada de requisitos de alto nivel o historias de usuario. Representa el alcance y la planificación del proyecto. La Prioridad en la lista: puede deberse a mitigar riesgos, necesidades técnicas, dependencias, satisfacción de áreas corporativas, alineación con estrategia de la empresa, etc..en ningún caso será capricho del product owner.

Gráfico de Burndown: es un gráfico que muestra cuanto alcance hay que entregar sprint por sprint para alcanzar el objetivo. Lo ideal es que la cantidad pendiente de hacer vaya disminuyendo, por lo que será una gráfica de un arco descendiente,..aunque se pueden producir parones. Se crea durante la planificación del reléase y es actualizado en cada sprint por el Product Owner.

Tablero de tareas Taskboard: es un instrumento de autogestión del equipo. Contiene un post-it por cada historia de usuario que incluye el sprint. Se van colocando en la columna que corresponda: no comenzado, comenzado y terminado. Debe estar siempre actualizado. Refleja fielmente quien está haciendo qué cosa.

Reglas básicas

Regla1: Los sprints no pueden ser redefinidos o ampliados nunca, haya terminado todo o no. En todo caso se pueden cancelar (es el Product Owner el que puede hacerlo) si hubiese un cambio grave o modificación que hiciese perder el tiempo en el desarrollo previsto, pero nunca se amplía para llegar a tiempo. Las historias no comenzadas o no terminadas se pasan al próximo sprint. O se cancelan si no son válidas. NO se entrega nada parcialmente. Si una funcionalidad está hecha y probada pero no documentada, paquetizada y subida al CVS… no se marca como finalizada.

Regla2: Durante el spring, las historias elegidas no pueden ser modificadas, para asegurar la consistencia.

Regla3: Solo existe un Product Backlog y cada elemento tiene una prioridad única.

Regla4: Organizamos en base a Releases que constan de varios sprints suficientemente pequeños y compactos. Cada sprint debe obtener un producto lo más autónomo posible. Es decir, …si posibilita una nueva utilidad o pantalla en una aplicación.. también debe llevar la parte que modifica la bbdd necesaria, no solo la de la aplicación.

Regla5: “done” o Hecho significa integrado, potencialmente listo para pasar a producción , probado, testado y documentado.

Proceso Sprint

Inicio. Reunión de Planificación del Sprint. Esta reunión durará entre 2 y 4 horas, según lo grande que sea el sprint.

Reunión What: Product Owner, equipo y Scrum Master repasan la funcionalidad de alto nivel que el primero está interesado en obtener en el sprint que comienza.

Reunión How: El equipo selecciona aquellos ítems que considera factible implementar. Esto es responsabilidad y decisión del equipo, no del Product Owner. Si éste considera que deben implementarse más ítems, se puede replanificar o abordar el tema, pero nunca podrá imponer. Se hace una tabla con la asignación de tareas por miembro con las horas asignadas según el esfuerzo que se le ha puntuado. Y se añade una columna por día para decir el esfuerzo que le queda pendiente invertir para terminar.     

En esta segunda reunión se realiza el análisis en detalle y descomposición en tareas de las historias de usuario seleccionadas. Normalmente estas tareas o pasos serán técnicas y no superarán un día de trabajo. En esta descomposición se pueden añadir o quitar historias, según se vea factible por los team members. Una vez que se termina la reunión y las historias descompuestas se confirman, pasan a la Pila del Sprint o Sprint Backlog. Se llena el Tablón de tareas con pos-it.

Scrum Diario: Es una breve reunión diaria a primera hora de unos 15 minutos. Se recomienda hacerla de pie frente al Taskboard. Es una reunión de sincronización y coordinación del equipo. El único objetivo es que cada miembro del equipo diga 3 cosas: lo que ha hecho desde la última reunión, lo que va a hacer hasta la próxima y si tiene algún bloqueo o problema que le impida hacerlo.

No es una reunión de reporte al gerente, al scrum Master o al Product owner, sino sincronizar y coordinar entre los miembros del equipo. Todos deben estar alineados con el éxito y saber lo que otros hacen para llegar al objetivo.

Importante: NO debe haber discusiones, enfrentamientos o debates en esta reunión. Cualquier tema de este tipo debe resolverse al organizarse una reunión a parte después de esta para debatir.

Cada día se actualiza el Sprint Backlog y el Burndown .

Finalización del sprint: se termina el día marcado, sin ampliaciones.

Reunión de Revisión del Sprint. Se reúnen el equipo, el Scrum Master y el Product Owner (también pueden asistir otros interesados en ver cómo va el proyecto: clientes, stakeholders, gerentes, usuarios finales..expertos) para repasar el trabajo que ha sido finalizado durante la iteración. Se obtiene feedback. La reunión debe ser abierta y transparente. Incluye una breve demostración de las nuevas funcionalidades y se obtiene feedback de todos los presentes. El Product Owner debe procesar la información recabada, finalizando potencialmente en nuevas historias, cambios de criterios o cambios de prioridades.

 

Reunión de Retrospectiva del Sprint. Está diseñada para mejorar continuamente el proceso de construcción. Se analizará que estamos haciendo bien y que hacemos mal y cómo podemos mejorar. Se capturará la información y se discutirá como aplicar las mejoras. El ScrumMaster será el responsable de mantener la Pila de Mejoras, una lista de cosas a mejorar.

 

Se supone que entre el 5-10% del esfuerzo total es para ir actualizando el Product Backlog y seleccionar las histórias del sprint.

Es una metodología ligera, pero cualquier gestión de proyecto necesita tiempo.

 

Tagged with: , , , , ,
Posted in Uncategorized