5 Razones Por Las Que Nunca Deben Usar Los Formularios Web de Nuevo

1. Facilidad en las pruebas: MVC proporciona una verdadera separación de responsabilidades, y hace que sea fácil realizar pruebas unitarias de UI.
2. Paginas Instantáneas: Se consigue crear las páginas de administración más rápido que nunca. El desarrollador ya no se queda estancado haciendo las típicas paginas Crear, Editar, Actualizar, Eliminar.
3. Mejor Control del código HTML: MVC simplifica el desarrollo poniendo de nuevo al desarrollador a cargo del Html, dando control sobre el tamaño y el performance del código que se presenta.
4. Depuración mas simple: Esto significa que en lugar de hacer un debug por ciclos de vida de Webform complicados, el ciclo de vida de MVC se resume en buscar la tabla de rutas, llamar al controlador quien se encarga de trabajar con los modelos y devuelve la info que la vista va presentar,esto con el objetivo; que un desarrollador pueda entrar de lleno en la codificación sin un conocimiento profundo del ciclo de vida de la página.
5. Soporte Móvil  Con comportamiento adaptable, MVC permite la misma interfaz de usuario para representar en diferentes dispositivos, por lo que los usuarios puedan ver en su PC, su Tablet o incluso su teléfono inteligente.

La Primera Reunión de SCRUM

Dando continuidad al blog, voy a contar como fue la primera aproximación a SCRUM en nuestro proyecto, como comenté anteriormente el proyecto ya había arrancado y este framework se está aplicando para su segunda fase en la cual se esta en un proceso de aprendizaje de Scrum, es por esto que no estamos aplicando SCRUM tal y como lo dice la teoría,  por el contrario dentro del proyecto se esta siguiendo las mejores prácticas del marco de trabajo apoyándonos en el libro “Scrum XP From the trenches” de Henrik Kniberg y adaptándolas a nuestra realidad, la idea principal es generar la cultura scrum en el equipo que es los mas importante en estos primeros pasos en su adopción. 

Pero para entender algo e iniciar a aplicarlo es necesario conocer sus fundamentos, es así como investigando sobre este tema me encontré con los "pilares" del desarrollo ágil (http://agilemanifesto.org/iso/es/ http://es.wikipedia.org/wiki/Manifiesto_ágil) :

Manifiesto por el Desarrollo Ágil de Software

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

Estos postulados nos dan una idea dentro del proyecto para enfocarnos en:

•  los individuos e interacciones del equipo sin dejar de lado los procesos que se están implementando en el área de tecnología a la cual pertenecemos, esto es vital para una profesión de innovación y creatividad como lo es la ingeniería, se imaginan ustedes un proceso de alta costura ejecutado por personas sin el talento para ello o peor aún, sin ningún conocimiento, el proceso esta ahí y puede ser el proceso más óptimo, pero de que sirve sin la habilidad o talento de los individuos.
• concentrarnos que el resultado de esta segunda fase del proyecto sea software que funcione sin dejar de lado la importancia de la documentación necesaria y solo la necesaria, al igual que el ejemplo anterior ¿se imaginan la construcción de un puente basándose en solo documentos que lo describen o donde se muestran los requerimientos como: que sea colgante, que deba tener 4 carriles, que sea en concreto, etc.? ¿pero que pasa si después de construirlo nos damos cuenta que se presentaron nuevas variables que debieron ser tenidas en cuenta al principio y que no se validaron por falta de planos, maquetas y prototipos?.
• el proyecto se debe concentrar en colaborar con el cliente, en nuestro caso satisfacer las necesidades que dejamos en la primera fase y dar una respuesta rápida, ya habíamos intentado hacer contratos con el negocio, y hasta tenemos un acta de la primera fase llena de firmas de representantes del negocio que aprobába todos los requerimientos especificados, ¿entonces si contamos con el contrato y lo cumplimos al pie de la letra por que la sensación de que faltan cosas en el resultado?.
• y por último, en la primera fase seguimos un plan pero nunca nos anticipamos a los cambios, esto nos dio un software que funcionaba pero que dejaba la sensación de que no cumplía todos los aspectos, es asi como decidimos que en el proyecto se generare la habilidad de anticiparnos y no simplemente seguir un plan hasta el final.

Haciendo la primera Reunión de Sprint

Como les comente en la entrada anterior empecé a leer e ir aplicando el libro Scrum y Xp desde las trincheras, al principio en el equipo como que la idea daba un poco de risa y se veía en la cara de sus integrantes, incluyendo la mía, expresiones de incredulidad, y de duda como: “Sera que si?”, es así como el día anterior a la reunión del sprint yo me encontraba “haciendo manualidades” como lo expreso un compañero del equipo, que consistían en cortar las cartas de planing poker (las pueden encontrar aquí totalmente gratis ) que usaríamos en la reunión del día siguiente y haciendo una gran cartelera en cartulina de nuestro tablero de tareas, para esta reunión deberíamos tener una pila de requerimientos de producto y deberíamos tener algunos roles definidos, esta pila se sacó de la retroalimentación de la entrega de la primera fase y ante la imposibilidad de la asistencia de una persona del negocio, citamos al gerente del proyecto que ejercería el rol de dueño del producto y le diera la importancia a cada uno de los requerimientos listados, realizando algunas búsquedas encontré aquí una macro en excel que nos ayudó a convertir la lista de requerimientos en tarjetas que podíamos imprimir para llevarlas a la reunión y colocarlas en la mesa, discutirlas y ordenarlas por importancia, a parte del gerente del proyecto, asistió a esta primera reunión el equipo técnico integrado por 3 personas incluyendome y una persona del área de procesos de la empresa la cual esta encargada de realizar pruebas de software. Ya en la reunion cuando los integrantes vieron las cartas de planing poker se hicieron comentarios graciosos, algo que ayudo en el ambiente, se inicio la reunión y se expusieron los requerimientos más importantes de la lista priorizada por el gerente del proyecto, para empezar aclaramos algunas de las reglas del juego, como planear tareas en días y en no en horas para evitar la tentación de estimar tareas de 1 o 2 horas, se establecio la menor medida permitida para la estimación de 0.5 dias, ademas, procedimos a calcular la cantidad de días que tenia el equipo técnico y de pruebas para atacar los requerimientos, es asi como hicimos un listado con los dias habiles que tenia para estas próximas 3 semanas y el resultado fue el siguiente:

Victor 15 días

David 15 días

Diego   5 dias (nuestro compañero salia de vacaciones y solo estaria 5 dias en el primer ciclo)

Martha 9 dias (ella tiene una dedicacion del 60% en el proyecto)

de esta actividad obtuvimos 44 puntos para estimar pero como los recursos no pueden estar el 100% del tiempo frente al computador se multiplico por un factor de dedicación, este factor mas adelante se pude sacar de las experiencias de ciclos ya ejecutados, pero como este era nuestro primer ciclo tomamos el factor por defecto 70%, esto quiere decir que solo podíamos tomar requerimientos que sumaran máximo 30 días para repartirlos en el equipo y que estos fueran nuestra pila de Sprint, entonces se escogieron de los 15 requerimientos que el gerente del proyecto había "priorizado" y uno por uno se iban estimando por cada uno de los participantes de la reunión, aquí se usaron las cartas de planig poker, el procedimiento fue el siguiente se nombraba en voz alta el requerimiento y cada persona colocaba una carta boca abajo (esto es psicológico  para no sesgar a los demas miembros de la reunion en sus estimaciones)  si se sacaban cartas similares esa era la cantidad de días que se le colocaba al requerimiento y si encontrábamos cartas muy altas y muy bajas en un mismo requerimiento se discutía el por que de las dos estimaciones y se llegaba a un consenso. se escogieron los 8 requerimientos mas importantes y los cuales sumaban 30 días en su estimación (debido a que los 44 días por el factor de dedicación 70% nos daban un resultado de 30.8 días disponibles para el ciclo)  y son los que atacaríamos en nuestro primer Sprint.

les comparto las tarjetas de Historia de usuarios generadas por el macro de excel, como podemos ver esta tarjeta de historia es acompañada por una foto o caricatura que representa al colaborador que la tienen asignada en nuestro tablero de tareas, escogimos personajes de tv o de cine que se parecieran a los  integrantes del equipo, pero he visto en otros equipos que usan caricaturas, personajes de los Simpson, South Park o simplemente el nombre de la persona.

Estas son las tarjetas de planing poker que se usaron en la primera reunión, mas adelante les explicare como funcionan ya que hasta ahora solo llevamos una sesión de planeacion con este método y no tengo la experiencia.

Acá esta nuestro tablero de Tareas con tareas que ya se han empezado a ejecutar, en esta fotografia vemos los personajes que representan a los integrantes y sus tareas asignadas ademas de un gráfico de Burndown que mas adelante explicare.

en la sigueite entrada del blog les comentare como fue la primera semana de Scrum en el proyecto.

Iniciando con Scrum

Por que este blog

Como líder técnico de un proyecto he visto la necesidad de investigar acerca de scrum, para poder optimizar el equipo técnico del proyecto y lograr que este sea de alto rendimiento en el desarrollo de software.
En el proyecto en el cual estoy trabajando, SCRUM se convirtió en algo vital para  desarrollar software al interior de este, las diversas situaciones surgidas en la primera fase del proyecto fueron generando un caldo de cultivo perfecto para realizar experimentos con este marco de trabajo.

Contando la historia de la primera fase y para colocar en contexto el por qué de este blog, en el proyecto teníamos una lista interminable de requerimientos que se especificaron al inicio y que eran inamovibles y que poco a poco se fue llegando a la típica situación en el desarrollo de software que después de un año de arduo trabajo entregamos una herramienta que no cumplía con la totalidad de las especificaciones del cliente, esta situación se ha incrementado en los últimos años con la explosión de la WEB 2.0 y todas las funcionalidades de esta, que nos acostumbro a recibir continuas mejoras en las aplicaciones en muy corto tiempo, ¿alguien se ha preguntado en que versión de Facebook estamos?.

Esto también se ha trasladado al ambiente empresarial, las compañías están enfocando sus productos de software internos como externos al “release early,release often” y  esto es justo lo que necesito ahora que arranco la segunda fase de mi proyecto y necesito liberar una nueva versión del producto que desarrollé en la primera fase con los requerimientos que dejé de suplirle al negocio o que quizás se generaron por la evolución del mercado y del medio ambiente (hablando de la definición de este en TGS).

Investigando Sobre Scrum

Con la necesidad de la cual he hablado, inicié una ardua búsqueda para poder mejorar en las siguientes fases del proyecto y poder dar soluciones rápidas a las necesidades del negocio con la mayor calidad posible, es aquí donde recordé una reunión donde había escuchado frases como Release early Release Often, Metodologías agiles, XP, SCRUM. Esta última despertó mi curiosidad ya que la había  escuchado varias veces pero no sabía que era, al principio yo creía que se trataba de una metodología ágil pero no, resulta que es un Marco de trabajo “Framework” o por lo menos hasta lo que sé y lo que he podido googlear, en esta búsqueda encontré mucha información, es así como descubrí links de gran utilidad como http://www.infoq.com/ acá halle este  libro http://www.infoq.com/minibooks/scrum-xp-from-the-trenches que se ha convertido en mi carta de navegación en este tema de SCRUM el cual empecé a aplicar en la segunda fase del proyecto que inició esta semana y que iré documentando en este blog.

Les comparto mi primer Tablero de Scrum, más adelante les explicare que es cada uno de los items.