Archivo de la categoría "Ágil"

Mini-informe gratuito de posicionamiento en buscadores y checklist para los que empiezan con SCRUM

Tuesday, 5 de February de 2008

¿Cómo ven tu web los buscadores? Puedes insertar aquí la dirección URL de tu sitio para obtener, al instante, un pequeño informe de posicionamiento. Hay que reconocer que esta empresa, dedicada al marketing online, ha creado una buena herramienta para promocionarse…

¿Nuevo en la metodología SCRUM? Henrik Kniberg ha creado una “lista de tareas” con todos los pasos que un equipo debe seguir para trabajar con metodología SCRUM sin meter demasiado la pata… Hay una versión con prioridades de primer nivel y otra, con la fuente muy pequeña, que muestra todos los pasos.

Desarrollos para PYMES: mejor con SCRUM

Friday, 25 de January de 2008

Es un hecho: las PYMES apenas invierten en desarrollos software a medida. Y es un sinsentido, porque podrían utilizar esos desarrollos para agilizar sus procesos y ahorrar costes; en definitiva, para hacer mejor las cosas gastando menos dinero.

Lo que está claro es que ese rechazo existe, y debe tener, por tanto, una explicación. Nuestra experiencia en ASPgems nos ha dado ocasión de hablar con muchos empresarios y gestores, y nos permite aventurar los siguientes motivos:

  • Abandonados en mitad de la nada. La queja es muy común: “Muchas empresas nos han dejado tirados en mitad del proyecto, nunca han llegado a completarlo”.
  • Miedo a la eternidad. Las PYMES piensan que el proyecto tardará en desarrollarse siempre mucho más de lo inicialmente previsto. Es un clásico: “Si el informático dice “es cuestión de días”, calculo semanas; si dice “semanas”, calculo meses; y si dice “tardaré un año”, entonces mejor ni hablamos…”
  • Problemas a la hora de definir los requisitos. El espacio de trabajo habilitado para definir lo que la PYME necesita resulta inadecuado. La empresa nunca tiene tiempo de contar todo lo que sabe hacer, y no encuentra lugar para explicar lo que realmente necesita.
  • Fuera de nuestro alcance. Todavía permanece la imagen de la tecnología asociada a grandes inversiones al alcance sólo de las grandes empresas.

Afortunadamente, el panorama ha cambiado, y mucho. Con la metodología de desarrollo ágil SCRUM, las cosas mejoran sustancialmente:

  • Dentro del plazo. Nuestra experiencia en ASPgems nos indica que es perfectamente posible finalizar los proyectos dentro del plazo previsto. De hecho, llevamos casi 2 años entregando proyectos on-time. Y, de todas formas, en el caso de que no acabáramos a tiempo, el cliente recuperaría parte del dinero comprometido.
  • El avance se ve y se toca. SCRUM permite que el cliente compruebe el avance del proyecto sobre la marcha, mediante entregas parciales. Esto supone una ventaja notable frente al método clásico, en el que el usuario debe esperar hasta el final para descubrir el resultado, que en ocasiones es toda una sorpresa. El riesgo añadido de no ver nada hasta el final es que, muchas veces, se ha estado circulando por la senda equivocada, y ya es demasiado tarde para rectificar…
  • Más sencillo, mucho mejor. El análisis funcional no es necesario. Se sustituye por una lista de necesidades que todo el mundo puede comprender y compartir, desde el cliente hasta el último miembro del equipo.
  • El último empujón. ¡¡Ya es posible quitar un 0 a la cifra de inversiones!!

En ASPgems queremos hacer llegar estas ventajas a las PYMES y, aunque la tarea no es fácil, lo que pensamos hacer es:

  1. seguir haciendo bien nuestro trabajo con SCRUM y, sobre todo
  2. comunicar a las PYMES el nuevo mensaje: hacemos bien nuestro trabajo y podemos ayudaros a hacer mejor el vuestro

Volverse ágil: ¿poco a poco o de golpe? Y dos gemas

Sunday, 20 de January de 2008

¿Cuál es la mejor manera de adoptar “Agile” para una organización? ¿Hacerlo poco a poco, a partir de un proyecto piloto, o cambiarlo todo de golpe? El patrón más común sigue siendo el de empezar la transición a Agile con un proyecto piloto, para aprender de él y después extenderlo al resto de la organización. Normalmente se arranca con uno, dos o tres equipos de 5 a 10 personas cada uno. Sin embargo, también hay empresas que prefieren atacar el cambio a Agile de una sola vez, es decir, que apuestan por realizar la conversión “de golpe”. Veamos algunas de las posibles ventajas y desventajas:

POCO A POCO

Ventajas.

  • Se minimiza el coste de los errores. No es lo mismo fallar con un solo equipo que hacerlo con 100…
  • Permite seleccionar y centrarse en los equipos y los proyectos más exitosos, para vencer así las reticencias de los escépticos
  • Siembra la organización con personas que actúan como embajadores para que otros comiencen a aceptar el cambio.

Desventajas.

  • Las conclusiones del trabajo con un grupo pequeño no tienen por qué ser extrapolables a un proyecto mayor.
  • Se tarda más en empezar poco a poco y escalarlo que en atacar el cambio de una sola vez.
  • Se puede transmitir la sensación de que la empresa duda o desconfía del proceso ágil, y que por eso prefiere empezar por unas “pruebas” para tantear la situación.

DE GOLPE

Ventajas.

  • Muestra el compromiso y la confianza de la empresa con Agile.
  • Todo acaba pronto. Puede ser doloroso, pero no dura demasiado.
  • Se evita el conflicto entre 2 procesos opuestos, el ágil y el tradicional, que de otra forma tienen que convivir, con los roces que eso implica.
  • Los escépticos se ven obligados a asumir la estrategia de la empresa: no les queda otra opción, puesto que es la única estrategia posible.

Desventajas

  • La transición es muy arriesgada. La empresa se juega el todo por el todo.
  • Lo más probable es que la transición requiera una complicada reorganización de los equipos y las relaciones internas.
  • El proceso puede generar mucho stress, presión y tensión.

Más sobre patrones de adopción de agile.

Y otras dos gemas:

  1. PHP o Ruby, ¿quién corre más? Un blogero ha realizado un pequeño experimento para medir la velocidad de ejecución -en segundos- del código PHP y Ruby. También ha incluido Perl, Python y C++ en este “benchmarking” casero. Los resultados, aquí.
  2. Una compañía de Manchester, 34SP, ha comenzado a ofrecer a sus clientes un servicio de hosting configurado específicamente para Ruby on Rails. Según su director técnico, “Ruby on Rails no funciona bien en un entorno de hosting compartido, así que para sacarle todo el jugo necesitas tu propio servidor. Pero dado que un servidor dedicado puede resultar demasiado caro, ofrecemos un servicio configurado para las aplicaciones de Rails con un frontend Apache“.

Scrum Pack: lista de empresas y una lección magistral

Thursday, 10 de January de 2008

Scrumalliance sigue actualizando una lista con las empresas que han utilizado la metodología Scrum en alguno de sus proyectos. Su objetivo: identificar las compañías en las que podemos encontrar profesionales con los que charlar y discutir sobre Scrum y Agile. En definitiva, dar soporte a la comunidad.

La fuente de información proviene, normalmente, del entorno de las empresas listadas, así que hay que observar los datos con cautela y prevención. En cualquier caso, es una referencia interesante: según la lista, grandes empresas de diferentes ámbitos, como Adobe, Bank of America, BBC, Google, Merrill Lynch, Microsoft, Nokia o Siemens han confiado en Scrum para llevar a cabo alguno de sus proyectos. Y cada vez son más.

Para completar este “Scrum Pack”, una lección magistral a cargo de Ken Schwaber, uno de los fundadores de Agile Alliance y Scrum, y firmante del Agile Manifesto. El vídeo es de hace tiempo, pero no tiene desperdicio.

Por qué usamos el framework Ruby on Rails

Wednesday, 7 de November de 2007

El pasado 6 de noviembre participé en una mesa redonda sobre frameworks en SIMO. Expertos en Drupal, Code Igniter, Zend Framework, .Net y Sun JSF expusieron su punto de vista sobre el estado del arte de los frameworks para desarrollo de aplicaciones web.

Yo por mi parte me encargué de explicar porqué hemos elegido Ruby on Rails como nuestra herramienta favorita para este tipo de proyectos. Podeis ver a continuación la explicación -más o menos fidedigna- que realicé en los 4 minutos de presentación que me correspondían.

Ruby on Rails es un framework para desarrollo de aplicaciones web escrito en el lenguaje de programación Ruby.

En ASPgems, donde todo el equipo tenemos experiencia en otros entornos sobre todo en proyectos grandes en el mundo corporativo, utilizamos Ruby on Rails porque nos permite desarrollar proyectos web de calidad en tiempos muy competitivos y usando metodologías de programación ágiles. Esto nos permite empezar a desarrollar un proyecto con un número mínimo de requisitos que sabemos que van a cambiar mucho durante la vida del proyecto, y que podemos aceptar cambios incluso en los días previos a la salida a producción sin que tengan un impacto significativo en la mayoría de los casos.

Encontramos varias ventajas en Rails sobre algunos otros frameworks. Por un lado, el lenguaje sobre el que se desarrolla, Ruby, es un lenguaje muy orientado a objetos, potente, y muy expresivo. Con pocas líneas de código puedo conseguir muchas cosas, con lo que la legibilidad del código es mayor y la probabilidad de errores se reduce.

Ruby on Rails, es un framework con opinión que se basa en el principio de “Convención sobre Configuración”, de forma que si yo utilizo las convenciones que el framework espera, Rails es capaz de hacer gran parte del trabajo por mí. En rails no hay que mantener ningún fichero XML para configuración de filtros, mapeos, validaciones o nada parecido. Además, al trabajar todo el mundo siguiendo las mismas convenciones, se puede incorporar gente a un proyecto en marcha o rotarla con un coste mínimo.

Otra gran ventaja de Rails, es la filosofía misma del framework. Rails está creado a partir de un proyecto real puesto en producción. Se desarrolló un proyecto web con Ruby siguiendo patrones de diseño estándar como MVC, Inversión de Control, Persistencia de Datos… y se vio que el proyecto funcionaba bien y que había varias partes reusables. Ese código reusable se extrajo para hacer un proyecto Open Source. Además, se le añadió un mecanismo de plugins para poder ampliar o modificar el comportamiento del framework de forma simple.

Como el código del framework es fácil de entender, y es sencillo crear un plugin, en seguida se consigue una comunidad de desarrolladores muy activa. Cuando un plugin se usa mucho dentro de la comunidad, se acaba incorporándo al núcleo del framework; y al contario, si una parte del framework no la usa casi nadie, se acaba sacando como plugin. Se puede seguir usando, pero no se mantiene dentro del framework, con lo que no se convierte en un framework monstruo donde cabe todo.

Debido a esto, tenemos un framework que está vivo y que se va modificando según los proyectos y las necesidades reales de la comunidad que lo usa en sus proyectos en producción.

El resultado es que, para una persona acostumbrada al desarrollo web, se puede desarrollar una aplicación completa con muy poco código. Te puedes centrar en la lógica de negocio y dejar muchos detalles de implementación al framework.

Esto choca con otros frameworks que están pensados en abstracto para cubrir cualquier caso posible, y acaban teniendo una arquitectura tan compleja que en muchos casos te da la impresión de que, más que desarrollar, estás luchando contra el framework.

Conferencia Rails Hispana 2007

Tuesday, 31 de July de 2007

Me acabo de dar cuenta de que no habíamos escrito en el blog sobre la conferencia rails de este año. Toda la información está en: Conferencia Rails Hispana 2007

El año pasado fue un “exitazo” de la comunidad, y nosotros estuvimos apoyando ese éxito. Este año repetimos.

Offshore programming vs. flexibildiad y experiencia.

Monday, 23 de July de 2007

Offshore programming es una forma elegante de llamarle al arbitraje salarial.
Se trata de encargar un trabajo de desarrollo de software allí donde los desarrolladores son más baratos y con el precio como criterio principal en la elección del proveedor.

Está práctica es muy frecuente sobre todo en USA y también en el Reino Unido. En España es una práctica que no ha tenido demasiado éxito hasta ahora quizás porque las diferencias de coste no eran tan grandes. En España el “offshore development” ha sido tradicionalmente sustituido por las empresas de “body shopping”, no mencionaré ninguna porque igual se ofenden ;-) , que venden muy barato horas de programación sin tener muy en cuenta ni la experiencia ni la calidad de los programadores.

Con la subida salarial y la demanda de profesionales cualificados en España subiendo, algunas empresas se han acercado a esta modalidad de desarrollo contratando desarrollos fuera de España (países del este, India, Argentina, etc.)

Pues bien nosotros llevamos ya 3 clientes que se acercan a nosotros después de no haber tenido éxito con sus proyectos de “offshoring” con aplicaciones Rails. y yo creo que la razón fundamental es que en proyectos cortos, con especificaciones poco definidas, y en los que la capacidad de adaptación es imprescindible, las distancias se hacen enormes, y las diferencias horarias mas todavía.

En nuestros proyectos el uso de SCRUMgem nos hace competir con las compañías de “offshoring” en aquello que ellos no pueden hacer que es la proximidad con el cliente, la flexibilidad en los cambios, y la capacidad de negociación cara a cara con el cliente.

Además todo esto es posible cuando cuentas con un equipo de gente muy cualificada, que en la mayoría de los casos a anticipado los cambios que vas a pedir, y con una tecnología de desarrollo como Rails.

Mirubi.com La web que te paga por navegar.

Friday, 20 de July de 2007

Hoy se está lanzando MiRubi.com la web que te paga por navegar.

Es un proyecto que hemos desarrollado en ASPgems, es para nosotros un claro exponente de los principios y tecnologías de desarrollo de software que defendemos porque:

  • Está hecho con Ruby on Rails.
  • Ha sido un desarrollo ágil, y muy basado en SCRUMgem.
  • Es “menos es mas” ha sido una dura lucha en el diseño y la concepción para no poner todo lo que se nos ocurría.
  • El tiempo de desarrollo no ha sufrido desviaciones sobre el previsto.

Yo creo que es un claro ejemplo de las cosas que la tecnología hace hoy posible.

Mucha suerte para MiRubi.com.

Lo que le contamos a la gente que nos pregunta de que vamos.

Thursday, 28 de September de 2006

No están todos los que son y probablemente alguno está y no debería pero amén del discurso cara a cara, y que cada día tenemos mejor estructurado a los amigos que nos preguntan que hacemos yo les paso esta lista de links:

Algunas cosas que molan:

En España:

Y para ver Un video Web 2.0 y La paradoja de la elección dos videos sensacionales.

Como hoy ya van dos veces que lo mando, pues he decidio subirlo al blog.