En qué he estado
Visita este artículo en http://www.estadobeta.com/2008/08/31/en-que-he-estado/
Por Ismael en artículosResumen de mi actividad de desarrollo web en los últimos meses.
Han pasado semanas (siglos, en tiempos de Internet) desde la última vez que escribí en EstadoBeta. Por supuesto no ha sido un abandono voluntario sino producto de una ocupada rutina de trabajo aquí en Londres.
El ritmo de trabajo aquí en New Bamboo ha sido intenso y una experiencia valiosa tanto en los exitos como en los fracasos. Desde que llegué – literalmente el primer día – hasta hace unos meses atras fui parte del equipo en el desarrollo de Naked, un ambicioso proyecto que pretendía entrar a la arena de las redes sociales de igual a igual contra Facebook, Friendfeed o Twitter. Si bien en el corazón del proyecto habían ideas excelentes, Naked fue tambien una catedra sobre como NO levantar un proyecto en la web: demasiada plata, demasiada gente, demasiados objetivos, demasiado riesgo.
Como tantas veces antes, el proyecto se derrumbó estrepitosamente producto de la falta de fondos y la incapacidad de la gerencia de identificar una sola idea que hiciera al proyecto novedoso y atractivo. Esa idea que explica tu proyecto en 30 segundos en un ascensor (el “elevator pitch”). En su lugar, Naked era un numero creciente de funcionalidades diversas que ya no sólo competían cara a cara con los grandes de las Redes Sociales, sino que con el email, la transferencia de archivos y la mensajería instantánea. Todo esto antes de lanzar el beta!
La cosa me olió desde el comienzo al reventón de la burbuja en los 90’s. La falta de objetivos claros y metas realistas nos llevo al equipo de desarrollo a cometer errores de juicio y es de ahí de donde extraigo las enseñanzas más valiosas.
- La “escalabilidad” es irrelevante al comienzo. Nunca sobrediseñes. Es más fácil agregar código que quitarlo. Resuelve un problema real a la vez en lugar de cientos de problemas imaginarios. En Naked invertimos meses en estrategias de escalabilidad y complicados diseños y la aplicación nunca salió del Beta.
- Escoge a tus clientes y raya la cancha. Olvídate de los billetes. Si tus clentes no entienden la naturaleza iterativa y adaptable del desarrollo web, forja tu relación con ellos en torno a esas características. Hay metodologías reconocidas que ayudan enormemente en esto (Agile, Scrum, XP). El ideal es que el cliente sea parte del equipo y no un adversario, y una implementación efectiva de estos métodos pasa incluso por un contrato en base a iteraciones y no una fecha de entrega ni un monto fijo. Si tu cliente no esta dispuesto a aceptar esas condiciones, muestrale gentilmente la puerta. Le estas haciendo un favor tanto como a ti mismo. El objetivo es trabajar mano a mano con el cliente – literalmente, en el mismo escritorio – y hacer el proyecto tuyo.
- Tests, tests, tests. No importa que seas el mejor desarrollador del mundo. Escribe un test para cada funcionalidad que implementes, antes de implementarla. Tener una “test suite” no sólo evita errores en el futuro. Escribir los tests antes de la implementación te obliga a pensar en la API y por lo tanto escribir codigo mas conciso y estable. Un buen set de tests además sirve de documentación para otros en el equipo.
- Aprovecha tus herramientas. Si tienes la suerte de trabajar con Rails o Merb, aprovechalo! Estos frameworks te permiten avanzar a velocidades alucinantes si te atienes a convenciones y buenas practicas (lease: REST). Estas restricciones son buenas: te fuerzan a economizar recursos y las convenciones hacen el código mas inteligible por otros en el equipo. No te des aires de genio ni construyas “code ghettos” donde ni la policía se atreve a entrar.
Y más. Aunque en terminos de habilidad adquirida Naked fue una excelente escuela (desde entender los secretos más profundos de Ruby hasta lidiar con aplicaciones distribuídas y colas de mensajes), el proyecto me ayudó a reafirmar la idea de que un proyecto web se sustenta en la sintonía de los miembros del equipo más que en documentos de especificaciones, cartas Gantt o fechas de entrega.
Más sobre la caída de Naked en Techcrunch UK.
Con todo, la experiencia fue buena para New Bamboo, mi compañía. Desde entonces seguimos una metodología estrictamente Agil en cada proyecto, con iteraciones de dos semanas, Historias de Usuario, Plan de Iteración, Retrospectivas y 3 días a la semana trabajando en las oficinas del cliente.
Recientemente terminé mi parte en una red social para activistas de Amnesty International. El sitio es www.protectthehuman.com y fue desarrollado aplicando metodologías ágiles al pie de la letra. Esto se tradujo en una mejor relación con el cliente y en un resultado que refleja con más fidelidad sus expectativas y propósitos.
En el intertanto, una breve visita a Chile me permitió avanzar en los detalles finales de la segunda edición de Inventario (pronto con nuevo nombre y socio), una aplicación para crear catálogos y tiendas online que Tomás Pollak y yo venimos desarrollando desde los días de Aardvark. Aunque el intenso trabajo aquí en Londres no me permite trabajar con la velocidad que quisiera en mis proyectos, Inventario está tomando forma y pronto será un aporte real en el ecosistema web latinoamericano.
De vuelta en Londres, trabajo en los detalles finales de una aplicación para Channel Five, un canal privado aquí en UK.
Espero retomar el ritmo de publicación aquí en EstadoBeta y matener a los fieles lectores informados de mis actividades como Desarrollador Web en esta alucinante ciudad.
- Servicios:
- Comentarios RSS
- Menear!
- Del.icio.us
8/31/2008 at 3:24 pm
Una duda, leyendo tu texto, veo que comentas sobre realizar muchos Tests, tests, tests,…
Bien que es un test de una web, los test no es probar a mano si va un formulario bien, o si tal función hace siempre un el resultado que quieres reciba la clase de parámetros que reciba,..
Y lo mas difícil aun para mi es entender lo que comentas de realizalo antes que la programación ahí si que veo difícil de imaginar como hacer eso, espero me puedas explicar mejor en en consiste para entenderlo.
8/31/2008 at 5:40 pm
Muy interesante conocer de estos fracasos que dejan lecciones importantes. Me alegra saber que todo por Londres va caminando bastante bien. Me comentó Tomas que estarías de visita por Chile, que disfrutes.
8/31/2008 at 9:26 pm
se refiere a los test unitarios, se crean programas que prueban parte de otro programa:
http://es.wikipedia.org/wiki/Prueba_unitaria
8/31/2008 at 10:16 pm
De los fracasos se aprende más que en cualquier otra situación.
Veamos si me pego esa vuelta por UK pronto
Saludos.
9/1/2008 at 12:56 pm
Gracias por compartir tu experiencia de trabajo, espero que retomes el blog.
Saludos.
9/3/2008 at 8:10 pm
Me ha encantado la narración del fracaso del proyecto y cómo has extraído interesantes conclusiones, que todos conocemos, pero que es necesario contrastar contra un proyecto que no ha funcionado.
9/3/2008 at 9:41 pm
“un proyecto web se sustenta en la sintonía de los miembros del equipo más que en documentos de especificaciones, cartas Gantt o fechas de entrega.” uff eso me toco profundamente. Exito Ismael!
9/4/2008 at 11:42 am
Como dice un cometario por anterior, de los fracasos se aprende más que de los exitos, pero siempre y cuando tengamos la capacidad de autoanalizar en que se falló y buscar soluciones futuras.
Por ahi mencionas metodologías tales como XP, Scrum, etc. Quedé hasta mas arriba de la coronilla con dichas metodologías en la Universidad (estudié ingeniería despues de años de experiencia en desarrollo web como tu sabes) y como conclusión saqué que todas (si, absolutamente todas) las metodologías están obsoletas, están pensadas para procesos de desarrollo stand-alone o bien para procesos generales de cualquier ámbito, pero nada está hecho a la medida de un desarrollo web. OMT++ entrega bonitas implementaciones de clases luego de la fase de diseño OO, pero y? esas clases podré implementarlas en JavaScript? perdón V de MVC no contempla el front-end.
Suerte Ismael!!
9/4/2008 at 12:27 pm
Buena Coto.
OMT++ es una metodologia de disenio de software. Agile y sus primos son metodologias para organizar la carga de trabajo, la interaccion entre miembros del equipo y las expectativas del cliente. Todo esto es independiente de la tecnologia que uses y de hecho Agile se usa mucho en empresas que no tienen nada que ver con desarrollo de software.
Aunque esta lejos de ser perfecto, hasta ahora nos ha servido mucho en nuestros proyectos.
Mas sobre Agile: http://en.wikipedia.org/wiki/Agile_software_development
9/6/2008 at 1:31 am
OMT++ no sólo es de diseño, sino sólo su segunda fase. Su tercera fase incluye implementación y la cuarta es de pruebas.
Me gusta la filosofía de Agile, pero sigo con la sensación de que falta una metodología que permita hacer un “Análisis”, que obtenga fielmente las expectativas del cliente con una buena ingeniería de requerimientos y permita conocer la carga de trabajo con antelación; “Diseño”, que aterrize los requerimientos para transformalos en requisitos, permitiendo diseñar las clases de una Vista (también de un Controlador o Modelo en caso de que sea ‘aplicación web’ en vez de ’sitio web’) considerando la interfaz generada por lenguajes back-end y a JavaScript que es amo y señor en la capa Vista; “Implementación”, que organice la interacción desarrollador-desarrollador y cliente-desarrollador, y “Testing”, que permita asegurar la calidad, definiendo la ‘validación’ del equipo de desarrollo y ‘verificación’ del cliente. Todo lo anterior independiente de la tecnología que se utilize (excepto JavaScript que es omnipresente).
Ufff, parace que me explayé mucho
9/6/2008 at 10:28 am
Coto, estoy de acuerdo contigo en que la comunicacion entre las distintas “habilidades” dentro de un equipo es dificil y no hay metodologias perfectas que se hagan cargo del problema.
Dicho eso, el “cambio de cabeza” que exige Agile es aceptar que un proyecto de desarrollo es inherentemente variable, sin requerimientos fijos.
Por experiencia sabemos que en cada proyecto el cliente cambia de opinion cada 5 minutos, o que una vez que una funcionalidad esta terminada nos damos cuenta de que no es exactamente lo que necesitamos. En metodos tradicionales se tiende a culpar al cliente, a la falta de requerimientos o a una falla por parte del equipo. Agile reconoce que el desarrollo es un proceso evolutivo y por eso se basa en iteraciones muy cortas que permiten ir ajustando el rumbo y acomodandose a las necesidades cambiantes del cliente (o cambios en las reglas de negocios) con la minima perdida de energia posible. Pero eso significa que, en Agile, no es realista tratar de conocer “la carga de trabajo total” o tener todos los requerimientos antes de empezar el proyecto. No hay cartas Gantt, y se requiere que el cliente este dispuesto a aceptar un contrato abierto donde se paga por iteracion en lugar de todo el proyecto.
La idea suena arriesgada y no todos los clientes estan dispuestos a aceptar ese tipo de trato, pero en la practica esto significa que el equipo tiene mas libertad para corregir el rumbo a tiempo y el cliente mas relevancia en la toma de decisiones, haciendo el costo final mucho menor para las dos partes. Estoy terminando el segundo proyecto Agile y me atrevo a afirmar que la cosa funciona, y funciona bien. No perfecto, pero mejor. Otra de las premisas de Agile es que se aprende de los errores de cometidos para ir refinando el proceso. Por eso se hacen “retrospectivas” (reuniones cortas de evaluacion y ajuste) al final de cada iteracion.
Hay mucho mas detalles de los metodos usados (Historias de Usuario, Poker de Estimacion, Graficos de Desgaste, Acciones) pero eso da para otros articulos.
9/6/2008 at 1:16 pm
Indagaré y leeré mas acerca de Agile para hacer mi siguiente comentario, mientras tanto encuentro muy atractivas las ventajas que ofrece mencionadas por ti, sólo faltaría agregar métricas para asegurar la calidad (”lo esperado por el cliente es igual a lo obtenido?”), algo así como el estándar ESA, pero sin su abultada documentación.. puaj,
Aunque con iteraciones de alta frecuencia igual se puede asegurar calidad, eterna discución con el profesor de ingeniería de software.
9/6/2008 at 1:51 pm
Uno de los puntos centrales de Agile es manejar las expectativas del cliente (”lo esperado es igual a lo obtenido”). Par eso se usan Historias de Usuario (”Como usuario del sitio, quiero poder registrarme en una sola pagina y recibir un correo de confirmacion”) que se divide en tareas de desarrollo (”implementar clase Usuario”, “implementar modelo de seguridad”, etc) que son estimadas por el equipo (mientras mas granulares las tareas, mejor). Las historias se crean al comienzo de cada iteracion hasta llenar el limite de dias de trabajo de la iteracion (1 o 2 semanas).
Las tareas se ponen en un plan de iteracion con varias columnas (”pendiente”, “en proceso”, “verificar”, “hecho!”). Cuando cada tarea llega a la columna “verificar”, se le pide al cliente que pruebe la funcionalidad. Solo se pasa a la columna “hecho!” cuando el cliente esta contento con la tarea.
Cuando todas las tareas en una Historia se completan, el cliente puede verificar la historia completa nuevamente. Si esta contento, se cierra la historia y se pasa a la siguiente. Si no se retoman las tareas incompletas. Si el cliente se da cuenta de que la Historia completa no le sirve, se crea una nueva Historia junto con el. Se crean las nuevas tareas y se estiman. No se puede aumentar el tiempo de trabajo de una iteracion, asi que si el cliente quiere la nueva Historia como parte de la iteracion, debe sacar alguna otra historia pendiente y moverla a la iteracion siguiente.
9/20/2008 at 11:52 am
Buen post Ismael. Sin duda que son experiencias valiosísimas. Te aseguro que muhcos de nosotros llegamos a las metodologías ágiles “a la mala”. A mi me pasó lo mismo hace algunos años en un par de proyectos y desde entonces soy un “XP evangelist” en todas las partes donde trabajo.
De todas formas pensar en diseños escalables en la etapas tempranas no es un completo error. Simplemente debe ser un equilibrio de cosas, por lo menos tener un buen diseño arquitectónico qu garantice que la cosa crecerá, pero claro, cuando uno implemente detalles desde un inicio entiendo que la cosa comienza a complicarse y ahí es donde uno comienza a gastar más horas en activemq, solr, proxys, cache, memcache, etc etc etc que en trabajar por la real cosa diferenciadora de tu producto.
Saludos!
Toño.
9/25/2008 at 2:29 pm
Muy interesante el post. Estoy en mis nuevas clases en el CCRMA y hoy hablamos del “Second System Effect” y me acordé de lo que había leido acá.
Second System Effect
Saludos,
J