Friday, March 23, 2007
Tuesday, March 20, 2007
Friday, March 09, 2007
Wednesday, March 07, 2007
Mis esfuerzos de colorear en Paint..
Sin embargo he tomado algunos consejos de la gente conocedora de esto y otro más
Obviamente no tengo la misma herramienta que ellos pero obteniendo el concepto basico y con el conocimiento del manejo de imagenes en C# se consigen efectos similares.
Como no he querido intentarlo primero con la imagen más grande he decidi probar los conceptos en algo más pequeño.
2.-Remarcar más las lineas de la figura.
También conocido como Lineart, es remargar contornos y lineas para que la imagen no se vea borrosa y sea más facil aplicar los colores.
3.-Aplicación de fondos
Yo prefiero hacerlo como un paso intermedio en el coloreo.
Obviamente esta tarea se simplifica dependiendo de la clarificación que hayas hecho (especialmente en paint donde los pixeles tienen que ser exactos al que intentas rellenar y normalmente tienes una gran cantidad de tonalidades siendo que de lejos se ve bien)
En este caso las sombras, oye no te mataste haciendo el Lineart y la clarificación para olvidarte de los claros obscuros
public void EscalarGris(Bitmap bmImagen)
{int j,i;
unsafe //Porque es posible que explote
{
//se genera otra zona a modificar (x,y,ancho,largo,como se lera y los colores usados)
paso = bmdDatos.Stride ; //Para recorrer el arreglo donde se carga la imagen
linea = bmdDatos.Scan0 ; //Donde se tiene que apuntar para leer la imagen
offset=paso - (bmdDatos.Width *3); //Para evitar diferencias entre el tamaño de la fila y el numero de bytes en la misma.
byte * bByteArray = ( byte *)( void *) linea ;
for (j=0;j<750;j++) i="0;i<500;i++){">
if (valor<255>=210)
{
bByteArray [ 0 ] = ( byte )( 0 ); //Azul
bByteArray [ 1 ] = ( byte )( 0 ); //Verde
bByteArray [ 2 ] = ( byte )( 0 ); //Rojo
}
if (valor<210>&& valor>= 150)
{
bByteArray [ 0 ] = ( byte )( 100); //Azul
bByteArray [ 1 ] = ( byte )( 100); //Verde
bByteArray [ 2 ] = ( byte )( 100); //Rojo
}
if (valor<150>&& valor>= 60)
{
bByteArray [ 0 ] = ( byte )( 155); //Azul
bByteArray [ 1 ] = ( byte )( 155); //Verde
bByteArray [ 2 ] = ( byte )( 155); //Rojo
}
if (valor<60>&& valor>= 0)
{
bByteArray [ 0 ] = ( byte )( 255); //Azul
bByteArray [ 1 ] = ( byte )( 255); //Verde
bByteArray [ 2 ] = ( byte )( 255); //Rojo
}
bByteArray += 3;
}
bByteArray += offset ;
}
bmImagen.UnlockBits (bmdDatos);
}
}
Y como funciona bueno..una imagen es un array de bits en pares de tres (Rojo, verde y azul) más datos de la misma imagen la cual al aplicar la formula valor = (int)((70 * bByteArray [ 2 ] + 150 * bByteArray [ 1 ] + 29*bByteArray [ 0 ])>>8) %65536 obtenemos una escala de grises con valores de 0 - 255 (blanco-negro)
El arreglo se mueve de izq a derecha y de arriba a abajo.
Dependiendo del valor que obtengas solamente debes determinar que rangos deben volverse de determinado color
En efecto, sin embargo, el instinto de magiver actuo en mi, además usar 700 Mb en mi disco para cambiar imagenes los tonos de una imagen que ya esta en gris me ha parecido excesivo.
Bueno el resultado me lo da en negativo pero es algo que paint puede manejar sin problemas.
Colorear y lineart lo hago al paso ya que no tengo ni una idea de como debería verse un cabello negro tirando a azul purpura con una gran fuente de luz por detras
Progreso hasta ahora.
Final sin fondo
Criticas, Sugerencias y link a un programa liviano de edición son recibidos
Tuesday, March 06, 2007
Friday, February 16, 2007
Invento Práctico
Para esas ocaciones requieres aplicar todo conocimiento que hayas adquirido como puede ser R.C.P., electromagnetismo para brujulas, producción de electricidad, nudos variados y porque no, Un lanza llamas casero.
Así es, como lo vío en los videos instructivos de cualquier organización terro... digo de cocina. Tendremos a nuestro joven instructor que nos guia en los pasos para la construcción de este lanza llamas, el cual fue pensado para aquellas eventualidades que una nunca puede olvidar: Enfrentar a un animal feroz, disuadir a una turba iracunda para llegar a la loncheria, abrirse paso entre un ejercito de zombies, preparar el terreno para la siguiente cosecha ó hacer un pollo rostizado.
Asegurese de tener permiso de sus autoridades locales para la fabricación de este dispositivo, que no infringe ninguna ley con su uso, además de no sufrir de píromania.
Wednesday, February 14, 2007
Así funciona la web 2.0?
http://www.1-click.jp/
Tuesday, February 13, 2007
Friday, January 26, 2007
Tuesday, January 23, 2007
0, digo Cero, digo Zero
Por que ellos no podian ser Light++.
Wednesday, January 17, 2007
Fuentes de información
Para cuestiones como esta y con la ayuda de internet y varios usuarios sin que hacer desinteresados se pudo armar la Wikipedia, pero como proyectos de esta envergadura (sin albur) suele replicarse tambien nacio la Frikipedia pero como se necesitaba una versión más cercana a las lenguas romances nacio la Inciclopedia.
Dentro de la Inciclopedia se desglozan interantes articulos desde las introespectivas del Yo hasta consejos practicos de como Dominar el mundo con la ayuda de prácticas herramientas computacionales
Y describiendo su información en los lenguajes más abstractos del ser humano.
Es por estas razones que Internet siempre es una gran fuente de información ^_^.
Monday, January 15, 2007
El invento esperado
Monday, January 01, 2007
Wednesday, December 27, 2006
Y el 2006 se va
..
..
..
bueno no me acuerdo bien de todo :P, sin embargo se que hemos visto cosas increibles, inteligentes, interesantes, internacionales, institucionales, inpen sables, incom prensibles, importantes, intelectuales, inentelegibles, inalcanzables, inciertas, inpudicas e inom brables.
Pero lo bueno de los años es que siempre se espera y se trabaja para que todo salga mejor; así que felices fiestas.
Monday, December 04, 2006
Tuesday, October 17, 2006
Las 10 (ó 9) dimensiones
Honores de la traducción MalaCiencia, el original Aquí
Seguramente el lector esta acostumbrado ha ver su mundo bajo el concepto de alto, largo y ancho, es decir, 3 dimensiones.
Sin embargo algunos cientificos se dan a la tarea complicarnos un poco más la existencia ó tratar de explicar lo complicado de esta.
Para este ejemplo necesitamos que el lector piense en un punto (.), si un punto, el cual no tiene ningúna dimension (no es de un alto, ancho o profundidad medible) en si un absoluto.
Suponga el lector que existe el mundo ó mejor dicho la dimensión punto donde sus habitantes solamente pueden estar donde estan, es decir, sin pueder moverse.
Ahora imagine una dimensión igual y trace una línea entre ambos punto, ahora tenemos una dimensión y los habitantes de los puntos pueden mover para atras y hacia adelante.
Repita el procedimiento con 2 puntos totalmente diferentes y cuya linea cruce la que ya estaba hecha anteriormente, acaba de crear la segunda dimensión y sus habitantes tienen largo y alto, y pueden moverse de arriba a bajo y adelante y atras.
Por supuesto la gente de los puntos a un existe y cualquiera puede viajar no solo en su línea sino en la línea que los cruza en el punto de intercepción aunque no pueden ver a las personas que viven en la segunda dimensión.
Ahora ¿Que pasa si alguien en punto desea viajar a otro sin tener que pasar por el punto de intercepción?, Sencillo, si han estado dibujando este ejercicio ahora escojan 2 puntos y doblen la hoja, ahora nuestro amigo puede viajar a donde desea gracias a nuestro pliege (lo cual también aplicaría si lo hicieramos para las lineas o nuestra 2da dimensión), pero también abremos creado profundidad entre las 2 dimensiones por lo cual acabamos de generar una 3ra dimension.
Obviamente aquí habitan seres de 3 dimensiones (gente como nosotros), ok, hasta aquí sabemos de tenemos puntos conectados y que estos puden plegarse para generar varias dimensiones, correcto, Ahora conviertan estas 3 dimensiones en un punto, (si de aquí deriva la deducción ó el truco llamenlo como deseen).
Al igual que al principio solamente estaríamos presentes sin poder movermos algo así como la pintura de un paisaje se ven los arboles que estan cercas y las montañas a lo lejos pero nada se mueve. Al igual que al principio crearemos otro punto y los uniremos con otra línea, ahora nuestros objetos tienen movimiento gracias a nuestra 4ta dimensión, el tiempo.
La 5ta dimension se aplica como lo que se vió en Volver al futuro 2 (:Publicidad subliminal: Disponible en BlockBoster :/Publicidad subliminal:) donde Martín y el Doc se encuentran atrapados en un presente diferente del que vinieron pero real para todo el mundo debido a que el malo del futuro se entrega a si mismo (malo del pasado) información para volverse millonario (el malo del presente). En la representación que hizo el Doc ellos habian ido al futuro desde su realidad atraves de su línea de tiempo y al regresar al presente callerón en esta la línea del tiempo.
Estas lineas del tiempo serían las que hicimos cuando creamos la 2da dimension (esta sería la 5ta dimensión) he igualmente si el Doc y Martin desean regresar a su linea deben pasar por donde se cruzan las líneas ó encontrar un punto donde se pliegue las líneas o los puntos en el tiempo y saltar a su linea (lo cual nos daría la 6ta dimensión).
Ok, que tenemos hasta ahora mundos de 3 dimensiones con su propia historia, desiciones y sucesos que pueden estar unidos en diferentes puntos gracias a los cruces entre las líneas y los pliegues que hagamos. Muy bien parece que hemos cubierto todo, correcto, pero la verdad es que todas estas líneas tiene un punto de creación común.
Pero supongan que existierón diferentes creaciones y cada una con sus diferencias así que cada una de estas diferentes creaciones son puntos y que podemos viajar a estos universos atraves de una línea (7ma dimensión) y que estas líneas a su vez se cruzan en algún punto (8va dimensión) ó que se tuerce la dimensión para saltar entre universos y dimensiones (9va) y que todo esto es un punto (10ma)
De acuerdo, podemos continuar, pues, aparentemente no; ¿por que no podemos hacer otro punto y otra línea?, yo pregunto ¿como? ya abarcamos todo lo que es posible, diferentes mundos, diferentes tiempos, diferentes creaciones y universos no es posible avanzar más pero segun supercuerdas aún no llegamos a las 23 dimensiones posibles. Para la programación es facil, solo debemos hacer un int[a][b][c][d][e]...n; Expliquen esto en primer semestre el primer día que vean arreglos en programación y fijense cuantos descertan xD.
Monday, October 09, 2006
Scrum (Estilos de programación)
Agile = More Work
Agil.
Que bonito suena. Sólo de escuchar esa palabra siente uno la suave brisa en el rostro y el radiante sol bronceando nuestra piel al mismo tiempo que el canto de los pajaritos nos anuncian la llegada de la libertad.
"ah!!, que a todo dar.. nada de documentación, nada de UML o diseño, ya no haríamos planes, no hacer estimación!...sin juntas de avance, directo a programar!... hay que adoptar eso en la empresa!!"
Sabemos que ni de chiste nuestros clientes ó directores nos dejarían trabajar de esa forma. Pero lo que nos intriga es que hemos escuchado que existen equipos de desarrollo que trabajan así. ¡Suertudos!. Sin UML, sin diagramas de casos de uso, piñas coladas junto al teclado, sandalias y pantaloncillos cortos, sin el líder de proyecto encima con su fastidioso '¿como vamos?' cada día. Llegar a trabajar a las 11 y salir a las 4. Después de todo no hay deadline. Las cosas saldrán cuando tengan que salir, que no presionen.
El problema, por supuesto, es que todas esas son nociones totalmente equivocadas de lo que es trabajar siguiendo una disciplina ágil.
Cualquiera que crea que el desarrollo ágil es más conveniente para los programadores que para los managers, esta un poco equivocado. Mucha gente que practica este tipo de disciplinas han descubierto que:
es mucho mas arduo el trabajo diario para los programadores cuando sigues una disciplina ágil
y que, por el contrario, las ventajas que ganan los clientes y stakeholders son enormes. Como lo dice Tim Ottinger de Object Mentor:
I remember when I first started reading about eXtreme Programming. The theory then was that it was going to make programmers happy, but that management would never go for it. Now we find that the argument is that it's great for managements, but that it is harder for programmers? Why the 180-degree turn? Have we sold it more successfully to managers than to programmers?
¿Sorprendente?
En IT Conversations hay una sesión muy interesante con Ken Schwaber (creador de Scrum) en donde explica la razón de este fenómeno.
Ken describe cómo el ejecutar un proyecto con Scrum requiere completa entrega de cada uno de los desarrolladores en cada uno de los días del proyecto. Llevar Scrum es bastante más difícil e intenso que hacer software 'de la manera clásica'. Requiere un compromiso especial y total de cada uno de los integrantes del equipo.
Por lo mismo, una de las principales dificultades para adoptar Scrum, ó cualquier otra disciplina ágil, es que no todo mundo está dispuesto asumir ese tipo de compromiso. Todos seguramente conocemos algún developer que suele pasar días haciéndo como que trabaja y luego poner pretextos para justificar que no ha avanzado. Nuestra cultura ha permitido que ese tipo de personas puedan pasar años y años en un puesto de desarrollo sin mucha dificultad. En particular, escuché de un equipo que después de adoptar Scrum, instituyeron el 'Wally Award', en honor del personaje de Dilbert, premio que es asignado por todo el equipo al mas flojo de los desarrolladores después de la junta scrum diaria. Esa es presión que no todo mundo soporta.
En un equipo que sigue un modelo ágil todos están expuestos permanentemente a una visibilidad mucho mas grande. Las cosas son mas 'transparentes'. El avance (o la falta de) es mas evidente.
"No es cierto, en mi empresa el líder de proyecto checa diario los avances con cada uno. No se necesita Scrum para eso"
Ok. Hay una enorme diferencia entre tener a un project manager revisando el avance todos los días y llevar una disciplina como Scrum. De hecho, cualquiera que conozca Scrum sabe que la manera de ejecutar la planeación y revisión de avances es casi el 90% de lo que la 'metodología' te especifica.
Como lo describe Ken Schwaber, la forma de trabajar de Scrum tiene como objetivo eliminar tres grandes errores de la disciplina 'tradicional' de administración de proyectos de software:
1. Asignar trabajo en forma de tareas es mala idea
El project managemente 'tradicional' consiste en asignar tareas a los desarrolladores, muchas veces una larga secuencia de ellas, y en ir revisando que las ejecuten en el tiempo y secuencia establecidos por el plan.
Mala idea
Por mas empeño que le ponga el project manager a especificar "cada una de las tareas necesarias", siempre ocurre, tarde o temprano, que el programador se va a encontrar con que faltan y sobran tareas.
¿Cuantas veces no nos han asignado una serie de tareas que luce mas o menos así?:
- Tarea T00341: 2 horas, Elaborar diseño de clases de negocio de caso de uso de cargo a cuenta
- Tarea T00342: 1 hora, Construir alta de registro de caso de uso de cargo a cuenta
- Tarea T00343: 2 horas, Construir eliminación de registro de de caso de uso de cargo a cuenta
- Tarea T00344: 2 horas, Construir busqueda de registro de de caso de uso de cargo a cuenta
- Tarea T00345: 1 hora, Construir modificación de registro de de caso de uso de cargo a cuenta
- Tarea T00346: 1 hora, Construir componente de interfaz de usuario de caso de uso de cargo a cuenta
- Tarea T00347: 2 horas, Construir elemento de menu de caso de uso de cargo a cuenta
- Tarea T00348: 4 horas, Pruebas del componente de caso de uso de cargo a cuenta
ARGGHHH!! además de que simplemente mirar el plan de trabajo hace mas daño a los ojos que el salir a ver el sol directamente por un par de minutos, en cuanto el programador descubre que para hacer el cargo a una cuenta se necesita, no se, digamos, un método que sabe redondear los montos de acuerdo a reglas del negocio complejas y que nadie conoce, entonces surge desde las mas profundas entrañas del infierno un mounstro por todos temido conocido por los eruditos en temas macabros como 'la tarea no planeada'.
Este engendro de satanás, la 'tarea no planeada', representa con su malevola existencia un retraso al plan de trabajo que desestabiliza todo el proyecto y que causa miradas de odio contra el programador que la descubrió por 'poner trabas' al avance. En el caso de que el valiente y temerario project manager se decida a enfrentarla, la 'tarea no planeada' le abriá nuevamente aquella úlcera que creía olvidada por el simple hecho de obligarlo a abrir de nuevo el archivo de Microsoft Project que le llevó 4 noches enteras ajustar a la fecha de entrega prometida y que ahora tendrá que modificar con el mismo cuidado (posiblemente con y los mismos resultados) que implicaría retirar el 3 de diamantes de la base de un castillo hecho con naipes.
En la mayoría de los casos, sin embargo, la 'tarea no planeada' es ignorada por todos con la esperanza de que, empujada por el rechazo e indiferencia, vuelva despúes de un rato a arrastrarse de vuelta hacia las entrañas del averno, dejando tranquilos al equipo y a su plan de trabajo, que después de todo ya había sido 'bendecido' por 'el ser supremo', y eso es signo de perfección.
Además de la infame 'tarea no planeada', el programador se va a encontrar como muchas tareas que si fuéron planeadas, pero que son tareas inútiles, duplicadas y sin sentido. Pero, ah!, cuidado con que caiga en la casi herética desobediencia de no reportar avances sobre ellas por que todos sabemos lo que puede pasar si hacemos la observación de que 'esa tarea no aplica' (para el que no esté acostumbrado a la jerga del profesional de sistemas, el término 'esa tarea no aplica' es en muchos lugares el término técnico para 'yo soy un holgazán que no quiero trabajar y el project manager es un imbecil y su virilidad y ética profesional son de bastante dudosa naturaleza').
Scrum, por el contrario, está diseñado a partir de un pequeño conjunto de aventuradas premisas (que tal vez en algún futuro algún grupo de iluminados científicos podrán comprobar o refutar):
- Que desarrollar software es un poquito más complejo que poner ladrillos en una construcción.
- Que los programadores tienen habilidades de análisis y solución de problemas un poco mas elevadas que las de un obrero de línea de ensamblaje de una fábrica.
- Que un equipo de desarrollo está formado por profesionales (aqui es desgraciadamente donde luego se viene todo abajo, pero eso es otro tema).
- Que los profesionales de cualquier ramo son los más indicados para determinar cómo hacer su trabajo para llegar a los resultados .
Obviamente lo de 'premisas aventuradas' es sarcasmo. En fin, el punto es que:
La asignación de trabajo basada en tareas no funciona.
Es como ir con el mecánico a que repare tu auto y en vez de pedirle que 'cambie el aceite', decirle 'mira, primero levantas el auto con el gato hidráulico, luego tienes que usar una llave inglesa para quitar la tuerca del depósito, luego vas por una cubeta y dejas que salga el aceite que actualmente está en el motor, etc. etc.'.
Suena ridículo, pero si sabemos que es estúpido querer dar a cualquier profesional (incluso a un mecánico de autos, que se pudiera calificar como un oficio no profesional) una lista detallada de tareas que le digan cómo hacer su trabajo ¿por que demonios queremos que eso suceda en el desarrollo de software?
El más indicado para determinar que tareas realizar en una actividad compleja es el experto. El profesional. Sobre todo porque en cualquier actividad compleja (creo que es evidente que el desarrollo de software es una de las tareas mas complejas que existen) hay incertidumbre. El experto es quién mejor puede decidir cuáles son las tareas necesarias cuando se encuentra con un problema durante la ejecución.
En vez de usar 'tareas', Scrum asigna trabajo en forma de elementos que representan entregables con valor funcional para el cliente. Por ejemplo, en vez de la lista de tareas detalladas, tendríamos algo como:
"Un comercio puede hacer un cargo a la cuenta del cliente a través del sistema"
El equipo tendrá que decidir si puede o no estimar esa funcionalidad (tal vez es de muy alto nivel y se necesita descomponer en fragmentos de funcionalidad mas pequeños para poder estimarla), decidir si es posible terminarla para la próxima iteración, investigar los detalles de cómo debe funcionar, organizarse para trabajar en ella y asegurarse de que funciona correctamente. El equipo tiene que determinar cómo y cuándo ejecutar cada una de estas actividades. Todo como profesionales que saben entregar resultados y lograr objetivos de beneficio para el cliente.
Por eso trabajar al estilo 'Agile' significa más trabajo para el desarrollador, pues esto impone un grado de responsabilidad mayor sobre todos los integrantes del equipo. Nadie puede cómodamente sentarse en su cubículo el día entero y limitarse a cumpilr una tras otra con las tareas asignadas por su project manager.
El segundo error que Scrum busca eliminar es:
2. Revisar el avance de cada programador por un supervisor y de forma aislada es mala idea
En un projecto 'tradicional' de desarrollo de software, cada programador ya tiene una lista de tareas asignada. En el caso típico de revisión de avances, tenemos el siguiente escenario entre el project manager (PM) y el desarrollador (DEV):
El PM se acerca sigilosamente al programador con una impresión del archivo de Project en la mano.
PM: Que onda, ¿cómo vamos con lo de cargo a cuentas?
El DEV siente el frio correr por su espalda y piensa para si mismo mientras sigue tecleando simulando estar muy concentrado para contestar:
"vamos?? me suena a muchos!! como voy, querras decir, maldito! ¿a ver, pues enseñame tú que has hecho, digo, además de este adefesio de plan de trabajo?!"
pero finalmente contesta:
DEV: "ehh.. ahh.. lo de cargo a cuentas... ehh.. si.., ya prácticamente está listo. ya nomas faltan unas cosillas"
DEV: (terminarlo y que funcione), piensa.
PM: Acuerdate que de acuerdo al plan eso tenía que estar para ayer. Nos estamos retrasando.
DEV: Ehh... ahh.. eh.. si. Es que tuve que hacer la parte del guardado de la configuración.
PM: Hmmm.. Ok.
DEV: ...
PM: Oye, ¿Configuración para qué??
DEV: Pues para lo del combito del catalogo de cuentas.
PM: Hmmm.. ok.. si, ya entendí.. Oye, pero si eso ya estaba, no?, es
DEV: Pero es que el componente que había lee la configuración de una base de datos, yo tuve que hacer un componente que guardara la configuración en un XML pues del lado del cliente no hay base de datos.
PM: Pero eso lo tenía que haber hecho el que hizo el componente de configuración. Se supone que la tarea del componente de configuración ya esta 100% terminada.
DEV: Es que le pregunté si ya lo había hecho, pero me dijo que no sabía que tenía que haber soporte para XML en el componente de configuración.
PM: Bueno, ¿pero por que te tomó tanto tiempo si ya casi estaba?. ¿Nada mas necesitabas hacer copy-paste del código del otro componente, no?
DEV: ¿copy-paste de ASP a C++ ?
PM: Pues si, no?
DEV: no.
PM: Ok. Hmm.. Hijole.., es que esto 'ya nos esta pegando en los tiempos'
DEV: piensa: (pues si, y? ...que quieres que yo haga?)
PM: En que te puedo echar la mano? Pasame el código para ver en que te puedo ayudar.
DEV: piensa: (Ni lo intentes, desgraciado. Alejate de mi código)
DEV: No, gracias, ahorita en nada, ya casi está.
PM: Orale. Ahi cualquier cosa me dices. ¿Si crees poder empezar hoy con
DEV: Ok... si.. Deja veo. Yo creo que si, esto ya casi queda.
PM: Sale. No se te olvide reportar tus horas.
Este escenario muestra los problemas típicos de este tipo de seguimiento al avance:
- Falta de comunicación entre el equipo. Pueden pasar semanas enteras sin que un programador se entere de lo que están haciendo los demás.
- Falta de flexibilidad para resolver problemas conforme se van descubriendo.
- Falta de conocimiento de quién elabora el plan de trabajo acerca de cómo deben hacerse las cosas (puede no ser el caso general, pero es frecuente).
En Scrum, el avance no lo evalúa el project manager. Sino todo el equipo de desarrollo. Todos juntos. Todos los días.
Es mas. En Scrum el project management lo lleva el equipo de desarrollo.
El rol de Scrum Master (lo mas parecido a un project manager que tiene Scrum) se encarga de facilitar al equipo de desarrollo las condiciones propicias para que puedan trabajar. Pero no lleva la administración del proyecto como tradicionalmente se conoce.
La forma en que el avance se planea y se evalúa (sprint planning, daily scrum meetings, sprint review) es simple, pero no es sencilla. Es decir, aunque las reglas son pocas y simples, se requiere de mucha participación e interés de cada uno de los miembros del equipo para hacerlo bien.
¿La ventaja? el equipo es quién decide qué se debe hacer y cómo. Y cuándo cambiar esa decisión.
No 'alguien' desde 'arriba'.
Por último, pero a mi parecer el error mas importante que Scrum busca eliminar:
3. Que la secuencia de tareas no refleje las prioridades del negocio es mala idea
Tradicionalmente, es común que las tareas de un 'plan de trabajo' (entiéndase diargrama de Gantt de Microsoft Project) se acomodan de acuerdo a las dependencias entre componentes de infraestructura del producto, y no necesariamente de acuerdo a la prioridad de la funcionalidad del negocio.
Esta claro que si uno pone el cuidado suficiente, se puede lograr un Gantt que tenga las tareas prioritarias para el negocio al inicio. Sin embargo inevitablemente el pensar en 'tareas' llevan al equipo a pensar en desarrollo de componentes primero y funcionalidad en segundo término. Por ejemplo, es típico que la primer tarea de construcción en un proyecto tenga que ver con algo relacionado al 'framework de acceso a datos' o 'framework de aplicación'. Después de todo, los demás componentes dependen de esas piezas, no?
Pues si, totalmente cierto. Pero ese es uno de los motivos por el cual 3 meses ya entrados en el proyecto todavía no tengamos nada que mostrarle al cliente. Y seamos sinceros, de todos modos siempre tenemos que regresar a hacer 'ajustes' al 'framework' una vez que iniciamos la construcción de componentes 'funcionales', pues es muy dificil predecir exactamente cómo quieres que se comporte tu framework si no sabes aún como son los componentes que lo van a utilizar.
¿Quiere esto decir que Scrum te indica que hagas primero las 'capas de arriba' y luego 'las de abajo'?
Claro que no. Scrum no te dice eso. Sería como si tu fueras un mecánico y Scrum te llevara su auto a que le cambies el aceite y te quisiera dar instrucciones detalladas de cómo acerlo.
Scrum sabe que eres un profesional y que sabes que necesitas hacer para entregar la unidad de trabajo asignada, que es un fragmento de funcionalidad útil para el cliente. Si eso significa que harás primero 'las capas de arriba' para luego ver como haces 'las capas de abajo', adelante. Si eso significa que vas a ir armando tu framework poco a poco al mismo tiempo que tus 'capas de arriba', adelante. Si quieres terminar totalmente el framework primero, adelante y suerte al negociar tus primeras iteraciones con el cliente en donde no vas a tener nada que mostrarle.
Y esta es la tercer razón por la que el trabajo en Scrum es mas dificil. El compromiso es entregar funcionalidad útil. No cantidades de líneas de código de infraestructura, que por si solas, no sirven para nada relevante.
Conclusión
¿Quieres trabajar usando una disciplina ágil como Scrum?
Entonces prepárate para trabajar más. No más tiempo. Sino con mayor intensidad. Más involucrado en el proyecto y sus metas, con más entrega, con mas responsabilidades. Preparate para trabajar duro.
¿Le quita esto el atractivo a las disciplinas ágiles? Claro que no.
Yo creo que es preferible estar en un equipo de desarrollo que se dedique a trabajar al 100% durante 8 horas todos los días y tener metas alcanzables, claras, compartidas, realistas, pensadas para lograr rápidamente beneficios para el cliente y que exigen de tu creatividad como profesional, que tener que trabajar 14 horas todos los días en una serie fija de tareas, concretas pero muchas veces mal planeadas, que no 'encajan', que te exigen muchos teclazos en vez de mucho talento como profesional del desarrollo de software.
Disclaimer
Como todas las herramientas, estoy totalmente conciente de que Scrum no es aplicable a cualquier situación (proyectos de outsorcing remoto/offshoring son especialmente dificiles de llevar con Scrum). Sin embargo lo interesante es que mucha gente piensa que disciplinas como Scrum sólo funcionan en proyectos 'sencillos'. Se cree que para proyectos 'complejos' tienes que empezar a usar técnicas mas 'tradicionales'.
Friday, September 29, 2006
Blog Reborn
Es bello ver cuando tu usuario se da cuenta que lo que pidio es más grande de lo que pensaba mostrandole lo que es tener que hacer Diseño De Sistemas (el problema es que se da cuenta cuando llevas 2 meses en algo que se planeo para 3 semanas :P)
Un poco más de post, aquí una desaventuranza del webmaster en cristalab.
Nota: agrego intervenciones en brochetes
Este webmaster se disculpa de antemano por el lenguaje soez que a continuación será expresado en estas cortas palabras. Pero a la mierda, yo hablo como se me de la gana en situaciones como esta, que alguna ventaja ha de tener pagar el puto hosting. Amen. [Eso]
El martes pasado a las 06:30am salía mi vuelo. Tenía un viaje de negocios a Medellín/Colombia en el que la misión era supervisar el montaje de un stand que mi agencia le vendió a una empresa de la que no hablaré, pero que diré que está dirigida por Yakuzas. Dejo como ejercicio al lector averiguar que empresa es. [Sony es un gran candidato xD]
El lunes anterior tuve un trabajo que no pude entregar y por el que trasnoché, llegando a no dormir nada y a no terminar el trabajo [ Como suele pasar ]. Desesperado, arreglé lo que pude para que medio funcionara, lo envié a mi otro cliente, me bañé y me fui al aeropuerto porque ya eran las 5:30am.[Para entonces estaria lejos del otro cliente]
El vuelo de mierda salió a las 8:20am por un “problema meteorológico”. No solo eso, sino que el vuelo aterrizo en Rionegro, una ciudad que queda a una hora de Medellín por carretera.
A las 10:30am, llevado, con sueño y ganas de matar y beber sangre, me dirigí a las oficinas de carga pesada de mercancía a ver si habían llegado las cajas y demás paquetes del stand. Todo parecía en orden excepto que las cajas eran inmensas, la estructura metálica venía ARMADA y su tamaño era tan masivo que tuvimos que pedir un camión para cargarlo todo.
El camión no llegó.
Afortunadamente, según el folleto que me dieron, el centro de convenciones era a una cuadra de la agencia de carga, por lo que monté todo en dos carritos de acarreo de mercancía que me prestaron en la oficina de envíos y anduve tal cual reciclador por las calles con mis cajas.
La dirección del folleto estaba mal. El evento era en la plaza de exposiciones, un centro inmenso a diez kilómetros. Hay que ser hijo de puta para, en estas condiciones, con sueño, cansancio de viaje y una tonelada dividida en carritos, escribir mal la dirección en el folleto.
¿Ya les conté que NO tenía hotel y que al mismo tiempo cargaba con mi maleta de viaje?
El hecho es que llegué al medio día al centro de convenciones ese. Contratamos a una empresa de montaje de eventos para que armara el stand, así que descargué las cajas y demás, la estructura inmensa, etc. Salí a buscar a la gente de logística, ellos me acercaron hacía el supervisor de los que montan los stands, hablé con él y me dijo que no tenía ningún contrato conmigo, que estaban todos sus “muchachos” muy ocupados y que no iba a montar mi stand.
WHAT THE FUCK!?
Busqué otro puto carrito de reciclador, monté en 4 viajes cada caja por partes y lleve todas las cajas de mierda al stand de 3x3. El sueño que tenía era indescriptible, de haber estado en mi casa ya me habría rendido y caído dormido sobre mi suave colchón (Disclaimer: Mi colchón no es suave). No tenía herramientas, no tenía ni siquiera un bisturí para romper las bandas de seguridad que le ponen en los aviones a este tipo de cajas. Mencioné siete veces a la madre del que se negó a montar todo y me puse, con un palito, a torcer los seguros para romper las cajas.
¿Han ustedes enviado una tonelada de carga delicada por avión? Es decir, una estructura completa desarmada, que armada debe verse hermosa, dividida en cajas, embalada por gente mal pagada que trabajan de 4am a 6am. Para resumirles esta historia, unas cajas de luz (Cubos de madera y acrílico con un pendón en vinilo que tiene un banner publicitario e iluminación interna. Como los del metro y eso) se rasparon en todos los bordes, haciendo que estas se vieran horrendas y que mi negocio se fuera a aquel lugar que comparte Satán y la mierda.
Zen.
Conseguí que dos “muchachos” de los que montan stands me ayudaran con el mió por 30 dólares. No sin que ellos repitieran cada 30 segundos como, si el supervisor los veía, los despediría. Conocí todo tipo de insultos y maldiciones autóctonas paisas que me sirvieron mucho ese día. Dos horas después, hasta ahora terminábamos de desembalar las cajas y medio montar los cubos de luz. La alfombra especial del stand exigía ser pegada con pegamento de caucho. Le di dinero al muchacho #1 para que lo fuera a comprar mientras nosotros seguíamos armando todo. Sacamos los 24 tubos de una estructura que permite colocar una pancarta de 3 metros de ancho en la pared. El muchacho #2 vio el plano de montaje de esa cosa, dijo que ya volvía con herramienta adecuada y no volvió. Esperé una hora, ninguno de los dos regresó
Las 3:30pm, con un sueño inconcebible, la boca seca, la lengua ardiéndome por la falta de hidratación, sin haber comido nada desde las 5am, sin haber dormido nada, sudando por el clima de Medellín y la ausencia total de aire acondicionado, amarrando la estructura de mierda con las malditas cuerdas de seguridad que envolvían el embalaje de las cajas. No quiero ver la cara del cliente cuando desarme el stand y vea que por detrás sus pancartas estaban tensionadas por una estructura sostenida por cuerdas con la marca de la aerolínea.
El diseñador industrial (Z <3) color="#3366ff">[ O_o ], comí un sándwich de 5 dólares, una malteada con muuucho azúcar para recuperar energías, hice el checkout del hotel y ya eran las 6:10pm. Sonreí al recordar que por lo menos mi vuelo era en clase ejecutiva y descansaría como me merecía.
El vuelo, el vuelo...
El avión salía a las 7pm. El aeropuerto está a una hora y cuarto del hotel por carretera.
Salí del hotel, tomé un taxi intermunicipal, le pedí que se teletransportara y corrió a 110Km/h por una carretera que permitía un máximo de 60 [ Lo normal, ustedes saben ]. Le pagué, entré al aeropuerto, hablé con la persona del check-in y me dijo que el avión acababa de despegar mientras señalaba al mismo por la ventana corriendo por la pista. Juro por el honor de ésta web que si no fuera por la policía le habría partido la cara a la empleada. Era completamente imposible que todo esto me pasara, algo hice, algo malo (¿Yo? ¿Malo?) en éste universo para que todo conspirara en mi contra. ¿Brujería? ¿Shamanismo? ¿Mal de ojo? ¿Jigoku Shoujo?
Pague otros putos 100 dólares en otra aerolínea que tenía vuelos más tarde para Bogotá, esperé hasta las 8:30pm (Hora del nuevo vuelo) y a las 8pm, la voz gigante [ no Dios, la de los anuncios ] dijo que el vuelo venía con un retraso desde Bogotá por las reputas condiciones meteorológicas. Pero esto es el puto trópico ¿Qué mierda de condiciones meteorológicas?
A las 9pm me sentí un héroe al sentarme en la silla de un avión que olía raro (Avianca, clase turista económica), donde sólo me dieron un jugo de mora y donde dormir era imposible con 3 malditos gringos que hablaban y se reían en un lenguaje que para mi, a esa hora, en mi estado mental, era ininteligible. Sospecho que estaban ebrios. [ Noooooo, Gringos de vacaciones y chupando imposible *sarcasmo ]
Así termina esta historia, rezando porque el panel no se caiga mientras escribo estas líneas, al calor de mi hogar, pensando en jamás, jamás, vender de nuevo otro stand.
Monday, August 07, 2006
Te acuerdas que hace un año...
Estare trabajando cerca de 2 semanas en un proyecto que me tomo 6 meses rediseñar y comprender despues de partiicipar en 7 proyectos, 1 como componete, 3 en funciones y tarabajando y 3 donde estuvimos involucrados aun nos falta camino por recorrer as{i que es hora de ver como enfrentamos este año.
(sí, hay mala redacción porque solo tengo 1 hora de internet y lo escribi al vuelo :P)
Tuesday, July 25, 2006
Disuación
El: ¿Puedo invitarte un trago?
Ella: En realidad preferiría que mejor me dieras el dinero
El: Estoy seguro que podría hacerte muy feliz
Ella: ¿Por que? ¿Ya te vas?
El: Que dirías si te pidiera que te casaras conmigo?
Ella: Nada. No puedo hablar y carcajearme al mismo tiempo
El: ¿Me puedes dar tu nombre?
Ella: ¿Por que? ¿No tienes tu uno?
El: ¿Vamos a ver una película?
Ella: Ya la vi
El: ¿Donde has estado toda mi vida?
Ella: Escondiéndome de ti
El: ¿No te he visto en otro lado?
Ella: Si. Por eso ya no voy allá
El: ¿Esta libre este asiento?
Ella: Si, y si te sientas también éste
El: Así es que, ¿A que te dedicas?
Ella: Soy trasvesti
El: Hola preciosa, ¿Qué signo eres?
Ella: De negación
El: Tu cuerpo es como un templo
Ella: Lo siento, pero hoy no hay misa
El: Si te viera desnuda moriría feliz
Ella: Si yo te viera desnudo probablemente moriría riendo
El: ¿Donde has estado toda mi vida?
Ella: Donde estaré el resto de tu vida: en tus sueños
El: Soy fotógrafo. He estado buscando un rostro como el tuyo
Ella: Yo soy cirujana plástica. También he estado buscando un rostro como el tuyo.
El: Hola, ¿No salimos juntos una vez? o ¿Tal vez dos?
Ella: Debió haber sido una. Nunca cometo dos veces el mismo error
El: ¿Como hiciste para ser tan bella?
Ella: Probablemente me toco la parte que te correspondía.
El: ¿Saldrías conmigo el sábado?
Ella: Lo siento, pero me va a doler la cabeza el fin de semana
El: Tu rostro hace que la gente vuelva a mirarte
Ella: Y el tuyo hace que vuelva el estomago
El: Vamos, no seas tímida. Dime algo
Ella: Ok, ¡Lárgate!












