Oferta de empleo: Desarrollador de software para Plain Concepts en Bilbao

PlainConceptsBlackLogoEn Plain Concepts estamos buscando para nuestra oficina de Bilbao, un desarrollador de software apasionado por .Net, con experiencia, pero sobre todo con capacidad y aptitud.

¿Qué harías en Plain Concepts?

Integrarte en un equipo de desarrollo que utiliza metodologías ágiles, que desarrolla diferentes tipos de proyectos utilizando metodologías ágiles siempre usando las últimas tecnologías. Además tendrás que impartir formación o ayudar a nuestros clientes presencialmente ocasionalmente. En Plain Concepts somos todo terreno, tenemos un equipo altamente multidisciplinar. No somos una ‘cárnica’, lo único que te garantizo es no vas a estar abandonado en un cliente sin saber quienes son tus compañeros. El resto depende de tus gustos y aptitudes.

¿Qué conocimientos valoramos especialmente?

Cualquier desarrollador de Plain Concepts es capaz de trabajar con soltura con las principales tecnologías del framework de .Net: ASP.Net, MVC, EF, WF, WCF, Silverlight, WPF, TFS, Azure, Blend… Esperamos además que tengas un nivel muy por encima de la media en alguna de estas tecnologías. Además deberías ser capaz de formar a otros y de transmitir los conocimientos que tienes. No esperamos que simplemente escribas código sino que tu código sea excelente, que participes en las decisiones de diseño, y que sepas plantear una arquitectura coherente. También deberías tener la capacidad de resolver problemas a nuestros clientes, no será en principio tu labor principal, pero si que esperamos que si es necesario puedas ayudar en labores de consultoría en aquellas tecnologías que domines.

Las certificaciones de Microsoft son bienvenidas, pero no imprescindibles.
En esta ocasión en concreto valoraremos especialmente que te manejes con mucha soltura con Silverlight y que manejes Blend.

¡Qué hablas inglés perfectamente! perfecto… así podrás colaborar con nuestra oficina de USA. Que no… mientras hables C# a nivel nativo y entiendas perfectamente documentación técnica… no pasa nada.

¿Qué aptitudes valoramos más?

Debes ser un jugador de equipo. Ser capaz de criticar constructivamente el trabajo de tus compañeros y estar abierto a recibir críticas sobre tu trabajo.
Tienes que tener interés constante por aprender y la capacidad de aprender rápidamente.
Tienen que apasionarte todas las actividad relacionadas con el desarrollo de software.
Tienes que tener capacidad de comunicación. Escribir un blog es un plus.
Si te gusta colaborar con la comunidad .Net mejor que mejor: eres habitual de un club de usuarios, has dado alguna charlita en la Universidad sobre .Net, eres un habitual de los foros de MSDN y ayudas a otra gente, etc…
Además puestos a elegir preferirías leer Silverligth in depth que Los pilares de la tierra.

¿Cómo será el proceso de selección?

Duro. Te va a entrevistar todo el equipo con el que vas a trabajar. Todos ellos con derecho a veto.
Es posible que queramos ver el código que escribes y algunas pruebas unitarias del mismo.
También sería un plus que nos sorprendieses con alguna aplicación de esas que todos hemos hecho alguna vez en nuestro tiempo libre por puro placer geek (una aplicación para gestionar la agenda de tu Nokia hecha en Mono, la web de la floristería de tu hermana, el backlog de la preparación de tu boda, el informe para TFS que dice quien es el que más días llega tarde al Daily de tu equipo, el pong en XNA…).

¿Me va a tocar viajar?

Ocasionalmente. El puesto que vas a ocupar ‘Software Development Engineer’ no debería exigir que este todo el día con la maleta, pero viajar no te debe importar demasiado.

¿Cuánto voy a ganar?

El sueldo que seas capaz de justificar, no tenemos un límite claro por arriba… ni por abajo. Este aspecto, dentro de lo razonable, no va a ser un problema. Si eres una autentico crack, lo sabremos valorar. Queremos a los mejores en nuestro equipo.

¿Y además de sueldo?

Vas a tener la oportunidad de formarte, de acudir a eventos organizados por Microsoft, de acudir a cursos de tu interés, etc…

¿Y el horario?

Pues el que mejor te venga, casi todos hacemos entre las 8:00 y las 18:00. Paramos a comer sobre las 13:30. Los viernes para las 15:00 nos solemos ir a casa. Nadie va a medirte por las horas que tu culo pasa en la silla, sino por tu capacidad para obtener resultados, cumplir tus compromisos y logra que nuestros clientes estén satisfechos.

¿Quién sería mi jefe directo?

Ibon Landa, Software Development Team Lead de Plain Concepts.
http://geeks.ms/blogs/ilanda
http://es.linkedin.com/in/ilanda

¿Cuándo tendría que incorporarme?

ASAP.

¿No os pasáis un poco pidiendo?

Es por tu bien, ¿no querrás ser el menos hábil de Plain Concepts? 😉

¿Puedo saber más de Plain Concepts?

En serio no sabes que existe Google… ;).
Pero no dudes en preguntar.

Tengo más preguntas, ¿qué hago?

Utiliza los comentarios del post para preguntar.

¿Y si prefiero contactar en privado o enviar mi currículo?

Escribe a rcorral at plainconcepts dot com, con el subject ‘Desarrollador Bilbao’.
El subject es importante, si no le pones bien, descartado, por no fijarte en los detalles ;).

Un saludo.

Videos de la Conferencia Agile Spain 2010

Ya están disponibles los videos de la Conferencia Agile Spain 2010.

En concreto podéis ver la ‘keynote’ de Henrik Kniberg autor de Scrum and XP from the trenches, que es más que recomendable. Un resumen de su interesante libro sobre Scrum y Kanban, Kanban vs Scrum, How to make the most of both, traducido al español por un grupo de miembros de Agile Spain, entre los que me encuentro.

El otro video es la sesión plenaria, una mesa redonda con pilares del agilísimo patri, introductores del agilísmo en la universidad… y un servidor haciendo el hooligan.

Un saludo.

Llevando Scrum a grandes organizaciones

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.