Así no se hacen las cosas por Ernesto Kiszkurno

Primero una definición de backlog coupling  extraída de aquí : "if a large number of items in the backlog of a digital product team require a corresponding backlog item to be raised in another team, then productivity and responsiveness suffer enormously. Backlogs get chained across the organisation, each being prioritised according to a different system. Tasks acquire big red ‘blocked’ stickers on kanbans, stakeholders get angry, the shared service providers react as best they can - usually responding to the loudest voice." Si extrapolamos la idea en personas, pasa algo parecido. Cuando tenemos una tarea en nuestra lista que depende de que alguien más haga alguna otra tarea, esas tareas están acopladas.  El problema de este acoplamiento es claro: "The tasks that had to wait for another team were 10-12x slower in elapsed time. So dependencies have a real significant impact." En el caso del software, la solución a esto es algo más compleja (y pueden le...

Así como los grandes proyectos de consultoría se "agilizaron", para pasar de años o meses a semanas o días, o los grandes data warehouses cedieron espacio a herramientas más pequeñas pero que dan poder de análisis a los usuarios finales y "agilidad" para hacer más rápido las cosas, el mundo de las grandes desarrollos de software y productos va a ceder espacio también . ¿Por qué desarrollar aplicaciones complejas, si podemos lograr lo mismo mediante microservicios y APIs? Son más fáciles entender y rápidos de evolucionar. Podemos reusarlos como building blocks para construir soluciones más grandes o complejas. Podemos usarlos internamente y externamente. Podemos combinar múltiples nubes. ¿Alguien no cree que esto sea así? Lo podemos convencer mostrándole el crecimiento que vienen teniendo ( ProgrammableWeb ). O el ecosistema de tecnología en el que nos movemos actualmente. Las APIs y micro servicios permiten el armado de verdaderos mashups  ...

En la parte 1 de una interesante saga llamada 5 Disruptions to Marketing , Scott Brinker me hizo notar un fenómeno interesante. Así como, cada vez más, el presupuesto de IT está siendo desviado a áreas de Marketing, las actividades de desarrollo (las más básicas obviamente) también estarían siendo tomadas por lo que Scott llamó "los ciudadanos del departamento de Marketing": "I use the phrase “citizens of the marketing department” quite intentionally, because these wizard-like capabilities that marketers are acquiring align with three big IT-democratization movements: CITIZEN DEVELOPERS — who use no-code or low-code tools to create web apps, mobile apps, interactive content, bots, and other kinds of functional experiences for staff, prospects, and customers CITIZEN INTEGRATORS — who use iPaaS and other workflow automation tools to create business processes on-the-fly, intelligently routing data and triggering activities across multiple teams CITIZEN ANALYST...

Les dejo un video de 5 minutos, en inglés, que responde a una pregunta que muchos se hacen hoy en día: "En qué consiste el diseño de la experiencia de usuario" Espero que les sirva. Seguimos pensando..

En nuestros días ya no es necesario recordar la importancia de la estrategia de testing a nadie. Todos somos conscientes de que es necesario pensar antes de actuar, si queremos cuidar los -siempre escasos- recursos y tiempos asignados a las pruebas. Lo que no es tan común es tener designado un rol de estratega de testing en el equipo, cuya responsabilidad principal es pensar (o cuestionar) la estrategia de cada prueba.  Un rol así es importante pues nos previene de un error recurrente en los equipos de prueba, el de quedarse enamorados de una estrategia "default" .  A veces encontramos una fórmula que nos sirvió en el pasado y la adoptamos como única para todo lo que viene. Está en la naturaleza humana hacerlo. El problema es que en testing tenemos la famosa paradoja del pesticida : los bugs se acostumbran a nuestros pesticidas, por lo que tenemos que cambiar. Seguimos pensando..

Qué alegría me dio leer este  artículo en el que se menciona como un aspecto clave de la transformación digital al cambio cultural que se requiere . Veo a muchos temerosos por los puestos que las máquinas van a arrebatarnos a nosotros los humanos, pero pocos pensando en el GAP de capacidades  que ya tenemos para afrontar la transformación. Rescato 6 frases del artículo: "The innovative approach required for digital disruption to succeed will instead come from talented people." “Employers can start encouraging a culture of collaboration through using technology in the right ways.” "One example is to give people the tools they need to free up their time from administrative or mundane tasks, so teams can collaborate on creative initiatives, customer-centric improvements to the business, and experimentation." “Working collaboratively will not just apply to working with other people, but having the skills to work effectively and efficiently with machin...

Les dejo un video de una charla TED de OK Go, unos tipos que hacen unos videos muy interesantes. La charla es acerca del proceso creativo que siguen para lograr sus videos. Me pareció interesante la noción de encontrar  una idea, en lugar de tener  una idea. Porque muchas veces se trata de encontrar una combinación nueva, de cosas viejas. También se mencionan, algo al pasar y rápido, otros conceptos que en estos días estamos aprendiendo a usar en esto de innovar que hace años ni se nos ocurrían: prototipos, planning iterativo, jugar, ... Llevando la atención hacia otro lado, ¿vieron la estructura y forma de presentar de la charla? Sin PowerPoint, sincronización total entre el orador y el grupo que hace de apoyo con láminas. También ahí hay cosas para rescatar, no? Me encanta cuando encuentro gente que puede tener este nivel de profesionalismo tanto en la fase planificación como en la de ejecución. Seguimos pensando..