DSN_XP y ADD

 Desarrollo impulsado por imbéciles

DSN_XP se encuentra con estas observaciones clásicas dentro del mundo del desarrollo de software, gracias al gentil aporte de @Ego Sum Tempestas

Original en inglés 

ADD

Las siglas y marcos se siguen acumulando. ¿Por qué?

Algunos dicen que es inmadurez: que el software es todavía una industria joven y que todos los cambios son el camino hacia algunos fundamentos verdaderos. Otros dicen que es porque a la gente del software le gusta inventar cosas y no pueden evitarlo. 

Bueno, digo esto: si vamos a tener docenas de modelos, también podemos tener algunos que sean honestos, aunque cínicos, con respecto a lo que realmente sucede la mayor parte del tiempo.

Desarrollo impulsado por imbéciles (ADD)

Cualquier equipo en el que el idiota más grande toma todas las decisiones importantes es un desarrollo impulsado por imbéciles (asshole driven development). Toda sabiduría, lógica o proceso se va por la ventana cuando el Sr. Imbécil (A) está en la habitación, haciendo cualquier cosa idiota y egoísta que crea que es mejor. Puede que haya reglas y procesos, pero el Sr. A los rompe y la gente los sigue de todos modos.

Desarrollo de disonancia cognitiva (CDD)

En cualquier organización donde existen dos o más creencias divergentes sobre cómo se debe crear el software. La tensión entre esas creencias, tal como se ha librado en varias reuniones y decisiones individuales de los jugadores de ambos lados, define el proyecto más que cualquier creencia individual en sí.

Cover Your Ass Engineering (CYAE) 

La fuerza impulsora detrás de la mayoría de los esfuerzos individuales es asegurarse de que cuando la mierda llegue al ventilador, ellos no tengan la culpa.

Desarrollo por negación (DBD)

Todo el mundo finge que hay un método para lo que se está haciendo y que las cosas van bien, cuando en realidad las cosas son un desastre y el proceso está en el suelo. Cuanto peor se ponen las cosas, más depende la gente de su negación de lo que realmente está sucediendo, o de su aislamiento en su pequeña parte del proyecto, para sobrevivir.

Metodología Get Me Promoted (GMPM)

Las personas escriben código y diseñan cosas para aumentar su visibilidad, satisfacer los caprichos de su jefe y acelerar su camino hacia un aumento o la oficina de la esquina, sin importar qué tan lejos de los objetivos establecidos lleguen sus esfuerzos. Esto incluye permitir que ocurran desastres para que las personas puedan ser héroes, escribir trucos que se vean geniales en el corto plazo pero que se desmoronen después de que el individuo haya seguido adelante, y centrarse más en la superficie del trabajo que en su valor.

DSN_XP en gratitud a Ivar Jacobson

 Actores fuente de conocimiento

Casos de Uso y diseño por componentes

DSN_XP entra en contacto con la fuente de conocimientos escrita por Jacobson, al iniciar nuestros estudios del modelado avanzado con Casos de uso.

Ivar Jacobson

En 1967 propuso la utilización de componentes de software en el desarrollo de la nueva generación de conmutadores telefónicos controlados, que Ericsson estaba desarrollando. Para ello inventó diagramas de secuencia y desarrolló diagramas de colaboración. También aplicó diagramas de transición de estado para describir el flujo de mensajes entre los componentes.

Pensó que era necesario hacer planes de desarrollo de software y fue uno de los desarrolladores originales de SDL (lenguaje de descripción y especificación). En 1967, SDL se convirtió en un estándar en la industria de las telecomunicaciones.

También inventó casos de uso como una forma de especificar los requisitos funcionales de software.

En abril de 1987, dejó Ericsson y fundó la empresa Objective Systems. Una mayoría de las acciones de la compañía fue adquirida por Ericsson en 1991, y la compañía fue renombrada Objectory AB.

Ivar Jacobson desarrolló el proceso de software OOSE en Objectory AB alrededor de 1992.

DSN_XP y la técnica A3

 Pensamiento LEAN

DSN_XP tuvo acceso a esta técnica gracias al aporte metodológico del equipo LeanSight mientras nos capacitábamos con ellos sobre el pensamiento Lean aplicado a la agilidad para la resolución de problemas y necesidades de la organización.

Técnica A3

En primer lugar, reconocemos a la capacidad creativa como un elemento que es estudiado por la perspectiva TeamView, por lo tanto, lo que nos interesa capturar es la potencia de la herramienta dentro de un contexto de solución.

Técnica A3 y el pensamiento crítico

La técnica A3 es además de una técnica de pensamiento visual, una forma de pensar por lo que se encuentra cubierta por la cultura organizacional.

Se denomina A3 por sus dimensiones como hoja en la cual se expresarían los componentes del pensamiento A3 para la solución de problemas por experimentación.

Nota: DSN_XP se encuentra en compatibilidad nata con la técnica A3 al tener los dos métodos el espíritu experimental para la búsqueda de soluciones a necesidades de la organización.

Componentes A3

Para utilizar la técnica del pensamiento LEAN en A3, la plantilla más utilizada define los siguientes componentes del diagrama capturado en la hoja A3, a saber:

• Título
• ¿Cuál es el tema a tratarse?
• Antecedentes
• ¿Por qué se lo menciona?
• ¿Cuál es el contexto de negocio/industria?
• Situación actual
• ¿Dónde estamos?
• ¿Dónde necesitamos estar?
• ¿Dónde deseamos estar?
• Mapa de situación actual
• Análisis
• ¿Cuáles son las causas raíz del problema?
• Qué requerimientos, restricciones y alternativas es necesario considerar?
• Objetivos
• ¿Cuál es el cambio específico que se desea lograr ahora?
• Contramedidas
• ¿Cuáles son las contramedidas recomendadas?
• Estado futuro (Plan)
• ¿Qué actividades se necesitarían para implementarse y quién sería el responsable de qué y cuándo?
• Mapa de estado futuro
• Resultados
• ¿Cómo se miden y registran los resultados?
• Seguimiento
• ¿Cómo sabremos si las acciones tienen impacto necesario?
• ¿Qué otros temas se pueden anticipar?

PDCA

Es el método propuesto por el mentalizador de la mirada del mejoramiento continuo y considera en su modelo, la capacidad de generar un Plan que defina la forma en la cual se puede entrar en acción y la capacidad de aprendizaje (motor de la mejora continua) mediante la acción realizada y la mirada técnica de una propuesta para lograr concretar el esfuerzo inicialmente planteado.

Pensamiento A3

Es una técnica para solucionar problemas de tipo colaborativo ya que promueve:

• El pensamiento lógico, objetivo (determinado por datos)
• Resultados y proceso.
• Síntesis, refinamiento y visualización.
• alineación.
• Coherencia al interior y uniformidad en general.
• Pensamiento basado en perspectivas sistémicas.

DSN_XP y las constelaciones familiares

 Constelaciones familiares

Dentro del estudio del TeamView, era necesario comprender aquellos aspectos que pueden influir en la capacidad de desarrollo del equipo, como equipo, sus miembros poseen una vida propia y los contextos familiares a su alrededor influyen en el proceso creativo y abstracto a la hora de codificar y diseñar soluciones basadas en el software.

Constelaciones Familiares

DSN_XP no entra en profundidad en el estudio del marco teórico que sustenta a esta escuela de pensamiento que está destinada a registrar a manera de terapia, representaciones de los eventos que pudieron haber sido hechos reales o patrones típicos de comportamiento de la línea familiar.

Desde nuestra observación, el hecho de poder tener acceso a una biblioteca con todos los registros de un escenario en particular para uno o varios actores, requiere que dicho registro capture tanto los mensajes hablados, comportados, pensados, intuidos, etc., conforme a la representación que se desea realizar de los eventos esperados en el escenario.

Sin embargo, para poder capturar los registros, se requiere poseer la interfaz necesaria para ello y la forma en la cual se asocia este proceso de captura es a través de la intuición y su capacidad de lectura del registro accedido o invocado.

Team View

Esta perspectiva se encarga del estudio del comportamiento del pensar humano, por lo que no profundiza en temas de psicología de manera profunda, pero asocia sus conocimientos de programación y estructuras algorítmicas para el entendimiento del comportamiento resultante del accionar y pensar del individuo y su colectividad, a esto lo denominamos como el estudio del autómata.

DSN_XP y Archimate

Especificación ArchiMate 

DSN_XP investiga esta herramienta como complemento a los modelos realizados con los artefactos propuestos por TOGAF.

Archimate

La especificación ArchiMate®, un estándar del "The Open Group", es un lenguaje de modelado abierto e independiente para la arquitectura empresarial que cuenta con el respaldo de diferentes proveedores de herramientas y firmas de consultoría. 

La especificación ArchiMate proporciona instrumentos para permitir que los arquitectos empresariales describan, analicen y visualicen las relaciones entre los dominios comerciales de una manera inequívoca.

Así como un dibujo arquitectónico en la arquitectura de edificios clásica describe los diversos aspectos de la construcción y el uso de un edificio, la especificación ArchiMate define un lenguaje común para describir la construcción y operación de procesos comerciales, estructuras organizativas, flujos de información, sistemas de TI y técnicos. infraestructura. 

Esta información ayuda a las partes interesadas a diseñar, evaluar y comunicar las consecuencias de las decisiones y los cambios dentro y entre estos dominios comerciales.

Objetivo

Este estándar es la especificación del lenguaje de modelado ArchiMate Enterprise Architecture, un lenguaje visual con un conjunto de iconografía predeterminada para describir, analizar y comunicar muchas preocupaciones de las arquitecturas empresariales a medida que cambian con el tiempo. 

El estándar proporciona un conjunto de entidades y relaciones con su correspondiente iconografía para la representación de descripciones de Arquitectura. El ecosistema ArchiMate también admite un formato de intercambio en XML que permite el intercambio de modelos y diagramas entre herramientas.

Descripción

Una arquitectura empresarial generalmente se desarrolla porque las personas clave tienen inquietudes que deben ser abordadas por los sistemas comerciales y de TI dentro de una organización. Estas personas se conocen comúnmente como las "partes interesadas" de la Arquitectura Empresarial. 

El papel del arquitecto es abordar estas preocupaciones identificando y refinando la motivación y la estrategia expresada por las partes interesadas, desarrollando una arquitectura y creando vistas de la arquitectura que muestren cómo aborda y equilibra las preocupaciones de las partes interesadas. Sin una arquitectura empresarial, es poco probable que se consideren y aborden todas las inquietudes y requisitos.

El lenguaje de modelado ArchiMate Enterprise Architecture proporciona una representación uniforme para los diagramas que describen las arquitecturas empresariales. Incluye conceptos para especificar arquitecturas interrelacionadas, puntos de vista específicos para partes interesadas seleccionadas y mecanismos de personalización del idioma. 

Ofrece un enfoque arquitectónico integrado que describe y visualiza diferentes dominios de arquitectura y sus relaciones y dependencias subyacentes. Su marco de lenguaje proporciona un mecanismo de estructuración para los dominios, capas y aspectos de la arquitectura. 

Distingue entre los elementos del modelo y su notación, para permitir representaciones variadas y orientadas a las partes interesadas de la información de la arquitectura. El lenguaje utiliza la orientación al servicio para distinguir y relacionar las capas de negocio, aplicación y tecnología de las arquitecturas empresariales.

DSN_XP y la arquitectura de procesos

Arquitectura de procesos

DSN_XP considera a la ingeniería de procesos como una de las perspectivas que pueden ser capturadas mediante el concepto de arquitectura, sin embargo, los procesos cambian y por ende, el modelo arquitectónico modelado debe poseer la facilidad de poder adaptarse a la organización en base a niveles de abstracción y control.

Arquitectura de procesos

Mientras estábamos investigando la forma en la cual se producen mejoras a las organizaciones públicas, nos encontramos con la presencia de una fuente de conocimientos que definía el concepto de arquitectura de procesos.

Arquitectura de procesos es un instrumento que muestra en general todos los procesos que la institución ejecuta, la relación transversal que mantienen y que evidencia el valor generado en el contexto en el que operan. [Norma técnica de procesos]

Ahora bien, no solo es cuestión de definir una arquitectura para que esta entregue al usuario lo que busca de su aplicación, en este caso se analiza la mejora institucional del sector público mediante la introducción del concepto de administración por procesos.

Bajo la misma norma se entenderá que:

Administración por procesos es el conjunto de definiciones y actividades sistemáticas implementadas en una institución, con el propósito de alinear sus procesos a la estrategia y modelo de gestión, clarificar y mejorar continuamente su operación para proveer servicios y productos de calidad que satisfagan las necesidades y expectativas de los usuarios.

Finalmente, ya que se introduce al usuario en el modelo, es necesario mapear el ámbito legal atribuible a la organización para efectos de poder definir su creación y participación dentro del contexto de servicio y administración por procesos. Usualmente se lo entiende como cadena de valor, tal que, según la norma expresa analizada, se tiene:

Cadena de valor, es el conjunto de procesos involucrados en la entrega de valor a los usuarios. Describe lógicamente cómo se desarrollan los procesos de  un sector o institución, buscando añadir en cada eslabón de la cadena un concepto de valor.  La cadena de valor será definida en concordancia con las competencias, facultades y atribuciones para ella definidas dentro del marco de los instrumentos creados para el efecto y bajo el enfoque de la política sectorial establecida. 

Finalmente, DSN_XP adopta el modelo de cadena de valor como el instrumento por el cual es posible introducir en la cultura organizacional los conceptos sobre administración por procesos.

Modelo de gestión

1. Conceptualizar y estructurar un servicio.
   
   Segmentar usuarios del servicio, identificar las necesidades que disparen el servicio y mapa de actores y establecer la tramitología del servicio, marco legal vigente, canales de atención, acuerdos o compromisos de calidad según y recursos.
2. Condiciones básicas para la prestación de los servicios.
   
   Gestionar infraestructura, personal, la tecnología de contacto, equipamiento y materiales, todos aquellos elementos considerados como básicos para la prestación del servicio, las condiciones se establecerán en función de los canales identificados por la institución.
3. Recolección y sistematización de datos e información relativa al servicio:
   
   Oferta, demanda, comportamiento de los indicadores, requisitos de los usuarios, mejoras registradas.
4. Gestión documental de la prestación de servicios y la administración por procesos.