Adsence

martes, 24 de octubre de 2017

Estabilidad en los Equipos de Desarrollo de Software

Resultado de imagen de equipos de desarrollo de software



Vamos a realizar reflexiones al respecto de cosas que al parecer son obvias pero que a veces nos abruman con argumentos que terminamos olvidando. Y volviendo a las aclaraciones obvias, por “estables”, quien lo pregunta te está preguntando sobre si es malo que en un proyecto entre y salga gente constantemente. Y si te vas al lado oscuro, bueno a la consultoría oscura, puede que la pregunta esconda algo así como… “Voy a sacar perfiles caros, digo seniors, y meter otros más baratos, digo juniors… ¿afectará mucho?”.

Quien dice que no pasa nada por mover gente dentro de un equipo, suele caer en la idea de confundir “personas” con “recursos”. Un “recurso” es sólo “dinero visto a traves de horas de trabajo”, pero una “persona” es, además, relaciones con otras, conocimiento, motivación, desmotivación, experiencia, etc. Por eso, mejor piensa en “personas” y no en “recursos”.

Si solo ves “recursos” pues, probablemente, y teóricamente, te cuadre lo de cambiar “recursos” de un equipo a otro, por motivos de costos, crisis, apagar fuegos, etc. Pero si piensas que en los proyectos hay “personas”, empezarás a ver que las siguientes, y casi centenarias, ideas, tienen más sentido del que pensabas:

– Ley de Brooks. O aquello de que “añadir gente a un proyecto software con retraso hace que se retrase más”, algunos detalles y revisiones, ya que añadir más recurso incrementa los canales de comunicación, tiene el costo de la fase de aprendizaje y sincronizacion de equipos.

El ciclo de Tuckman, que tiene que ver con la formacion de equipos de alto rendimiento.
Representación lineal del modelo de desarrollo de equipos de Tuckman.

– La multitarea, es decir, tener a personas distribuidas en varios equipos y proyectos, olvidando que trabajar en más de un proyecto a la vez genera pérdidas de tiempo y disminuye la productividad.

Por lo tanto, la próxima vez que alguien te plantee esto, más si vas a “subcontratar” un desarrollo, es que ni te lo plantees: los equipos deben ser estables. Olvida cualquier justificación contraria a esto, si bien hay una justificación hipnotizante sobre la que debes estar más alerta que sobre cualquier otra: “si lo hacemos así el proyecto saldrá más económico”. Económico, palabra cautivadora. Pero recuerda, lo barato… muchas veces sale caro.

Los miembros de los equipos estables se conocen, conocen su estilo de trabajo, se forman juntos. Por ello, ten en cuenta, que sin equipos estables, raro es que conozcas la capacidad de trabajo del equipo, llámalo velocidad (mírate eso de ¿Qué es la velocidad en un proyecto software (normalmente ágil o Scrum)? Aclaración de dudas frecuentes) si estás siguiendo un proceso ágil, lo que difícil tener previsibilidad sobre cómo y cuándo acabará el proyecto. Y ten en cuenta que puede que se termine el desarrollo, pero que lo que te ahorraste te lo gastes multiplicado en el mantenimiento (supuesto mantenimiento, por no llamarle terminar las cosas)

viernes, 15 de septiembre de 2017

Hasta 2020 el análisis de datos estará presente en 90% de las empresas.




Según un estudio independiente, el 90% de las empresas utilizarán el análisis de datos en 2020, a pesar de los obstáculos derivados de los silos de datos, la seguridad y la falta de alineación.
El 40% de las empresas ya están utilizando la analítica de datos en funciones clave de negocio como ventas, desarrollo de productos y marketing, y un 23% más tiene previsto implementarla en los próximos 12 meses, según un estudio realizado por Forrester Consulting. Una tendencia que anticipa un crecimiento exponencial del Data Analytics a pesar de que todavía existen ciertas barreras que dificultan su adopción.
El estudio se realizó sobre una muestra global de más de 580 empresarios y responsables de TI de 11 sectores industriales, en tres continentes y según Forrester la adopción de Data Analytics aumentará en los próximos 3 años y se prevé que en 2020 cerca del 90% de las empresas utilizarán en su negocio información procedente de estos datos.
Al analizar la barreras que dificultan la adopción del Data Analytics, el 44% los encuestados dijo que el aumento de una gran variedad de datos no estructurados representa un gran desafío, mientras que el 35% mostró su preocupación por las prácticas tradicionales basadas en los silos de datos y por la falta de alineación entre TI y la operativa del negocio.
La mayoría de las empresas encuestadas han puesto ya en marcha medidas para superar estas barreras y entre sus prioridades críticas para los próximo 12 meses destacan la mejorara de la relación entre TI y el negocio (71%) y la reorganización del TI para alinearla mejor con el negocio (66%).
El estudio analizó los objetivos y prioridades de once sectores de negocio, identificando diferentes prioridades específicas del mercado, dependiendo del sector. Así, para sector de las Utilities, la analítica de datos se considera un requisito previo en el desarrollo de redes inteligentes, mientras que en la fabricación, el análisis está estrechamente vinculado a la smart factory, en particular en relación con el mantenimiento predictivo.
La investigación proporciona perfiles del sector para las actitudes analíticas y las prácticas a través de múltiples sectores, incluyendo la energía y las Utilities las finanzas, el sector público, manufacturing, el retail y las telecomunicaciones.

Conclusiones

Forrester ha destacado la necesidad de que las organizaciones sean rigurosas en establecer objetivos comerciales claros y cuantificables en todas las iniciativas de análisis de datos: Un cambio que afecta tanto a los procesos y la cultura de las empresas donde se empiezan a implementar desiciones basadas en datos esto tiene como consecuencia retos tecnologicos para poder sostener estas estrategias en empresas.

Metodología

En este estudio, Forrester llevó a cabo una encuesta en línea de 583 empresas y líderes de TI de empresas de América del Norte, Europa y Asia-Pacífico para evaluar la estrategia de sus organizaciones y la gestión de análisis de datos. Se cubrieron once industrias, incluyendo energía y servicios públicos, servicios financieros y seguros, Telco, Retail, Gobierno y Manufactura. El sector manufacturero incluye, alta tecnología e ingeniería, automoción, fabricación de productos de consumo, productos farmacéuticos, productos químicos y metales y procesos. Los participantes de la encuesta incluyeron directores, VP y tomadores de decisiones a nivel C. A los encuestados se les ofreció un pequeño incentivo como un agradecimiento por el tiempo gastado en la encuesta. El estudio comenzó en septiembre de 2016 y se completó en noviembre de 2016.

Importancia de las pruebas de software

Estamos realmente seguros que por premuras de entregas damos por alto el desarrollo de un nivel adecuado de pruebas?.. A continuacion un comic de las dos realidades a modo de reflexion.


jueves, 9 de febrero de 2017

Desarrollar software es una tarea muy compleja




Un buen software es poco común porque escribirlo es difícil. En resumen, todos sabemos que es difícil. Hablamos incesantemente de cómo es difícil. Y, sin embargo, también colectivamente parecen sorprendidos - sólo conmocionado! - cuando sucede lo esperable y el software que estamos expuestos o está trabajando en resulta pobre.

Esta es la disonancia cognitiva clásica: Aceptar que el software de escritura es difícil, pero esperando que todo lo que debe ser bueno.

También es una aplicación de una teoría del mundo justo de esfuerzo y logro. Que a pesar de las probabilidades, todo el que tiene la intención correcta en el corazón, y pone en el trabajo, tendrá éxito. No, no lo harán. Eso es simplemente delirante. Y esos delirios son todo menos inofensivos.

Cuando esperamos que el buen software sea el resultado más probable de la dificultad de escribirlo, nos estamos preparando para una decepción inevitable. Aún peor, si creemos que merecemos un buen software de nuestros esfuerzos imperfectos, proyectaremos los fracasos inevitables en todo el mundo y en todo menos en nosotros mismos.

El primer sospechoso habitual que ha sido acusado de responder por este sorprendente fracaso aún esperado es el de nuestras herramientas. Es la salida más fácil. Si usted está maldiciendo en su entorno de programación, no va a hablar de nuevo, no va a refutar sus cargos absurdos. Cuando compartes tu historia con tus amigos o colegas, por lo general hacen lo que la gente amable que saben que hacer: Están de acuerdo con usted. Ellos están de acuerdo, incluso si estás equivocado.

Esto infla una burbuja de competencia ilusoria con bondad y autoestima. Las herramientas no se defienden y sus compadres le complacen. Así que no hay nada que pinchar esa burbuja. (Bueno, a menos que te aventures en Internet, los extranjeros siempre están dispuestos a decirte lo incompetente que eres si no justificas las opciones tecnológicas que ya han hecho).

De todos modos, eso es un gran preámbulo para llegar a una verdad básica, pero incómoda: El software a menudo no es bueno porque sus creadores simplemente no son competentes desarrolladores de software. Hay muchas calificaciones a ese cargo, muchas circunstancias de alivio, y una definición muy amplia de "desarrollador de software competente". Pero es un comienzo útil para aceptar la responsabilidad. Y aceptar la responsabilidad es el primer paso para mejorar.

Porque considere la alternativa: si culpo mis herramientas o mi proceso o mis partes interesadas o la luna llena, consigo exonerarme, y mi ego, pero me quedo con mucho menos motivación para mejorar y muy poca penetración en cómo. Si en cambio acepto al menos la responsabilidad parcial, hay un lugar claro para empezar a mejorar.

Yo entiendo completamente cómo terminamos aquí. Con buenas intenciones, por supuesto. Aprender algo nuevo, como la programación, es desalentador. El síndrome de Imposter es abundante. Tenemos todo tipo de razones por las que queremos alentar y apoyar a todos los que tratan de atraer a las computadoras gruñonas a bailar.

Y hemos logrado un grado asombroso con esas intenciones. Comenzar a programar hoy nunca ha sido tan fácil. De fuente abierta a libros y tutoriales magníficos a bootcamps, es realmente asombroso.

Esto contrasta claramente con el hecho de que la programación también nunca ha sido más difícil de dominar, tanto en profundidad como en amplitud. Nunca ha habido más lenguas, más conceptos, más marcos, bibliotecas, herramientas. Es imposible saber, y mucho menos entenderlo todo. Qué extraña dicotomía. Pero esa dicotomía rara vez es el punto culminante de cualquier discusión con los recién llegados. Todos estamos tan ansiosos de alentar y exaltar con razón lo fácil que es para empezar. Así que, por supuesto, muchas personas se sienten un poco erróneas cuando su falta de competencia conduce al fracaso. Y por supuesto van a buscar chivos expiatorios, como malas herramientas o mala documentación.

Es por eso que vale la pena reflexionar sobre qué mal servicio podemos ofrecer a aquellos que buscan aprender programación al proclamar lo fácil que es ahora. Sí, hemos hecho que sea más fácil y menos intimidante empezar. Ese es el verdadero progreso. Pero empezar es, por definición, sólo el primer paso.

Creo que es hora de hablar con más franqueza sobre el paso dos, tres y mil. Para dejar de esperar que todo el mundo que se dispone a desarrollar software va a terminar con código hermoso y las estructuras de mantenimiento como el resultado más probable. Simplemente no. La mayoría del código es probable que siga siendo sólo eso: código. Impenetrable para los lectores secundarios, porque era apenas comprensible para su autor original. Es difícil de razonar porque la razón era un objetivo lejano detrás de "hacer que funcione lo suficientemente bien para enviar".

Algunos ambientes pueden hacer que sea un poco más o menos probable. Al igual que el viento detener un balon de futbol, algunos coches realmente se toman las curvas más rápido. Las herramientas absolutamente, positivamente importa. Sólo mucho menos de lo que nos gustaría dejar creer a los recién llegados.

El verdadero propósito de encontrar las herramientas adecuadas es cómo ayuda al progreso del desarrollador de software en su camino hacia la maestría.

Ahora me doy cuenta de que estoy hablando de mi propio libro aquí. Como desarrollador, he escuchado varias historias lamentables de toda la vida, culpando a los entornos de programación por software deficiente. Pero también es mi libro porque es mi propia historia: Un camino a la maestría pavimentado con mucha proyección hasta que me golpeó la chispa roja que encendió mi curiosidad y cambió mi trayectoria.
También es la suma de la observación de diez años desarrollando software y mirando a otros hacer lo mismo. Ver quién sigue creciendo y quién se asienta para la meseta. Las personas que se resignan a quejarse de su entorno sin tratar de mejorarlo normalmente caen en la segunda categoría. También lo hacen las personas que están ansiosas de saltar a una persecución sobrenatural o personal como explicación de por qué no pueden hacer que algo funcione.

Me gustaría ver menos gente atrapada en la meseta. La vida es más interesante cuando sigues subiendo. Y es más probable que lo haga si acepta las probabilidades: Desarrollara mal software durante mucho tiempo. Si aceptas la responsabilidad de esto, tienes la oportunidad de desarrollar lo que es al menos es pobre en nueva tecnologia y emocion, pero probablemente mejor desarrollado también.

No hay un marco o incluso un lenguaje que le permitirá evitar esta progresión. Sólo hay más o menos probabilidades de coincidir con sus sentimientos y encender tu motivación para entender todo. Encuentra algunos de esos puntos o motivaciones que te permitiran crecer y empiece a caminar.

La idea es poder seguir creciendo para con nuestro trabajo mejorar todo nuestro entorno.

miércoles, 11 de enero de 2017

Contratos en Scrum

Resultado de imagen para contratos en agile
El tema de las contrataciones en proyectos de software, siempre ha sido polémico. De forma tradicional, en un contrato se acuerdan un grupo de requisitos del cliente, que deben ser desarrollados en un tiempo X y por un valor Y. Estas condiciones generalmente conllevan a largas negociaciones posteriores por alcance, cuando el cliente quiere añadir alguna funcionalidad, o a que no se cumplan los plazos, anexos al contrato especificando valores adicionales a los pactados por la incorporación de nuevos requisitos, malos entendidos sobre los requerimientos iniciales podríamos decir que la contratación puede convertirse en una vulnerabilidad para empresas desarrolladoras de software.
Si hablamos de una empresa que desea o ha adoptado un marco de trabajo ágil, este siempre será uno de los primeros puntos dentro de sus preocupaciones. ¿Cuánto voy a tardar? ¿Cuántos requisitos pactamos? ¿Con cuánto presupuesto contamos? ¿Cómo voy a añadir cambios que están fuera de lo pactado? Definitivamente, una organización que adopte ágil, deberá revisar y modificar sus procesos, en especial, los de contratación.
Todos conocemos el siguiente grafico en el cual se tiene un triangulo con tiempo, alcance y recursos por lado a esto hay que añadir la calidad como area del mismo, pues en todo proyecto se tiene que tener claro que maximo se puede fijar 2 de los 3 lados y este es uno de los principales puntos a considerar en la contratación de software.
En este punto existen varias opciones, pero todos los clientes querrán saber cuánto les va a costar su producto y cuándo lo van a tener. Es por ello que para un contrato “ágil” se va a necesitar conocer en profundidad los principios y funcionamiento de Scrum y tratar de encontrar un punto medio, que beneficie a ambas partes y permita efectivamente que el contrato responda a los principios ágiles. El manifiesto agile valora la colaboración con el cliente por encima del contrato, pero siempre será necesario establecer las reglas con el cliente, de forma que se aumenten las probabilidades de éxito.
Dos de las opciones que sugiero valorar  son:
1. Contrato de sprint
Estructura: en realidad, no es un contrato comercial, sino simplemente un acuerdo entre el Product Owner y el equipo para un sprint.
Alcance: el equipo acuerda esforzarse al máximo para entregar el conjunto de características acordadas (alcance) con un estándar de calidad definido al finalizar el sprint. El Product Owner acuerda no cambiar las instrucciones antes de finalizar el sprint.
Riesgo: un proyecto de Scrum puede ser visto como una serie de miniproyectos con parámetros fijos, tiempo (duración del sprint), alcance (backlog del sprint),  calidad ( definition of done), y  gastos (tamaño del equipo × duración del sprint).
2. Money for nothing. Changes for free
Estructura: este contrato funciona con los proyectos de software ágiles porque casi no hay trabajo en progreso. Al final de cada sprint, la funcionalidad está acabada o no se empezó. El trabajo es del tipo time & materials con un objetivo de coste, a menudo con la intención de que el proyecto no use todo el presupuesto. Una vez se entrega cierta cantidad de funcionalidad, el cliente puede darse cuenta de que ya se ha entregado una cantidad suficiente de valor de negocio y que no se necesita más desarrollo, por lo que puede cancelar el proyecto. Hay un gasto de cancelación que es igual a la ganancia restante que faltaba.
Alcance: puede cambiar. Las características planificadas sin implementar se pueden reemplazar por otras historias del mismo tamaño. Las características adicionales cuestan más.
Riesgo: compartido. Ambas partes están interesadas en completar antes el proyecto. El cliente obtiene costes inferiores y el proveedor, un margen más amplio.
Referencias.
Bermejo, M. (s.f.) Contratos ágiles. FUOC. Fundación para la Universitat Oberta de Catalunya. Recuperado de: https://www.exabyteinformatica.com/uoc/Audiovisual/Produccion_multimedia/Produccion_multimedia_(Modulo_5).pdf