sábado, 24 de marzo de 2018

¿TDD sobre código existente? - ¡¡¡Blasfemia!!!

Hoy me encontre con una situación particular. Un equipo de desarrollo, que tiene algún tiempo trabajando en una aplicación web, se encontró con la exigencia de parte de la administración de la empresa de que todo el código tenía que llevar pruebas escritas (TDD), y no cualquier tipo de pruebas, sino pruebas unitarias (Unit Testing).



Además de sentir algo de empatía por el equipo y tristeza por esta decisión, decidí investigar un poco, y averiguar qué tan viable o que tan absurdo era el proceso. Y pues me he encontrado con que desarrolladores de diferentes culturas y niveles han llegado a las siguientes conclusiones.

No todos los casos requieren pruebas.

No todas las funcionalidades requieren o pueden recibir pruebas unitarias. Es absurdo escribir pruebas que van a tomar más tiempo que una funcionalidad que tiene solo dos posibles resultados. EL TDD es bueno, pero cuando no es exagerado.

La refactorización del código es más importante.

Cuando se tiene una base de código antigua, es más importante hacer refactoring que pensar en pruebas. Ya mientras se hace el refactoring se pueden escribir las pruebas de los diferentes casos si se consideran necesarias, pero no debe ser la prioridad.

Si se requieren pruebas en alguna parte del código, es mejor empezar desde 0.

Si el código que se está revisando requiere si o si las pruebas unitarias, es más fácil borrar y empezar de 0. Esto después de preguntar a varios desarrolladores. escribir pruebas unitarias, sobre todo en código que no es modular e independiente puede tomar mucho esfuerzo, ya que se deben evaluar casos externos al código que se está modificando. En esos casos empezar de 0 puede ser más efectivo y a la larga mejor para el proyecto.

Así que ¿La TDD puede ser buena?, claro que si. ¿Nos hace mejores desarrolladores?, es otro rotundo si. ¿Se debe aplicar a todo lo que desarrollemos?, en mi humilde opinión, No, a veces es mejor no exagerar, ni con la TDD ni con la refactorización. Ya, reconocer si una función requiere refactorización o pruebas unitarias es algo que solo la experiencia puede definir.





x
Share:

viernes, 9 de marzo de 2018

Buenas practicas para llegar a XP No, no Windows XP - Extreme Programming

A mi me gustaría definir XP (Xtreme Programming), como “El arte de escribir y ejecutar código tan bueno, que si existiera un cielo para programadores, los que hacen XP tendrían todos los cupos”

Eso en el mundo ideal, pero para mi son simplemente una serie de reglas que nos hacen mejores profesionales en esto de tirar código, quedarnos calvos, no afeitarnos y consumir cantidades alarmantes de café.

A través de los años que llevo aprendiendo a programar (17 aproximadamente), he leído sobre muchas metodologías, consejos, reglas, etc. Que nos pueden hacer mejores, he aislado las que de verdad me han servido a mi personalmente, esperando que tal vez puedan ayudar o confundir aún más a alguien más.

1- Trabajar en un lugar tranquilo y quieto.
Programar es un trabajo que requiere concentración en niveles muy altos, y muchas personas no podemos mantener la concentración ante ruidos y distracciones visuales. Un lugar silencioso y tal vez solo con la música que me gusta o que me ayuda a concentrar sonando a mis oídos hace el mejor lugar para programar.

2- Siempre que se termine una tarea hacer deploy y pruebas.
Trabajar en un proyecto a largo plazo requiere de integración continua. Siempre que se termine una tarea se debe hacer un deploy al proyecto principal, hacer las pruebas y compilar si se requiere compilación.

3- Tener un script que haga pruebas y compile si es necesario en un paso.
Un script que una vez hecho el deploy, realice las pruebas unitarias automáticamente y compile si es necesario. 4- Sistema de control de versiones.
Git, CVS, ojalá se elija Git con GitFlow, aunque la elección es personal. Pero siempre usar control de versiones para el código.

5- En cuanto se encuentre un bug debe ser resuelto.
No dejar nunca bugs para después.

6- Base de datos de bugs.
Cada bug que se encuentre debe ser arreglado y además añadido a una base de datos de bugs del proyecto.

7- Tener historias de usuario claras y concisas.
Básico, cada requerimiento debe estar expresado y explicado en una historia de usuario. Así como las sub historias necesarias.

8- La comunicación entre todos los miembros del equipo debe ser constante.
Todos los miembros del equipo deben estar en sintonía. Idealmente en el mismo espacio físico

9- Nunca trabajar sobretiempo, y mantener un ritmo sostenible.
Una jornada de 8 horas diarias es más que suficiente de trabajo para un ser humano, hacer más de 8 horas de trabajo es contraproducente. Si se tiene que hacer sobretiempo, algo se está haciendo mal.

10- Siempre hay que medir la velocidad del proyecto.
Burndown Charts, Gantt Charts, hojas de excel, gráficos, siempre hay que medir la velocidad de los proyectos y calcular o mover la ETA. (Estimated Time of Arrival, Fecha de entrega estimada).

11- Simplicidad.
En el diseño, en el código, en las preguntas, en las respuestas, en todo, simplificar al máximo.

12- Refactorizar.
Siempre que se pueda, se debe hacer refactoring del código.

13- Ceñirse a los Estándares.
No es necesario usar los estándares de otra empresa, el equipo puede definir los propios, pero todo el código debe ceñirse a esos estándares. Si se usa una base como un cms o un framework, deben ceñirse a los estándares definidos para este.

14- Siempre escribir la prueba de unidad antes del código.
No necesita explicación, solo leer y aplicar TDD.

15- Cuando se encuentra un bug, escribir una prueba para ese bug.
Extender las pruebas de TDD para albergar las situaciones que genera el nuevo bug.

Algunas normas de la lista no hacen parte de la definición dada por XP (Xtreme Programming), y las he agregado por experiencia en varios proyectos. Así como también no inclui algunas de la lista de XP.

La lista de normas (reglas) de XP, las pueden encontrar aquí:

http://www.extremeprogramming.org/rules.html

Espero sea de ayuda para alguien esta lista. Cualquier cosa quedo atento a los comentarios.
Share:

miércoles, 7 de marzo de 2018

Certificados Scrum - ¡No certifican absolutamente nada!



Un certificado de Scrum no te certifica en absolutamente nada, hay quienes piensan diferente y consideran que una persona certificada en Scrum tiene ventajas sobre aquellos que no están certificados.

Un certificado lo único que me dice es que conoces bien la metodología, los términos aplicados y ciertas situaciones que aparecen en los métodos de estudio de las diferentes entidades certificantes. Pero Scrum es mucho más que términos y situaciones. Un equipo puede moldear y modificar tanto scrum que el memorizar estos datos no le servirá absolutamente para nada.

También el ceñirse a la metodología al pie de la letra va en contra de la definición de ágil. Scrum debe ser moldeable y debe amoldarse a las necesidades del equipo y el equipo debe poder moldearse sin sacrificar cosas importantes como rendimiento y ejecución.

Hace unos 4 años, trabajé con un equipo muy bueno, estabamos en diferentes partes del continente, sin diferencia horaria significante, todos muy capaces y buenos, cada uno en lo suyo, éramos tres scrum developers, un scrum master/project manager certificado por el Scrum Institute y con certificación PMI, y estoy seguro que tenía otras varias certificaciones en su currículum y un product owner que era la persona que se comunicaba con los clientes y entendía claramente las necesidades de los proyectos. Pero el equipo no funcionaba, hacíamos planning, daily por skype, teníamos axosoft a nuestra disposición, consultabamos todos los días, éramos buenos amigos y todos éramos muy profesionales y dimos lo mejor de cada uno para cada sprint, pero nuestros Sprint Review y nuestras Retrospectivas mostraban problemas y no podíamos hallar solución a estos.

Así estuvimos cerca de 2 meses, cuando alguien nuevo entró al equipo, esta persona no tenía certificación en ninguna metodología, es más creo que ni certificaciones técnicas tenia, era una mujer de Bogotá que había trabajado en diferentes empresas, mejorando procesos ágiles y había sacado adelante varios proyectos. No tenía grandes credenciales, pero entendía algo que no entendía nuestro Scrum Master por más certificaciones que tuviera encima.

“Ella entendía que ninguna metodología estaba escrita en piedra y se puede moldear a las necesidades del equipo, así como la experiencia para hacer de los equipos y las personas mejores”.

Lo primero que hizo fue que cada uno tuviera un Kanban físico en su pared, así cada uno podía saber que tenia por hacer, que estaba haciendo y que había hecho.

Modificó las ceremonias, durante las primeras semanas, como el equipo era autosuficiente, los Daily se trataban de temas personales que quisieramos compartir.

Nuestro Scrum Master pasó a ser Product Owner, y hacia un mejor trabajo que como Scrum Master (Que es la certificación que tiene).

El product owner ahora solo se dedicaba a recoger requerimientos y a mantener los clientes de la empresa como clientes, era la persona encargada de mercadeo y de atención al cliente, aspectos que mejoraron mucho.

Cada día invertía tiempo en revisar el trabajo de cada uno, el product owner debía cada día revisar y actualizar el backlog, nosotros los developers éramos responsables de nuestro trabajo y de aplicar técnicas de XP a nuestro desarrollo. Cada día además del Daily manteníamos contacto constante entre nosotros, y hacíamos preguntas sobre temas técnicos y si era necesario cambiar de tarea con alguno se hacía. Incluso intentamos hacer pair programming pero no fue posible por la distancia y por falta de una herramienta mejor. No se había aplicado la técnica a ningún IDE, al menos no una que fuera eficiente.

Después de 4 meses, nuestra “Scrum Master” nos abandonó, bueno, es una forma de decirlo, su trabajo consistía en ser mentora en metodologías ágiles, sin ser mentora certificada, y hacer que todos como equipo fuéramos mejores. Ambas metas se lograron, incluso yo quede como Scrum Master de ese equipo. No miento, me hacía falta la parte técnica y programar, pero con cada sprint me sentía orgulloso de haber aprendido tanto de ella, y de saber que no necesitaba que ningún instituto me dijera qué y cómo debía hacer las cosas, ya que la mejor Scrum Master que había conocido me había enseñado lo básico para seguir estudiando y creciendo por mi cuenta. Me había enseñado que el mejor aprendizaje es hacer y leer, y que la mejor certificación es cuestionar y que nada está grabado en piedra.

Como anécdota, ella fue contratada por una empresa londinense y ahora mismo esta radicada alla. Intenté pedir su permiso para publicar su nombre, pero aún siendo la mejor, sigue siendo muy timida y me pidió que no lo hiciera. :)



Share:

¿Por qué odio (odie) el agilismo?



Mientras trabajaba en una empresa hace unos años, siempre odie el agilismo y el Scrum, llegue a pensar que más que ágil, el concepto en si, entorpecía el desarrollo y llevaba a los equipos a ser muy suaves y coodependientes. Que equivocado estaba, pero la culpa no fue del todo mía. Solo un 95% fue culpa mía, el abismal 5% causante de el odio al Scrum y al Agilismo fue culpa mía también. Ahora pensando en retrospectiva, (Uso términos de scrum sin darme cuenta), he podido aislar que fue lo que salio mal en ese entonces, y tal vez sea la causa de que en muchas empresas sus empleadas hagan "Scrum" por hacerlo, porque hacer Scrum sin querer no sirve, no funciona y da más problemas que soluciones.

Un día en la empresa en la que trabajaba, a nuestro CEO; que por cierto es una persona que respeto mucho y se que ama y defiende todas las metodologías ágiles a capa y espada; se le ocurrió que los equipos de trabajo implementaran Scrum como metodología para el desarrollo de software.

Como buen amante del rugby, esto fue lo primero que vino a mi cabeza:

Establecer el valor de un punto de historia, para al final decidirnos por usar horas como veníamos haciendo.
Priorizar las tareas. Para nuestro product owner el 90% de las historias era primordial, el otro 10% también.
Establecer nuestra definición de hecho, que se mantuvo igual durante el tiempo que estuve en la empresa.
Una hora en entender el formato de las historias de usuario. Yo como rol requiero ...
Una hora construyendo un tablero para el backlog y el scrum board (Que despues se mejoró a un Kanban Board)

- Todos tenían impedimentos en sus tareas, por falta de conocimiento o porque la asignación se hizo a dedo, porque nadie quería tomar las tareas complejas.

Despues de una reunión de todo el equipo de desarrollo y administrativo de la empresa, se nos entregaron las bases del Scrum, la guía Scrum (Scrum Guide) se nos explico muy por encima en que consistían las metodologías ágiles. Las ceremonias de Scrum, los roles y los artefactos, y casi inmediatamente se nos presento con nuestro primer "Sprint Planning" o reunión de planificación de Sprint. 

(No se preocupen si no saben que es un Sprint Planning, conozco scrum hace más de 5 años y aún no se completamente que es y hace cada ceremonia. Todo porque el proceso es orgánico, en otro post se hablara mejor de esto.).

Yo, tome el rol de Scrum Master, sin entender del todo que era lo que hacía, y creo que el resto de la empresa tampoco lo sabía, seguía siendo el project manager, seguía siendo el programador líder, y lo peor, seguía involucrado 100% en el desarrollo como programador y técnico. Nadie, absolutamente nadie en la empresa estaba certificado en Scrum, no es que hiciera falta, porque unos años más tarde entendí que un certificado no hace de una persona un mejor miembro del equipo en cuanto a scrum se refiere. Y pues el equipo a mi cargo era Junior en su totalidad, lo que dificultaba las cosas en cuanto a estimación, riesgos y gestión.

Por cierto, tengo pendiente un post sobre el tema, "El que una persona este certificada en scrum no significa absolutamente nada".

Terminamos nuestro "planning" que debería tomar 2 horas, en unas 8 horas. Y ya teníamos 6 horas de retraso en nuestro Sprint. El tiempo se fue:

Esto si tenemos en cuenta que eramos 5 personas, fueron 40 horas/persona en un sprint, y eso que íbamos en el planning no más. Así fue nuestro viernes.


Y llego el lunes... (El día de la pesadilla.)

El día empezó muy bien, cada uno tenía su tarea asignada, y todo fluía maravillosamente, e hicimos nuestra primera reunión diaria (daily scrum o daily meeting para bilingües).

Se supone la reunión era a las 10:00 a.m. Digo se supone porque todos estábamos ocupados en algo critico y la reunión se aplazo casi hasta las 11:00 a.m. Una vez empezó la reunión, empezó el caos. Resumiendo:

- El scrum master (Yo) también era programador y también tenía impedimentos, el impedimento es que mis labores como scrum master me restaban tiempo de mis tareas de programador, y por lo tanto no tenía el tiempo para resolver los impedimentos del resto del equipo.

- Nuestro equipo no era interdisciplinario ni autosuficiente, y dependíamos del departamento de diseño gráfico, que a su vez respondía a varios equipos y que de por si ya tenía su propio equipo de scrum con mercadeo.

- Nuestro product owner, que era la diseñadora y no tenía contacto con el cliente, seguía incluyendo requerimientos que el cliente pasaba al CEO o a mi directamente, e incluyendolos entre los requerimientos super importantes que sumaban al 100% de requerimientos urgentes que había.

- Y para rematar el "daily", que debería durar 15 minutos tomo casi 1 hora.

El resto del día paso sin novedad, excepto el estress, los animos bajos y el respectivo mal genio de todo el mundo por no poder cumplir sus tareas y el que la persona que debería ayudar a solucionar esos impedimentos (Yo, el super scrum master) no podía, ya que tenía sus propios impedimentos.

Despues de una semana. Algunas cosas pasaron: 

Lo bueno:

- Nuestros dailies ya no duraban una hora, habían bajado a 20 minutos aproximadamente.

- Cada persona conocia sus tareas y estaba enfocada en terminarlas.

- Los impedimentos habían bajado.

Lo malo:

- Yo seguía sin tener tiempo para ser scrum master y developer, estaba saturado de trabajo y de horas.

- El equipo no crecía, simplemente cumplía con las tareas, con sobrecostos y sobretiempo. 

- Cuando por fin entendí como hacer diagramas de Burndown (Cosa que no aparece en los requerimientos para ser scrum master). Me di cuenta de lo mal que estábamos.

- A pesar de que estaban impresos y por toda la oficina, nadie reparaba las razones ni las definiciones de los artefactos, ceremonias y roles.

Lo feo:

- El ambiente con la administración se puso muy tenso. Obviamente los resultados no eran los mejores.

- Aún con un solo equipo, el "scrum" no era nada ágil, nuestras iteraciones no iban a entregar valor hasta el final, y solo pasamos en seccionar el método de cascada en varias cascadas pequeñas que no podían ser evaluadas independientemente, sino que tenían que confluir de nuevo en la cascada gigante.


Así que ahí estábamos, El bueno, El malo, El feo y el Scrum master.

Y así pasamos a nuestro primer sprint review. Nuestra product owner no veía avances, porque no los habían, el equipo tenía la moral baja por no cumplir las expectativas y yo no tenía como responder por lo que estaba pasando, porque no sabía que pasaba, ¿Por qué el super Scrum que funcionaba en todo el mundo, no funcionaba para nosotros?

La respuesta estaba frente a mis ojos en ese momento, en el equipo, en el CEO, en todos, solo que aún no me había dado cuenta, y me di cuenta despues de que me marche de la empresa, pero esa es otra historia.

Para algunos de nosotros "ágil = scrum" era nuestro dogma, y pensabamos que el simple hecho de hacer las ceremonias nos hacía ágiles. Estábamos muy equivocados.

El Scrum, y las metodologías ágiles en general, no son para todo el mundo ni para todas las situaciones, no son el santo grial prometido, y en ciertas ocasiones, sencillamente, no funciona.

Un resumen corto de loque nos faltó:

- El Scrum Master debe conocer el Scrum de arriba a abajo. Debe respirar Scrum y debe vivir creyendo que funciona y que puede solventar gran parte de sus problemas.

- El Scrum Master debe ser solo Scrum master, debe tener conocimientos interdisciplinarios, debe poder hablar con la parte adminsitrativa de la empresa sin miedo, debe poder decidir cuando cortar algo de raíz, cuando cancelar y cuando seguir con algo, debe estar pendiente de sus equipos y de sus product owners, debe dirigir las ceremonias, debe presentar los reportes, debe hallar las fallas y los cuellos de botella a tiempo y sobre todo debe tener un equipo capaz.

- El Scrum master no debe estar en otras tareas que no sean las de Scrum master y tener su checklist a la mano y aplicarla todos los días.

- La definición de hecho debe ser completa y autocontenida, no debe depender de la opinión de terceros ni tampoco de las tareas de terceros.

- Si todo el equipo no esta comprometido con el Scrum, no es posible aplicarlo, es mejor sacar un huevo podrido del panal que perder todos los huevos.

- El scrum master debe poder mostrar al equipo que es el Scrum y como mejora los procesos y a las personas, así se evita el punto anterior.

- Un equipo debe ser interdisciplinario, pero también disciplinado, deben estudiar por su cuenta, mejorar, aprender y dar lo mejor de si para que el equipo sea más fuerte. Esto viene del Rugby y cualquier deporte de equipo. Una cadena es tan fuerte como su eslabón más débil.

- El Scrum no se puede aplicar ni aprender en una semana, toma años siquiera entender la mentalidad detrás de este y todos los procesos ágiles.

- El Scrum no funciona en todos los proyectos.

- Antes de poder hacer un Scrum hay que ser un equipo, y un equipo trabaja en conjunto, en igualdad de condiciones para una meta común.

- Por ultimo, y, aunque va en contra de uno los valores del manifiesto ágil, pero a nivel estructural y funcional de una empresa es vital. Si, alguna persona, definitivamente no funciona, se debe dejar ir. No es feliz y hace que los demás miembros del equipo se sientan mal porque esta afectando el rendimiento y el como se ve el equipo, no solo se afecta a el mismo. El bienestar del equipo siempre debe ser más importante que el de un individuo.

Conclusión:

No se debe entregar un libro de Scrum a un equipo y decirles, hagan lo que dice el libro que les va a cambiar la vida. El Scrum es orgánico y debe crecer y adaptarse a cada equipo, y llegar a un punto donde esta cerca de ser perfecto toma años, y toma el mismo tiempo darse cuenta de que siempre hay espacio para mejorar y que es un proceso de nunca acabar, pero que siempre nos hará mejores personas y mejores miembros de un equipo, mientras generamos valor.
Share: