Nuevos horizontes - Tritium Software

Bueno, llevaba semanas queriendo escribir este artículo, pero no había encontrado el momento.

Como alguno de vosotros ya sabéis hace ya unas semanas que acepté un nuevo reto profesional, después de una larga y, por que no decirlo, dura pausa. Durante este tiempo he aprovechado para estudiar mucho, cumplir una de mis cuentas pendientes - User Agile Development), y cuidarme menos de lo que me habría buscado.

La incertidumbre te atenaza, más de lo que jamás habría pensado.

He participado en multitud de, agotadores, procesos de selección, y la decisión no fue nada fácil. Me siento muy afortunado, en primer lugar por poder haber podido decidir, y además por haber encontrado un lugar en el que, pese que voy a currar de lo lindo (es lo que quiero, lo que me gusta, y lo que me llena) voy a seguir trabajando en un start-up, dentro del ámbito de producto, y teniendo la oportunidad de crear y liderar el equipo de trabajo.

Tritium Software, S.L. es una compañía catalana, que acaba de cerrar su primera ronda de financiación, y que dispone de un producto CRM (para los no iniciados - una herramienta de gestión de clientes (Customer Relationship Management) ofreciendo una clara orientación a movilidad, ofreciendo clientes para iPhone, Android, BlackBerry y próximamente para iPad y Playbook.)

Como buena startup todos tenemos que empujar en todas direcciones, pero mi responsabilidad es la de dirigir el equipo de producción, consolidar el uso de buenas prácticas (basándome dentro de lo posible en metodologías ágiles, perfectas en este contexto)

Para ello, después de evaluar diferentes herramientas  TeamBox, GoPlan, Assembla ... y como no JIRA, la decisión ha sido continuar con el mismo sistema que utilizamos en Grouxo, y no es otro que Assembla.

Los motivos son los siguientes:

• Ofrece un repositorio SVN integrado con la herramienta colaborativa. Git es una propuesta de lo más interesante, y mucho más potente que SVN, pero exige cierta disciplina y experiencia en el uso de repositorios (Algo que no tiene por que estar asegurado en nuestro contexto)
• Dispones de herramienta wiki integrada en el portal
• Dispones de issue traking totalmente adaptado para metodologías ágiles, con un Cardwall que hace las delicias como un perfecto Task Board, unas gráficas BurnChart suficientes, y una sección StandUp para los informes matinales de actividad de todo el equipo
• Además los planes básicos, aunque se me antojan algo limitados ya que solo permiten 1 espacio y 1 Gb de espacio, tienen un precio de lo más razonable 9$ /mes (90$ / año)

A medio/largo plazo mi opción predilecta es JIRA, que en su versión cloud integra confluence, greenhopper, subversion, fisheye, bamboo ... es decir lo ideal para tener un entorno de integración continua completo. No se si es buena opción en cloud o gestionado por nosotros mismos si disponemos de los recursos necesarios, eso nos permitiría por ejemplo incluir Sonar, etc.

En fin, una aventura muy interesante. 

Estamos en un momento de consolidación/constitución del equipo, no dudes en hacernos llegar tu CV si te gusta la iniciativa y consideras que puedes aportar tu granito de arena.

Un abrazo,

User Agile development. Best practices

Fruto de las muchas y recientes adopciones de las metodologías ágiles por parte de la industria, los partidarios de UCD han debido pensar en cómo plantear su integración. A continuación expongo una relación de buenas prácticas iniciadas por Patton en 2008, y que Pirkka Rannikko expone en su Tesis.

1. UCD debe adoptar la mentalidad ágil. Es imprescindible ese cambio de mentalidad de cascada a ágil para poder garantizar el éxito. Los expertos en UCD deben verse así mismos como miembros del equipo ágil.
2. UCD debe estar cerca del Product Owner. Deben trabajar cerca, incluso en algunos casos ser el product onwer. Ese camino ayudará a influenciar para que los objetivos del proyecto estén alineados con los usuarios
3. UCD debe estar físicamente. Es bueno que el especialista en UCD co-habite con el resto del equipo de desarrollo para enfatizar la buena comunicación entre ambos.
4. Cross-functional Team. El equipo debe participar de manera conjunta en todos los pasos del ciclo de vida, de manera complementaria, pero conjunta, para compartir el conocimiento del por qué en las tomas de decisiones.
5. Gestión común del proyecto. La gestión del proyecto debe ser común para todos, por lo que las tareas que no sean de desarrollo, deben igualmente romperse, estimar su velocidad. Esto unifica el modo de trabajo de todo, y facilita la gestión
6. Diseñar un programa de socios. Existen algunos usuarios del proyecto que participaran en las fases iniciales de estudio, o en las finales de validación, pero otros usuarios representativos pueden convertirse en 'socios' y comprometerse durante todo el proyecto, reclutar este tipo de usuarios es muy recomendable y ayuda la logística de los test de usabilidad
7. UCD trabajos previos de interfaz. Existen trabajos que pueden y deben adelantarse al inicio del desarrollo, en caso contrario pueden convertirse en cuello de botella, y crear riesgos indeseados. Requisitos de alto nivel, diseño conceptual de la solución, diseño UI inicial, incluso la guía de estilos.
8. Desacoplar investigación de usuario. Fuera del ciclo de vida ordinario del proyecto, se deben paralelizar algunas investigaciones de usuario, para adelantar o cubrir futuras necesidades del proyecto
9. Diseños pequeños / Just InTime. Los diseños se dividen en tareas menores, a ser realizadas incrementalmente tal y como sucede con historias de requisitos o funcionalidades. Para paralelizar trabajos de desarrollo y diseño en un mismo sprint. (Aunque sea en ciclos cruzados como hemos visto en anteriores artículos)
10. Desarrollo paralelo. Tal y como adelantamos en el punto anterior, el UCD trabaja en paralelo pero iniciando los diseños 1 o 2 sprints antes de su desarrollo.
11. Historias de usuario mejoradas. Las historias de usuario deben reflejar los requisitos de diseño y usabilidad, por lo que los criterios de aceptación deben incluirlos. 
12. Solución enfocada a pruebas de usabilidad. Además de las pruebas automáticas unitarias y de integración, y además de las pruebas de validación, se deben incluir tempranas y periódicas pruebas de usabilidad. Se debe ayudar al equipo a solucionar de manera eficaz los problemas (RITE)

Como sucede con las metodologías ágiles en general, estamos hablando de guidelines, siento insistir mucho en este punto, pero es importante entender que no estamos hablando de reglas a seguir sí o sí, como pasaría con CMMI, por poner un ejemplo. Si no líneas maestras que deberás aplicar o no en función del equipo, el cliente, tu organización, etc.

Saludos,