lunes, 27 de junio de 2016

Método iterativo e incremental

Imagen de Henrik Kniberg


Tu empresa ha externalizado la creación de una aplicación a una empresa en India y a los cuatro meses de la fecha límite entregan una primera versión.
En esa primera versión te das cuenta que tiene bastantes problemas. Como por ejemplo:
  • Los requisitos mínimos no han sido cumplidos.
  • La interfaz de usuario tenía que ser igual a otra aplicación, ya que los usuarios están acostumbrados a esta primera, y no se parece nada.
  • La aplicación no funciona con el número mínimo de usuarios concurrentes que va a tener.
  • Las funcionalidades desarrolladas hacen lo que tiene que hacer, a veces.
  • El código no tiene un mínimo de calidad

Como puedes imaginar, no vas a poder arreglar todos los problemas en solo cuatro meses y los costes en cuanto a tiempo y dinero aumentan con cada mes que no ha entregado el producto, y serán muchos meses.
Además, la gente de negocio tiene que hablar con los clientes sobre estos cambios, ya que no van a estar terminados en la fecha prometida. Lo que bajará la confianza de los clientes en la empresa.
Lo mismo pasa con la gente de marketing y la campaña que tenían pensada hacer para captar nuevos clientes, que tendrán que ser pospuestas. Con el coste adicional que supondrá este cambio.

La forma de desarrollar este producto es en cascada (waterfall) ya que todos los requisitos han sido dados al principios del desarrollo y el producto se entrega cerca de la fecha de entrega.

Imagen de https://www.adictosaltrabajo.com/tutoriales/metodos-agiles


La forma de desarrollar un producto en cascada es la más eficiente porque si los requisitos han quedado claros y no hay problemas durante el desarrollo del producto se han gastado cada céntimo en las cosas necesarias para obtener el producto.
El problema es que en los 10 años que llevo desarrollando software siempre hay "problemas". Puede ser que sea casualidad o que los problemas no son tal, si no un es algo habitual en el desarrollo de software. Personalmente me decanto por el segundo motivo.

Hay varias alternativas a este tipo de desarrollos en cascada pero voy a hablar del que conozco. Del desarrollo iterativo e incremental.

El desarrollo iterativo e incremental consiste en ir entregando versiones de tu producto que vayan entregando cada vez más valor con cada versión del producto.

Imagen de https://www.adictosaltrabajo.com/tutoriales/metodos-agiles


La ventaja de esta forma de desarrollar un producto es que si hay algo mal, como la lista que he comentado al principio, tenemos tiempo suficiente para poder solucionarlo. O lo que es lo mismo, estamos reduciendo el riesgo que es el entregar un producto al final del desarrollo sin saber si está bien.

Claro que esta forma de desarrollo tiene sus inconvenientes. El más importante es el tiempo que hay que dedicarle a verificar que vamos por el buen camino. El tiempo que dedicamos a hablar con el cliente o con la gente de negocio para comprobar que lo que estamos desarrollando encaja con lo que tenían pensado.
Otro inconveniente importante es que la forma de desarrollar cambia de forma drástica. En cada nueva versión de nuestro producto tenemos que comprobar que las nuevas funcionalidades funcionan de la forma correcta y que las funcionalidades desarrolladas en las versiones anteriores siguen funcionan. Así, con cada nueva versión que se acerca más al producto tenemos que probar muchas cosas: las funcionalidades nuevas y las antiguas.
Como puedes imaginarte llega un momento que este proceso de comprobar que todo lo desarrollo funciona de forma correcta no se puede realizar de forma manual. De forma manual quiero decir de una persona que compruebe un todo funciona.
Por lo que necesitamos algún tipo de proceso automático que nos permita comprobar que lo que hemos desarrollo funciona. Aquí es donde entra en juego los test unitarios, los test de integración y los test de aceptación.
Los test unitarios y de integración comprueban que la aplicación funciona como debe funcionar y los test de aceptación comprueba que la aplicación funciona como el usuario final quiere.

Los cambios de un proceso en cascada a un proceso iterativo e incremental son grandes. Tanto a nivel de negocio como a nivel de desarrollo. La gente de negocio tiene que ayudar a comprobar que lo que que el usuario quiere es lo que se está desarrollando (test de aceptación) y la gente de desarrollo tiene que crear test de integración y unitarios para comprobar que lo que se está creando funciona de forma correcta.
Estos cambios son grandes pero van a permitir a vuestra empresa a reducir los riesgos. Lo que va a permitir a vuestra empresa crecer reduciendo los riesgos en este crecimiento.

Personalmente las ventajas ganan a los inconvenientes en un proceso iterativo e incremental. ¿Tú qué opinas?


miércoles, 25 de mayo de 2016

Pequeño ejemplo en Python y TDD

Imagen de http://code.tutsplus.com/tutorials/beginning-test-driven-development-in-python--net-30137


Hace un tiempo leí el libro Test-Driven Development by Example de Ken Beck y me pareció un gran libro. Es una gran introducción a TDD.

Una parte del libro no entendí bien. La relacionada con un ejemplo de xUnit.
En esa parte del libro, implementa una librería para poder testear código y el ejemplo que va desarrollando está escrito en Python y no conocía el lenguaje. Creo que el lenguaje fuera Python hizo que no lo entendiera.

Así que para poder entenderlo y aprender un poco Python he escrito el código resultado de cada capítulo en un fichero mientras iba leyendo el libro. He subido los ficheros a:

https://github.com/kikers25/tddByExamplePython

Se puede comparar un fichero (con Winmerge) con otro para ver cual han sido los cambios en cada capítulo. Por ejemplo, los cambios entre el capítulos 18 y 19 serían:

Python

Espero que te resulte útil.


miércoles, 4 de mayo de 2016

Mi camino aprendiendo inglés

Imagen de http://www.cleverlearncebu.com/the-importance-of-learning-english/


Siempre me resultó fácil el aprobar asignaturas en el instituto. Solo tenía que estudiar durante unos pocos días y ya era suficiente.
Eso me pasaba con casi todas las asignaturas. El inglés se me resistía. Si parte de la nota dependía de hablar o de escuchar en inglés tenía serios problemas para pasar de curso.

Creo que fue en el instituto cuando empezó mi odio (si, he dicho odio) al inglés. Pero como no iba a odiar algo en el que tenía que esforzarme muchísimo para poder sacar un aprobado raspado, que me hacía sudar y pasarlo mal y que me dejaba en ridículo delante de mis compañeros cuando intentaba hablar.

El problema era mayor por mis complejos a la hora de hablar. Este complejo empezó cuando era pequeño al no poder pronunciar la letra r. Por ejemplo, mi nombre lo pronunciaba Enlique en vez de Enrique. Si no me sentía cómodo al hablar en mi propia lengua, imagínate en otra.

Cuando terminé el instituto estaba muy contento de que no iba a tener ninguna asignatura relacionada con el inglés. Sabía que el inglés era importante en mi carrera profesional ya que soy informático y el inglés es la lengua común para todos los informáticos pero no me importaba. El odio que lo tenía podía más que mi carrera.

Durante mis primeros años trabajando me di cuenta que no tenía odio al inglés. Sino que lo que tenía era miedo. Un miedo inmenso y sin sentido. Miedo al hablar, miedo al escuchar y también al escribir y leer en inglés.

Estando trabajando en Madrid, me surgió la oportunidad de vivir en Holanda. Le di muchas vueltas. Creía que era una oportunidad que no se me iba a presentar una segunda vez, que si la dejaba escapar no volvería. También sabía que iba a ser muy duro. Al final tomé la decisión de ir a vivir a Holanda.

La primera impresión que tuve en Holanda fue de total inutilidad. Toda la gente a mi alrededor hablaba en inglés y holandés y algunos también en español. Si ellos eran capaces de hablar tantos idiomas y yo no, el problema debía de ser yo. Posteriormente vi que había otros factores por lo que los holandeses eran capaz de hablar de forma tan correcta en Inglés.

Al poco tiempo de estar allí hice varias entrevistas debido a mi experiencia y a la gran demanda de programadores. Pero debido a mis nulas capacidades de comunicarme no me cogieron en ninguna. Recuerdo lo mal que lo pasaba intentado comunicarme en inglés al teléfono con los recruiters que me llamaban.

Conseguí trabajo en una pequeña startup gracias a que su presupuesto no les daba para contratar a un programador holandés. Allí aprendí a comunicarme en inglés pero nunca me sentí a gusto hablando. Lo que más recuerdo de la startup es que al principio tuve bastantes dolores de cabeza porque tuve que hablar mucho en inglés con el dueño de la startup.
Al mismo tiempo, atendí varios cursos, fui a intercambio de idiomas y poco a poco me iba sintiendo más cómodo.

Tengo que agradecer a la serie juego de tronos que leyera mi primer libro en inglés. Tenía tantas ganas de saber cómo continuaba la serie después del último capítulo de la temporada (creo que de la segunda) que tuve que leerme los libros. Si alguno conoce los libros sabrá que cada libro tiene más de 500 páginas.

Cambié de empresa después de más de dos en la startup. Fue un cambio duro porque los compañeros de la startup se habían convertido en mi zona de confort.

Llegó un momento en el tiempo que pasé en la segunda empresa en el que me sentí más cómodo hablando. Habían pasado alrededor de tres años. Ayudó en sentirme más cómodo el curso que atendí para mejorar mi acento.
Todos los cursos relacionados con el inglés los hice en la empresa English Breeze. No hay nada mejor que encontrar un buen profesor que te ayude a recorrer el camino que te has marcado.


Aunque fue muy duro y me ha costado años el aprender inglés y el sentirme a gusto hablándolo ha merecido la pena porque me ha abierto muchas puertas. No estoy hablando solo a nivel profesional sino también a nivel personal. Me encanta aprender cosas nuevas y hay miles y miles de cursos y charlas gratis y que si no supiera inglés no hubieran estado disponibles para mí.

Todo esto lo cuento porque lo principal que he aprendido en mi tiempo que he pasado en Holanda ha sido que el único que está entre tu y tu objetivo eres tú mismo. Y que solo necesitas esforzarte y ser constante para conseguirlo.
Si tienes algo que quieres realmente hacer tienes que ponerte a ello, porque con constancia, tiempo y esfuerzo lo conseguirás.

* Modificado 05-05-2016: Corregidos errores gramaticales