Tag Archives: Metodologias Agiles

Code Smells

O también conocidos como bad smells, se refiere a cualquier sintoma en el código fuente de un programa que posiblemente indica un problema mas profundo. No son bugs y en realidad no impiden que tu programa funcione correctamente, sin embargo, sugieren deficiencias que pueden generar tiempos de desarrollo mas extensos o riesgo de errores a futuro.

Determinar un code smell es con frecuencia un proceso subjetivo y puede variar según el lenguaje de programación, la metodología de desarrollo y finalmente el desarrollador.

Para simplificar la categorización de los mismos, se crearon los siguientes grandes grupos:

Bloasters

Son bloques de código, métodos y/o clases que han aumentado en tales proporciones gigantescas que son difíciles de trabajar. Por lo general, estos code smells no surgen de inmediato, sino que se acumulan con el tiempo a medida que evoluciona el programa. (sobre todo cuando nadie realiza un esfuerzo por mitigarlos)

Object-orientation Abusers

Están basados en la utilización de manera incompleta o incorrecta de los principios de la programación orientada a objetos.

Change Preventers

Se basa en el problema de que al cambiar algo en tu código, terminas haciendo muchos cambios en muchos otros lugares, por lo tanto el desarrollo de software se convierte en algo mucho mas costoso y complicado.

Dispensables

Es algo inútil e innecesario cuya ausencia haría que el código sea más limpio, eficiente y fácil de entender.

Couplers

Contribuyen al excesivo acoplamiento entre clases o muestran lo que sucede si el acoplamiento se sustituye por delegación excesiva.

Para mas información sobre este tema pueden visitar los siguientes enlaces:

Los geek actuales y sus metodologias

dilbert-agile_programming_0

Diego: Buenas noches profesor
Profesor: Buenas noches Ramirez
Diego: Profesor, queria ver con usted mi nota
Profesor: Ah si, hubo un error cuando la cargaron en la pagina.
Diego: Ah, me imaginaba. Que me saque?
Profesor: Un 2
Diego: Como un 2!!??
Profesor: Y.. si. Un 2 Ramirez. Su evaluacion no estaba nada bien.
Diego: Pero no puede ser! Si yo hice todo lo necesario! Mi evaluacion no merece menos que un 10
Profesor: Un 10 !!! ?? Usted no sabe lo que dice..
Diego: No profesor. Y se lo puedo demostrar. Mire, ve mi tarjetita: dice “Gerente de Desarrollo”. Y al otro lado dice “psicofxp.com” Sabe lo que significa?
Profesor: No, la verdad que no. Pero eso no cambia el 2 que se saco.
Diego: No, no, no. Usted no esta teniendo en cuenta que yo trabajo en una “punto-com”. Eso cambia todo
Profesor: No veo en que puede cambiar!
Diego: Espereme un segundo. Vamos a revisarla juntos, analicemos todos los puntos, cuantifiquemos el total de las consignas sugeridas, evaluemos cuanto tiempo usted nos dio para hacer el examen, y cuanto en realidad podia hacer yo. Y ahi llegamos al primer indicador
Profesor: Que indicador Ramirez? Usted tenia 8 ejercicios, e hizo 4. Y todos mal. El 2 en realidad se lo estoy regalando.
Diego: Bueno, ve: hice 4 ejercicios porque cuantifique que en este sprint no podia hacer mas. La semana que viene, en el proximo sprint hago los otros 4
Profesor: Ramirez, disculpeme pero no le entiendo.. Usted sugiere que esta bien que hiciera 4 puntos, cuando todo el mundo hizo 8?
Diego: Por supuesto. Mire: 8 puntos era el product backlog, pero en este sprint solamente podian entrar 4. Como soy proactivo hice mi propia estimacion. Ahi ya tengo un punto.
Profesor: Usted esta loco? y de todas formas, aunque aceptara que solo hiciera 4, los 4 están mal.
Diego: Porque mal? Fijese el primer ejercicio: “Ingresar las edades de 10 personas, determinar el máximo, el minimo y el promedio de edad. Imprimir los 3 resultados”
Profesor: Usted solamente hizo el calculo y la impresión. No hizo el ingreso de datos.
Diego: Claro, porque este calculo es invocado por un ajax que le pasa los parametros. El ejercicio esta perfecto. Ahi ya van dos puntos.
Profesor: Ramirez usted me esta tomando el pelo?
Diego: Para nada Profesor. Veamos el siguiente ejercicio: “Generar una matriz de 4×4 con los números de 1 a 16”
Profesor: Aca dejo un espacio vacio.
Diego: Pero claro: esta es la vista del HTML. Pero la tabla la dibuja el CSS
Profesor: Que!!? Y los datos?
Diego: Los escribe el JQuery!
Profesor: Ramirez, estoy a punto de perder la paciencia!
Diego: Eso por lo menos fueron dos puntos mas y van 4. Que sigue? Ah, si: “Comprobar que un numero de cédula sea correcto”
Profesor: Y usted solamente puso una direccion de pagina web
Diego: Error. Yo puse una invocación a un servicio RESTFUL del SAIME que me devuelve true o false. Un punto mas.
Profesor: Ramirez, estoy a punto de expulsarlo de mi clase
Diego: Profesor, ya terminamos: Miremos el ultimo ejercicio: “Realice un programa que solicite nombre y apellido e imprima el resultado”
Profesor: Ramirez: usted dibujo tres cuadraditos.
Diego: Son los dos campos del formulario, y el boton Submit
Profesor: Y la logica!?
Diego: Obviamente no esta aca! Usted no oyo hablar del patron MVC. Bueno, esta es la Vista. El modelo y el controlador lo hizo mi compañero, que es del otro team.
Profesor: Que compañero? Que team? De que me habla?!!
Diego: Que yo dividi las tareas con mis compañeros para poder terminar el sprint. Encima hice su trabajo de Scrum Master. Por lo menos dos puntos mas me merezco por eso.
Profesor: Ramirez, suponiendo que acceda a todas sus locuras, esta llegando a un 6. Y usted sabe que se aprueba con 7
Diego: Pero usted se esta olvidando que el examen valida, no vio que le puse “This exam is XHTML 1.0 valid” Ahi tengo un punto mas.
Profesor: Pero…
Diego: Y ademas, antes de entregarlo hice una copia para llevarme, con lo cual esta commiteado en el versionador. Otro punto. Si sumamos que el examen no ocupa mas de media carilla, quiere decir que esta minificado. Otro punto mas. Y finalmente antes de irme puse en Twitter y en Facebook “Acabo de terminar un examen de Programación. Me voy a comer una pizza y ver Lost. Hasta mañana followers”. Eso por supuesto, me suma otro punto y llego al 10
Profesor: Ramirez, sabe que? Me harto. Le voy a poner el 10 solamente para que se calle y se siente. Total esto es una universidad privada, asi que poco importa si usted aprende o no.
Diego: Gracias Profesor, pero no me ponga un 10. Mejor pongame un 9 y en la parte superior de mi examen pongame un circulito pintado de verde manzana que diga “Beta”. Así todos piensan que queda algo por mejorar.

Via: minimalart

Estructura ágil de Scrum

agil

1.- Concepto

En la fase de concepto se crea la vision del producto o servicio que quiere obtener. Se decide y selecciona al equipo de personas que lo llevara a cabo. Partir sin una vision determinada produce esfuerzo baldio. Igual que para una empresa, la vision es un factor critico para el éxito del proyecto. Se necesita tener la vision de lo que se quiere, y conocer el alcance del proyecto. Esta información la deben compartir todos los integrantes del equipo.

2.- Especulación

Una vez que se dispone de la vision de lo que se quiere conseguir, el equipo especula y construye hipotesis sobre la información de la vision, que per se es muy general e insuficiente para determinar las implicaciones de un desarrollo (requisitos, diseño, costes). En esta etapa se determinan las limitaciones impuestas por el entorno de negocio (costes y agendas principalmente) y se determina la primera aproximación de lo que se puede producir. La gestión ágil investiga y desarrolla tomando como partida la vision del producto. Durante el desarrollo confronta la realidad de lo que va obteniendo. Su valor, posibilidades y la situación de negocio del entorno en cada momento. La etapa de especulación se repite en cada iteración del desarrollo, y teniendo como referencia la vision y el alcance del proyecto consiste en:

  • Desarrollo / revision de los requisitos generales del producto.
  • Desarrollo de una lista con las funcionalidades esperadas
  • Construcción de un plan de entrega: Fechas en las que se necesitan las versiones, hitos e iteraciones del desarrollo. Este plan refleja ya el esfuerzo que consumira el proyecto durante el tiempo.
  • En función de las características del modelo de gestión y del proyecto puede incluir también estrategias o planes para la gestión de riesgos. Si las exigencias de cumplimiento de la organización lo requieren, también se generan información administrativa y financiera.

3.- Exploración

Desarrollo de las funcionalidades que para generar el siguiente incremento de producto, ha determinado el equipo en la etapa anterior.

4.- Revision

El equipo y los usuarios revisan las funcionalidades construidas hasta ese momento. Trabajan y operan con el producto real para determinar su alineación y dirección con el objetivo

5.- Cierre

Al llegar a la fecha de entrega de una version de producto (fijada en la fase de concepto y revisada en las diferentes fases de especulación), se obtiene el producto esperado. Posiblemente este seguirá en el mercado, y si se emplea gestión ágil es presumible que se trate de un producto que necesita versiones y mejoras frecuentes para no quedar obsoleto. No quiere decir necesariamente que se ha terminado el proyecto. Lo que para en un ciclo de desarrollo secuencial seria mantenimiento, en un entorno ágil es la continuidad del proyecto en ciclos incrementales hacia la siguiente version para ir acercandose a la vision del producto, que también es posible que vaya evolucionando con en el tiempo, al ritmo de su entorno tecnológico y de negocio.

Apuntes sobre el libro “Lean Startup”

startup-feedback-loop1

En el post http://arbo.com.ve/2012/11/20/excelente-resumen-del-metodo-lean-startup-segun-techmi-es/ les compartí un resumen del libro realizado por la gente de techmi.es, sin embargo el día de hoy me gustaría mostrarles algunas de las frases o porciones de texto que me parecieron mas interesantes mientras realizaba la lectura del libro:

  • En toyota se conoce con el término japonés genchi gembutsu, una de las expresiones mas importantes del vocabulario del Lean manufacturing. En español, suele traducirse como la directriva de <<ir al lugar del problema y verlo por nosotros mismos>>.
  • En lugar de eso, usaron “pruebas del mago de Oz” para hacer creer que el producto funcionaba. En una prueba del mago de Oz, los consumidores creen que están interactuando con el producto real, pero detrás de la escena son humanos quienes están haciendo el trabajo.
  • Los análisis de cohortes convierte las acciones complejas en informes basados en las personas, cada análisis de cohorte dice: “entre la gente que usó nuestro producto durante este período, ésta es la proporción que mostró cada uno de los comportamientos que nos interesan”
  • Un pivote es un tipo especial de cambio, diseñado para probar una nueva hipótesis fundamental sobre el producto, el modelo de negocio y el motor del crecimiento.
  • Un pivote es el centro del método Lean Startup

Continue reading