bitácora de uno

Hace ya años que empezamos a seguir la metodología Scrum en el equipo de desarrollo que coordino para hacer Osmius, un producto complicado de desarrollar desde el punto de vista de ingeniería, y con el objetivo de ser fácil de entender y de utilizar por el usuario.

Como dice Medinilla, Scrum no es la bala de plata, no soluciona problemas ajenos a la metodología, pero es cierto que en un equipo de gente medianamente responsable y motivada, debe servir para dos cosas:

• Mejorar la eficiciencia individual; y por tanto la del equipo
• Mejorar la visibilidad de lo que se hace: A los demás y a nosotros mismos

En mi caso, que me gusta construir, además y gracias a lo anterior se mejora la experiencia; disfruto más vaya.

Es por todo esto, que cada vez pienso más que podría crearse una empresa cuyos procesos de negocio - la producción, la operación, el marketing, la gestión del conocimiento, la gestión de los recursos, el community management, y el sursum corda - puedan gestionarse de igual manera con metodologías ágiles. La empresa Scrum que se diría.

Para que no me consideréis naive tan pronto, o no tanto, también es verdad que pienso que estas prácticas no son para todas las empresas o para todos los equipos o para todas las personas, pero sus razones habrá, pues está claro que la productividad aumenta cumplidos unos requisitos.

Bajando de las ramas y para quien esté interesado Ángel Medinilla ha vuelto a poner gratinos al montón de lo Ágil traduciendo junto a otros, el texto “Kanban vs Scrum”.

Ahora Kniberg ha sacado un nuevo trabajo comparando Scrum con una aproximación nueva que se está realizando a los procesos de desarrollo: Kanban. Kanban no es nuevo para nada, surge como todas estas herramientas y disciplinas en el seno del sistema de producción de Toyota, “la máquina que cambió el mundo”.

Más | Kanban vs Scrum en castellano en Presión Blogosférica

Si lees de vez en cuando estas líneas sabrás que cierto ser llamado Enrique tiene la costumbre de revolver archivos musicales por la Web para seleccionar una perla cada una o dos semanas.

Bien, a partir de ahora iremos a recoger los regalos de T.R.U.C a este mostrador:

Te Regalo una Canción

Via | Enriquillo

Ya viene siendo tradición quedar con el amigo Miguel para que nos ilustre con sus incisivos comentarios a cada versión del producto, dado que tanto él como Alberto (otro de sus secuaces) dominan aquello que se conoce como Monitorización de Sistemas.

En este caso vamos a mostrarle a él y a otros (estáis invitados quienes leéis este texto) un Osmius muy evolucionado en el que hemos acentuado la usabilidad - vamos que sea fácil de usar y de entender - y sobretodo queremos enseñarle el manejo de traps SNMP en particular y en general a Osmius como herramienta de Monitorización amplia. Capaz.

El plan es como sigue:

• Quedamos es mi casa a la hora de comer
• Mostramos la aplicación: Respaso de Conceptos y Puntos fuertes
• Vemos cómo funcionan los traps y cómo le damos una pana a los productos de HP o IBM o a Nagios, etc
• Tomamos notas de las cŕiticas y las sugerencias; Y sin rechistar
• Dejamos que la conversación vaya a donde tenga que ir

En esta ocasión el vino es Caliza 2006 D.O. de pago Dominio de Valdepusa

Empezaremos a eso de las 15:00 y nos solemos liar hasta las 20:00 en casa y sin límite fuera de casa.
Eres bienvenido/a con la sóla condición de que avises para la intendencia y que te guste o aguantes una reunión entre técnica y dispersa, de creativa a friki.

El otro día quedamos unos pocos de SoliMadrida charlar y debatir de modelos de negocio delante de unas raciones y unas mirindas y una de las tarjetas que me llevé a casa fue la de la foto.

Efectivamente han usado un Billete sencillo desechable de Renfe como soporte para la tarjeta de visita.
Ejemplo de idea original, que cumple su cometido y alguno más, y encima !llevada a la práctica!

Vía | Enreda

El Círculo de Bellas Artes ha abierto la terraza situada en el edificio de la calle Alcalá, 42 de Madrid.
Hace ya tiempo, no es noticia, pero merece la pena ir o repetir; por dos euros puedes subir a la planta 7 y además ver las exposiciones de los otros pisos (hay una de Win y Donata Wenders que nos ha gustado)

Más | Terraza Círculo de Bellas Artes

Curiosamente navegando por sitios web dedicados al diseño gráfico he llegado a “La filosofía Unix y el diseño” en el que se enumeran 17 reglas que no tienen desperdicio.

Os copio las 5 primeras que dejan claro como el agua cómo hacer determinadas cosas:

• Regla de Modularidad: Escribe partes simples, conectadas por interfaces simples.
• Regla de Claridad: ser Claro es mejor que ser ingenioso.
• Regla de Composición: Diseña programas para que se conecten a otros programas.
• Regla de Separación: Separa las reglas del funcionamiento; separa los interfaces de los mecanismos.
• Regla de Simplicidad: Diseña para la simplicidad; añade complejidad sólo donde sea estrictamente necesario.

¡Si es que está todo inventado !

Vía | Ale Muñoz de Sofá Naranja en “La filosofía Unix y el diseño”

Me reservo el derecho a romper estas reglas y cuantas me cruce si la ocasión lo requiere. Si quieres pido vez y te lo reservo también a ti.

Siempre he sido un defensor de la regla 80-20 que en el fondo no es regla sino concepto.

Para quien no se haya tropezado ya con ella, una forma de expresarla aplicándola a un producto software, cambie el lector el objeto a su antojo, sería que de todas las funcionalidades o características deseables del producto hay un 80% que le van a dar el máximo de amplitud, de clientes, de usuarios, y que el 20% restante te va a añadir pocos usuarios y que sin embargo el esfuerzo en implementarlo es mucho mayor.

Basándonos en esta regla, en el equipo de Desarrollo que coordino, priorizamos las funcionalidades más básicas y sencillas sobre las más específicas y complicadas. Así y a lo largo de los años, conseguimos un producto: Sencillo y Evolutivo.

Esto, en un proyecto complejo, no es ni bueno ni malo: Es necesidad.
Hay tanto que hacer que de esta forma evitas perderte en marasmos y haber echado medio año del trabajo del equipo en no sé qué característica que añadida.

Osea, una vez que tenemos las funcionalidades básicas, bien implementadas, con una buena ingeniería de componentes, usable y extendible, evitamos la especialización cuando es dolorosa y larga de desarrollar.

Además, en el caso de Osmius, estamos hablando de Software Libre, y esto quiere decir que tu modelo de negocio se basa en servicios, uno de los cuales es precisamente desarrollarle a alguien esa funcionalidad “Tipo 20%” de forma remunerada. Tienes una base, ese 80% o una parte de él, libre y dejas las personalizaciones o las tareas complicadas para quien las pague. Es un asunto de retorno de la inversión o de optimización del esfuerzo, que viene a ser lo mismo.

El problema es cuando se convierte uno en un Ochentacentista para todo. La regla anterior está bien, pero en ese 20% final está la diferencia entre la mediocridad y la excelencia, y cada una de ellas tiene su momento.

En el caso anterior queda claro que la mediocridad tiene su momento y su utilidad. Nos ha permitido priorizar y crecer de forma que mejoremos las posibilidades de éxito del proyecto, pero no podemos mantenernos en la misma línea en otros casos.

Rafael Nadal no deja de ir a por el 20% de las bolas en un partido de tenis. Va a por todas, busca el 99% de efectividad. Por eso es un top10.
Creo que de igual forma hay que comportarte ante otras situaciones como el desarrollo personalizado a un cliente, la preparación de una charla de venta importante sobre el producto, la redacción de una oferta o el soporte a alguien que tiene un problema.

Ahí no quieres ser mediocre, o yo no quiero o no me parece buena política para ser sostenible, rentable; no quiero dar un soporte al 80%, ahí no quiero ser del montón porque ser diferente es lo que vendo, pero igual que lo venden los demás. Qué comercial no dice de su producto X que los profesionales son los mejores, que si bli, que si bla.

Resumiendo: La regla 80-20 está muy bien, pero hay momentos y situaciones en que puede ser contraproducente, puede coartar buenas ideas y puede ser un impedimento para hacer algo realmente bien y que además sea lo que marca la diferencia en entornos competitivos en los que a menudo nos encontramos.

Detonante | Why the 80 20 rule is wrong
Detonante | For CIOs: 2010 will require new emphases on customers, revenue, external information, and a passion for rapid change