Comments on: En qué he estado http://www.estadobeta.com/2008/08/31/en-que-he-estado/ desarrollo web con estándares Tue, 14 Feb 2012 20:00:29 +0000 http://wordpress.org/?v=2.3-alpha By: fzslyrvehd http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-97494 fzslyrvehd Fri, 23 Apr 2010 19:07:56 +0000 http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-97494 I can't read your webstie ni Opdra 2.2, just figrued I might tell you about it. <a href="http://videosepulchre.blogspot.com/2010/03/video-guano-neglectful.html ">htis oikn </a> I can’t read your webstie ni Opdra 2.2, just figrued I might tell you about it.

htis oikn

]]> By: Jorge http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-42224 Jorge Thu, 25 Sep 2008 18:29:06 +0000 http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-42224 Muy interesante el post. Estoy en mis nuevas clases en el CCRMA y hoy hablamos del <b>"Second System Effect"</b> y me acordé de lo que había leido acá. <a href="http://en.wikipedia.org/wiki/Second-system_effect" title="Second System Effect" rel="nofollow">Second System Effect</a> Saludos, J 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

]]> By: toño http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41960 toño Sat, 20 Sep 2008 15:52:52 +0000 http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41960 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. 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.

]]> By: Ismael http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41620 Ismael Sat, 06 Sep 2008 17:51:45 +0000 http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41620 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. 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.

]]> By: Coto http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41617 Coto Sat, 06 Sep 2008 17:16:10 +0000 http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41617 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. 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.

]]> By: Ismael http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41604 Ismael Sat, 06 Sep 2008 14:28:03 +0000 http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41604 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. 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.

]]> By: Coto http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41596 Coto Sat, 06 Sep 2008 05:31:39 +0000 http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41596 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 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

]]> By: Ismael http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41535 Ismael Thu, 04 Sep 2008 16:27:06 +0000 http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41535 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 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

]]> By: Coto http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41534 Coto Thu, 04 Sep 2008 15:42:36 +0000 http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41534 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!! 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!!

]]> By: Jorge Epuñan http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41443 Jorge Epuñan Thu, 04 Sep 2008 01:41:25 +0000 http://www.estadobeta.com/2008/08/31/en-que-he-estado/#comment-41443 "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! “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!

]]>