Mes: Abril 2018

DevOps – El inicio

DevOps es una filosofía operativa que promueve una mejor comunicación entre el desarrollo y las operaciones a medida que más elementos de las operaciones se vuelven programables. En su interpretación más limitada, DevOps describe la parte del equipo de tecnología de la información (TI) de una organización que crea y mantiene la infraestructura. El término también se puede usar para describir una cultura que analiza estratégicamente toda la cadena de distribución de software, supervisando los servicios compartidos y promoviendo el uso de nuevas herramientas de desarrollo y mejores prácticas.
La mejor manera de definirlo en profundidad, es usar un método paralelo a la definición de un término similar complejo, desarrollo ágil.

Valores ágiles / Valores de DevOps

  • Individuos e interacciones sobre procesos y herramientas
  • Software de trabajo (servicio o software entregado por completo al cliente) sobre documentación completa
  • Colaboración del cliente sobre la negociación del contrato.
  • Responde al cambio sobre el siguiente plan.

Principios ágiles / Principios de DevOps

  • Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de una funcionalidad valiosa. (más general que “software”).
  • La funcionalidad del software solo puede ser realizada por el cliente cuando es entregada por los sistemas de sonido. Los requisitos no funcionales son tan importantes como la funcionalidad deseada para el resultado del usuario.
  • Los empresarios, las operaciones y los desarrolladores deben trabajar juntos a lo largo de todo el proyecto
  • La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Métodos ágiles / Métodos DevOps

  • Scrum con operaciones, Kanban con operaciones.
  • Control de cambio de estilo Visible Ops.
  • Sistema de Comando de Incidentes para respuesta a incidentes.
  • Prácticas ágiles / Prácticas DevOps
  • Integración continua y despliegue continuo, gestión de configuraciones, métricas y esquemas de monitoreo, un enfoque de herramientas para herramientas.

Herramientas Ágiles / Herramientas DevOps

Jenkins, travis, teamcity, configuración de gestión (marioneta, chef, ansible, cfengine), orquestación (zookeeper, noah, mesos), supervisión, virtualización y contenedorización (AWS, OpenStack, vagabundo, docker) y muchos más. Es incorrecto decir que una herramienta es “una herramienta DevOps” en el sentido de que mágicamente te traerá DevOps.
Bajo un modelo DevOps, los equipos de desarrollo y operaciones ya no están “aislados”. A veces, estos dos equipos se fusionan en un único equipo donde los ingenieros trabajan en todo el ciclo de vida de la aplicación, desde desarrollo y prueba hasta implementación y operaciones, y desarrollan un rango de habilidades no limitadas a una sola función.

Historia de DevOps

Algunos puntos relevantes:
2007: Patrick Debois, un consultor de desarrollo de software, tenía el objetivo de aprender todos los aspectos de TI. Trabajó como desarrollador, especialista en redes, administrador de sistemas, tester y gerente de proyectos. A Patrick siempre le habían molestado las diferencias entre cómo funcionaban Dev y Ops, pero se sintió particularmente frustrado con los desafíos de administrar el trabajo entre los dos grupos en la migración de este centro de datos. La integración continua estaba ganando popularidad en la comunidad ágil y estaba acercando más a Dev al despliegue, pero todavía no había nada que cruzara completamente la división entre Dev y Ops.

 

2008: Andrew Shafer publicó una idea para una sesión de ágil infraestructura “pájaros de una pluma” en la Conferencia Agile 2008. Patrick Debois vio la publicación y fue a la sesión. Desafortunadamente, él fue el único que apareció. La idea fue tan mal recibida que Andrew ni siquiera se presentó a su propia discusión. Andrew y Patrick decidieron comenzar un grupo de Google llamado Agile System Administration.

 

2009: John Allspaw, vicepresidente senior de operaciones técnicas en Flickr, y Paul Hammond, director de ingeniería en Flickr, dieron una presentación en la Conferencia O’Reilly Velocity en San José, “10+ despliegues por día: cooperación Dev y Ops en Flickr “.
DevOpsDays, en Gante, Bélgica. [Patrick Debois]

 

 

 

 

¿Qué no es DevOps ?

No es NoOps: no es “¡se están quitando nuestros trabajos!”. algunas partes de las operaciones necesitan ser automatizadas, eso significa que o bien las personas hacen algún desarrollo de automatización, o los desarrolladores están escribiendo código de “operaciones”, o ambos.
No son (solo) herramientas: DevOps tampoco está simplemente implementando un conjunto de herramientas. Una herramienta puede ser útil en Agile (o DevOps), pero si no sabes cómo usarla, es como darle un arma de asalto a una persona no entrenada. (principios)
No es (solo) Devs y Ops: Y al final, no es excluyente. Algunas personas se han quejado “¿Qué pasa con las personas de seguridad? ¡Y administradores de red! ¿Por qué dejarnos afuera??! “. DevOps es un paso importante para que una disciplina se una a la cultura general de colaboración ágil que debe involucrar a todas las disciplinas de una organización.
No es (solo) un título de trabajo: simplemente tomar un equipo de operaciones existente y llamarlos “El equipo de DevOps” en realidad no ayuda nada por sí mismo. Tampoco cambia el título de un puesto de trabajo a “DevOps Engineer”. Si no adopta los valores y principios anteriores, que requieren cambios a nivel general del sistema, no solo dentro de un equipo determinado, no obtendrá todos los beneficios.
Una práctica fundamental es realizar actualizaciones muy frecuentes pero pequeñas.
La integración continua es una práctica de desarrollo de software donde los desarrolladores combinan regularmente sus cambios de código en un repositorio central, después del cual se ejecutan compilaciones y pruebas automatizadas. Los objetivos clave de la integración continua son encontrar y corregir errores más rápidamente, mejorar la calidad del software y reducir el tiempo que lleva validar y lanzar nuevas actualizaciones de software.
La entrega continua es una práctica de desarrollo de software donde los cambios de código se crean, prueban y preparan automáticamente para su lanzamiento a la producción. Se expande tras la integración continua implementando todos los cambios de código en un entorno de prueba y / o en un entorno de producción después de la etapa de compilación. Cuando la entrega continua se implementa correctamente, los desarrolladores siempre tendrán un artefacto de construcción preparado para la implementación que haya pasado por un proceso de prueba estandarizado.
La arquitectura de microservicios es un enfoque de diseño para construir una única aplicación como un conjunto de pequeños servicios. La arquitectura de microservicios desacopla sistemas grandes y complejos en proyectos simples e independientes. Esta arquitectura reduce la sobrecarga de coordinación de la actualización de aplicaciones.
La infraestructura como código es una práctica en la que la infraestructura se aprovisiona y administra utilizando técnicas de desarrollo de código y software, como el control de versiones y la integración continua.
Comunicación y colaboración, una mayor comunicación y colaboración en una organización es uno de los aspectos culturales clave de DevOps.
BizDevOps (Negocios, Desarrollo y Operaciones), también conocido como DevOps 2.0, es un enfoque para el desarrollo de software que anima a desarrolladores, personal de operaciones y equipos comerciales a trabajar juntos para que la organización pueda desarrollar software más rápidamente, responder mejor a la demanda del usuario y finalmente maximizar los ingresos.

 

Devops 2.0
Principios
Desacoplar despliegue de funciones desde la implementación del código
Entrega continua
Implementaciones centradas en el usuario
Coordinación técnica no técnica +
Comentarios de los clientes
Mitigación de riesgos
Entrega de software más rápida e iterativa

 

 

Single Sign On

Actualmente las organizaciones empresariales se ven en la necesidad de mantenerse actualizadas, es por ello ha sido necesario para éstas la implementación de diversos sistemas y aplicaciones informáticas que permitan incrementar la eficiencia, reducir costos y aumentar la productividad
A consecuencia de las grandes cantidades de información gestionada por las tecnologías implementadas en una empresa u organización, es de vital importancia que cada una posea mecanismos de seguridad, entre uno de éstos el uso de credenciales
Como la mayoría de los sistemas requieren del uso de credenciales, es evidente que mientras haya una mayor cantidad de aplicaciones, servidores, entre otros, los inicios de sesión también incrementan, lo cual es un problema que se soluciona con la implementación de una herramienta de inicio de sesión única.

 

Single Sign On es un mecanismo que utiliza la autenticación única para permitir a los usuarios el acceso a los recursos de uno o más sistemas a los que éste ha sido autorizado.

 

 

  • Ventajas:
    • Requiere de pocos recursos computacionales
    • Mejora la seguridad y el soporte de las bases de datos que contienen las credenciales
    • Desventajas:
    • Se deben tomar medidas adicionales de seguridad informática y control de acceso
    • Las credenciales deben ser protegidas
  • Tipos:
    • Single Sign On Web
    • Single Sign On Empresarial
    • Single Sign On Federado

Arquitectura según Single Sign On

Simple

 

Centralizada

Múltiple

 

 

Estándares y Protocolos usados

Kerberos:
Sistema de autenticación distribuido basado en la identidad, el cual proporciona un método para que los usuarios puedan acceder a un servidor y, que permite la autenticación.

 

Oauth 2
Framework de autorización, cuyo objetivo es proporcionar a determinados clientes el acceso a los recursos protegidos de un sistema o determinada entidad.

 

 

OpenID connect
Protocolos para sistemas Single  Sign On implementado como una capa sobre OAuth 2, cuyo propósito es proporcionar autenticación mediante proveedores de identidad.

 

 

Security Assertion Markup Language (SAML)
Estándar definido por la Organización para el Avance de los Estándares de la Información Estructurada (OASIS por sus siglas en ingles), cuyo propósito es crear un framework para el intercambio de datos de autenticación y autorización entre dos o más dominios de seguridad.

 

 

Central Authentication Service (CAS)
Protocolo utilizado en soluciones Single Sign On, cuyo propósito es permitir el acceso de un usuario a múltiples aplicaciones proporcionando las credenciales una única vez.

 

 

 

 

 

Lightweight Directory Access Protocol (LDAP)
Protocolo para el acceso a servicios de directorio distribuido, el cual puede ser utilizado para mecanismos de autenticación y autorización

 

 

Agile Testing

Involucra a todos los miembros de un equipo ágil multifuncional, en el cual el rol del tester es el de un experto multifuncional, garante que se entregue el valor de negocio deseado por el cliente a un ritmo sostenible y continuo.
Las metodologías ágiles no ven al software testing como una fase separada, sino como parte integral del Desarrollo de software al igual que la programación. Agile Testing, incorpora una serie prácticas, como por ejemplo Testing de “todo el equipo”, Testing independiente (opcional), Integración continua, Testing guiado por pruebas (Test Driven Development – TDD), Desarrollo guiado por comportamiento (Behaviour Driven Development – BDD), Desarrollo guiado por pruebas de aceptación (Acceptance Test Driven Development – ATDD), entre otros.

Principios de Agile Testing

El Testing no es una fase: El testing continuo es la única forma de garantizar avance continuo
El Testing hace avanzar el proyecto: Bajo métodos convencionales, el testing es una alcabala, en cambio en Agile Testing se proporciona retroalimentación continua, permitiendo corregir el rumbo continuamente durante el desarrollo de software.
Todo el equipo realiza pruebas: en Agile Testing, los Analistas de negocio y Desarrolladores de software también ejecutan pruebas, no sólo los testers como en métodos convencionales.
Reducir el tiempo para recibir retroalimentación: En Agile Testing, los equipos del área de negocio (el cliente) están involucrados en cada iteración, no solo al final durante la fase de aceptación.
Código limpio: Los defectos en el código se corrigen en la misma iteración, por lo que se mantiene el código limpio.
Reducir la documentación de pruebas: Los Agile Testers usan listas de chequeo reusables en lugar de documentación extensa, se enfocan en la esencia de la prueba en lugar de detalles.
Guiado por pruebas: El Agile Testing, las pruebas se hacen “durante” el desarrollo y no después del desarrollo como en métodos convencionales.

 

Algunas prácticas:

  • Test Driven Development (TDD):  Técnica que combina un enfoque de refactorización del lado de desarrollo con un enfoque de probar primero en cuanto al testing.

  • Acceptance Test Driven Development (ATDD): Es una dimensión del TDD aplicada al nivel de gestión de requerimientos de software, en el cual las pruebas escritas son a nivel de cliente, es decir, lo equivale
  • nte a una prueba de aceptación o test funcional.
  • Behaviour Driven Development (BDD): También puede llamarse Story Driven Development. Bajo este enfoque primero se desarrolla una prueba funcional o de historia de usuario automatizada, luego se eje
  • cuta el desarrollo aplicando TDD hasta que la prueba es exitosa.
  • Testing exploratorio: Enfoque en el cual el aprendizaje de la funcionalidad, diseño de pruebas y ejecución de pruebas ocurren simultáneamente, en contraposición con el enfoque convencional en el cual primero se documenta la funcionalidad o requisito, luego se diseña el caso de prueba y luego se ejecuta de acuerdo a guiones prestablecidos.
  • Automatización de pruebas de regresión: Tanto la integración continua como la refactorización son prácticas necesarias para poder implementar una metodología ágil de desarrollo de software.
  • Automatización de pruebas unitarias: Consiste en usar un marco de trabajo o framework (como NUnit) para ejecutar tus tests unitarios, en lugar de ejecutar estos manualmente una y otra vez cada vez que modificas el código.

Pirámide de Testing

 

En la forma tradicional (pirámide de la izquierda), la gran mayoría de las pruebas son manuales y funcionales, pudiendo existir algún pequeño grado de automatización y de pruebas unitarias por desarrolladores.
La pirámide de la derecha representa como se ejecuta el Software Testing en Agile, donde la gran mayoría de las pruebas son unitarias automatizadas, de aceptación automatizadas y de interfaz gráfica automatizadas, buscando reducir al mínimo las pruebas funcionales manuales.

 

Cuadrantes de Agile Testing

Los cuadrantes representan los diferentes propósitos y tipos de pruebas de software que podemos realizar en un entorno Agile. Aquí una imagen de los cuadrantes del Agile Testing.

 

Emotional Intelligence : Walface in Workplaces

El contexto laboral en el cual nos encontramos inmersos en el día a día, influye en nosotros de forma directa e indirectamente, especialmente en nuestras emociones de una manera que a veces no imaginamos o simplemente no nos damos cuenta. Es cierto que en muchas ocasiones de nuestra vida cotidiana no podemos cambiar situaciones que nos generan en su mayoría emociones negativas, pero si podemos cambiar o mejorar la forma en la cual nos afecta o nos hace sentir.

 

Existen muchas investigaciones, no solo sobre la inteligencia emocional, si no en la productividad organizacional, por lo tanto se ha revelado que el bienestar en entornos empresariales siempre va a significar mayor producción, esto se evidenció en una teoría a la cual denominaron la Teoría de las relaciones humanas (Elton Mayo, Sociólogo y psicólogo Industrial especializado en teoría de las organizaciones), en el cual se afirmó que en las empresas cuando mayor es la interacción, mayor es la capacidad productiva y que cualquier cambio produce una reacción en lo personal del individuo, todo esto mediante un experimento que se usó para determinar la satisfacción de los trabajadores y la eficiencia de los mismos), en este sentido,  la idea de la productividad fue cambiando así como el modelo organizacional iniciado con la administración científica enfocada en la eficiencia.

 

Actualmente las pequeñas, medianas y grandes empresas  desarrollan entornos como:
  • Turbulentos impredecibles y agitados.
  • Profundidad en cambios o profesos internos.
  • Los procesos de transformación afectan los ámbitos individuales, familiares y profesionales de las personas que componen a una empresa.
  • Los ambientes se vuelven altamente competitivos, especialmente por los continuos cambios en el mercado y las nuevas tecnologías, en donde existe mucha competencia y las ansias de innovar.
  • Los cambios suelen escapar a control de las personas y las organizaciones, un ejemplo básico podría ser la fuga de profesionales que a suelen tener las empresas por diversos motivos tanto internos como externos a la organización.
¿Alguna vez nos hemos percatado y sido conscientes de la influencia que ejercen nuestras emociones en el ambiente laboral?, bueno esta debería ser una pregunta que toda persona  debería hacerse, mayormente se desbordan las emociones y no somos capaces de reconocerlas.

 

Debemos recordar que, como seres humanos contamos con una mente racional encargada de pensar y una mente emocional la cual permite que se activen las emociones por causa de estímulos externos que se presenten

 

La Inteligencia Emocional es un término que se acuñó en 1990 por dos psicólogos americanos Peter Salovey y Jhon Mayer, sin embargo fue difundido en 1995 por Daniel Goleman actualmente reconocido como el gurú de la inteligencia emocional, este último la definió como “La capacidad de reconocer nuestros propios sentimientos y los ajenos, motivarnos y de manejar bien las emociones en nosotros mismos y nuestras relaciones”

 

Por lo general existen estudios científicos que evidencian que la inteligencia emocional es importante en todo ser humano, tanto en la vida personal como la vida profesional,

 

Actualmente se requiere impulsar decisivamente en las empresas programas que ayuden efectivamente al desarrollo humano. Sin éste no será posible en modo alguno lograr el desarrollo organizacional en forma firme y sostenida en un contexto mundial de creciente competencia e incremento de competitividad.. Ya no es suficiente el cociente intelectual y la pericia para el logro del éxito sino que también es imprescindible el dominio de ese complejo psicológico al que se denomina inteligencia emocional.

 

La inteligencia emocional significa entre muchas otras cosas la capacidad para expresar a plenitud la conducta ética, rica en valores humanos y esencia de nuestra propia humanidad.. La inteligencia emocional no es la pastilla o medicina para todos percances que pueda presentar una organización, sin embargo se ha comprobado científicamente que cada de una de las habilidades proporcionan una ventaja competitiva en las organizaciones, la misma no se puede aprender de una día para otro, se debe ir trabajando poco a poco y cada líder debe tratar de impulsarla en cada uno de sus equipos de trabajo.

 

Debemos aprender a identificar cada una de las emociones que se nos presentan en los entornos laborales, desde los equipos de trabajo hasta el liderazgo, el líder juega un papel fundamental en el desarrollo de la misma, cuando un liderazgo no se acompañado de habilidades personales como el autoconocimiento, la auto regulación la motivación y en cuanto a la parte social la empatía y las habilidades sociales, difícilmente la planificación, estrategia organización puede llegar al éxito, de igual modo los equipos de trabajo deben concientizar el trabajo en equipo, debemos recordar que todos somos personas diferentes, algunas mas rápidos otros mas lentos, algunos con carácter difícil otros de carácter mas llevadero, pero igual de importantes para una organización, es importante que todos los miembros logren trabajar en equipo en miras de siempre buscar el logro exitoso de los objetivos propuestos.

 

Inicialmente para comprender un poco a fondo sobre nuestras emociones debemos acudir a un experto en el área que nos pueda guiar , sin embargo podemos comenzar por tratar de conocernos mejor a nosotros mismos.

 

 

 

 

 

SQL vs NoSQL

SQL (Structured Query Language): Es un lenguaje de programación estandarizado utilizado para el manejo y manipulación de la data, el mismo incluye modificaciones a las tablas de base de datos y estructura de índices. SQL comprende un conjunto de tablas que contienen datos en filas y columnas. SQL fue desarrollado por primera vez en los años 70’s por Donald Chamberlin y Raymond Boyce. En los laboratorios de IBM fue creado el nuevo software de base de datos llamado Sistem R y para gestionar dicho sistema se creó el lenguaje SQL.

 

NoSQL (Not Only SQL) : No sigue el modelo relacional ni posee esquema, ofrece garantías de consistencia débil (BASE), de igual modo no existe un único modelo de datos y busca resolver problemas de escalabilidad y rendimiento. Erradamente se cree que NoSQL prohibe el lenguaje de consultas SQL. Algunas no lo usan y otras continúan usándolo:
  • MondoDB utiliza JSON
  • BigTable lo ha transformado anteniendo su estructura básica.
                          
Propiedades Base:
  • Basicamente Disponible (BA): Cada solicitud garantiza una respuesta, bien sea correcta o no, en lo que respecta al teorema de CAP.
  • Estado flexible (S): El estado del sistema puede cambiar con el tiempo, a veces sin una entrada (por consistencia eventual).
  • Eventualmente Consistente (E): Las base de datos puede estar momentáneamente inconsistente pero será consistente con el tiempo.
Teorema de CAP

 

Tipos de Base de Datos NoSQL
Clave-Valor : Son el modelo mas popular y mas sencillo en cuanto a funcionalidad, se asemeja mucho a un diccionario. Cada elemento está identificado por una llave única que apunta a un elemento. No existe el concepto de relaciones y  existe falta de consistencia
Ejemplo:

Documental: Orientada a gestionar el almacenamiento y acceso a docuemntos, no almacena datos en esquemas estrictos ni usan tablas con campos uniformes.
Ejemplo :
{ "_id:
 ObjectId ("4efa8d2b7d284dad101e4bc7",
 "Last Name": "PELLERIN",
 "First Name": "Franck",
 "Age": 29,
 "Address": {
 "Strert": "1 chemin des Loges",
 "City": "VERSAILLES"

    }
}
Basada en Grafos:  Se representan como nodos de un grafo y sus relaciones con las aristas del mismo, para sacar el máximo provecho, su estructura debe estar totalmente normalizada y su principal ventaja es ofrecer una navegación mas eficiente entre las relaciones que en un modelo relacional.
Ejemplo:

Basadas en Columnas: Almacena los datos en columnas en lugar de filas, su objetivo es leer y escribir datos de manera eficiente y hacia el almacenamiento en disco duro, de igual modo se encuentran diseñadas para reducir la escala utilizando clústeres distribuidos para aumentar el desempeño. Las basadas en columnas también resultan ideales para el almacenamiento de datos y el procesamiento de Big Data.
Ejemplo

SQL vs NoSQL

¿Que tipo de Base de Datos elegir?

  • Cuando los datos deben ser consistentes sin dar posibilidad de error : SQL.
  • Cuando nuestro presupuesto no se puede permitir grandes máquinas y debe destinarse a máquinas de menor rendimiento: NoSQL.
  • Cuando las estructuras de datos que manejamos son variables: NoSQL.
  • Para análisis de grandes cantidades de datos y datos semi estructurados o no estructurados: NoSQL.
  • Para tiendas online con motores de inteligencia complejos : NoSQL.

 

 

 

Agile Business Analysis

Para tener éxito en el entorno del mundo actual con las competencias del mercado, las empresas deben ser capaces de cambiar rápidamente la forma en que crean y entregan los productos a sus clientes. Dado que las aplicaciones y el software desempeñan un papel en casi todas las funciones de todas las industrias, el análisis de negocio ágil se convierte en una capacidad curricular de todas las organizaciones. Inicialmente para conocer un poco mas sobre esta metodología debemos diferenciar lo que es una agilidad y el análisis de negocios:
Agilidad: es un término utilizado para describir una serie de metodologías para desarrollo iterativo de software, que se han desarrollado a lo largo del tiempo.

 

Business Analysis: tiene la capacidad de crear un valor agregado coherente y sostenible para los clientes y la empresa. Con base en el contexto empresarial y las partes interesadas, se identifican soluciones adecuadas para satisfacer las necesidades y objetivos más importantes.

 

El Agile Manifesto o Manifiesto para el desarrollo de software ágil es una proclamación de cuatro reglas vitales y doce principios que sirven de introducción y guía para las personas en el software de gestión ágil.

 

El software de gestión ágil se centra en mantener el código simple e ir testeando los códigos que el propio software vaya sacando. Este nuevo modelo se inventó para agilizar la gestión de proyectos y llegar a sustituir al modelo en cascada. Un modelo más lineal y secuencial.

 

Existen 4 reglas vitales dentro de este manifiesto:
  • A los individuos y su interacción por encima de los procesos y herramientas.
  • El software que funciona por encima de la documentación exhaustiva.
  • La negociación con el cliente por encima de la negociación contractual.
  • Las respuestas al cambio por encima de seguimiento de un plan.
A estas reglas básicas mencionadas, se le suman 12 principios que todo Agile Coach debería conocer para poder gestionar proyectos de negocio y tecnológicos:

 

  • Satisfacer al cliente con un suministro de trabajo continuo y de calidad, dado que se involucrará y comprometerá a lo largo del proyecto. En cada etapa del desarrollo se informará al cliente sobre los progresos del mismo. De ese modo, el cliente puede sumar su  experiencia para optimizar las características del producto final. Se pueden evitar así numerosos malentendidos dado que el cliente poseerá en todo momento una completa visión del estado del producto.
  • Dividir las tareas más complejas en pequeñas partes mucho más sencillas para poder completarlas más rápidamente.
  • Reconocer que el mejor trabajo nace de los equipos que están bien organizados. Pero esta mejora no es casual: las metodologías ágiles permiten a todos los miembros del equipo conocer el estado del proyecto en cualquier momento. Los compromisos son negociados y aceptados por todos los miembros del equipo y las ideas de cualquiera de sus integrantes son tenidas en cuenta.
  • Motivar a los trabajadores en un ambiente de trabajo favorable y depositar nuestra confianza en ellos, sabiendo que sacarán el trabajo adelante.
  • Crear procesos que apoyen un desarrollo del trabajo más sostenible.
  • Mantener un trabajo constante en la organización.
  • Estar abiertos a recibir nuevos cambios, incluso en la recta final del proyecto.
  • Reunir al equipo de trabajo y directivos cada cierto tiempo para hablar sobre los cambios que se están realizando y los avances en el proyecto. Aquí se tratarán dudas y mejoras.
  • Por intervalos, juntar a los empleados para recordarles cuáles son los objetivos para ser más efectivos y ajustar el comportamiento a dichos objetivos.
  • Contabilizar el rendimiento a medida que se realiza el trabajo.
  • Buscar la excelencia de una manera continua.
  • Agarrarse al cambio para conseguir ser una fuerza más competitiva.
El desarrollo ágil de software es una de las tendencias más de moda en el sector tecnológico pero, ¿sabes en qué consiste realmente? ¿Cuáles son sus ventajas frente al modelo tradicional de cascada?

 

Una tendencia en alza en la que el desarrollo iterativo e incremental se impone a los trámites habituales en esta industria. O, dicho de otro modo, una metodología en la que el desarrollador va adaptando sus soluciones a unos requisitos también cambiantes a lo largo del tiempo.

 

Frente a los pasos del tradicional método en cascada, el desarrollo ágil de software se basa en seis pasos comunes dentro del ciclo de vida del software: planificación, análisis de requisitos, diseño, codificación, test y documentación. En cada interacción, el equipo de desarrollo no entrega todo el programa, sino que se van añadiendo pequeños elementos totalmente probados, sin errores, con el fin de que la solución final esté completamente operativa desde el minuto uno. En los métodos de desarrollo ágil de software, la comunicación entre todos los miembros del equipo es clave, ya que se busca eliminar las trabas habituales de reuniones, validaciones y revisiones formales por encuentros más informales y en fases tempranas e intermedias del proceso, no sólo en la última etapa del trabajo.

 

Consideraciones Finales
A la hora de diseñar un software por el método clásico de cascada, lo normal es que se complete un proceso antes de arrancar con el siguiente; lo cual obliga a acelerar los trabajos (y reducir la calidad) a fin de cumplir con los plazos impuestos por los clientes. Sin embargo, al optar por una metodología ágil en la que se trabajan distintos elementos en paralelo, el equipo puede ir validando pequeñas partes del proyecto antes de realizar la entrega final perfecta.
  • Cuando exista mucha incertidumbre en una determinada funcionalidad, evitar dar estimaciones muy optimistas.
  • Tener siempre funcionalidades en “el banquillo”.
  • Tener las prioridades de las funcionalidades muy bien definidas.
  • Dejar siempre un tiempo durante las iteraciones dedicado a imprevistos.
  • Dar visibilidad inmediata al cliente de las situaciones imprevistas. 
Conclusiones
Cuando se ejecuta un análisis de negocio bajo un contexto ágil, se presentan características únicas que permiten reevaluar, adaptar y ajustar los esfuerzos y tácticas. Se trata de tener una mayor flexibilidad frente al cambio y entregar justo a tiempo para ser efectivo en el marco ágil.
El análisis de negocio se realiza activamente dentro del marco ágil en las actividades de planeación, análisis, pruebas, entregas y revisiones. Estas actividades pueden ser ejecutadas por un rol de dueño de producto “product owner”, o por un analista de negocio como tal, que haga parte del equipo ágil. Su función es servir de puente entre los interesados “stakeholders” y el equipo técnico de desarrollo del proyecto, para asegurar que las necesidades de negocio sean correctamente traducidas y priorizadas en un listado de trabajo pendiente, “backlog”. También, para asegurar que existe alineación estratégica entre el proyecto/requerimiento con los objetivos organizacionales y necesidades de negocio.

 

“La solución exitosa de problemas requiere encontrar la solución correcta al problema correcto.”
Rusell Ackoff.
Scroll to top