Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Empirismo. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Empirismo. Mostrar todas las entradas

miércoles, octubre 12, 2016

Dueño de Producto, usted ha sido invitado a la Retrospectiva


El Dueño de Producto, ¡ese ilustre olvidado!

Me preguntan por interno si este personaje debe asistir a la ceremonia de inspección y adaptación. Es una buena pregunta, teniendo en cuenta que hay quienes recomiendan que no sea así o que la participación del Dueño de Producto es opcional en la Retrospectiva.
No hay ninguna buena razón por la cual el Dueño de Producto no deba estar en la retrospectiva. Desde la misma guía de Scrum ya sus autores sugieren que debería participar:
"La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint".
Y ya sabemos que el Equipo Scrum se compone de Scrum Master + Desarrolladores + Dueño de Producto.
Pero más allá de esto, no concibo cómo, sin la participación del Dueño de Producto en esta reunión, sea posible que el equipo en pleno se inspeccione a sí mismo para luego crear un plan de mejoras que nunca estará completo sin la intervención de este actor. Por ejemplo, ¿cómo mejorar la comunicación con el entorno del negocio? El resto del equipo no podría definir la mejor estrategia para lograrlo en ausencia del Dueño de Producto.
Algunos dirán que se define la estrategia en la reunión y luego se la comunican al Dueño de Producto, eso simplemente extendería la retrospectiva, con el riesgo de que él "tumbe" las acciones a realizar por cualquier motivo válido.

  • ¿Y qué pasa si hay problemas con la salud del backlog? 
  • Problemas con la definición de los criterios de aceptación de las historias de usuario.
  • ¿El equipo conoce cómo los usuarios realmente usan el producto?
  • Problemas con la aceptación del incremento sprint tras sprint.
  • ¿El equipo conoce la visión completa del producto, la estrategia de implementación y cómo lo quieren los usuarios?
  • ¿Y qué ocurre si el Dueño de Producto no está el tiempo suficiente con el equipo para responder sus preguntas y clarificar las características del producto? O para proporcionar retroalimentación efectiva.

En fin, muchas son las razones para que el Dueño de Producto sí esté en la reunión. Estas que mencioné son solo algunas. En breve, el Dueño de Producto es protagonista principal en esta ceremonia.
Ahora bien, se me ocurren algunas malas razones por las cuales no debería asistir. Las mencionaré brevemente y estableceré alguna razón sólida para no tenerlas en cuenta:
Lo aburrimos con minucias técnicas. Una retrospectiva no es para profundizar en los detalles de lo puramente técnico.
El equipo de desarrollo y el Scrum Master son de un proveedor y el Dueño de Producto es del Cliente. Entonces dónde queda la confianza y, por consiguiente, la transparencia. Si estamos pensando así, todavía nos hace falta mucho de la Cultura Ágil y de liderazgo. En cualquier caso, esta práctica reduciría mucho la transparencia, necesaria a todas luces en un entorno ágil.
No tiene tiempo. ¡Este es, precisamente, un tema a abordar con él en la retrospectiva!
Así lo hemos hecho aquí y nos funciona. Esta es interesante. ¿Y qué tal si lo hacemos de la otra forma (qué si asista) y vemos la diferencia? ¿Mejoramos o empeoramos? Seguramente será lo primero.
Esta última es la típica cuestión que se enmarca en el empirismo, es decir, aprendemos de la experiencia, como todo en Scrum. Algo que se resume también en eso de "usar o hacer lo que te funciona". Sin embargo, las razones que expuse al principio y muchas otras precisamente nos han enseñado los beneficios de la presencia del Dueño de Producto en la ceremonia.
Entre otras, pero todas absolutamente son "malas" razones.
En definitiva, el Dueño de Producto debería (sí debe) asistir a las retrospectivas, así que adelante. Si como Scrum Master te sugieren que el Dueño de Producto no debe estar en la reunión, te enfrentas a una sintomatología que te indica que falta algo de la base, los valores y principios ágiles, la forma cómo racionalizamos, el fondo de la cultura ágil, más que del mismo Scrum y otras prácticas. --- ¿Y tú invitas al Dueño de Producto a tus retrospectivas? Déjamelo saber en el foro.


sábado, julio 30, 2016

Un vistazo a la guía de Scrum

¿Hace cuánto leíste por última vez la guía de Scrum? Es bien sabido que a medida que tu experiencia y conocimientos crecen, tu forma de ver (leer) algo cambia respecto a la vez anterior. Quizás aprendas algo más, quizás seas capaz de visualizar o entender algo que antes no habías percibido o entendido.

Aprovechando la revisión de la que fue objeto la guía por parte de sus autores y de que había que traducir esa actualización, realicé una revisión exhaustiva tanto de la versión en inglés como de la versión en español en la que tuve la oportunidad de trabajar por primera vez en 2013. (Para conocer los cambios introducidos a la guía, ve a: http://www.gazafatonarioit.com/2016/07/revision-la-guia-de-scrum.html)

Con tres años más de experiencia y conocimiento en Scrum y temas relacionados, me tomé la libertad de actualizar la Gramática y redacción del documento y también algunos asuntos de fondo que me hacían ruido desde hacía mucho tiempo respecto a la versión original de la guía en inglés.

Con todo esto, aproveché también para “repasar” lo que dice la guía, para mirarla más a fondo y decidí traer aquí una lista, arbitraria por demás, pero de todo mi gusto, de algunos puntos que quiero resaltar. Son los siguientes:
“Scrum no es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas”.
Es impresionante la cantidad de personas, equipos y organizaciones que solo “aprenden” o quieren aprender Scrum, como si con eso fuera suficiente para hacer todo el trabajado que se les viene por delante. La lista de proceso, técnicas, marcos de trabajo y prácticas que podemos y deberíamos usar con Scrum es extensísima, no voy a elaborarla aquí, pero lo que sí es cierto, lamentándolo mucho por quienes no lo han visto, es que Scrum solo no es suficiente.
“Scrum muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas de desarrollo de modo que podamos mejorar”.
Scrum se basa en la teoría empírica  de control de procesos. Esto quiere decir básicamente que aprendemos de la experiencia. Scrum nos permite visualizar la eficacia las prácticas que usamos las personas, los equipos y las organizaciones y nos permite inspeccionarlas continuamente y adaptarlas y adaptarnos de acuerdo con los distintos escenarios circundantes.
“El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto”.
Todavía me encuentro con muchos equipos y organizaciones que no terminan de integrar al negocio, vía el Dueño de Producto, en sus equipos. Y muchos menos son los Dueños de Producto que realmente actúan como tal. El muy comentado pero pocas veces entendido “backlog” de producto sigue siendo gestionado por el equipo y muchas veces solo por el Scrum Master o por alguien más que no es ninguno de los roles propuestos en la guía.
“El Scrum Master es el responsable de asegurar que Scrum se entienda y se adopte. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum”.
Usar Scrum no nos hace ágiles, eso lo tenemos claro muchos. Pero muchos no tienen claro que si vamos a usar Scrum como marco de trabajo ágil, debemos ajustarnos a las reglas enumeradas en la guía. Estas reglas condensan la experiencia de muchos años de trabajo, sobre todo en proyectos de software, de los autores y de muchos otros en la industria. Conjuguemos esta observación con la del primer punto más arriba.
“La Planificación de Sprint tiene un máximo de duración de ocho horas para un Sprint de un mes. Para Sprints más cortos el evento es usualmente más corto”.
En las versiones anteriores es español aquí decía que el tiempo de las reuniones era proporcional a estas ocho horas para sprints más cortos. En ninguna parte de la guía original en inglés dice así, de tal forma que la actualicé en este sentido.
“Al finalizar la Planificación del Sprint, el Equipo de Desarrollo debería ser capaz de explicar al Dueño de Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado”.
¿Cuántos de los equipos en los que has trabajado, en los que eres Scrum Master, miembro del Equipo o Dueño de Producto, hacen esto? De hecho, muchos quieren terminar lo más rápido posible la planificación para ponerse a trabajar pero nadie es capaz de explicar cómo van a trabajar para lograr la meta trazada del Sprint.
“El objetivo del Sprint puede representar otro nexo de unión que haga que el Equipo de Desarrollo trabaje en conjunto y no en iniciativas separadas”.
Es más, muchas veces los equipos no establecen un objetivo más allá de aquel que indica el número de historias de usuario a construir en el sprint. La meta del Sprint debería ser algo más de Valor para el Dueño de Producto y, por ende, para el negocio. Dejaré este asunto de la meta del sprint para otro artículo pero además de pensar en las características o funcionalidades a implementar siempre es bueno pensar en las razones para llevar a cabo la iteración. Bien sabemos que metas efectivas nos sirven para probar o demostrar que nuestras ideas funcionan, para fomentar el trabajo en equipo, para reducir o eliminar un riesgo específico o para proporcionar mayor valor entregado al negocio.
 “El Equipo de Desarrollo o los miembros del equipo a menudo se vuelven a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar, o replanificar el resto del trabajo del Sprint”.
La expresión clave aquí es “a menudo”. Hacer otras cosas después de la reunión diaria puede hacernos perder foco y, por consiguiente, productividad y puede alejarnos de la consecución del objetivo del sprint. Por ejemplo, en la reunión diaria no hablamos de las soluciones a los impedimentos, entonces es buena idea tener reuniones específicas sobre estos asuntos justo después de aquella.
“El Scrum Master se asegura de que se cumpla la regla de que solo los miembros del Equipo de Desarrollo participan en el Scrum Diario”.
Sigo viendo mucho de comando y control en la reunión diaria. ¡El seguimiento diario, dicen algunos! Esta es una reunión de coordinación, de planificación, es precisamente “una reunión clave de inspección y adaptación”. Cualquier otra cosa que se requiera hacer con el equipo, debe ser en otra reunión especial, no en esta.
“Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint. Basándose en esto y en cualquier cambio a la Lista de Producto durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor”.
La Revisión de Sprint no es solo para hacer la demostración del incremento de producto terminado. Y puesto que a esta reunión asisten o pueden asistir interesados clave en el producto, es una oportunidad única para discutir lo que viene a continuación en el proyecto.
“Una Lista de Producto nunca está completa. Mientras el producto exista, su Lista de Producto también existe”.
“Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente”. ¿Hace falta decir algo más?
“Los elementos de la Lista de Producto tienen como atributos la descripción, el orden, la estimación y el valor”.
El valor para el negocio. Noten además que hablamos de “los elementos de la lista”, no son solo historias de usuario, como muchos erróneamente creen y manifiestan.
“Scrum no reconoce subequipos en los equipos de desarrollo, no importan los dominios particulares que requieran tenerse en cuenta, como pruebas o análisis de negocio; no hay excepciones a esta regla”.
No existe tal cosa como “ellos y nosotros”, somos un único equipo indivisible, somos una unidad morfológica (orgánica) y funcional y actuamos como tal. Valoramos las habilidades y fortalezas de cada uno de los miembros de esta unidad, pero hacia el mundo exterior somos El Equipo.


Y bueno, como dice mi amigo y colega Jorge Abad, hasta aquí estas reflexiones, viscerales por demás, sobre la guía de Scrum. Los invito a que la descarguen y vuelvan a leerla y a que nos cuenten en el foro cuáles son sus puntos favoritos de la guía, con cuál no están de acuerdo, cuál cambiarían, etcétera.

También pueden descargar la guía de:

Guía de Scrum en español

jueves, junio 16, 2016

Purga ágil de producto

Nuestro backlog del producto puede no tener una “buena salud”. Es decir, puede contener elementos que lo oscurezcan o que disminuyan su transparencia. Por lo general estos elementos tienden a ir hasta el fondo del backlog y muchas veces no son detectados hasta que es muy tarde en el proyecto, trayendo como consecuencia la extensión innecesaria del esfuerzo de desarrollo y la desmotivación del equipo debido a la gran capacidad energética que sus miembros invierten en estos elementos de poco o ningún valor para el producto y para el negocio.
Una de las técnicas que podemos aplicar al backlog y, por consiguiente, al producto, es esta de la purga del producto. Los detalles de cómo hacerlo lo encuentran en mi artículo en Pulse de LinkedIn:

miércoles, junio 01, 2016

Los Pilares de Scrum

Los Pilares de Scrum. Clic en la imagen para ampliar.

Sin ninguna duda, para que Scrum sea eficiente y efectivo, cada uno de estos pilares debe estar en pie, deben promoverse desde las personas y los equipos hasta toda la organización y deben apoyarse sin restricciones. Sin uno o más de estos pilares, cualquier implementación de Scrum está condenada a un cataclismo anunciado.

Déjame saber en el foro como te ha ido con la puesta en macha de estos pilares mientras implementas Scrum en tu organización.

Puedes descargar el PDF de la imagen en alta resolución haciendo clic aquí.

O me la solicitas a mi correo: lucho.salazar@gmail.com.



martes, enero 19, 2016

Agilidad: algunas características intrínsecas

Infografía: Agilidad 101. Clic en la imagen para ampliar.

AGILIDAD

La habilidad de las personas, equipos y organizaciones de crear Valor a la vez que promover y responder al cambio para tener éxito en un entorno incierto.

Algunas características intrínsecas a la Agilidad son:
RETORNO DE LA INVERSIÓN

Ágil proporciona ROI en forma de beneficios cualitativos como el mejoramiento de la moral del equipo y principalmente ROI en la forma de beneficios cuantitativos, expresado en términos económicos, mediante la entrega continua y frecuente de soluciones con Valor.
MARCOS DE TRABAJO

Estamos descubriendo formas mejores de desarrollar software. Los marcos de trabajo ágiles son iterativos e incrementales y de Valor. Scrum y otros métodos y prácticas ágiles se basan en la teoría empírica, es decir, aprendemos de la experiencia. El propósito final de las prácticas ágiles no es tanto el hacer como el encontrar formas mejores del hacer.
TIEMPO

Entregamos productos frecuentemente, incluso todos los días. Las iteraciones son períodos muy cortos de tiempo que finalizan con la entrega de productos que generan Valor del negocio.
DOCUMENTACIÓN

Valoramos más las soluciones en uso que la documentación exhaustiva. La meta de ágil es encontrar el balance adecuado entre la documentación y la comunicación cara a cara. La documentación es una parte importante de todo producto, pero la documentación exhaustiva como tal no asegura el éxito de un proyecto. De hecho, aumenta la probabilidad de fracaso.
INNOVACIÓN

En la forma de mejoramiento continuo.  Las prácticas ágiles nos permiten encontrar formas innovadoras para crear productos y servicios mejores, más baratos, más livianos, más rápidamente y de una forma más conveniente y personalizada para nuestros clientes.
PERSONAS

Valoramos más las personas y la comunicación cara a cara entre las personas. Lo más importante en el ecosistema ágil somos las personas. Los equipos son autoorganizados y nuestra mayor prioridad es satisfacer al cliente.
MEDICIÓN


Las mediciones se hacen mediante observación directa en el lugar de trabajo, el Gemba, y medimos la realidad de la organización y de los proyectos con el ánimo de encontrar continuamente opciones de mejoramiento. Fomentamos la retroalimentación continua en todas las direcciones. 

jueves, enero 14, 2016

Nexus, el exoesqueleto de desarrollo a escala con Scrum


Scrum es un marco de trabajo para desarrollar sistemas complejos. Como dice la Guía Oficial, es liviano, fácil de entender, pero quizás, después de un tiempo, con el acompañamiento adecuado, hayas sido capaz de llegar a dominarlo y tú y tu organización se encuentren en el camino de las entregas frecuentes de software con valor, del mejoramiento continuo vía retrospectivas, con equipos autoorganizados, donde las decisiones frecuentes de adaptación se basan en el conocimiento ganado vía la inspección y la experiencia. Después de todo, la autoorganización y el empirismo constituyen la doble hélice del DNA de Scrum.
Pero ¿cómo ha sido tu experiencia al querer dar el siguiente paso: escalar Scrum? Quizás has intentado SAFe, LeSS o el soberbio modelo de Spotify, para mencionar solo algunos de los ejemplares que prometen llevar con éxito la agilidad a toda la organización. ¿Cómo ha sido tu experiencia al intentar que múltiples equipos trabajen en un producto? O Quizás múltiples equipos trabajando en productos individuales o en una suite de productos integrados. ¿Qué tal toda la organización tratando de adoptar Scrum y otras prácticas ágiles? ¿Acaso has intentado una transformación organizacional de 180º hacia Ágil? Una que sea sostenible, es decir, un cambio que sea capaz de conservarse y reproducirse sin necesidad de apoyo o intervención externa.
Nexus™ – Un Exoesqueleto para 3-9 Equipos Scrum.
De eso se trata Nexus, “un marco de trabajo que consiste en roles, eventos, artefactos y técnicas que vinculan y entrelazan el trabajo de aproximadamente tres a nueve equipos de Scrum que trabajan en una sola Lista de Producto para construir un Incremento Integrado que cumpla un objetivo”.
Para entender Nexus, primero debemos entender de qué se trata el desarrollo de software a escala con Scrum: cualquier implementación de Scrum donde múltiples Equipos Scrum construyen un producto o un conjunto de características de un producto en uno o más Sprints o, también, cualquier implementación de Scrum donde múltiples Equipos Scrum construyen múltiples productos relacionados o conjuntos de características de productos en uno o más Sprints.
En el caso de múltiples equipos construyendo un producto, este tiene una Lista de Producto manejada por un Dueño de Producto y los equipos en conjunto crean un Incremento Integrado en cada Sprint por lo menos. Este Incremento se convierte en el foco y objetivo de todos los equipos dejando de lado el énfasis en el incremento individual que produce cada equipo en un Sprint.
Es precisamente la integración del trabajo (o la ausencia de esta), uno de los mayores obstáculos que encuentran las organizaciones al escalar Scrum o al tratar de implementar Scrum a gran escala. Para sobrepasar este impedimento, Nexus aumenta Scrum de manera orgánica, es el siguiente paso natural. Si has entendido y estás practicando Scrum, Nexus te parecerá más que familiar. Este nuevo marco de trabajo adiciona un nuevo rol, el Equipo de Integración Nexus, responsable de asegurar que se produzca el Incremento Integrado, es decir,  el trabajo combinado de un Nexus que adhiere a la definición de “Terminado”.
Además, Nexus adiciona un conjunto de eventos que, en general, extienden los eventos de Scrum o los reemplazan, lo mismo que un artefacto adicional:
Construido sobre los principios, valores y fundamentos de Scrum, el marco de trabajo Nexus:
  • Crea rutas de comunicación
  • Extiende y profundiza los mecanismos de inspección y adaptación
  • Fomenta la transparencia continuada
  • Depende de la inteligencia hacia arriba, en este caso, del Equipo de Integración Nexus hacia los equipos individuales que forman el Nexus.
Con mis grandes amigos Leonardo Agudelo y Jorge Abad tuve la oportunidad de traducir al español la Guía de Nexus, la misma que ya está publicada y disponible para descarga inmediata en:
Nota: este artículo se publicó por primera vez en diciembre de 2015 en Pulse de LinkedIn:
https://www.linkedin.com/pulse/nexus-el-exoesqueleto-de-desarrollo-escala-con-scrum-luis-antonio
------------------------------
Actualización 20150406:
Esta noche estuve hablando de Nexus con amigos de la Comunidad Ágiles Colombia en Medellín. Aquí está la presentación:

------------------------------
Actualización 20151007 (Ágiles 2016):
Hoy estuve hablando de Nexus con amigos de la Comunidad Ágiles Latinoamérica en Quito, durante las Jornadas Ágiles Latinoaméricanas - Ágiles 2016, una experiencia gratificante. 
Aquí está la presentación actualizada:



miércoles, octubre 28, 2015

El enfoque Iterativo e Incremental, ¡una vez más!


El enfoque Iterativo e Incremental, ¡una vez más!
Mucho se habla de esto, de hecho iba a titular este artículo: “Todavía otra lección más sobre el enfoque iterativo e incremental para construir productos (de software)” pero entonces pensé en cambiar ligeramente la dirección del tema… Pero no tanto.
Iterativo e incremental son de esos principios que pueden resultar artificiosos para quienes intentan aplicarlos por primera vez. Su interpretación se  presta a confusiones y a desacuerdos y finalmente los productos que surgen de los así llamados ‘proyectos iterativos e incrementales’ terminan siendo una colcha de retazos, pedazos de funcionalidades que no se integran bien entre sí y que terminan ocasionando más problemas al usuario de los que intentan resolver.
En breve, ‘iterativo’ quiere decir ‘en períodos cortos de tiempo’. El término clave es ‘cortos’. ¡De menos de un mes, gritamos a los cuatro vientos los agilistas! Durante este período se diseña y se construye, en el sentido extenso de la expresión ‘diseñar y construir’, una parte del producto que llamamos ‘incremento’. Pero no es cualquier parte del producto la que se construye. Sin embargo no voy a detenerme mucho en ello. Pueden consultar más sobre ‘Iterativo e Incremental’ aquí, gracias a Javier Garzás, o en cualquiera de estos lugares:
O algunos de los míos:
Entre muchos otros. Y no puedo terminar esta breve presentación del tema sin referirme a esa imagen que ya se está convirtiendo en icónica y que ilustra muy bien este par de conceptos: se trata de la imagen de Henrik Kniberg, actualizada:

Pero a dónde verdaderamente quiero llegar esta vez es a este asunto del ‘Incremento de Valor’, ¿qué quiere decir eso realmente? Así que empecemos de nuevo:

El Nuevo Nuevo Enfoque Iterativo e Incremental y de Valor

Resuelta la trama de ‘Iterativo e Incremental’, lo que queda es entender qué significa ‘producto de Valor para el cliente o usuario’, qué significa ‘Desarrollo de producto dirigido por el Valor’. Vamos a ver si lo logramos entender:
En este enfoque, conocido también como ‘desarrollo guiado por el valor’ o VDD, por sus siglas en inglés, el cliente o usuario juega un papel primordial:
  • Es el cliente o usuario del producto quien determina o establece su valor, no el equipo de desarrollo
  • Es el usuario o cliente quien solicita el producto, o esa porción del producto, es decir, fue ese usuario o cliente quien priorizó el desarrollo de ese incremento en ese momento del tiempo (del proyecto)
  • El incremento resuelve un problema pequeño o parte de un problema grande al usuario
  • Le permite obtener retorno de la inversión que está haciendo (ROI): reduce los costos para el negocio o aumenta las ganancias… ¡o ambas cosas a la vez! En últimas, al entregar el producto hay o se genera una compensación para el usuario, además de la satisfacción aumentada y de la felicidad recargada, no solo de él como receptor de un objeto de valor, sino de todo el equipo de desarrollo y, por qué no, de todos los demás interesados, dado el logro de objetivos.

Foto de FreeDigitalPhoto.Net
  • Varias o muchas personas se benefician de inmediato con el producto (con su uso), ya sea porque lo están usando directamente (usuarios, clientes) o porque otros lo usan (patrocinadores, otros interesados, alta gerencia, etcétera)
  • El producto está diseñado para humanos, sus componentes hacen resonancia unos con otros e impactan el modus vivendi de las personas, aunque solo para mejorarlo
Human-driven development o HDD –Desarrollo de Software Para Personas. Foto de FreeDigitalPhoto.Net 
  • El riesgo del proyecto, inherente a cualquier tentativa de construcción de software, se reduce dramáticamente luego de las primeras entregas. Si hemos de fallar, que sea rápido, en porciones pequeñas y muy barato. A partir de allí, el ascenso hacia el logro de los objetivos es vertiginoso y siempre positivo.
  • El crecimiento del producto es orgánico, se parte de un mínimo producto viable o ‘mercadeable’ (MVP por sus siglas en inglés) y el producto completo va creciendo alrededor de este MVP, en entregas sucesivas y constantes. Y ya que llegamos a este apartado, olvidémonos del “viable” en el MVP, la V ahora es por Valor, como en Mínimo Producto de Valor. Recordemos que este MVP es el primer objeto con el que el cliente o usuario podrá interactuar, así que el impacto a conseguir debe ser máximo, debemos hacer que se convierta en un objeto de deseo. A propósito de deseo, entonces en vez de llamarlo MVP, nombrémoslo MDP, por las siglas en inglés de Mínimo Producto Deseable. Es un juego de palabras, apenas para mi Gazafatonario, pero ayudan a entender lo que queremos realmente con esta generación de valor desde las primeras de cambio.
  • Se disminuye considerablemente la incertidumbre, tanto la del proyecto como un todo, como la del producto que se empieza a usar. Esto ocurre porque con cada entrega el equipo conoce mejor a su usuario y aprende mucho más rápido de sus necesidades y ambiciones. A la postre, el equipo construye el software para aprender y medir el impacto del uso real del producto. Después de todo, el proceso de creación de conocimiento se acelera si ellos entregan rápido un conjunto mínimo de elementos del producto priorizados por los objetivos que el cliente quiere alcanzar.
No son las únicas condiciones, si acaso algunas de las más importantes. En cualquier caso, la próxima vez que te soliciten un plan de trabajo para un proyecto, ya sea a mediano o a largo plazo, ten el coraje de responder: ¿quieres un plan a mediano/largo plazo o Valor en términos cortos?
Nota: este artículo se publicó originalmente en Pulse de LinkedIn en el siguiente enlace: https://www.linkedin.com/pulse/iterativo-e-incremental-luis-antonio-salazar-caraballo

miércoles, octubre 07, 2015

Principios para Frameworks de Procesos de Software Efectivos

Septiembre 28 de 2015, por Scott Ambler



El framework de decisión de procesos de Disciplined Agile se guía por los siguientes principios:
  1. Elegir es bueno y tomar decisiones informadas es mejor. Cada equipo es una colección única de individuos que enfrentan situaciones únicas dentro del contexto de una organización particular. Un único proceso no sirve para todo. Para facilitar la elección, el framework DA soporta varios ciclos de vida de entrega y es un proceso dirigido por metas. Y más importante, el framework DA describe las compensaciones involucradas con una gran variedad de prácticas ágiles y no ágiles que permiten a las personas a tomar decisiones inteligentes relacionadas con prácticas para adoptar la situación actual que enfrentan.
  2. Optimizar el todo. El framework DA cubre todo el ciclo de TI, mostrando como encajan todos sus elementos. Si los equipos no entienden el entorno de los procesos, corren el riesgo de optimizar localmente sus propios procesos causando detrimento en el todo. Por ejemplo, el equipo de manejo de datos puede tener su propio proceso basado en estrategias DAMA (Gestión de Datos, por sus siglas en inglés) tradicionales, mientras que el equipo de entrega puede tener el proceso basado en los principios del Manifiesto Ágil y el equipo de operaciones puede tener su proceso basado en ITIL. Las cosas así, el proceso general se vuelve inefectivo porque estas tres estrategias individuales se contradicen y se degradan unas con otras cuando se combinan.
  3. Cada equipo es dueño de su proceso. Los equipos y las personas miembros de esos equipos deben ser libres de mejorar la forma en que trabajan basados en su aprendizaje en el tiempo. En el parloteo ágil decimos que estos equipos “son dueños de sus procesos”.
  4. Mejorar continuamente. Personas, equipos y organizaciones deben esforzarse por aprender y mejorar continuamente la forma en que trabajan. El framework DA incluye la meta de proceso Mejorar el Proceso y el Entorno del Equipo, la cual describe opciones para hacer exactamente lo que esto implica. También tiene un apartado explícito para el Mejoramiento Continuo de procesos que describe las estrategias para compartir mejoras entre equipos, incrementando de esta forma la velocidad de los esfuerzos de mejora de procesos de su organización.
  5. Promover y apoyar el cambio en el proceso. Los departamentos de TI son sistemas adaptativos complejos. Una implicación de esto es que cualquier mejora que un equipo haga puede cambiar la forma en que trabajan con otros equipos, motivando mejoras de proceso dentro de esos equipos. Estos cambios a su vez pueden motivar mejoras dentro de otros equipos y así sucesivamente. Los equipos ágiles disciplinados son conscientes de su estatus corporativo y entienden que necesitan trabajar con otros equipos para ayudarlos a entender y a adoptar nuevas innovaciones y a prepararse para que otros los ayuden a hacer lo mismo.
  6. Resultados repetibles son mucho más importantes que los procesos repetibles. Los equipos efectivos se enfocan en producir resultados repetibles, tales como entregar software de alta calidad que cubra las necesidades de los interesados de manera efectiva en tiempo y en costo. Debido a que cada equipo se encuentra así mismo en una situación única, para ser más eficientes necesitan seguir un único proceso personalizado que refleje esa situación. Ese “único proceso” puede constar de un ciclo de vida relativamente estándar y de prácticas comunes tales como la ideación de la arquitectura, pruebas de regresión de la base de datos y muchas otras (asumiendo que estas prácticas también se personalicen para reflejar esa la situación). A cada equipo en su organización se le debe permitir seguir su versión del proceso, idealmente compartiendo componentes similares del proceso, definidos por un framework común de proceso, para lograr los resultados requeridos.
  7. El empirismo es mucho más importante que la teoría. Observar qué tan bien funciona una técnica en la práctica y, más importante aun, observar el contexto de las situaciones en las que (no) funciona, es de mayor valor para los practicantes que las teorías o la prognosis sobre lo que debería funcionar. La teoría tiene su lugar, pero es una prima pobre del empirismo. El framework DA se desarrolló originalmente basado en observaciones de docenas de organizaciones en todo el mundo y ha evolucionado desde entonces basado en el aprendizaje de muchas otras. Además está siendo respaldado por investigaciones en curso de nuestra industria.


Los departamentos de TI son sistemas adaptativos complejos únicos. Cualquier persona que trabaje en un ambiente así necesita un framework de proceso que sea lo suficientemente flexible como para que aborde el amplio rango de situaciones que enfrentan sus equipos. El framework de decisión de procesos DA es liviano a la vez que lo suficientemente flexible para soportar el escalamiento tanto a nivel táctico como estratégico.

-----
Nota del traductor, o sea yo:

Este artículo se publicó originalmente en inglés por Scott Ambler, bajo el título de “Principles for Effective Software Process Frameworks” que pueden encontrar en: http://www.disciplinedagiledelivery.com/software-process-framework-principles/

Publicado con permiso del autor.