CentOS 8 Cómo configurar y administrar el firewall

Un firewall es un método para monitorear y filtrar el tráfico de red entrante y saliente. Funciona definiendo un conjunto de reglas de seguridad que determinan si se permite o bloquea el tráfico específico. Un firewall configurado correctamente es uno de los aspectos más importantes de la seguridad general del sistema.

CentOS 8 se envía con un demonio de firewall llamado firewalld . Es una solución completa con una interfaz D-Bus que le permite administrar el firewall del sistema de forma dinámica.

Conceptos básicos de Firewalld
firewalld utiliza los conceptos de zonas y servicios. Según las zonas y los servicios que configurará, puede controlar qué tráfico está permitido o bloqueado hacia y desde el sistema.
Firewalld se puede configurar y administrar mediante la firewall-cmdutilidad de línea de comandos.

En CentOS 8, iptables se reemplaza por nftables como el servidor de seguridad predeterminado para el demonio firewalld.

Zonas Firewalld
Las zonas son conjuntos predefinidos de reglas que especifican el nivel de confianza de las redes a las que está conectada su computadora. Puede asignar interfaces y fuentes de red a una zona.
A continuación se muestran las zonas proporcionadas por FirewallD ordenadas según el nivel de confianza de la zona de no confiable a confiable:

drop : todas las conexiones entrantes se eliminan sin ninguna notificación. Solo se permiten conexiones salientes.
block : todas las conexiones entrantes se rechazan con un mensaje icmp-host-prohibited para IPv4 y icmp6-adm-prohibited para IPv6n. Solo se permiten conexiones salientes.
public : para uso en áreas públicas no confiables. No confía en otras computadoras en la red, pero puede permitir conexiones entrantes seleccionadas.
external : para usar en redes externas con enmascaramiento NAT habilitado cuando su sistema actúa como puerta de enlace o enrutador. Solo se permiten conexiones entrantes seleccionadas.
internal : para usar en redes internas cuando su sistema actúa como puerta de enlace o enrutador. Otros sistemas en la red son generalmente confiables. Solo se permiten conexiones entrantes seleccionadas.
dmz : Usado para computadoras ubicadas en su zona desmilitarizada que tienen acceso limitado al resto de su red. Solo se permiten conexiones entrantes seleccionadas.
work : Utilizado para máquinas de trabajo. Otras computadoras en la red son generalmente confiables. Solo se permiten conexiones entrantes seleccionadas.
home : utilizado para máquinas domésticas. Otras computadoras en la red son generalmente confiables. Solo se permiten conexiones entrantes seleccionadas.
trusted : se aceptan todas las conexiones de red. Confíe en todas las computadoras en la red.

Servicios de firewall
Los servicios Firewalld son reglas predefinidas que se aplican dentro de una zona y definen la configuración necesaria para permitir el tráfico entrante para un servicio específico. Los servicios le permiten realizar fácilmente varias tareas en un solo paso.

Por ejemplo, el servicio puede contener definiciones sobre cómo abrir puertos, reenviar tráfico y más.

Firewalld Runtime y configuraciones permanentes
Firewalld usa dos conjuntos de configuración separados, tiempo de ejecución y configuración permanente.
La configuración de tiempo de ejecución es la configuración real en ejecución y no persiste en el reinicio. Cuando se inicia el demonio firewalld, carga la configuración permanente, que se convierte en la configuración de tiempo de ejecución.

De manera predeterminada, al realizar cambios en la configuración de Firewalld utilizando la firewall-cmdutilidad, los cambios se aplican a la configuración de tiempo de ejecución. Para que los cambios sean permanentes, agregue la --permanentopción al comando.

Para aplicar los cambios en ambos conjuntos de configuración, puede usar uno de los dos métodos siguientes:

Cambie la configuración del tiempo de ejecución y hágalo permanente:

sudo firewall-cmd <options>
sudo firewall-cmd --runtime-to-permanent
Cambia la configuración permanente y recarga el demonio firewalld:

sudo firewall-cmd --permanent <options>
sudo firewall-cmd --reload
Habilitar FirewallD
En CentOS 8, firewalld está instalado y habilitado de manera predeterminada. Si por alguna razón no está instalado en su sistema, puede instalar e iniciar el demonio escribiendo:
sudo dnf install firewalld
sudo systemctl enable firewalld --now
Puede verificar el estado del servicio de firewall con:

sudo firewall-cmd --state
Si el firewall está habilitado, el comando debería imprimir running. De lo contrario, lo verás not running.

Zonas Firewalld
Si no lo ha cambiado, la zona predeterminada se establece en publicy todas las interfaces de red se asignan a esta zona.
La zona predeterminada es la que se usa para todo lo que no está asignado explícitamente a otra zona.

Puede ver la zona predeterminada escribiendo:
sudo firewall-cmd --get-default-zone


Fuente: https://linuxize.com/post/how-to-configure-and-manage-firewall-on-centos-8/

Por que no funciona Scrum o Agile en Colombia

Tenermos estudios mundiales que dan algunas luces sobre las barreas en la adopcion de los modelos  nuevos de gestion de proyectos como agiles y scrum.
Algunas de mas mencionadas x versionone en el 2019:

Cultura organizacional en desacuerdo con valores ágiles, Organización general resistencia al cambio
Inadecuada gestión de apoyo y patrocinio, Falta de habilidades / experiencia con métodos ágiles
Insuficiente capacitación y educación., Procesos y prácticas inconsistentes entre los equipos.
Falta de disponibilidad de negocios / clientes / propietarios de productos, Generalidad de los métodos de desarrollo tradicionales.Herramientas fragmentadas y datos / mediciones relacionadas con el proyecto. Colaboración mínima e intercambio de conocimientos. Cumplimiento normativo o problema gubernamental
Pero en Colombia por que seria ?? Yo propuse esta encuesta online x 1 semana a ver que dice

¿Por qué es importante desarrollar épicas en Scrum?

En términos simples, las epicas son requisitos del usuario que el equipo de Scrum debe cumplir

¿Qué son las Epicas? Es posible que las historias de usuario tengan que escribirse constantemente a lo largo de la duración del proyecto. En las etapas iniciales de la escritura, la mayoría de las Historias de usuarios son funcionalidades de alto nivel. Estas historias de usuario se conocen como Epic (s). Las épicas generalmente son demasiado grandes para que los equipos las completen en un solo Sprint. Por lo tanto, se dividen en historias de usuario más pequeñas.

Reuniones de grupos de usuarios

En la Metodología Scrum, las reuniones de grupos de usuarios involucran a las partes interesadas relevantes (principalmente usuarios o clientes del producto) y proporcionan al equipo central de Scrum información de primera mano sobre las expectativas de los usuarios. Esto ayuda a formular los Criterios de aceptación del producto y proporciona información valiosa para el desarrollo de Epics. Las reuniones de grupos de usuarios son vitales en la prevención de costosas modificaciones, que pueden resultar de la falta de claridad con respecto a las expectativas y requisitos. Estas reuniones también promueven la aceptación del proyecto y crean un entendimiento común entre el equipo central de Scrum y las partes interesadas relevantes.

Las epicas se escriben en las etapas iniciales del proyecto, cuando la mayoría de las Historias de usuarios son funcionalidades de alto nivel o descripciones de productos, y los requisitos están ampliamente definidos. Son grandes historias de usuarios sin refinar en la cartera de productos priorizada. Una vez que estas epicas aparecen en el Backlog priorizado de productos para completar en un próximo Sprint, se dividen en Historias de usuarios más pequeñas y detalladas. Estas historias de usuario más pequeñas son generalmente funcionalidades simples, cortas y fáciles de implementar o bloques de tareas que se completarán en un Sprint.

Riesgos identificados

Al crear Epics, se pueden identificar nuevos riesgos y dichos riesgos identificados forman una salida importante de esta etapa. Estos riesgos contribuyen al desarrollo de la cartera de productos priorizada (que también podría denominarse cartera de productos ajustada por riesgo). Los miembros del Equipo Scrum deberían intentar identificar todos los riesgos que podrían afectar el proyecto. Solo mirando el proyecto desde diferentes perspectivas, utilizando una variedad de técnicas, pueden hacer este trabajo a fondo. La identificación de riesgos se realiza a lo largo del proyecto y los riesgos identificados se convierten en insumos para varios procesos de Scrum, incluyendo la creación de una reserva de productos priorizada, la reserva de productos priorizados del novio y la demostración y validación de Sprint.

fuente: http://blog.scrumstudy.com/why-is-it-important-to-develop-epics-in-scrum/

Qué tan bien funciona ágil para grandes organizaciones

El éxito de las organizaciones de hoy depende de qué tan bien puedan adaptarse al huracán de los cambios que se extienden por su industria. ¿Cómo pueden hacer esto? Muchas organizaciones están buscando a Agile como la respuesta.

A pesar de su popularidad, Agile no ha sido acogido calurosamente por las grandes organizaciones. Una de las razones obvias para esto es que las grandes organizaciones no realizan cambios importantes a menos que sea absolutamente necesario. Otra razón está relacionada con el hecho de que Agile es diferente de las filosofías tradicionales de gestión de proyectos desde las raíces hasta las hojas. Las grandes organizaciones son bastante ortodoxas cuando se trata de sus estructuras organizativas y gestión.

La implementación exitosa de Agile en un entorno burocrático es extremadamente difícil, porque uno de los fundamentos centrales de Agile es la mejora continua del proceso, mientras que la burocracia moribunda apuesta por la ilusión de la estabilidad del proceso. Sin embargo, las grandes organizaciones están comenzando a sentirse atraídas por la importancia y la tasa de éxito de Agile. Los conglomerados de software como Microsoft, IBM y SAP están implementando con éxito Agile para proyectos de desarrollo de productos seleccionados.

Para que Agile tenga éxito, una organización debe decidir que está lista para implementar los principios básicos de Agile. Tiene que liberarse de sus formas rígidas de abrazar la cultura ágil. Es esencial que una empresa comprenda las condiciones en que la implementación de Agile conducirá al éxito:

Condición 1: un equipo pequeño que trabaja en una ubicación, en lugar de un equipo grande que opera desde diferentes ubicaciones

Condición 2: iteraciones cortas y frecuentes durante las cuales los problemas se pueden identificar más rápido que en ciclos extensos del proyecto que tienden a ocultar problemas hasta el final del proyecto

Condición 3: El proyecto incluye la participación del cliente durante el desarrollo del proyecto. Si la compañía es estricta acerca de una ruta burocrática y basada en formas para llegar al cliente, Agile se verá obstaculizado por la misma burocracia.

Condición 4: Empoderar al equipo para tomar decisiones sobre el desarrollo es un componente necesario para lograr el éxito en la metodología Agile. Agile fracasará si la empresa cree en una jerarquía rígida de toma de decisiones.

Condición 5: Agile hace hincapié en trabajar el software en lugar de documentar los códigos, lo que se puede hacer más adelante. Si la empresa tiene que confiar en una extensa documentación para las auditorías, Agile puede proporcionar mejoras de proceso inferiores a las deseadas.

No se establece que estas condiciones adviertan o asusten a las grandes empresas de adoptar Agile. Se afirma que evitan que las empresas adopten Agile de manera ciega y parcial y luego se quejen de que Agile no funciona. Cualquier organización grande debe tener en cuenta sus necesidades comerciales inmediatas y los recursos disponibles, y comprender claramente qué es exactamente lo que desea lograr. Luego, los ejecutivos de la organización deberían decidir si adoptar la metodología Agile totalmente o adoptar un enfoque pragmático. Cualquiera sea la decisión que tomen, el apoyo ejecutivo inquebrantable y holístico es uno de los requisitos principales para que Agile trabaje en una organización grande.
fuente: http://blog.scrumstudy.com/how-well-does-agile-function-for-large-organizations/

Qué NO es un equipo autoorganizado

Comiencemos por reconocer los errores y mirar oportunidades de mejorar los equipos.

La autoorganización es un proceso y una característica, no algo que se hace de una vez por todas .

La autoorganización, desde la perspectiva de los sistemas sociales, solo significa que el equipo puede crear nuevos enfoques y adaptarse para enfrentar los nuevos desafíos en su entorno.

conceptos erróneos

1. Los equipos autoorganizados son completamente autónomos, autogestionados y no necesitan gerentes.
2. Todo lo que necesita hacer para formar un equipo autoorganizado es proporcionar un objetivo y aplicar presión.
3. Dado que el equipo se autoorganiza, pueden acomodar a las personas que se mueven dentro y fuera del equipo fácilmente.

Los equipos ágiles autoorganizados tienen autoridad limitada para hacer sus propios compromisos, organizar y asignar su propio trabajo. Diseñan estrategias apropiadas para lograr sus objetivos y toman decisiones con un impacto económico y organizacional (nuevamente limitado).

Los gerentes deben crear las condiciones que permitan a los equipos prosperar y continuar autoorganizándose . Los gerentes deben trabajar en toda la organización para crear un sistema de trabajo que permita a los equipos entregar valor a los clientes y a la organización.

“No se puede soltar a la gente y dejar que un equipo tome todas las decisiones. Arruinarán las cosas. Y con todos estos Scrum Masters, entrenadores y equipos autoorganizados, parece que no tengo trabajo ”

Concepto erróneo 2: el (time box) limite de tiempo obliga a cualquier grupo a convertirse en un equipo. Reúna a un grupo de personas y entrégueles un desafío y se unirán. No apostaría por eso, y tú tampoco deberías.

Los equipos necesitan un objetivo de trabajo claro y convincente . Sin eso, no hay razón para formar un equipo.
Time boxing es una de las estructuras que puede ayudar a los equipos a tener éxito al proporcionar enfoque. Trabajar en cajas de tiempo crea un ritmo natural de retroalimentación y conexión con el propósito del equipo. Pero una caja de tiempo y un objetivo, en sí mismos, no crean un equipo.

También necesitan las habilidades técnicas requeridas por el trabajo y las habilidades interpersonales para trabajar en equipo . Necesitan recursos como herramientas y acceso a información y educación. Necesitan una conexión con la organización más grande.

Los equipos necesitan tiempo para desarrollar las estrategias y la confianza que permite un alto rendimiento . Necesitan tiempo para comprender las fortalezas y debilidades de cada uno, desarrollar conocimientos compartidos y aprender a aprender juntos.

Cuando nuevas personas constantemente llegan y se van, un grupo nunca puede desarrollar los enfoques compartidos y el conocimiento compartido que les permite superar a un grupo de individuos.

Fuente : https://dzone.com/articles/what-a-self-organizing-team-is-not?edition=521296&utm_source=Zone%20Newsletter&utm_medium=email&utm_campaign=agile%202019-09-02

Contratos en proyectos con Scrum

Algunos de los tipos más comunes de contratos utilizados en los proyectos Scrum son los siguientes:

1. Contrato de entrega incremental: este contrato incluye puntos de inspección a intervalos regulares. Ayuda al cliente o partes interesadas a tomar decisiones sobre el desarrollo de productos periódicamente durante todo el proyecto en cada punto de inspección. El cliente puede aceptar el desarrollo del producto, decidir detener el desarrollo del producto o solicitar modificaciones del producto.

2. Contrato de empresa conjunta: este contrato se usa generalmente cuando dos o más partes se asocian para realizar el trabajo de un proyecto. Las partes involucradas en el proyecto lograrán un Retorno de la Inversión porque los ingresos o beneficios generados serán compartidos entre las partes.

3 Contrato de Desarrollo en Fases: este contrato pone a disposición fondos cada mes o cada trimestre después de que se completa con éxito un lanzamiento. Proporciona incentivos tanto para el cliente como para el proveedor y garantiza que el riesgo monetario para el cliente se limite a ese período de tiempo particular, ya que las liberaciones fallidas no se financian.

4. Contrato de incentivo y penalización: estos contratos se basan en el acuerdo de que el proveedor será recompensado con un incentivo financiero si los productos del proyecto se entregan a tiempo, pero incurrirá en penalidades financieras si la entrega se retrasa.

fuente : http://blog.scrumstudy.com/types-of-scrum-contracts/

Historias de usuario lo mejor para entregar valor a nuestros clientes

Que es una historia de usuario ?

1. Tarjeta
2. Conversacion
3. Confirmación

Estos tres componentes son una trinidad inseparable. Elimine cualquiera de ellos, y el valor se pierde de inmediato . Examinemos estos componentes para entender por qué.

La tarjeta

La tarjeta es la primera representación física de la historia del usuario. Como dije anteriormente, la tarjeta suele ser su índice promedio. Su pequeño tamaño es intencional. Estamos evitando la tentación de documentar exhaustivamente el requisito . Una definición de historia típica será solo una oración:

"Como gerente de laboratorio, debería poder filtrar una lista de reactivos para poder localizar fácilmente los que necesito usar".

También te puede interesar: La tarjeta no es una historia de usuario

Notarás este mismo patrón en muchas historias de usuarios. Este patrón es tan frecuente que ha heredado su propio nombre, "Role-Goal-Motivation". Hablaremos sobre los roles en un artículo posterior. Por ahora me gustaría centrarme en el objetivo y la motivación.

El objetivo es "lo que tengo que hacer". La motivación es "por qué tengo que hacerlo". El porqué representa el VALOR que brindará esta historia en particular. Siempre trato de asegurarme de que nuestras historias estén representadas de esta manera para que no nos olvidemos de la parte del valor .

De hecho, evitar el olvido es el valor principal proporcionado por la tarjeta. No estamos tratando de documentar todo. Solo estamos creando lo que Jeffries llama "una ficha". Incluso podría referirse a él como un kanban del mundo delgado. Su propósito principal es recordarnos que tengamos esas conversaciones .

La conversación

La conversación es donde ocurre la captura de valor real . Es en las conversaciones cara a cara regulares entre los clientes y los desarrolladores que cada participante adquiere una comprensión común de lo que se trata un requisito particular.

Estas conversaciones tienen lugar varias veces en el transcurso del desarrollo. Inicialmente ocurrirán cuando se defina la historia y se cree la tarjeta. Volverán a ocurrir cuando llegue el momento de estimar y programar la historia para su implementación. Deben ocurrir con frecuencia en el transcurso de la iteración en la que se implementa una historia determinada. Ocurrirán una vez más cuando la historia se "complete" y las nuevas capacidades del software se demuestren por primera vez.

Cada una de estas conversaciones resulta en el intercambio de "pensamientos, opiniones y sentimientos" con respecto al valor que debe agregarse. Estas conversaciones son el corazón de cómo mitigamos los problemas con las especificaciones de los requisitos de software.

Debido a que nuestras conversaciones nunca son inamovibles, ya que no existe un proceso de control de cambios, podemos responder de manera eficiente y efectiva a nuestra comprensión cambiante de la mejor manera de entregar valor . Debido a que no intentamos documentar exhaustivamente nuestra comprensión del valor requerido, podemos permitir que nuestra comprensión evolucione a lo largo del diseño y la implementación del software . Debido a que estas conversaciones ocurren continuamente en lugar de por adelantado, no hay demoras entre la elaboración de los detalles y la implementación de esos detalles .

Nuestro problema de cambio de contexto ha sido eliminado.

La confirmación

Las conversaciones en sí mismas, sin embargo, no son suficientes. ¿Cómo sabemos cuándo hemos terminado? El último componente crucial de la historia es la confirmación o "prueba de aceptación".

Las pruebas de aceptación son pruebas automatizadas que documentan de manera maleable nuestra mejor comprensión actual de cómo se entregará el valor para una historia dada. Deben ser entendibles tanto por el cliente como por el desarrollador. El aumento en la disponibilidad de herramientas de desarrollo impulsado por el comportamiento , como Cucumber,  proporciona un medio excelente para crear pruebas de aceptación.

Debido a que estas pruebas son maleables, se pueden cambiar fácilmente a medida que ocurren conversaciones adicionales sobre la historia y a medida que el software evoluciona. Debido a que son automatizados y ejecutables, podemos decir fácilmente en cualquier momento dado si el software cumple con nuestra mejor comprensión actual de lo que requiere una historia dada.

No hay riesgo de que el software y los "requisitos" se desincronicen siempre y cuando estas pruebas se ejecuten de manera regular . Si es posible, esto debería suceder cada vez que se confirme un nuevo código en el repositorio de origen.

Resumen

El desarrollo de software se trata principalmente de entregar valor a nuestros clientes . Dado que ese es el caso, deberíamos estar utilizando las mejores herramientas disponibles para garantizar que estamos entregando continuamente el valor que nuestros clientes esperan. Espero que a través de este artículo haya podido arrojar algo de luz sobre por qué las historias de los usuarios son una excelente herramienta para lograr la entrega de valor.

Fuente:  https://dzone.com/articles/use-stories-deliver?edition=513292&utm_source=Weekly%20Digest&utm_medium=email&utm_campaign=Weekly%20Digest%202019-08-07