La masa, el ladrillo, la bota, el bocadillo…

Ha sido un año muy intenso. Tan intenso que he dejado mi pobre blog abandonado. Tenía tantas cosas que contar que no he podido contar nada. Ha sido el trabajo de Sisifo, no lo voy a negar, pero ha sido muy enriquecedor. Y parece que con Septiembre todo vuelve a empezar. El mito de Sisifo continua.

Angel Medinilla y un servidor solemos bromear sobre quien de los dos llevo la primera implementación ágil en este país. Entre los dos anda el juego. Sin duda hemos visto mucho del proceso que ha llevado a la popularización de Scrum. El primer post sobre agilidad en este blog es de 2006. Ya ha llovido. Ahora puedo hablar con algo de perspectiva.

Si este año ha sido tan intenso es por que la percepción de la empresas hacia las metodologías y las prácticas ágiles ha cambiado de manera clara. El boom ha sido grande, las metodologías ágiles han ganado tracción y se han popularizado. Han surgido cientos de telepredicadores, de certificaciones de dudosa utilidad, de interpretaciones de Scrum que pondrían los pelos de punta a los padres de la criatura, de gente que habla de agilidad y en su vida ha tirado una línea de código, y menos aun gestionado un proyecto, de telepredicadores, de empresas que han tirado CMMi a la basura y se han lanzado de cabeza a Scrum… sin duda no todo lo que se deriva de la popularidad de las metodologías ágiles ha sido bueno, aunque el balance es netamente positivo. Cada vez hay en España empresas ágiles más grandes o más granes empresas ágiles. Eso si ahora es más difícil separar el grano de la paja: todo el mundo es ágil, todo el mundo quiere se ágil, todo el mundo te quiere vender agilidad y pocos se dan cuenta de lo lejos que está el objetivo, de lo largo que es el camino.

Pero bueno voy a dejar de divagar y a centrar el tiro en lo que es el objeto de este post, contar a grandes rasgos, la experiencia vivida y adquirida durante este año en el que mi trabajo en lo relativo a Scrum a cambiado de manera radical. He pasado de llevar Scrum a equipos de entre 4 y 9 desarrolladores a llevarlo a empresas con entre 5 y 15 equipos de desarrollo. Un cambio radical.

El manifiesto ágil no es suficiente. Los empresas quieren ser ágiles, pero necesitan respuestas. No vale ponerse el modo gallego y decir depende. Las inercias son difíciles de romper. Tienes que dar respuestas, respuestas que a veces no están en los libros de gestión ágil de proyectos sino en libros de ingeniería del software. La gente quiere saber como organizar sus ramas de desarrollo, cómo evalúo mi backlog, cómo hago estimaciones, cómo hago mi sistema testable, como implemento testeo automatizado en sus múltiples variables, que hago para mejorar la calidad, por qué necesito testers, cómo evalúo las métricas, como mido el avance del proyecto, … y no las empresas no quieren especular, no vale decir eso de el manifiesto ágil dice que valoramos más los elementos… que no, que quieren respuestas, bibliografía y respuestas claras, tajantes y convincentes que puedan transmitir, punto. Y que nadie se olvide, Scrum está muy bien como marco, pero sus fundamentos y las técnicas básicas de calidad e ingeniería del software que lo sustentan llevan más de un cuarto de siglo descritas. Lee sobre gestión de proyectos básica.

Dos días de formación no te hacen ágil. Sin duda formarte en Scrum es una condición necesaria. Hay que formar a todos los miembro del equipo, sin que falte ninguno. No funciona eso de formar a los mandos intermedios y que estos lo transmitan. El motivo es claro, Scrum  cuando se lleva a la práctica y más a nivel empresarial está lleno de preguntas, y es necesario una bagaje importante en gestión de proyecto y un plus de credibilidad extra para responderlas. Los mandos intermedios que me encuentro, en su gran mayoría buenos profesionales, no tienen el conocimiento necesario sobre gestión de proyectos y carecen de la credibilidad extra que tiene alguien de fuera. Una formación de Scrum dura dos días, ni más ni menos. Pero no te capacita para hacer Scrum de igual manera que estudiar dinámica no te hace esquiador. Solo la práctica de Scrum te habilita a hacer Scrum y los golpes que te vas a dar, dependen de lo bueno que sea quien este esquiando a tu lado. Cuantos más golpes se haya dado tu Scrum Master, menos se va a dar tu equipo. Un curso de dos días no da margen para caerse lo suficiente. Las certificaciones están haciendo daño. Mucho Scrum Master de postal. No voy a cometer nunca más el error de simplemente formar a equipos de empresas. Si una empresa quiere solo formación sobre Scrum y cree que eso es suficiente para llevar Scrum a una organización, que llame a otro. Algunos incluso te dan una etiqueta de Anís del Mono. Si quieres que lleve Scrum a tu empresa, no me pidas solo formación, por que no es suficiente. Te voy a decir que no quiero ese proyecto, así de simple. No me va a volver a ocurrir dar formación a varios equipos de una empresa, que se maten a golpes tratando de hacer funcionar Scrum y que luego sea otro el que venga a corregir el desaguisado. Visibilidad, inspección y adaptación: los errores una vez y no más.

Todo el mundo quiere atajos. Todo el mundo quiere que formes a su equipo en medio día. Y tener Scrum en toda la empresa en un mes. Pero esto no funciona así. Hacer funcionar Scrum exige tiempo, dedicación, una inversión. He visto como me regateaban delante de un equipo el poder ayudarles con un Sprint Planning Meeting o como negaban comprar dos pizarras y un panel, mientras diez operarios pintaban y cambiaban todos los logos de la empresa por que alguien había decidido que el logo antiguo no era ‘dinámico’. Scrum te va a exigir invertir tiempo y dinero, vas a tener que hacer un esfuerzo. No te va a costar tiempo y dinero, cuando empieces a ver los frutos de tu inversión verás como se recupera con creces. Scrum es una inversión, no un coste, pero como toda inversión exige un desembolso inicial. El balance entre tiempo y dinero depende de cuanta experiencia estés dispuesto a pagar. No necesitas un coach para hacer Scrum, yo lo implemente sin un coach la primera vez, pero es más probable que cometas errores o fracases.

Después de tu primer Sprint Review solo has dado en primer paso. Entiendo perfectamente que los gestores de una empresa tienen que responder ante sus jefes y exhibir resultados. Pero lo siento, mostrar tu primer burdown chart o los resultados de una retrospectiva como quien a cortado una oreja en La Monumental no demuestra que estés haciendo Scrum. Ni siquiera demuestra que estés en el camino de Scrum, demuestra que estás dando pasos, que no es poco, pero que no es todo. No hay un fin. Este es un camino sin fin. Solo tras varios meses vas a ver tu éxito o tu fracaso. Se que es motivador, se que es excitante, se que estás visualizando tu proceso y que ahora tienes métricas que hace semanas ni soñabas. ¡Pero eso no es nada!, al menos hasta que tengas un proceso claro de crítica continua y continua mejora de tu proceso de desarrollo.

Las herramientas importan. Evidentemente las herramientas no son lo más importante. La gran mayoría del software que rige Internet se escribió usando vi como editor. Pero si que son importantes. Las herramientas que elijas van a afectar de manera clara a la curva de aprendizaje de técnicas sin las que Scrum es más duro de implementar. Valora que herramienta es adecuada y si tienes varios equipos procura que compartan herramienta ¿cómo van a aprender unos de otros si usan herramientas diferentes?. Presta atención a tu herramientas, afílalas, púlelas, mantenlas limpias y preparadas para la batalla. Automatiza, automatiza y automatiza. Lima todas las esquinas y asperezas de las herramientas que drenan productividad. Evidentemente si tus equipos comparten herramienta, te ahorras pulir ciertas esquinas dos veces. Es preferible un mal cuchillo bien afilado, que un buen cuchillo con el filo mellado. Aunque lo ideal, sin duda, es un buen cuchillo bien afilado. Si vas a llevar la agilidad a tu organización asegúrate de tener alguien que afile el cuchillo.

La ingeniería del software importa. Nadie me va a convencer de que Scrum es suficiente. No lo es. Scrum no es nada sin buenas prácticas de ingeniería del software. Si formas a tu equipo en Scrum y no lo formas en TDD, calidad, automatización, gestión de la configuración etc… ¿Cómo va a actuar tu equipo cuando encuentre impedimentos técnicos? La experiencia me ha demostrado que los impedimentos técnicos son un gran porcentaje de los que aparecen durante las retrospectivas. Si quieres tener éxito vas a tener que mojarte y capacitar a los equipos en aspectos técnicos.

No hay Product Owners. No existen. Son como el monstruo del Lago Ness. Es un rol clave que las empresas tienen más que serios problemas para cubrir. Casi siempre ocurre lo mismo. Se coge a los Product Managers o a los comerciales y se les dice: ‘ahora eres Product Owner, PO para los amigos’. Y eso es todo. Este enfoque falla por dos aspectos: uno, el ratio entre Product Managers y desarrolladores es sistemáticamente insuficiente. Acabas con un PO para seis equipos, situación claramente insostenible. Y dos, los PM de Power Point y reunión que tanto abundan resultan ser muy malos PO. No se trata de guiar a alto nivel un producto, de decidir si pondremos en letras grandes nueva versión con Cirintione o destacaremos más el nuevo condensador de fluzo de nuestro software, no. Se trata de definir en detalle características, evaluar el retorno de la inversión, priorizarlas y asegurar que se desarrollan con la calidad suficiente y no más que el cliente demanda. Casi nada. No hay Product Owners, hay que crearlos. Tendrás que formarlos, entrenarlos, dejar que se equivoquen varias veces, lograr que aprendan y luego podrás decir que tienes Product Owners. Ni siquiera puedes contratarlos, ¡recuerda que no existen!.

No hay equipos. El primer trabajo que tienes que hacer para extender Scrum por una organización es saber qué carajo es un equipo en esa organización. Y no, no hay organizaciones a las que haya llegado y me hayan dicho de manera clara que es un equipo para ellas. Cada uno tiene una visión. Y nadie sabe en que equipo juega. Y donde hay equipos son de 20 o 30 y tienes que partirlos. Definir que es equipo es difícil, pero cuando logras poner en la pizarra los equipos, quien será su PO y quien será su Scrum Master, has dado un paso de gigante. En la empresa más grande, la que más equipos tiene, nos llevo más de dos días de rompernos la cabeza.

Los tester, si existen, tienen que cambiar radicalmente su rol. Ya no son la policía de la calidad que certifica los indolentes que somos los desarrolladores en este aspecto (que lo somos). No señor. Los testers pasan a ser los facilitadores de la calidad. Establecen los mecanismos necesarios en colaboración con el equipo de desarrollo e incluso integrándose en el para que la calidad brille. En un entorno realmente ágil los testes son miembros del equipo de desarrollo. Esto choca con la cultura imperante en las empresas donde se sigue concibiendo la labor del tester como el certificar la ausencia o presencia de calidad en fases finales del desarrollo. Desde hace años se sabe, todos los esfuerzos de calidad en el software tienen que estar orientados a detectar los defectos de manera temprana. El coste de los defectos crece exponencialmente con el tiempo. Esa es la máxima que debemos recordar. Solo acercando a los testers a las fases más tempranas del desarrollo lograrás que el trabajo sea eficiente y los desperdicios mínimos. Generalmente las organizaciones entienden bien este cambio cuando se explica. El problema es que muchas siguen pensando que la calidad surge de la nada.

Necesitas el respaldo de la gerencia. Estamos hablando de cambiar la manera en la que una empresa funciona. Esto transciende el ámbito del equipo. No valen tácticas que he sugerido en otras ocasiones. Si no tienes todo es soporte claro y absoluto de alguien de mucho peso, mejor vete a casa. Y empieza por un solo equipo, que no es moco de pavo. Ya hablaremos de como lograr ese respaldo en otro post.

No todo son malas noticias. Yo no voy a titular este post Agile mato a mi gato, no se trata de sensacionalismo sino de realidad. La realidad, al menos la que yo he visto, es la que he relatado, pero lo que es fantástico es que cada vez más y más organizaciones más y más grandes están luchando para cambiar la manera en la que desarrollan software. Y aunque el camino no está exento de dificultades, el balance es positivo. Cada vez que oigo como un desarrollador habla de la manera en que Scrum ha impactado en la organización en la que trabaja oigo cosas positivas. Tengo clientes que incluso están haciendo esfuerzos para extender Scrum a sus proveedores o que organizan charlas-café para que les cuente a sus clientes que es Scrum y transmitirles como han cambiado las cosas a mejor en su organización. Las empresas que implementan Scrum lo están contando con orgullo al mundo, están evangelizando. Con todos sus problemas, dificultades y fallos ¡Scrum funciona!.

El balance es claro: Scrum ha llegado y está aquí para quedarse.

Desde Geeks·ms queremos darle un empujón a el Wiki de la comunidad. La idea es que empiece a tener la masa crítica suficiente para que poco a poco se convierta en el Wiki de referencia para la comunidad .Net hispano hablante.

Por ello hemos preparado el siguiente concurso:

Envía al menos 12 colaboraciones antes de la media noche del 30 de Octubre al Wiki de Geeks·ms y serás candidato a obtener una subscripción MSDN con Visual Studio 2010 Ultimate.

Entre el 30 de Octubre y el 7 de Noviembre seleccionaremos mediante votación por parte de un jurado elegido entre los bloggers más activos de Geeks·ms a aquellos tres usuarios que más hayan aportado al Wiki de Geeks·ms.

Contamos con tres subscripciones MSDN. Si el jurado (formado por al menos 7 miembros) decide por unanimidad que las aportaciones no tienen una calidad suficiente para ser premiadas se podrá declarar el concurso desierto.

Los colaboradores del Wiki merecedores de ser premiados contarán con un blog en Geeks·ms si así lo solicitan.

Los miembros del jurado y los resultados de las votaciones serán totalmente públicos.

¿A que esperas para sumar entradas en el Wiki?.

Si tenéis alguna duda, esperamos vuestras preguntas en los comentarios.

Estoy en Bruselas asistiendo a un Train The Trainers para la nueva certificación Professional Scrum Developer creada por Ken Schwaber, uno de los padres de Scrum de la mano con Microsoft (hay una versión para Java también). La formación la está impartiendo Richard Hundhausen, viejo conocido de la comunidad en torno VSTS y TFS.

Hace un tiempo mandó un correo a una lista interna de MVPs y desarrolladores de Microsoft lanzando una cuestión muy interesante ¿Cuando una prueba unitaria se deja de considerar unitaria?. El problema es que no hay una respuesta clara para esta pregunta, pero lo bueno es que esto puede generar un debate muy interesante. Hoy he aprovechado que le tenía a mano para preguntarle si le importaba que usase las figuras de su correo para plantear esta misma cuestión en mi blog y en esas estoy.

Quiero lanzar las siguientes cuestiones:

¿De los siguientes ejemplos cuales son pruebas unitarias para tí?.
¿Si no son pruebas unitarias que tipo de pruebas son? integración, aceptación, caja negra, caja blanca… ¿cómo las etiquetarías?.

Ejemplo 1 – Muy probablemente todos coincidamos en que esto es una prueba unitaria. Sin lugar a dudas ¿no?.

Ejemplo 2 – ¿Y si el método público llama a uno privado? ¿Sigue esto siendo un test unitario?

Ejemplo 3 –¿Y si se llama a otro método público se convierte el test en un test de integración?

Ejemplo 4 – ¿Esto es un test de integración? o sigue siendo un test unitario.

Ejemplo 5 – ¿Un test unitario se convierte en un test de integración si cruzamos las fronteras del assembly bajo test?

Ejemplo 6 – ¿Y si llamamos a una base de datos o a un servicio web? ¿Es esto un test unitario para vosotros? o es un test de sistema.

¿En definitiva cuando una prueba unitaria deja de ser una prueba unitaria y pasa a ser otra cosa?

Para mi todos los casos son casos de pruebas unitarias, de diferente naturaleza, pero pruebas unitarias al fin y al cabo.

Poniéndome purista podría admitir que el ejemplo 6 no lo sea. Pero ya he dejado claro anteriormente que una cosa que quiero poder hacer con mis test es ejecutarlos contra la base de datos (no siempre, pero si cuando me convenga, hago posible gracias a inversión de control e inyección de dependencias).

El ejemplo 5 también me plantea dudas, pero si consideramos que no es una prueba unitaria ¿deberíamos entonces sistemáticamente mockear todas las llamadas hacia afuera de nuestro assembly? ¿Incluidas también las llamadas al framework?.

Espero vuestras opiniones.

Se que tengo un poco abandonados a los lectores del blog. Prometo remediarlo en próximas fechas. Pero de momento me podéis leer en Twitter en http://twitter.com/r_corral.

Un saludo.

Gracias a la invitación de Navarra Dot Net y al CES, y al ínclito Carlos Segura mañana, 17 de Febrero, tendré el placer de visitar una vez más este magnífico club de usuarios, uno de los más veteranos, para charlar durante dos horitas sobre Windows Azure.

Microsoft ha creado, sin duda alguna, la plataforma más completa e integrada para la computación en la nube, Azure. Esta plataforma permite crear aplicaciones para la nube y ofrece una infraestructura hospedada escalable para implementar y administrar estas aplicaciones y sus almacenes de datos además de toda una serie de servicios adicionales: workflow, control de acceso, bus de servicios, etc…

En esta presentación daré una visión general de la plataforma, las ideas detrás de ella y el valor de negocio de uso de esta plataforma..

Comentaremos Azure a nivel arquitectónico y el cambio de que supone lleva las aplicaciones a la nube. Además clarificaremos los pasos que todo desarrollador debe dar para subirse a la nube. Veremos la estructura de una solución Azure y el amacenamiento de datos en la nube.

No dudéis en inscribiros.

¡Nos vemos!

Dos docenas de programadores, tres años, 4732 errores y la búsqueda de un software trancendente… hay es nada.

Supón que eres un programador que al principio de su carrera a dado un pelotazo (que nadie piense aquí en la acepción negativa de pelotazo). Un pelotazo brutal, todo el mundo, absolutamente todo el mundo usa tu software. Todo el mundo usaba Lotus 1-2-3 en un tiempo. Supón que ahora eres un ‘hombre de negocios’, uno muy inquieto. Eres quien dirige la Mozilla Foundation, eres parte del comité de dirección de la empresa que ha creado Second Life, y estás en el consejo de la Wikimedia Foundation. Pero aun así no es suficiente. Eres Mitch Kapor.

Sigues soñado con hacer proyectos que cambien el mundo… otra vez. Y tienes dinero de sobra para financiar cualquier proyecto. Y conoces a la gente adecuada para llevarlo a cabo. Puedes atraer a cualquier programador del mundo.

Juntas el dinero, juntas al equipo, y les dices… no quiero un proyecto cualquiera, quiero un proyecto que cambie el mundo, quiero un proyecto en el que la gente trabaje sin presión de fechas, quiero otro Lotus 1-2-3, quiero plantar cara a Microsoft y no en cualquier producto, sino en Exchange, hay es nada.

Además el software será libre. Hordas de programadores nos ayudaran…

El equipo empieza a trabajar, y claro, ideas no le faltan. Has juntado auténticos cracks. Todos quieren implementar su parte del proyecto de manera excelente, ninguno quiere simplemente hacer algo que funcione. ¡Eso no cambia el mundo! Hagamos nuestro propia solución de almacenamiento, hagamos nuestro propio ORM, hagamos nuestro propia implementación de… suena muy divertido… pero…

Tras tres años de andar sin rumbo, no hay producto, el entusiasmo inicial se ha diluido, desarrolladores clave se van del proyecto. Las versiones se retrasan, unos meses primero, sine die después… La comunidad que se pretendía surgiese por el simple arte de usar una licencia libre ni está ni se la espera… y cuando está lo que más aporta es ruido…

Estas es la historia, no por triste, poco habitual, que Scott Rosenberg nos narra en este libro. Pero lo interesante no es solo la historia del proyecto, sino que Scott aprovecha el seguimiento que realizo como observador del mismo para salpicar el ensayo de referencias a toda la mejor literatura sobre gestión de proyectos. Es un viaje a lo largo de la vida del proyecto que dio como resultado Chandler. Fuera de plazo, presupuesto y características, pero resultado al fin y al cabo. Eso sí, no creo que haya nadie en el mundo que piense que Chandler lo ha cambiado.

La historia del proyecto, línea argumental del libro, está jalonada por excelentes referencias comentadas a textos de influencia vital en la ingeniería del software y la gestión de proyectos modernas. Este libro es una forma muy muy amena para leer sobre algo tan ‘aburrido’ como la gestión de proyectos y la ingeniería del software.

Tras leer el libro, si alguien me preguntar ¿por qué el proyecto fallo?. Lo tengo claro. No puedes dejar a un motón de excelentes técnicos marcar las prioridades de un proyecto. Alguien debe marcarlas, teniendo en cuenta la necesidades de los clientes. Y esa figura brilló por su ausencia en este proyecto. No hubo un Product Owner que marcase con voz única y firme que había que hacer en cada momento para satisfacer la necesidades del cliente. No había prioridades, la técnica marcaba la agenda. La ausencia total de metodología, el que el equipo tuviese que descubrir una forma de trabajo a lo largo del proyecto tampoco ayudo en absoluto.

El libro es excelente, sobre todo si estás empezando en esto del desarrollo de software, poder leer la experiencia de este proyecto, narrada de manera que al terminar el libro parece que has sido parte del mismo, es una gran oportunidad de atesorar conocimientos que solo la experiencia te da. Buen libro que merece la pena comprar y leer. ¡Además es barato!, menos de 10 dólares en Amazon.

¡Un saludo!

Siempre me ha interesado la economía. Ya de niño me empollaba las páginas salmón con el gusto de aprender algo por el simple hecho de saber sobre algo que la mayoría de la gente simplemente ignora. Además, ya con unos añitos más, las páginas salmón eran las únicas que siempre estaban abandonadas al fondo de la barra del bar. No le he sacado nunca partido ninguno a ese conocimiento: mi situación económica no es espectacular, pero me sigue gustando el tema.

Acabo de terminar de leer El crash del 2010, libro escrito por Santiago Niño Becerra, gurú económico que ha ganado relevancia por su certero, hasta el momento, y apocalíptico diagnostico de la crisis que vivimos. El libro me parece bueno, más que nada por la explicación historicista que da la situación actual (la historia es otra de mis aficiones). Pero este post no es uno de mis habituales comentarios de libros de la sección He leído… de este blog. No, en esa sección solo hablo de libros que tengan que ver con desarrollo de software, temática de este blog (pese a lo que pueda parecer). Tampoco este es un post sobre economía, aunque pueda parecerlo, es un post sobre gestión de proyectos (esto ya parece más este blog)… y ¡economía!.

Hay dos ideas claras en el libro. Bueno tres. La primera es que lo peor lo peor está por llegar, vamos que vamos de marejadilla a fuerte marejada, que la crisis no ha  hecho nada más que empezar y que es de agárrense que vienen curvas… pero bueno, esta idea no me interesa, de verdad. Y encima dice que ¡no podemos hacer nada!. Me la sopla lo que piense este señor, me da igual, vengan como vengan dadas, la resignación y el pesimismo no van conmigo. Por mal que vengas las cosas, siempre podrán se menos malas si las encaramos con optimismo.

Vamos con las ideas del libro que me parecen relevantes… y con lo que realmente importa ¡cómo van a cambiar la gestión de proyectos!…

La primera es que los recursos que hemos tratado hasta ahora como ilimitados han dejado de serlo. Vamos a tener que pensar en lo que consumimos para producir. El resultado no va a ser lo único relevante, sino que los recursos consumidos para obtener el resultado van a ser un elemento clave.

«El crecimiento ha estado basado en la creencia de que gastar de todo, sin límite, era posible e incluso necesario […] pero cuando la deuda se ha hecho físicamente insostenible […] nuestro sistema ha encarado una crisis»

La segunda es que la economía va a cambiar de manera radical y que el nuevo paradigma económico va a ser la productividad. Vamos a ser tan productivos que va a sobrar factor trabajo por todos los lados.

«Hoy la tendencia apunta hacia la buena administración, hacia el no desperdicio, hacia lo necesario, hacia la productividad.» dice Santiago.

Bien, recursos limitados y productividad serán la clave, ¿cómo afectan estos dos elementos a la gestión de proyectos?

Todos conocemos como se han hecho tradicionalmente los proyectos de desarrollo en este país (y seguro que en la gran mayoría). A base de fuerza fruta. Que un proyecto no se mueve, no hay problema, para que vamos a pensar, simplemente añadamos más carne de cañón. Pongamos más programadores, ¡más recursos!, eso sí, de los baratitos, de los ‘recién salidos’, que total ‘solo tienen que hacer informes y mantenimientos’. Nos da igual la productividad.

Y así es como acabamos en una guerra de trincheras, enquistada, en la que el proyecto no avanza por que al cliente se le ocurren más informes y mantenimientos que los que nuestro equipo es capaz de completar. Y la productividad daba igual, que no somos productivos, no pasa nada, más fuerza bruta. Total siempre podemos ignorar la ley de Brooks. La ignorancia tiene una virtud, no genera inquietud. ¡Viva al Spanish theory management! que tan bien describe Peopleware.

Que queréis que os diga, a mi no preocuparía esta situación, si no fuese por la pobre carne de cañón y por los recursos que se dilapidan. Miles de programadores que acaban hastiados de una profesión que es realmente bonita. Miles de millones de euros quemados en retrabajos, fallos de calidad, en características que nunca se van a usar, en proyectos faraónicos donde el único afán de la mega consultora de turno es mantener la factoría en funcionamiento. Mientras hay esclavos moviendo la maquinaria, el dinero fluye y se queda en las manos de los de siempre. Da igual el resultado del proyecto, lo importante es facturar. Si sale una castaña, ya haremos otra versión total, hasta ahora los recursos eran ilimitados…

… pero no hija no… es no… que decía Ozores, el tirar con pólvora del Rey se ha acabado. Ahora las administraciones están caninas, y las empresas ni te cuento. Todos van a mirar la pela, todos van a exigir un retorno de la inversión. Ya no va a valer con quemar pólvora, la gente querrá ver fuegos artificiales cuando huela a pólvora quemada.

Que va a ocurrir en la gestión de proyectos según yo lo veo:

Que nadie va a financiar megaproyectos a tres años, ni fases de captura de requisitos de meses, ni continuos cambios de requisitos por antojos de vaya usted a saber quien… se van a empezar a exigir resultados pronto y rápido. Las metodologías ágiles van a ganar mucho peso, mucho. Es imposible ser productivo y trabajar con recursos limitados si tu proceso de desarrollo no lo promociona y facilita. No te digo nada si no tienes proceso. Nadie va a poder pagar la burocracia inútil.

Tampoco nadie va a poder mantener equipos lentos y enormes, sin capacidad de reacción y que tardan decenas de meses en liberar valor. Los equipos ágiles, altísimamente productivos, excepcionalmente preparados va a brillar como siempre debieron brillar.

La gran consultora va a sufrir, y mucho. Va a ganar la pequeña empresa altamente especializada y sumamente rápida que logre hacer software de calidad y entregar valor en un flujo continuo. ¡Vale, vale! Reconozco que el que mi empresa, Plain Concepts, trate de seguir esta definición quizás influya en mi juicio 😉

Y que queréis que os diga… si las cosas son como Santiago Niño Becerra y yo las vemos, bendita crisis. Por fin van a ganar los que lo merecen: los que se han preparado, son técnicamente excelentes y aman su trabajo de desarrolladores de software, en definitiva, los productivos.

La mala noticia es que la parte difícil es asegurarse de que tú y tu empresa sois productivos. Que esfuerzo.

¡Un saludo!

Gracias al trabajo espectacular que los organizadores del Code Camp ha realizado todos podemos disfrutar de los videos de las sesiones que se impartieron allí.

Os invito a ver mi charla sobre Azure de la que ya os hablé anteriormente en este blog.

Y no os perdáis la estelar actuación de Los tres tenores de VSTS, Bruno, Luis Fraile y un servidor (como nos han bautizado los chicos de la organización). Una charla muy divertida.

Tenéis los videos a vuestra disposición aquí. Especialmente recomendables… ¡todos!.

¡Un saludo!

Juan Palacio, David Alfaro y un servidor grabamos un podcast este pasado sábado sobre el papel que en Scrum juega el Propietario del Producto o Product Owner.

Cualquiera que se haya aproximado mínimamente a Scrum sabe que la labor del Propietario del Producto es representar la voz del cliente asegurando que el equipo de desarrollo se enfoca en los temas adecuados desde la perspectiva del negocio.

Evidentemente dentro de esta definición caben muchísimos matices y detalles. Precisamente esto es lo que tratamos en el podcast.

Los asuntos más relevantes que hemos tratado son:

Las labores del Propietario de Producto, todas ellas relacionadas con la gestión de los requisitos del proyecto de un modo u otro:

Mantener contento al cliente.
Realizar la captura de requisitos.
Priorizar los requisitos.
Digerir esos requisitos antes de que lleguen al equipo de desarrollo.

También hemos hablado sobre la diferencia entre el papel que juega el Propietario del Producto comparándolo con roles como el de Product Manager que aparece en otras metodologías. Hemos comentado sobre este punto como la principal diferencia es el uso de determinados artefactos (product backlog, historias de usuario) y liturgias (scrum planning meeting, scrum review) y como la labor del Propietario del Producto esta en todo momento guiada por la búsqueda de valor para el cliente.

Hemos hablado también de como la priorización de requisitos es la técnica que lleva a lograr ese retorno de la inversión.

Hemos hecho mucho hincapié en la importancia de tener este rol perfectamente detectado entre los participantes en el proyecto y que su voz debe ser única y respetada en todo lo relativo a que se debe hacer en el proyecto.

Sirva este post de introducción al tema y de invitación a que escuchéis el podcast.

Si os a gustado este podcast no os perdáis otros muchos relacionados con Scrum y la agilidad en el canal Open Knowledge Scrum Manager.

¡Espero vuestros comentarios!

Una larvada, oculta y desconocida guerra, para mi mucho más importante que la de Afganistan o la de Iraq, me mantiene regularmente ocupado. Es la lucha contra los comentarios de spam en Geeks.ms. La verdad es que si no me lo tomase como un hobby, como una extraña partida de ajedrez, como un juego de inteligencia, una arcana lucha entre el bien y el mal… ya tendría una ulcera de estomago de tanto cargarme el la p**a madre de los p**os spammers.

La guerra ha tenido diferentes batallas como todas las guerras que se precien. Y también algunos daños colaterales, ninguno de gravedad extrema gracias a Dios, como usuarios que no han podido acceder a su sitio favorito, o autores que no han podido publicar o han sido banneados del sitio, e incluso algún comentario perdido en la onda expansiva de algún script un poco desviado de su objetivo.

Hemos jugado numerosas partidas los spammers y yo. De momento, dado que el sitio no está totalmente tomado por el spam pese a sus intentos y que nunca he tenido quejas sobre este tema, creo que voy ganando. Aunque por poco: solo puedo actuar reactivamente y evitar que los comentarios de spam perduren. Aunque este en si mismo es una victoria, el simple hecho de hacer ver que el sitio está defendido, hace que los spammers mas perezosos abandones sus ataques y dirijan sus esfuerzos hacia otros sitios más vulnerables.

En esta batalla, he usado y uso numerosas armas. Durante un tiempo tuvimos captchas por todos los lados, los viejos del lugar lo recordarán, luego solo comentarios de usuarios autenticados (algo que odio, pues creo que Geeks.ms debe ser lo más abierto y accesible posible para los usuarios licitos), luego incluso tuve que capar el registro de usuarios con mail de determinados dominios de correo…

Lo interesante del tema es el continuo toma y dada. Ellos intentan algo, yo lo detecto e implemento una medida de protección. Rara vez comento de manera explicita estas medidas en el blog, algunas de ellas curiosas, por razones obvias de no dar información al enemigo. Aunque de manera clara, mi particular guerra ha inspirado algún que otro post, como por ejemplo: Protegerse de las inyecciones de SQL por URL, fruto de una de las más cruentas batallas libradas en esta guerra.

Hoy os vengo a contar una medida que he usado durante mucho tiempo, pero que ha caído en desuso. Ya digo que lo que ayer les funcionaba a los spammers hoy no les funciona y viceversa. Ahora este mecanismo ya no sirve ya que los spammers, que serán unos cabr*nes pero no gilip*yas del todo, spoofean sistemáticamente la IP. Pero quizás vosotros si que lo podáis sacar partido para para ataques que podáis sufrir en vuestro sitio o en otras situaciones.

Durante mucho tiempo, los muy capullos, no cayeron en la cuenta de que, cuando un bot se ponía a inyectar comentarios yo podía evitar que lo volviese a hacer con el simple mecanismo de bannear su IP. Como Community Server me permite de manera simple saber que comentarios se habían considerado spam y la IP origen del comentario, yo banneaba la IP que había creado los comentarios y borraba los comentarios recientes de esa IP. Alguna vez alguien perdió un comentario y se quedo fuera de Geeks.ms un tiempo por culpa de este mecanismo, daños colaterales, ya digo, inevitables en toda batalla.

Bueno dejando las batallas del abuelo cebolleta vamos a dar el toque técnico que el título del post promete: ¿Cómo cortar el acceso a tu IIS a una IP mediante programación?. Pues con esta simple función que usa el modelo de objetos de IIS por WMI.

       
	/// <summary>
	/// Ban an IP from IIS
	/// </summary>
        /// <param name="IP">IP to ban</param>
        /// <param name="siteIdentifier">IIS site identifier</param>
        private void IISBanIP(string IP, string siteIdentifier)
        {
            try
            {
                //Get the directory entry for the root of the IIS server
                DirectoryEntry IIS =
                     new DirectoryEntry(
                     @"IIS://localhost/w3svc/" + siteIdentifier + "/root");

                //Get the IPSecurity property
                Type type = IIS.Properties["IPSecurity"][0].GetType();
                object IPSecurity = IIS.Properties["IPSecurity"][0];

                //Get the IPDeny list from the IPSecurity object
                Array oldIPDenyList = (Array)type.InvokeMember("IPDeny",
                                     BindingFlags.DeclaredOnly |
                                     BindingFlags.Public | BindingFlags.NonPublic |
                                     BindingFlags.Instance | BindingFlags.GetProperty,
                                     null, IPSecurity, null);

                List<object> newIPDenyList = new List<object>(oldIPDenyList.Length);

                foreach (object ip in oldIPDenyList)
                    newIPDenyList.Add(ip);

                newIPDenyList.Add(IP + ", 255.255.255.255");

                //Add the updated list to the IPSecurity object
                type.InvokeMember("IPDeny",
                                 BindingFlags.DeclaredOnly |
                                 BindingFlags.Public | BindingFlags.NonPublic |
                                 BindingFlags.Instance | BindingFlags.SetProperty,
                                 null, IPSecurity, new object[] { newIPDenyList.ToArray() });

                IIS.Properties["IPSecurity"][0] = IPSecurity;

                //Save changes
                IIS.CommitChanges();
                IIS.RefreshCache();

                ShowMessage("IP {0} was banned", IP);
            }
            catch (Exception e)
            {
                ShowMessage("Error banning IP: {0} Error:{1}", IP, e.InnerException.Message);
            }
        }

Os preguntaréis como protejo ahora Geeks.ms… el día que los sepáis será por que un spammer lo ha averiguado antes ;).

¡Ojala os sirva! Contra el spammer ¡Aur, aur… Desperta ferro!.