ÉticaLa "ética empresarial" es cuestionable cuando se antepone el beneficio propio al del cliente.

Para medir la ética de mis comportamientos no tengo que mirar los beneficios que me producen, sino los que producen en los demás.

La ética empresarial no se muestra con palabras, sino con los beneficios que la actividad de la empresa genera en los demás. La ética es esencialmente altruista, y las empresas éticas deberían responder más a motivaciones altruistas que egoístas.

En una empresa ética el beneficio propio es una consecuencia de su actuación para garantizar la continuidad de su trabajo, pero no es su fin. Su fin es el beneficio de sus clientes, trabajadores y la sociedad en general.

Quizá un criterio para determinar el nivel ético de la empresa pudiera ser saldo "green" y "commons" que produce esa empresa en el sistema: si es positivo o negativo y en qué proporción.

Post relacionado: ¿Cuál es la finalidad de las empresas?

Pepe Gotera y Otilio

Este fragmento de código prueba la afirmación de que la diferencia entre los promedios y los mejores, en programación no es 1:2 como en otros trabajos, sino 1:100 (Nathan Myhrvod)

Es un trabajo real escrito por un programador para hacer una función que comprueba la validez de una fecha, en un programa desarrollado con Visual Basic.

¿Hubiera sido muy diferente el resultado si lo hubiera realizado otra persona?

Otra persona podría haber empleado directamente la función que incorpora Visual Basic precisamente para calcular la validez de una fecha: IsDate()

Esta segunda persona no hubiera invertido un día de trabajo, sino medio minuto.

La función que se entregó al al cliente tiene 2 errores: considera como fechas válidas las cadenas vacías y comprueba mal los años bisiestos. La función que podría haber hecho otro programador (la de los 30 segundos) no tendría errores.

En una empresa de consultoría, de las que basan los resultados en modelos de procesos y emplean métricas formales para medir la eficiencia de los programadores (ej. procesos CMMI con métricas PSP) el primer programador tendría un volumen de trabajo de 110 líneas de código, mientras que el segundo sólo tendría una, por lo que es muy probable que el primero pudiera ofrecer mejores registros de eficiencia en su ficha profesional, del mismo modo que con un criterio similar de medición, Corín Tellado daría mejor foto como escritora que Camilo José Cela.

libroCeste me ha invitado de nuevo a impartir clases de Ingeniería del Software. He recopilado ejercicios y apuntes para las clases que comenzaron el mes pasado. Dejo aquí para quien pueda resultar útil, el fichero que resume en 650 diapositivas los temas que incluyen:

  • Introducción a la ingeniería del software
  • Gestión de proyectos predictiva
  • Producción basada en procesos
  • Ingeniería de procesos de software
  • Modelo de procesos CMMI
  • Modelo de procesos ISO IEC 15504
  • Ciclo de vida del software
  • Ciclos de desarrollo y patrones de gestión de proyectos
  • Los requisitos del software
  • Diseño del software
  • Documentación de usuario
  • Verificación y validación
  • Mantenimiento
  • Gestión de la configuración
  • Agilidad
  • Conocimiento
  • Síntesis entre procesos y agilidad
  • Scrum
  • Kanban
  • Gestión en organizaciones ágiles

Descargar "Compendio de Ingeniería del software" (rev. 0,9)

encajarEl Instituto de Ingeniería del Software americano (SEI) empezó  en los 90 el desarrollo de los modelos de procesos de la familia de CMM para ayudar a que los proveedores de sistemas de software para el Departamento de Defensa de los Estados Unidos cumplieran con de las condiciones de adquisición, principalmente: calidad, costes y fechas.

Al ser la norma que debían alcanzar las grandes suministradoras de soft del ejército americano, los CMMI's se convirtieron a principios de los 2.000 en el "vestido" con el que las software factory también se querían mostrar, para parecerse a las grandes.

Pero quizá porque muchas empresas de soft están empezando ya a pasar de tanto CMMI, y prefieren trabajar con métodos ágiles, SEI se acaba de publicar las primeras notas técnicas para ayudar al Departamento de Defensa a contratar con esas empresas tan tercas ;-)

Pueden ser información de referencia útil si se necesitan encajar procedimientos de contratación pesados con empresas de programación ágil.

Cito los dos párrafos siguientes de la nota "Agile Metrics: Progress Monitoring of Agile Contractors" que describen muy bien su objetivo y contenido:

"Esta es una de las notas técnicas publicadas por el Instituto de Ingeniería de Software destinadas a la ayuda de los profesionales del Departamento de Defensa de Estados Unidos encargados de la adquisición con proveedores que utilizan métodos ágiles de desarrollo de software. Estos profesionales de apoyo a la adquisición y mantenimiento de los sistemas de software están siendo testigos de cómo una gran parte de la industria se aleja de los llamados procesos de ciclo de vida "de cascada tradicional". La infraestructura existente apoyar el trabajo de los profesionales de adquisición ha sido moldeada por la experiencia de la industria, que hasta hace poco ha tendido a seguir un proceso de cascada. La industria está encontrando que los métodos orientados a los procesos del ciclo de vida heredados necesitan realinearse con las nuevas formas de hacer negocios." ...


... "Estos individuos suelen tener formación y experiencia en gestión de proyectos, y conocen bien las normas y reglamentos que rigen el proceso de adquisición. Sin embargo , muchos de estos profesionales cualificados no están familiarizados con los métodos de desarrollo ágil . Como muestra el gráfico de abajo, estos profesionales se encuentran a veces en el medio - entre un proveedor innovador y un conjunto arraigado de expectativas que deben ser satisfechas . Las conexiones entre las nuevas formas de trabajo y las viejas formas de hacer negocios pueden no son fáciles".

dod agile

"En la Sección 2, Fundamentos de métricas ágiles, ofrecemos una breve introducción a los métodos ágiles, comparándolos con los métodos tradicionales para ayudar al lector a comprender las restantes secciones del informe.
En la Sección 3, Consideraciones de medición seleccionadas en el Departamento de Defensa de Adquisición, se describe el contexto normativo en el que se deben implementar las métricas ágiles, junto con una lista de categorías de indicadores que habrá que tener en cuenta.
En la Sección 4, Métricas ágiles, se discuten las métricas empleadas específicamente por los métodos ágiles, ilustrando con ejemplos, los indicadores que normalmente utilizan los equipos de desarrollo ágil.
En la Sección 5, Seguimiento del avance de la adquisición usando métodos ágiles , ofrecemos un análisis detallado de las métricas utilizadas para monitorizar el trabajo en curso de los equipos de desarrollo ágil."

Información y descarga:


evaluandoHace dos décadas la medicina suprimía de la dieta de las personas con problemas de colesterol los alimentos grasos, incluidos pescado azul o aceite de oliva.

Con frecuencia las soluciones simples crean mitos que por simplicidad lógica de su razonamiento resultan fáciles de aprehender y difíciles de cuestionar: "Si el enfermo presenta exceso de grasa en sangre, reduzcamos la ingesta de grasa".

"Para todo problema complejo hay siempre una solución simple, que es errónea"
George Bernard Shaw


Esta afirmación no caen bien en las empresas con directores de "recursos humanos" que aplican evaluaciones de desempeño. 
Estamos de acuerdo en el objetivo de lograr un sistema de beneficio muto "organización <-> personas", en el que éstas se trabajan motivadas y en continua mejora profesional, de forma que la organización también mejora su eficiencia y la calidad de los resultados.
Estamos de acuerdo en que el exceso de grasa en sangre es malo.
La cuestión es: ¿Las evaluaciones de desempeño ayudan o perjudican?.

A ver si eso de que las evaluaciones de desempeño sirven va a ser un mito, porque lo cierto es que no hay muchas pruebas objetivas de sus bondades.
El 80% de las empresas hacen evaluaciones de desempeño, sin embargo, el 90% de las que hacen evaluaciones, y un porcentaje similar de quienes evalúan y son evaluados están insatisfechos con este procedimiento
Tom Coens y Mary Jenkins, "Abolishing Performance Appraisals"

Ningún estudio controlado ha hallado jamás un mejoramiento de largo plazo en la calidad del trabajo de las personas que resulte de ningún tipo de programas de recompensas o incentivos
Alfie Kohn, Punished by Rewards
Los problemas de motivación y eficiencia, se suelen abordar de forma errónea, especialmente en industrias como la del software, que se basan en el talento de las personas donde emplear las evaluaciones de desempeño como medio de motivación (v. ¿Motivar a los programadores para que programen?) es un error.


Las evaluaciones por escrito deben proporcionar efectivamente una documentación objetiva e imparcial, necesaria o útil en las decisiones disciplinarias o en los despidos
Tom Coens y Mary Jenkins, "Abolishing Performance Appraisals"


Las evaluaciones de desempeño tienen formas poco alineadas con los fines que deberían perseguir:

  • Son un procedimiento obligatorio.
  • Se documentan por escrito.
  • Las administra el jefe.
  • Hacen a las personas responsables de metas y medidas pasadas.
  • Exigen a los individuos comprometerse por escrito con metas y acciones futuras.
  • Se sitúan y conservan durante años en el expediente oficial de personal del empleado.
  • Se ordena que el empleado la firme.
  • Se utilizan para tomar importantes decisiones relativas al salario, el avance, la promición y las suspensiones.
  • Están vinculadas a la disciplina o el despido, o se utilizan en conjunto con éstos.


¿De verdad es una buena práctica para conseguir equipos motivados y comprometidos?.

Cafe y tilaQue la industria de la consultoría pretenda vender las bondades de aplicar CMMI y agilidad a la vez es como si la industria del café y la de la tila quisieran vender el potencial "sinérgico" de sus productos:  tomar café y tila a la vez... Una misma infusión, saludable y útil para todo el mundo: lo mismo para  somnolientos, que para insomnes.
 
Estoy convencido de que no es posible aplicar en un proyecto desarrollo ágil con CMMI (o con otros modelos de procesos). Para los modelos de procesos el know-how responsable del resultado está en el conocimiento explicitado en los procesos y la tecnología, mientras que para la agilidad está en el conocimiento tácito de las personas. El afán de mezclarlos responde a los intereses de los consultores que lo recomiendan, que al de sus asesorados.
Tambien estoy convencido de que una cosa es la síntesis de ambos conocimientos (porque entre ellos son tésis y antítesis) y otra cosa muy diferente es pretender la suma de los dos.
 
Y como estar convencido nada tiene que ver con estar en lo cierto, por mucho que al convicto se lo pueda parecer; que tan segura como para el ateo es su razón, lo es para el creyente su fe, es aconsejable conocer y analizar opiniones diferentes. Al hacerlo te das cuenta muchas veces de lo despistado que andas, y otras te reafirmas en lo despistados que andan otros (por no pensar que su intención es desinformar).
 
En este intento de las consultoras de vender de todo se llega a falsifiar la historia para adecuarla al razonamiento que se quiere sostener, como ocurre en el informe panfleto de SEI "CMMI or Agile, Why not Embrace Both!: 
 
que esto de las metodologías ágiles tiene muy poco de vanguardista.  Que en realidad y aunque no lo supiéramos nadie (sólo ellos) la agilidad  que ahora hace furor, es un modelo de ingeniería más viejo que la tos, con nada menos que 75 años (¡8 años antes de que que se construyera  Eniac!) y que se llama IIDD (Iterative and Incremental Design and Development). Que el Ministerio de Defensa Americano DoD (Patrón de SEI), estaba ya cansado de usarlo en los 50, y que para complementarlo y evitar las áreas de fallos que tiene, se desarrolló precisamente el CMM y luego el CMMI.
 
"This cornerstone is iterative and incremental design and development (IIDD), a method adopted by engineers over 75 years ago. Early adopters of IIDD included Department of Defense (DoD) engineers who engaged in propulsion-
related research and development, which included engineering activities tied to hardware not software...
...proliferated with names such as Scrum, Crystal, FDD, and others. With the proliferation of IIDD methods..."
 
 
¡Alucinante! y al mismo tiempo curioso. Y porque se trata de un organismo tan reputado como SEI, que si no uno pensaría que este IIDD Iterative and Incremental Design and Development, tan misterioso como supuestamente antiguo es una mentira que se sacan de la manga, porque ni Google ha leído una sóla página en la que se le mencione (Supongo que enseguida tendrá al menos dos: la de su panfleto técnico y ésta (1) y que todas las que vayan surgiendo luego serán posteriores a 2008)
 
Viendo que SEI recurre a la estrategia pueril de inventar lo que sea para "vender" la excelencia de su modelo, en lugar de convencerme de ella, refuerza más la sospecha de que su objetivo es cada vez menos la mejora del negocio de las empresas de software, y más la del suyo propio de consultoría.
 
Todo el rigor del informe panfleto, cuyo título podría despertar la ilusión de algún argumento interesante, se reduce a:
 
kanbanUn tablero kanban es una herramienta para mostrar la situación de trabajos previstos y los que están en curso. La gestión ágil y el desarrollo evolutivo de proyectos TIC usan tableros kanban  para gestionar visualmente un flujo de tareas continuo, sin atascos ni tiempos muertos (o al menos para intentarlo ;-)
 
En foros de gestión ágil,  compañeros habituales del término kanban son: lean y wip, ambos como "claves" para su funcionamiento. También es muy frecuente la relación con  la filosofía "start-up" y su concepto de "mínimo producto viable" por el que los clientes o los gestores de producto deben priorizar los trabajos que necesitan para, con los recursos de que disponen, desarrollar el mayor valor de producto en el menor tiempo.
 
A modo de mapa de situación de las relaciones entre kanban, lean, WIP, priorización de tareas y la teoría de gestión de colas, he preparado esta infografía con la que actualizar los apuntes de Ingeniería del Software, ahora que me vuelve a invitar CESTE a retomar las clases.
 
La comparto aquí para todos los que os pueda servir.
 
Kanban, claves para la mejora del flujo
 

 

Safe Creative #1312089540117