Una vez más Managengine nos sorprende, una vez más, con una herramienta para la Gestión centralizada de PCs y dispositivos móviles. Desktop Central.
Es un software integrado de administración de escritorio y dispositivos móviles que permite administrar servidores, laptops, desktops, smartphones, y tabletas desde una ubicación central.
Desktop Central está disponible en cuatro variantes – versión Patch, versión Professional, versión Enterprise y versión Free.



Administración de parches:
Puedes automatizar el despliegue de parches relacionados con el sistema operativo y otras aplicaciones externas, así como proteger Windows y Mac contra amenazas de seguridad.


Despliegue de software:
Contiene plantillas integradas para creación de paquetes, simplificando así, la distribución de software.


Administración de dispositivos móviles:
La administración de dispositivos móviles permite configurar, administrar y asegurar dispositivos móviles.


Administración de aplicaciones móviles:
Con la administración de aplicaciones móviles permite distribuir y administrar apps; es compatible para dispositivos iOS y Android.


Administración de activos:
Puedes administrar los activos de TI, medir de software, administrar de licencias de software y software prohibido, entre otros


Control remoto:
Resolución de problemas de escritorio remoto con colaboración multi-usuario, transferencia de archivos, grabación de video y más.


Administración de energía:
Podrás aplicar esquemas de energía, apagar computadoras inactivas y obtener informe de tiempo de actividad del sistema.


Administración de dispositivos USB:
Podrás restringir y controlar el uso de dispositivos USB en la red, tanto a nivel de usuario como a nivel de Equipo.

Configuraciones:
Configuraciones pre-definidas incluyendo, administración de energía y políticas de seguridad, entre otras.
En definitiva una herramienta muy completa que además es capaz de integrarse con otros software de Managengine como el Gestor de Incidencias Service Desk Plus.
Se puede integrar con Microsoft SQL Server, aunque en la instalación inicial trabaja sobre Postgre.







17 July 2017 - admin @ 13:47 | Comentar(0)

BMC Remedy Parte I -





Para los que no lo conozcáis, Remedy es una aplicación ITSM, basada en buenas prácticas y muy aceptada en el mercado. Contiene todos los módulos necesarios para gestionar servicios y soportar todo el ciclo de vida del mismo.

Conozco BMC Remedy desde hace algunos años. Lo empecé a utilizar en su versión 7, integrando su módulo de gestión de incidencias con el módulo de gestión de incidencias de HP Service center (Hoy HP Service Manager).
Recuerdo que fue una integración complicada debido a las características de los dos aplicativos, y utilizamos WebService para esta integración.
Desde ese momento, Remedy casi siempre ha estado en mi camino, a través de desarrollos o consultorias.
He visto muchos cambios en este aplicativo, desde el incómodo interface de las versiones 7.x hasta el "amigable" interface visual de las versiones 8.x.
En sus versiones 7.x el aplicativo contenia aplicaciones como el cliente pesado y el Administrador, que se utilizaban y se siguen utilizando (esta versión está aún implantada en muchas organizaciones) como interface de usuario e interface del Administrador/desarrollador. Trabaja con bases de datos como Oracle, SQL Server etc...
Al contrario que otras herramientas como HP Service Manager por ejemplo, Remedy basa su desarrollo en formularios y a estos le son aplicados filtros, active link, guias, etc... De esta forma, el desarrollo y la parametrización de la herramienta a una organización se hace bastante sencilla y abarca casi el desarrollo de cualquier requisito para adaptar la herramienta a determinadas necesidades.
En sus nuevas versiones 8.x, el interface del usuario está mucho más trabajado, sus módulos de gestión (Incidencias, cambios, CMDB etc...) se instalan todos a la vez si lo deseamos, aunque esto ya se podía hacer así desde la versión 7.6 creo recordar.
Quizas este post es muy somero, pero en las siguientes partes, intentaré detallar todo lo que pueda las versiones 7.x y 8.x, interface, SRM, Gestión de Incidencias, cambios, con sus ventajas y desventajas con ilustraciones, para hacer el post más amigable y comprensible.

Vista de Remedy en sus versiones 7.0 - 7.5


Vista de Remedy en sus versiones 7.6 - 8.x










15 November 2014 - gpereira @ 06:32 | Comentar(0)

Acercándonos al BI -






Acercándonos al BI

Se habla de BI constantemente en las organizaciones, en las redes sociales, parece estar siempre intrínsecamente relacionado con las estrategias de Empresa.
Pero ¿Cuál es el principal objetivo de BI para una empresa que quiere adoptar una herramienta para tal fin?
Apoyar la toma de decisiones aportando información relevante y actualizada a los destinatarios adecuados en el momento necesario.
Bi, transforma los datos en información. Esta información será crucial para adoptar unas medidas u otras y por supuesto para tomar una u otra decisión.
No todas las organizaciones tienen la posibilidad de implantar una herramienta BI, es costoso y los perfiles consultores que la gestionan también. Pero, cabe destacar que toda compañía tiene la posibilidad de implantar herramientas de BI, podrán contar con una información realmente óptima para la toma de decisiones.
Los beneficios que se obtendrían al implantar un sistema BI están relacionados con la mejora de la gestión de la compañía, reducción de costes, incremento de los ingresos, mejora de la toma de decisiones.
¿Cuáles serian algunos de estos beneficios?

1. Información en tiempo real: Información actualizada y dispuesta para ser utilizada en el momento requerido. Por ejemplo, la extracción de datos de una herramienta de gestión de incidencias, con unas categorizaciones y tipificaciones adecuadas, se traducirá en un control de KPI óptimo que nos
guiarán en la correcta toma de decisiones. Así, nos permitirá un mayor control sobre los objetivos estratégicos marcados por la organización.

2. Interpretación de los datos: Los datos ordenados y clasificados favorecen su conversión a información. Ya sabemos que lo más importante a día de hoy es la información ya que genera poder.

3. Distribución de la información: Debido a la correcta distribución de la información, se optimizan los flujos de la comunicación. De esta forma, quedan alineadas las partes implicadas, favoreciendo la colaboración dentro de la compañía.

4. Gestión del conocimiento: Que duda cabe que favorece al control de conocimiento de la organización, conociendo en el momento en que lo requiera, la información necesaria para optimizar las estrategias.

5. Reducción de tiempo y costes: Gracias a esta transformación de datos en información, se simplifican las labores de mantenimiento de los sistemas IT, lo  que reduce el tiempo que los dedicado a estas tareas y ello conlleva a la reducción de los costes.

Aunque es una breve pincelada sobre BI, creo que la implementación de herramientas BI, siempre será beneficioso para cualquier organización que se lo pueda permitir.













23 May 2014 - admin @ 14:21 | Comentar(1)

Criterios de selección tecnológica -




Históricamente, las decisiones de adopción de una determinada tecnología se regían por el ahorro de costes basándose en determinadas características técnicas. Sin embargo, se ha convertido en uno de los pilares de la ventaja competitiva de muchas organizaciones. Las TIC apoyan para tomar decisiones efectivas e inteligentes en cualquier área de la organización.
Seleccionar una tecnología u otra, es básico para un directivo por las implicaciones estratégicas de esa tecnología.

Estas decisiones, se basan en el análisis de coste/beneficio de la solución, la capacidad de la organización para llevarlo a cabo, y otros valores colaterales.
La incertidumbre es un concepto anexo a aquellas organizaciones basadas en un gran porcentaje por la tecnología, por ello la adopción de nuevas tecnologías influirá en la cultura de estas. De esta forma cada organización debe de tomar la decisión de adoptar una nueva tecnología basándose en sus experiencias y expectativas.

1.CRITERIOS RACIONALES DE SELECCIÓN

Las métricas iniciales para este tipo de selección son:
- Objetivos de rendimiento necesarios para el correcto funcionamiento del sistema.
- Análisis las diferentes alternativas tecnológicas alineadas con los objetivos propuestos.
- Análisis de las diferentes alternativas tecnológicas alineada a la inversión necesaria.
- Análisis de las diferentes alternativas tecnológicas más favorable entre la inversión y el rendimiento.
- Total Cost of Ownership (TCO), nos permite medir el valor de las inversiones necesarias para llevar a cabo un proyecto TIC.
En cualquier elección, es importante analizar los costes directos y los indirectos.

1.1 Costes directos

- Inversión: Compra y mantenimiento del hardware y software.
- Gastos: Personal técnico y administrativos (Consultorías, Auditorías etc.)

1.2 Costes indirectos

- Formación: formación a los usuarios de la nueva plataforma.
- Control de las herramientas.
- No productividad: En los tiempos de migración de plataformas, tiempos de parada y gestión de red.
- Espacio y energía: Ubicación, coste energético etc.
Un parámetro asociado a los anteriores, son el ROI o retorno de la inversión, que nos permite medir la recuperación de la inversión, y el TTM (Time To Market), que nos estima la disponibilidad del nuevo sistema a incluir en nuestro entorno.

1.3 Calidad

Parámetros como la escalabilidad (capacidad de un sistema para adaptarse a una demanda futura de servicios), fiabilidad (capacidad para dar servicio de forma ininterrumpida), rendimiento (velocidad de respuesta ante la demanda de una tarea), marca (valor intangible que hace referencia a la seguridad y confiabilidad) y seguridad (técnicas para proteger la integridad de los datos), nos acercarán a la medición de la calidad del sistema a incluir en nuestro entorno.

1.4 Factores bloqueantes

- Costes de transición: Si este coste es elevado, el cambio de tecnologías es complicado, apareciendo una situación de bloqueo.
- Internos: Contratos firmados a largo plazo con proveedor de la actual tecnología, tecnologías heredadas o resistencia al cambio por parte del usuario de la organización.
- Externos: Dependencias del proveedor tecnológico

2. CRITERIOS DE INFLUENCIAS

Existen parámetros que influyen en la decisión a la hora de adoptar una nueva tecnología, como son las influencias sociales. Se toman decisiones basándose en criterios de terceras personas, usuarios e incluso opiniones de la competencia.
Cuanto más extendida esté una tecnología mayor seguridad otorgará a la organización, no importando que esa misma tecnología ya habite en la competencia. La innovación integra incertidumbres y riesgos, pero si ofrece buenos resultados, esta será adoptada por otras organizaciones.

3. CRITERIOS DE SITUACIÓN

Análisis de ventaja: Analizar las ventajas del nuevo sistema frente al antiguo y riesgos reales implícitos en la sustitución.
Visibilidad: Visibilidad de los resultados y mejoras implícitas en el cambio hacia la organización.
Impacto: Analizar si impactará en los procesos y resultados de la organización.
Compatibilidad: Analizar si será compatible y se adaptará a la política de la organización y su infraestructura.
Facilidad: Analizar si poseemos la capacidad para tratar y mantener el nuevo sistema, y con ello la facilidad de uso y comprensión por parte de los operadores del sistema.
Pilotos: Realizar pruebas piloto antes de implantar en producción el sistema, mitigaría los riesgos.
Formación: La formación al usuario final es básica, y esto, puede dificultar la adopción de la nueva tecnología aunque esta sea superior a la actual.
Riesgos: Se deben analizar los riesgos implícitos en el cambio.
Difusión: A medida que aumente el número de usuarios aumentará la demanda de la tecnología y su valor en el mercado.










17 May 2014 - jpsantiago @ 17:50 | Comentar(0)

Metodologías de pruebas -




Las etapas de ciclo de vida del software, se nutre de la toma de requisitos, Análisis, diseño, desarrollo, pruebas, implantación y mantenimiento.
Vamos a ver como se desarrolla la etapa de pruebas y cuales son sus metodologías más convencionales.

El término “Prueba” viene utilizándose  dando nombre  a diferentes estrategias y objetivos en su aplicación. Pruebas unitarias, de integración, se sistema o de aceptación. Se presentan como una actividad que se desarrolla para evaluar la calidad de un producto. En actividades, se identifican los errores, y se solventan mejorando el producto.


Las pruebas se aplican en diferentes fases del proceso de desarrollo, y en ocasiones  mediante diferentes probadores.


1. Metodologías convencionales


En este tipo de metodología, que es la mayormente utilizada, la actividad de ejecución de las pruebas no empieza hasta que la etapa de desarrollo es finalizada. Esto requiere un entorno de desarrollo, un entorno de certificación (ambos entornos iguales) donde se realizarían los casos de prueba (unitarias, de integración, se sistema o de aceptación, las pruebas de integración no podrían iniciarse hasta que finalizasen las unitarias) y se certificaría su funcionalidad como correcta o incorrecta. En el caso de ser correcta, se abriría una ventana de implantación en producción, y se implantaría el desarrollo con un porcentaje del 100% de acierto en la funcionalidad en este entorno.

La parte negativa de este método es que si las pruebas resultaban erróneas, se vuelve a la etapa de desarrollo, se corrigen los errores y se vuelve de nuevo a la etapa de pruebas, esto obviamente retarda mucho las subidas de nuevos desarrollos a producción que en muchos casos podría ser un desarrollo estratégico para la organización.
Estos flujos, han ido evolucionando y ahora,  las pruebas se consideran como una actividad que debe estar integrada en todo el proceso de desarrollo.
En las metodologías convencionales, los ingenieros de pruebas definen los casos de pruebas y los probadores son los responsables de ejecutarlos.



2.Metodologías ágiles




La evolución del mercado hace ineficientes los cambios usando las metodologías convencionales y se requiere una progresiva reducción del tiempo requerido su implantación en producción.
Las metodologías ágiles intentan incrementar la calidad del producto y reducir el coste derivado de los cambios en los requisitos.

Las pruebas tienen objetivos diferentes, la idea es que los requisitos sean traducidos a pruebas, así, cuando las pruebas sean correctas se garantiza que el software cumple con los requisitos que se han establecido. En las metodologías ágiles los encargados de realizar las pruebas, son los propios desarrolladores, ellos conocen el código y su estructura y pueden subsanar el error en tiempo real. Estas pruebas serán unitarias son los desarrolladores los encargados de ejecutar este tipo de pruebas mediante pruebas unitarias, y los casos de pruebas serán creados por ellos mismos.

Las metodologías ágiles, abogan por que las pruebas y el desarrollo estén completamente integradas y presentan distintos enfoques del proceso de desarrollo que vienen determinados por los tipos de pruebas que se están realizando. Utilizan las pruebas unitarias y de aceptación como principales herramientas para dar soporte a los enfoques de pruebas.

En la estrategia Test-driven development (TDD), se toma como base las pruebas unitarias. En primer lugar, se detalla una prueba y se verifica, si falla se implementa el código que hace que la prueba sea correcta, re-factorizando el  código escrito logrando un código limpio que funcione.


2.1 Ciclo de pruebas:





- Elección del requisito
- Escribir una prueba.
- Verificar que la prueba falla
- Escribir código.
- Ejecutar las pruebas automatizadas.
- Refactorización.
- Validación en la lista de requisitos.


La estrategia Acceptance Test Driven Development (ATDD) ayuda a coordinar los proyectos de software y de esta forma entregar al cliente lo que realmente desea. Las pruebas de aceptación son especificaciones de comportamiento y funcionalidad deseados para un sistema. Este enfoque toma como punto de referencia al usuario, y una vez que las pruebas de aceptación están definidas, el equipo de desarrollo comienza a escribir el código fuente necesario para superar los criterios de aceptación.

El objetivo de ATDD es  probar la funcionalidad del sistema mientras que TDD tiene como objetivo que el sistema se construya de acuerdo a la funcionalidad determinada por el usuario. ATDD se lleva a cabo en colaboración con el usuario y en un lenguaje que usuario pueda entender.


2.2 Ejemplo prueba de aceptación (ATDD):





- Propiedad del cliente.
- Escrito con los usuarios, desarrolladores y analistas de pruebas.
- Basándose en el “Qué” y no el “Cómo”.
- Lenguaje entendible por el usuario.
- Conciso y preciso.


En resumen...


Mientras en las metodologías convencionales, las pruebas no se ejecutarán hasta que se haya finalizado el desarrollo, en las metodologías  ágiles las pruebas se escriben antes comenzar el desarrollo y sólo se escribe el código necesario para superar las pruebas guiando así el proceso de desarrollo.















7 May 2014 - admin @ 14:56 | Comentar(0)

Cuadros de Mando (II) - Informe Automatizado -




Como comenté en el la parte I del post, vamos a mostrar como realizar automatizaciones de cuadros de mando. Tenemos que recordar que es necesario un conocimiento bastante alto de las herramientas Excel y Power Point.

La creación de la automatización conlleva los siguientes pasos que veremos uno a uno:

Extracción de los datos

- Creación de la plantilla Excel
- Creación de la plantilla Power Point
- Integración de Excel en Power Point: vincular los datos
- Informe Final.


La extracción de datos

La extracción de datos se realizará desde la herramienta que estemos utilizando para la gestión de la información. Existen varias herramientas BI que podríamos estar utilizando en nuestra organización, Business Object, Microstrategy etc. Lo que si es cierto, es que en algunas ocasiones, estas herramientas se utilizan para crear vistas que recogen información de una Base de datos de una herramienta de gestión (Remedy, Service Now, GPSSD, SM etc.) y simplemente la muestran con la posibilidad de descarga en distintos formatos.

Nosotros vamos a partir de la base que ya hemos extraído los datos y los tenemos descargados en formato Excel o csv. Este documento, contiene los datos relevantes que se han extraído de la herramienta BI, donde previamente se configuraron unas Querys para encontrar la información que ahora tenemos en nuestro documento Excel.
Este documento ya lo tenemos preparado y vamos a proceder a crear las plantillas para el informe automatizado.



Creación de la plantilla Excell



El ejemplo que vamos a crear es sencillo, pero nos dará una visión de todo lo que podremos conseguir ejecutando más desarrollos en nuestra hoja Excel.
Vamos a crear nuestra hoja Excel donde crearemos los desarrollos necesarios para poder realizar las mediciones correspondientes que luego asociaremos al documento Power Point.
Lo primero que tenemos que hacer es tratar los datos. El tratamiento de los datos, dependerá de lo que queramos medir. En nuestro ejemplo, hemos decidido medir las Incidencias resueltas vs reclamadas, de dos sistemas diferentes, Sistema 1 y 2.
Hemos creado dos pestañas, una que llamaremos Diapo 2 y otra que llamaremos Títulos.
De las dos pestañas, linkaremos los datos para Power Point.
Dentro de la pestaña Diapo 2, creamos un cuadro de datos, e incluimos los datos recogidos y los mostramos en nuestro cuadro de datos:



En este cuadro hemos insertado los valores que recogimos de la herramienta BI y que exportamos a formato Excel. (La inserción de estos valores, también se pueden automatizar, y lo veremos en un siguiente post).
De la misma forma, hemos creado en esta hoja Excel de desarrollo, pestaña diapo 2, dos modelos que muestran de forma gráfica los datos extraídos e insertados en el cuadro de datos.

Hasta aquí, tenemos los datos propiamente dichos.
En una segunda pestaña que llamamos Título en nuestro ejemplo, escribimos los títulos y nomenclaturas que vamos utilizar.


Creación de la plantilla Power Point

Una vez tenemos preparada nuestra hoja Excel de desarrollo, tenemos que crear la plantilla Power Point donde vamos a insertar los vínculos desde nuestra hoja Excel de desarrollo.
En nuestro ejemplo, hemos utilizado dos diapositivas, una con una presentación de la PPT y otra con el informe que incluye nuestro cuadro de datos y modelos gráficos.


Integración de Excel en Power Point: vincular los datos

Para la integración, necesitamos tener abiertos los dos documentos, el Excel y el Power Point. Vamos a integrar los datos en desde nuestra hoja de desarrollo hacia el PPT. Para ello, copiamos el cuadro de datos de nuestra hoja Excel de desarrollo y en la PPT, a la hora de copiar en la diapo nuestro cuadro de datos, lo hacemos con “Pegado especial”.




Esta operación, la realizaremos con cada elemento que queramos vincular en nuestra PPT desde nuestra hoja Excel de desarrollo.
Podéis descargar el ejemplo del informe con los dos documentos aquí.






25 April 2014 - gpereira @ 11:56 | Comentar(2)

Cuadros de Mando (I). ¿Que medimos y para qué? -




En la mayoría de los casos, son los propios usuarios (Dirección del cliente) los que estiman que tipo de cuadro de mando y con que KPI quieren contar a la hora de controlar la marcha del servicio y sus posibles desviaciones con respecto a un SLA.

Es cierto que aunque un cuadro de mando suele presentarse en las reuniones quincenales, mensuales, trimestrales, semestrales y anuales, es posible que el cliente te demande una información (vital para la dirección) y que debes entregarlo en un tiempo record. Esto nos ha pasado a todos. Voy a detallar una lista de posibles KPI, y en posteriores post, incluiré automatizaciones y trucos para cuadros de mando.

Lo primero y obviamente más importante, es tener los datos. Sin datos no hay información, y sin información no hay informe. Siempre se habla de que la información son datos ordenados con un sentido lógico. Es cierto que cuando extraemos los datos de una herramienta para poder medirlos (BO, Remedy, SM9 etc.), en la propia herramienta podremos tipificar que necesidad de datos tenemos. Pero la lógica de situación, puede ir cambiando a lo largo del informe.

Supongamos que he sacado ya los datos desde BO, que tiene unas vistas montadas sobre la herramienta Remedy y estos datos se componen de todas las peticiones que ha habido en un mes. Estos son los datos en bruto.

A partir de ahora, es imprescindible el conocimiento profundo de Excel para poder crear condiciones, condicionales, macros etc. Los cuales utilizaremos para medir. Yo ya tengo preparada una hoja Excel donde insertaré estos datos. En ella, voy a definir los KPI de medida en lo que llamaré una hoja de desarrollo. En esta hoja, desarrollaré lo necesario para poder obtener los informes necesarios que surgirán de las combinaciones y lógica que yo quiera otorgarle a cada dato.

Como estamos hablando de Peticiones, estos son algunos de los KPI que podríamos medir:

En primer lugar, el número de peticiones según su estado:

- Peticiones Recibidas al mes

- Peticiones Rechazadas/Canceladas

- Peticiones realizadas al mes

- Peticiones en curso

- Peticiones pendientes


En segundo lugar, el número de peticiones según su complejidad:

- Peticiones por complejidad Alta

- Peticiones por complejidad Media

- Peticiones por complejidad Baja

En tercer lugar, el número de peticiones según su origen: (Por ejemplo dependiendo de si la petición la realizan para una modificación sobre un servidor, sobre el portal web, sobre las herramientas propias etc.

- Número de peticiones según el tipo de herramienta 1

- Número de peticiones según el tipo de herramienta 2

- Número de peticiones según el tipo de herramienta 3

En cuarto lugar, el número de peticiones según su origen y su complejidad: ( Por ejemplo dependiendo de si la petición la realizan para una modificación sobre un servidor, sobre el portal web, sobre las herramientas propias y segmentada dependiendo de su complejidad.

- Número de peticiones según el tipo de herramienta 1 con complejidad Alta.

- Número de peticiones según el tipo de herramienta 1 con complejidad Media.

- Número de peticiones según el tipo de herramienta 1 con complejidad Baja.

En quinto lugar, el número de peticiones según su origen y su complejidad y el tiempo empleado en su resolución: (Por ejemplo dependiendo de si la petición la realizan para una modificación sobre un servidor, sobre el portal web, sobre las herramientas propias y segmentada dependiendo de su complejidad anotando el tiempo que se ha tardado desde su estado abierto, hasta su estado Resuelto. (Tiempo de resolución habitualmente un tiempo de SLA que se acuerda y se debe cumplir.)  Estos tiempos, nos ayudarán a conocer el estado del servicio en cuanto a peticiones, cuanto tiempo se invierte en su resolución y en que tipo de peticiones se emplea más. Es importante para establecer la línea base y obtener tiempos medios de resolcuión.

- Tiempo medio que se tarda en resolver una petición, según el tipo de herramienta 1 con complejidad Alta.

- Tiempo medio que se tarda en resolver una petición, según el tipo de herramienta 1 con complejidad Media.

- Tiempo medio que se tarda en resolver una petición, según el tipo de herramienta 1 con complejidad Baja.

Es cierto que podríamos hacer esta lista de mediciones casi infinita. Hay que recordar que lo más importante es saber que queremos medir y para que. Es decir una vez obtengamos los resultados de las mediciones, estas deben servir bien para premiar si el resultado está dentro de lo esperado o corregir desviaciones, si no lo estuviesen.







14 April 2014 - gpereira @ 13:26 | Comentar(2)

SCRUM: Metodología Ágil -






Es cierto que hoy día la metodología denominada SCRUM, hace eco en la gestión de los desarrollos  y en la evolución continua de estos.
Las organizaciones, no pueden esperar a poner un producto en el mercado o implementar unos requisitos definidos 1 o 2 años hasta ver los resultados finales.Hay organizaciones que necesitan disponer de una primera versión con funcionalidades básicas en 1 mes, no pueden depender de planificaciones detalladas previa a los desarrollos. El mercado evoluciona vertiginosamente y no hay tiempo para esperar a un desarrollo final.

La interacción y colaboración con el cliente/usuario,  que el desarrollo funcione y la rápida adaptación a los cambios, priman más que la planificación, procesos o documentación.Es necesario, Satisfacer al cliente a través de la entrega rápida y continúa de software que genera valor, así como también trabajar junto con el cliente/usuario el día a día. La comunicación cara a cara en la jornada laboral, será de vital importancia.

Adoptar una estrategia de desarrollo incremental en lugar de tradicional de planificación y ejecución completa del producto, nos conducirá a una buena implementación de la metodología, de esta forma, las fases de desarrollo se realizarán en paralelo, en lugar de una tras otra, otorgará agilidad a la hora de entregar los desarrollos.
Todos los que trabajamos en este sector, conocemos la importancia que las organizaciones dan a las entregas de documentación planificadas. Si bien es cierto que podrían llegar a ser necesarias de cara a alimentar los repositorios de documentación, requieren un tiempo valioso que se podría emplear en otras tareas que agilicen la entrega de desarrollos.

La metodología SCRUM establece un modelo de gestión evolutiva, basada en entregas de revisiones de desarrollo que se van adaptando a los requisitos (Pila del producto según SCRUM), que también pueden sufrir cambios constantes, de la organización. Los requisitos del sistema formales se especifican de forma completa y cerrada al inicio del proyecto, en el caso de la metodología SCRUM el documento de requisitos es un documento expuesto a cambios que evoluciona junto con los desarrollos.  La diferencia entre el clásico documento de requisitos y la Pila de producto, es que esta última nunca seda por finalizada, siempre pueden surgir y surgirán, nuevos requisitos, al contrario que el documento de requisitos clásico que es un documento cerrado y previamente acordado.

En la pila del producto se incluye  el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas revisiones (sprints según SCRUM). La pila de producto, al igual que el documento de requisitos, prioriza los sprints dependiendo  del valor que le da a la organización.

Los desarrollos se testean junto al cliente/usuario según se van terminando las revisiones de los desarrollos. De esta forma, evitamos el tener que tener el desarrollo final, planificar una gestión de calidad y pruebas que puede incrementar en gran medida la entrega final del desarrollo.
La metodología SCRUM, pone especial hincapié en el seguimiento. Al igual que en las reuniones clásicas de seguimiento que se realizan para ver la evolución y el estado de los requisitos cerrados y acordados previamente, en el caso de SCRUM, las reuniones de seguimiento son diarias, para ver la evolución y estado de la Pila de producto y sprints.

Si queréis conocer más sobre esta metodología, podéis encontrar toda la información al respecto en http://www.scrummanager.net/bok/.
Si queréis saber acerca de las certificaciones disponibles, http://www.scrummanager.net/certificacion/

También puedes descargar las versiones ebook:













12 April 2014 - admin @ 00:56 | Comentar(1)

Calendario

Archivos