Lanzarote, fuego por dentro Octubre 18, 2009
Posted by ravelus in Cultura, Experiencias.add a comment
Hace poco menos de un mes estuve con mi novia de vacaciones en Lanzarote, una de las islas que, como todos saben, conforma el archipiélago canario. Disfrutamos de un tiempo espléndido, visitamos lugares muy interesantes y cenamos a cuerpo de rey. Quería compartir aquí mi experiencia desde un punto de vista más o menos objetivo, para que futuros visitantes de la isla puedan tener un punto de referencia acerca de qué ver, qué comer y dónde hospedarse.
Hospedaje
Nosotros elegimos un apartotel por la privacidad de tener nuestra propia casita y el precio de este tipo de hospedajes. Encontramos una buena oferta en Sun Park en régimen de alojamiento y desayuno, por 16€ cada persona. Un precio muy asequible teniendo en cuenta que las habitaciones incluyen una pequeña cocina con todos los utensilios necesarios para preparar comida. Además el complejo hotelero tiene varias piscinas, salas de reunión, parques para los críos y demás. Situado en Playa Blanca, al sur de la isla, en dirección a Playa Papagayo.
Qué comer
Algunos días cenamos en los numerosos restaurantes que se ubican en el paseo marítimo de Playa Blanca, con vistas al mar y todo el pastel. Alguna vez elegimos pescado del día, como no podía ser de otra manera, y no nos decepcionó en absoluto. Cherne (como allí llaman al mero) fino, suave al paladar, aunque es más típica la Vieja. Los precios varían entre restaurantes levemente, pero en general se come barato y bien.
Qué ver
Montañas de fuego.
Vista del parque nacional de Timanfaya y el Atlántico al fondo
En pleno parque nacional de Timanfaya, en el centro de la isla, existe una ruta en autobús, por 8€ que le mostrará el árido y virgen desierto rojo de la isla, suelo protegido por la Unesco como Reserva de la Biosfera. Es algo fuera de lo común para los que vivimos en la península, y puede merecer la pena por ello; pero van a ver eso mismo: desierto.
La Cueva de los Verdes.
Un paseo de aproximadamente 1km por el interior de cuevas rehabilitadas por César Manrique, artista polifacético y gran defensor de la isla. En su interior no veremos las típicas estalactitas y estalagmitas, sino marcas de los ríos de lava que quedan de las últimas erupciones de la isla, allá por el siglo diecinueve. Todo decorado con luces de colores, da un aspecto bastante curioso. Lo del nombre de los Verdes es algo muy curioso que… no, es mejor que vaya y se lo cuenten. Cuidado con los desfiladeros, en algunos, inexplicablemente, no hay barandilla… Precio: 8€.
El volcán de Caldera blanca.
Ruta de senderismo a través de Timanfaya, por un auténtico pedregal que desemboca en los volcanes de Caldera Pequeña y Caldera Blanca más adelante, los volcanes con mayor altitud de la isla, a unos 500m de altura. Muy recomendable llevar bastón y calzado adecuado, esto es: botas de montañismo, no zapatillas deportivas. Dificultad: media, por la ascensión al cráter y el suelo pedregoso, no apto para tobillos frágiles.
Interior del volcán de Caldera Blanca
Jameos del agua.
Bueno, pues otra bajada a una gruta con un estanque subterráneo donde se aloja una especie endémica de cangrejo canijo y blanco. Los jameos son precisamente las salas subterráneas que la lava fue creando a su paso por debajo de la tierra y que después han quedado al descubierto al derrumbarse los techos de roca. Incluye un pequeño centro de interpretación donde aprenderemos cómo funciona el asunto del volcanismo, la formación de la isla y demás. Precio: 8€.
Jardín de cactus
Jardín de cactus.
Alberga miles de especies de cactus recogidas de todos los rincones del planeta, a cada cual más curioso. Precio: 6€.
Y para terminar…
… puede dar un paseo en camello por las áridas arenas de Timanfaya; el precio es de 12€ el alquiler del camello, en el cual pueden montar dos personas.
Malditos bastardos… Octubre 3, 2009
Posted by ravelus in Cultura.1 comment so far
El pasado domingo fui al cine a ver Malditos Bastardos, de Tarantino. Qué peliculón. Merece la pena pagar los 6 euros que cuesta la entrada para ver una película así. Aunque he de reconocer que me dolió un poco. Tarantino es uno de esos directores cuyas películas no se recuerdan por ser maravillosas en su conjunto, grandes historias, impresionantes personajes, no.
Tarantino hace películas de las que todo el mundo recuerda tal escena, o tal otra porque son pasajes, simplemente, geniales.
Aquella de Kill Bill donde ruedan cabezas por todas partes, o aquella de Pulp Fiction en que Samuel L. Jackson recita
un pasaje de la biblia, o la escena del coche, o tal otra… son escenas magistrales, en las cuales todo es sencillamente,
para enmarcar en un museo: los diálogos, los personajes, la situación.
Tarantino sabe sacar lo mejor de cada actor; en sus películas vemos al mejor Travolta, Jackson, Thurman, Willis, y por qué no decirlo, Pitt. Algunas de las mejores interpretaciones de estos actores están en sus películas.
Alguien me dijo hace poco, discutiendo sobre esta película, que la diferencia entre Robert Rodríguez y Tarantino, buenos amigos por cierto, es que la violencia de Robert Rodríguez es previsible y bestial; la de Tarantino es bestial, pero es imprevisible. De repente un personaje muere así, sin avisar; o una situación tranquila se convierte en una matanza. Y sin embargo no hay violencia gratuita; todo tiene un sentido y un por qué, y al final todo encaja, y las pequeñas historias cuadran, y el resultado es un todo que como las fractales en matemáticas es bello en sus niveles más elementales y bello en el todo que conforman.
Hay quien dice que esperaba más de esta última, que las tiene mejores, que es una pequeña decepción… yo no soy un cinéfilo devoto de Tarantino, pero bajo mi ignorante punto de vista es una película magistral, donde lo fundamental a destacar es el personaje de Hans Landa (Christoph Waltz), un general alemán. Digno de estudiar minuciosamente cada gesto, cada movimiento de este impresionante actor políglota (además de alemán, habla perfectamente francés, inglés e italiano). Bajo mi parecer, un digno merecedor del Óscar al mejor actor secundario.
Además, nuestro medio hispano Daniel Brühl se confirma como un actor de los grandes, y eso nos debe llenar de orgullo. Su papel es menos importante que en otras películas como Salvador o Goodbye Lenin, pero hace un buen trabajo.
Brad Pitt hace una buena puesta en escena, se nota que se ha preparado a conciencia su personaje, pues quien espere ver al típico guaperas sonriente y pillín está equivocado; verá a un Brad Pitt rocambolesco, entre Ace Ventura y Marlon Brando en El Padrino.
No sé si serán de los que se deja caer regularmente por las salas de proyección, o son más de palomitas, manta y sofá, o de los de compartir contenidos libremente en la Red; en cualquier caso, vean esta genial obra maestra.
P.D.: A título personal, quiero pedir perdón por mi ausencia de varios meses… espero estar a partir de ahora más atento al blog; de todos modos, gracias a los que en este período de hibernación (como diría el bloguero de Kriptópolis) no han dejado de visitar esta humilde página; apenas he caído poco más de 10 visitas diarias. Esto significa dos cosas: o bien que tengo tan pocas visitas que menos no puedo tener, o que el paro está haciendo estragos y la gente tiene poco que hacer. En cualquier caso, gracias por visitarnos, vengan cuando quieran.
10 Buenas prácticas de Testing Julio 26, 2009
Posted by ravelus in Informática.1 comment so far
Probar un sistema implica simular ese sistema, asegurarnos de que tal sistema hace lo que debe y no hace lo que no debe. Implica un análisis con el propósito de encontrar problemas y errores, medir la funcionalidad y la calidad, capacidades, etc.
Una cuestión muy importante a considerar es que no se puede probar todo. No existe el producto perfecto, siempre tenemos que hablar en términos relativos o porcentuales, como por ejemplo, tasas de error. El proceso de pruebas es un proceso creativo y difícil; es importante planificar qué se va a probar, definir qué escenarios se va a probar. Finalmente, es importante dedicar tiempo y recursos suficientes a dicha tarea.
Diez buenas prácticas:
1.- Haz de la autoevaluación del trabajo de cada uno una responsabilidad de equipo. Insiste en que Test y Evaluación (T&E) forme parte del trabajo diario de cada uno (utiliza smoke tests para apoyarte en ello). Es necesario garantizar la producción de trabajo de calidad todo el tiempo.
2.- Establece cuanto antes un plan integral de pruebas y evaluación. Establece pautas, objetivos y entregables de cada tipo de test. Puede establecerse en sesiones RAD (Rapid Application Development) al comienzo o en sesiones de tormenta de ideas.
3.- Realiza un parte preventivo de pruebas de todo el trabajo especificado. No dejes nada sin cubrir; haz escenarios de todo; esto también te ayudará a entender mejor los requisitos. Inspecciona periódicamente los test y su adecuación al comento de desarrollo actual. Desarrollo y pruebas van de la mano: crea los casos de prueba antes de desarrollar.
4.- Utiliza las pruebas como indicadores de progreso. Que las pruebas te sirvan como indicador seguro de que algo está hecho y funciona.
5.- Haz un inventario de los objetivos de las pruebas y diseña para “testabilidad“. Diseña una lista de qué debe ser probado antes de diseñar o implementar otra cosa.
6.- Prueba desde el principio y a menudo. Así retroalimentas el desarrollo y detectas problemas en el momento en que ocurren.
7.- Diseña y desarrolla test como si fueran entregables. Con la misma disciplina y método. Desarrolla test en paralelo con el código, actualiza los test cuando el producto cambia. Si escribes los test demasiado pronto, luego habrá que redefinirlos, así que tampoco es bueno adelantarse demasiado. La ingeniería de desarrollo de test es igual que la ingeniería de cualquier producto software.
8.- Provee herramientas y soporte adecuados para el testing.
9.- Mide costes, cobertura, resultados y efectividad de los test. Así entenderás mejor el proceso de testing y podrás controlarlo y gestionarlo.
10.- Entrena y gestiona al equipo. Así se tomarán el testing como algo serio y conocerán qué se espera obtener de dicha tarea. El gestor indica guías, la dirección a seguir, qué pasos dar, etc.
Referencias:
The Little Book of Testing, Vol I, varios autores.
Errores comunes en desarrollo software (IV y final) Julio 11, 2009
Posted by ravelus in Informática.add a comment
Por parte del producto como objetivo final nos encontramos con los siguientes problemas:
- Requisitos de “placa dorada”. Requisitos no tan importantes para el usuario como nosotros pensamos, obsesión por el desempeño y otros factores que como informáticos puedan parecernos clave pero que un usuario no valorará tanto. Alargan la calendarización, y si les damos demasiada importancia, restaremos valor a otros requerimientos clave para el cliente.
- Inestabilidad de los requisitos. Algo presente siempre, por lo tanto es fundamental vigilar y controlar los cambios en los requisitos. Alarga la calendarización.
- Desarrolladores de “placa dorada”. Los programadores suelen estar ansiosos por utilizar una nueva tecnología, herramienta o técnica que ha aparecido en el mercado, aunque no sea necesaria para el proyecto. La investigación en nuevos campos conlleva gran incertidumbre, y esto alarga la calendarización, además de aumentar riesgos.
- Negociaciones de tira y afloja. Es extraño que cuando se negocia un deslizamiento en la estimación de un producto automáticamente alguien añade nuevas funcionalidades, lo cual invalida la nueva estimación…
- Desarrollo orientado a investigación. Si quieres desarrollar proyectos, no te sumerjas demasiado en investigar nuevos algoritmos, técnicas, etc. El riesgo de fracasar o ralentizar el proyecto es muy elevado. Desde luego que, si no te queda más remedio hazlo, pero cuenta con el riesgo que ello conlleva y desde luego no esperes terminar el proyecto en un tiempo récord, precisamente.
Finalmente, en cuanto al factor tecnológico:
- Síndrome de la bala de plata. No dejes que los equipos confíen demasiado en una nueva técnica, herramienta, etc. como si fuera la solución de todos los problemas. Las balas de plata no existen en informática; no creas lo que te venden los comerciales… 
- Ahorros sobreestimados de nuevas herramientas o métodos. Las organizaciones no mejoran su productividad a grandes saltos, sino en pequeños avances; entre los inconvenientes de utilizar nuevas tecnologías están: riesgos de utilizar algo tan novedoso que pueda no tener soporte para el cliente, adecuación, curva de aprendizaje, etc. Otro ejemplo de esto podría considerarse el reutilizar software. Nuevamente, el ahorro no es tan grande como se podría prever en un primer momento.
- Cambiar las herramientas a mitad de proyecto. Casi nunca funciona bien. La curva de aprendizaje, rehacer el trabajo ya hecho, errores inevitables cometidos por el desconocimiento de la herramienta… ralentizan el proyecto.
- Falta de control automático del código fuente. Expone al proyecto a riesgos innecesarios. Es fundamental utilizar un buen software de control de versiones, junto con una buena política de gestión de configuraciones. Muchas empresas se conforman con adquirir buenas herramientas de control, pero se olvidan de que sin una buena política de gestión de configuraciones la herramienta no es más que un soporte, algo que puede considerarse incluso como un elemento lelo si se utiliza sin cabeza.
Es posible que redacte en próximas entregas lo que bajo mi punto de vista sería una solución a todos estos problemas. No quiero decir con ello que tenga la solución a todos los problemas, que sea un gran consultor ni nada parecido; simplemente reflejaré lo que los autores aconsejan sobre esto y expondré qué cosas se podrían hacer para paliar estas situaciones. Y desde luego que exponer una solución no es el final de todo. No existen balas de plata, recordemos, y la aplicación de tales soluciones será unas veces más sencillo y otras más complicado, requiriendo en algunos casos de la implicacion de todo el equipo para alcanzar el éxito. Tampoco existen garantías absolutas, pero sí podemos aumentar nuestras posibilidades, y por esto bien puede merecer la pena el esfuerzo.
Errores comunes en desarrollo software (III) Julio 4, 2009
Posted by ravelus in Informática.add a comment
- Actividades fundamentales acortadas. En cierto modo, una consecuencia del error anterior. Cuando hay prisa, se recortan las tareas que no producen código directamente. Habitualmente las candidatas son: análisis de requisitos, diseño y elección de la arquitectura, curiosamente las fases con mayor riesgo y más claves del proyecto.
- Diseño inadecuado. Viene un poco en consonancia con lo que acabamos de anotar: diseños realizados con prisa, no atendiendo debidamente al tiempo requerido conducen a malos productos. Un diseño completo requiere varios ciclos.
- Acortar tareas de calidad. Cuando hay prisa, tratan de acortarse tareas de revisión de código y testing. Eliminar un sólo día de tareas de calidad puede alargar el proyecto entre 3 y 10 días más.
- Controles de gestión insuficientes. Antes de tratar de mantener un proyecto en el buen camino, pregúntate si el proyecto está en dicho momento en el buen camino.
- Convergencia prematura o demasiado frecuente. Cuando se acercan fechas de entrega del producto, es necesario realizar tareas de mejora de desempeño, documentación, preparación de la instalación del producto, etc. Se suele tender a converger demasiado pronto en el sentido de empezar a preparar la release demasiado pronto, lo cual es contraproducente porque luego habrá que volver a converger alguna vez más con nuevas mejoras producidas y además condiciona negativamente al proyecto. Realmente es complicado cómo decidir cuándo converger: no puede ser demasiado tarde porque hay un buen número de tareas propias de fase de release, como las que hemos apuntado antes, que deben ser realizadas, pero si se trata de integrar el trabajo demasiado pronto luego habrá que integrar nuevas funcionalidades y bug fixing realizado.
- Omitir tareas necesarias de las estimaciones. Es fácil olvidar tareas menos visibles pero necesarias, que luego añaden tiempo a la calendarización. Una buena medida sería guardar información histórica de anteriores proyectos para tener algo más de información acerca de qué se necesitó realizar y poder estimar con más conocimiento de causa.
- Planear ponerse al día más adelante. Si una estimación resulta no ser adecuada en la realidad, las estimaciones de las tareas dependientes de ella deben ser reajustadas en consonancia, y no esperar que el proyecto avance más deprisa a partir de tal momento. Es razonable fallar una estimación: uno aprende del proyecto a medida que éste avanza. Es necesario reajustar estimaciones también cuando cambian los requisitos.
- Programar a lo loco. Olvidarse de realizar un diseño bien trabajado. Sin razonar. Al más puro estilo ensayo y error. Esto conduce a tirar mucho trabajo que no vale, a perder mucho tiempo en experimentación poco productiva. Esto, que parece un error de novato, es a lo que conducen las calendarizaciones ambiciosas, cosa que está a la orden del día en muchas empresas.
Referencias:
Steve McConnell: Rapid Development, Taming Wild Schedules
Turismo rural en Aliste (Zamora) Junio 27, 2009
Posted by ravelus in Cultura, Experiencias.add a comment
Hace ya unas cuantas semanas estuvimos mi novia y yo haciendo turismo rural por la región de Aliste, al oeste de Zamora, una zona muy bella en cuanto a paisajes y tranquilidad que recomiendo a todo el mundo.
Aliste es una región húmeda, contrastando con la zona del este de Zamora (Tierra de Campos), mucho más seca. Mientras que el oeste es zona de pastos y vegetación abundante, que bien nos puede recordar al norte de España, la zona oeste es más típica de la meseta castellana, con campos de cereal y llanuras interminables. Cubre desde la sierra de la Culebra al norte hasta la zona de Sayago al sur de Zamora, por el oeste con la frontera de Portugal y con el este aproximadamente con la Vía de la Plata, antigua calzada romana utilizada para transportar plata desde las minas asturianas a los puertos de Cádiz, aunque probablemente se empezó a utilizar antes por otros pueblos. Hoy, carretera nacional y vía del peregrino del sur hacia Santiago de Compostela.
Estuvimos en un pueblecito llamado Ceadea, a pocos kilómetros de Alcañices, cabecera de comarca de la región. Es un pueblo tranquilo, típico de la región, donde las linderas de las tierras se separan con lo que ellos llaman cortinas, que no es más que un muro de piedra de unos 80 cm. de altura.
Vista del pueblo de Ceadea
Lamentablemente para mí, no es una buena zona de senderismo, debido a que no hay rutas bien trazadas y hay poca información al respecto. No hay una buena coordinación entre los distintos concejos para tratar de establecer un conjunto turístico regional importante, lo cual es una verdadera pena. En Muelas de Pan, por ejemplo, existe un pequeño museo de alfarería típica de la región, pero poca gente sabe cuándo está disponible.
De modo que los mejores conjuntos paisajísticos serán visitados en coche. Posiblemente desde el punto de llegada se pueda, posteriormente, hacer alguna ruta. Los lugares más interesantes son:
- La Sierra de la Culebra, a la que se puede acceder en coche, pasando por el pueblo de Villardeciervos, cuyas casas de piedra y madera son curiosas de ver; otro pueblo, éste semi-abandonado, sería Sta Cruz de los Cuérragos, un pueblo muy bello de calles y casas empedradas y tejados de pizarra. Desde allí se puede hacer una pequeña ruta a pie, de una media hora, descendiendo al Valle de los Infiernos, que cae a la derecha del pueblo, en un aparcamiento gratuito que hay.
Una casa típica de Villardeciervos, pueblo que prosperó gracias al contrabando con Portugal de diversas materias
Santa Cruz del Cuérrago
- Los Arribes del Duero, con varios pueblos para recorrer. El principal atractivo turístico de la zona probablemente sea el Puente Pino, en Pino del Oro, un puente de cien años de antigüedad, el primero de hierro que se construyó en España. Se accede por una carretera serpenteante por la cual no conviene correr mucho.
Puente Pino. Impresiona verlo en vivo y en directo 
- Miranda de Duero, en Portugal. Cruzando la frontera, está este bonito pueblo (más bien ciudad) portuguesa, típicamente conocida por sus baratas toallas. Personalmente me quedo con sus bares, sus cafés bien cargados y aromáticos a 50 céntimos, sus bacalaos a la dorada y sus vistas del río Duero.
Catedral de Miranda do Douro, en Portugal
- La propia región de Aliste, con sus paisajes, sus vacas y su ternera de Aliste con denominación de origen, que tuve la oportunidad de degustar en la casa rural donde nos hospedamos y es una auténtica delicia. En horno de leña y chimenea tradicional. De la brasa al plato. Una gozada.
A la parrilla, sabe mejor 
- Embalse de Ricobayo y región circundante. Es un embalse que se construyó hace varias decenas de años. En esa zona, más soleada y seca, existen algunas rutas de senderismo y escalada.
Otros pueblos interesantes son Tábara, Alcañices (donde hay una pequeña ruta muy agradable que discurre a lo largo de un arroyo, pasando la Torre del Reloj), Fornillos de Aliste… Como curiosidad sepan que en esta región la Casa de Alba tiene importantes extensiones terrenos…
Torre del Reloj de Alcañices. En el Medievo este pueblo estaba amurallado.
El visitante también podrá hacer alguna ruta a caballo y practicar deportes acuáticos.
Si pueden hacer una escapadita de fin de semana o un pequeño puente, no lo duden, visiten Castilla y León. No hace falta ir más lejos cuando lo bueno lo tenemos aquí.
Errores comunes en desarrollo software (II) Junio 20, 2009
Posted by ravelus in Informática.add a comment
- Expectativas irreales. Incapacidad para comprender el significado de la palabra “estimación”. Esta mala praxis puede presentarse de dos formas: bien mediante estimaciones optimistas, bien mediante una selección para desarrollo de un conjunto de funcionalidades demasiado ambiciosas.
- Falta de apoyo efectivo al proyecto. Aquí la principal responsable es la parte directiva: planificación, control de cambios, introducción de nuevas prácticas de desarrollo… Sin esto surgirán compromisos irreales o cambios que dañarán el desarrollo del proyecto.
- Falta de implicación de los stakeholders (personas implicadas e interesadas en el desarrollo del producto: clientes y usuarios). Toda persona relacionada de algún modo con el proyecto debe implicarse. Cuando todas estas personas se coordinan es más probable lograr un desarrollo rápido y satisfactorio.
- Falta de involucración por parte del usuario. Conduce a una mala interpretación de los requisitos.
- Políticas por delante del objetivo. Anteponer políticas a resultados es fatal para un buen desarrollo. El objetivo siempre es lo primero, y todo lo que ayude a alcanzar ese objetivo se cuidará y se aprovechará al máximo; todo aquello que sea un factor negativo para la consecución del objetivo se descartará.
- Pensamientos pretenciosos. Las suposiciones optimistas no tienen razón de ser, conducen a la desesperación y a la sensación de fracaso. Es cerrar los ojos y esperar que todo funcione bien, sin ninguna base lógica que lo apoye. Esto es especialmente peligroso en las primeras estimaciones del proyecto, que es donde más se presenta este error.
En cuanto al factor productivo:
- Estimaciones excesivamente optimistas. Mala percepción del proyecto, minimización de tareas de análisis y diseño, daño al plan, excesiva presión en los desarrolladores… todo esto daña la productividad a largo plazo. Es uno de los condicionantes más frecuentes y más graves.
- Gestión de riesgos insuficiente. Riesgo es un error no común. Basta con que ocurra un riesgo no previsto de antemano para ralentizar e incluso cancelar el proyecto. Más claro y más simple imposible.
- Fallo de subcontratación. Si se utilizan COTS (Components Of The Shelf, utilidades desarrolladas por terceros) y el diálogo con este personal no es fluido, podemos encontrarnos con componentes de baja calidad o que no se ajustan a lo que pretendíamos. La paradoja surge cuando vemos que siendo el objetivo de subcontratar el acelerar, lo que hemos conseguido es ralentizar.
- Planificación insuficiente. La planificación debe ser apropiada para un desarrollo rápido.
- Abandono del plan en situaciones de presión. Los equipos hacen planes y de forma habitual los abandonan cuando empiezan a tener problemas de calendarización. Otro de los habituales. El raíz del problema aquí yo creo que está en la percepción de que el plan es algo estático, que se hace al principio de forma muy estudiada y que si luego no se cumple, surge la alarma y el caos.
El plan es siempre dinámico, y la mejor cualidad de un plan debe ser su capacidad de adaptación y flexibilidad a todo tipo de situaciones más o menos esperadas (una vez más, aquí tiene mucho que decir una buena gestión de riesgos).
- Tiempo perdido en fases “ante-proyecto”. Es decir: tiempo durante el cual se estudia el presupuesto, la viabilidad… Muchos proyectos pierden aquí demasiado tiempo y luego vienen las prisas en etapas más críticas y que precisamente necesitan más cuidado en su desarrollo por su riesgo inherente (ej.: diseño).
Referencias:
Steve McConnell: Rapid Development, Taming Wild Schedules
Errores comunes en desarrollo software (I) Junio 12, 2009
Posted by ravelus in Informática.9 comments
Ya iba para largo que no escribía, he tenido una semana bastante ajetreada, aunque las cosas al final no han acabado muy bien y es un tanto irónico que precisamente yo hable de lo que voy a tratar hoy, pero bueno, mejor dejemos estos temas de lado ya que no me gusta hablar de mis problemas por aquí, el enfoque de este blog siempre fue bien distinto.
Introducción
Steve McConnell, y ya con esta serie dejo en paz a este caballero, qué pesado me pongo con él, divide el desarrollo software en cuatro pilares básicos. La metáfora de pilar nos viene muy bien para entender que si uno de estos pilares falla, la estructura (el producto) se viene abajo, por tanto es fundamental cuidar todos con especial atención. Estos cuatro pilares, sin embargo, son independientes. Éstos son:
- Personas: Tienen un efecto muy importante sobre la productividad y la calidad. Es fundamental, por ello, mejorar el potencial humano. Probablemente sea éste el factor más importante de todos.
- Proceso: Visto desde el punto de vista técnico y de gestión. Un buen proceso evita tener que rehacer trabajo por no haber realizado anteriores tareas correctamente (ejemplo: rediseñar un producto por no haber captado correctamente los requisitos). Asegura, además, la calidad desde dos frentes: por uno garantiza la entrega de un producto satisfactorio para el cliente; por otro permite detectar problemas y errores lo antes posible. Conceptos fundamentales aquí son la gestión de riesgos, el aprovechamiento de los recursos disponibles, el aprendizaje de técnicas y modelos de desarrollo…
- Producto: El tamaño y las características pueden reducir considerablemente el tiempo de entrega, si puedes elegir qué funcionalidad entregar antes.
- Tecnología: Utilizar tecnologías más cómodas y avanzadas, teniendo en cuenta los riesgos que estas mismas conllevan.
Cuando se atienden debidamente las 4 dimensiones en su justa medida, podemos alcanzar sinergia.
Errores comunes en desarrollo software
A partir de la clasificación anteriormente explicada, se identifican los siguientes errores comunes a la hora de desarrollar software; todos ellos tienen que ver con alguno de los cuatro pilares:
En cuanto al factor humano,
1.- Baja motivación. Probablemente sea el factor más influyente de todos, en cuanto a productividad se refiere.
2.- Personal escasamente cualificado. Las capacidades individuales, así como la relación con el resto del equipo, influyen en la productividad casi tanto como el error anterior.
3.- Problemas entre los miembros del equipo no controlados. Escucha los problemas del equipo y atiéndelos debidamente; no hagas caso omiso a cualquier situación que pueda perjudicar el objetivo común.
4.- Heroicidades. Es mejor basarse en estimaciones realistas que en compromisos (commitments) imposibles de cumplir que a la hora de la verdad conllevan más riesgo.
5.- Añadir personal a un proyecto ya empezado. Si alguien piensa que agregar gente simplemente va a aumentar la productividad, está equivocado. Puede ser como echar gasolina al fuego. Añadir personal requiere una etapa de formación y aprendizaje más o menos larga, que al principio conlleva más gasto que beneficio y que solamente con el tiempo se logra un retorno de la inversión (ROI, Return Of Investment, que dicen los anglosajones).
6.- Oficinas ruidosas y abarrotadas. Afectan negativamente a la productividad.
7.- Tensiones entre programadores y clientes. Pobre comunicación, pobre entendimiento de los requerimientos del cliente, pobre diseño de la interfaz de usuario. Como consecuencia más catastrófica: no aceptación del producto.
Basta por hoy. Continuaremos en otra ocasión. Nos vemos, pues.
Referencias:
Steve McConnell: Rapid Development, Taming Wild Schedules
