Cuando el mínimo producto viable es demasiado grande

El proyecto en el que estamos trabajando es una plataforma que nuestro cliente ofrece como servicio a sus propios clientes bajo un modelo tipo “suscripción”.

Más específicamente estamos construyendo una nueva versión de esta plataforma, pues el cliente ya tiene versión que ha construido durante varios años. Más aún el cliente ya está recuperando su inversión. Las razones que lo llevan al contratar a un nuevo proveedor para hacer una nueva versión de su plataforma no vienen al caso en este artículo, pero es interesante destacar que la nueva versión no incluye nuevas funcionalidades (al menos en un principio) aunque se espera que resulte mucho más estable y escalable. Pero esta cuestiones técnicas no son precisamente lo que más me inquieta.

El tema que más me inquieta tiene que ver con la planificación. Construir un nuevo producto con toda la funcionalidad existente en el producto actual podría llevarnos más de un año. Demasiado tiempo, demasiado riesgo.

En estos días precisamente estamos trabajando con la gente de negocio para intentar identificar un estrategia que nos permita liberar al menos una parte del producto y de esa forma comenzar a tener un retorno de la inversión y mitigar los riesgos.

Continuara…

 

Categorias de prácticas DevOps

Por estos días me encuentro leyendo el libro de DevOps del SEI que me compré el mes pasado. Llevo leído aproximadamente un tercio de libro y por el momento viene bien, o sea, la mayoría de las cosas ya las conocía, algunas pocas no y otras pocas no estoy seguro de compartirlas. Entre las cosas que no conocía hay una en particular que me resultó muy interesante: la categorización de las prácticas DevOps. El libro propone agrupar las prácticas en 5 categorías:

  1. Hacer al grupo de Operaciones un ciudadano de primera clase (first-class citizen).
  2. Hacer al grupo de Desarrollo responsable del manejo de los incidentes en producción
  3. Establecer un proceso formal de deployment
  4. Usar Continuous Deployment
  5. Manejar la infraestructura como código

En teoría todas las prácticas DevOps podrían caer en alguna de estas 5 categorías. A mi parecer las 3 primeras categorías son más de índole “cultural” o de proceso, mientras que las 2 últimas son más de índole técnica. En este sentido el poder hacer la distinción puede ayudar a la hora de armar un plan de adopción de DevOps.

El desafío de las pequeñas empresas de IT versus las grandes multinacionales

El año pasado tuve la oportunidad de trabajar por un período muy breve con un joven y talentoso ingeniero de @Fiuba. En aquel momento él trabaja para una empresa de desarrollo de software de tamaño mediano (en términos de Argentina serian unos 100 empleados). Recientemente supe que fue contratado por una empresa multinacional y eso me recordó un pasaje de mi propia carrera profesional. Al mismo tiempo me puse a pensar ¿como pueden hacer las pequeñas empresas para retener a sus talentos ante las ofertas de las grandes empresas?

En primer lugar sospecho que la cuestión no pasa por dinero/beneficios, porque creo que incluso cuando las pequeñas empresas pudieran competir (o incluso superar) las ofertas económicas de las grandes empresas, creo que hay otra serie de cuestiones mucho más influyentes. Tomo mi propio caso, cuando decidí trabajar para un gigante multinacional no lo hice por dinero sino para ganar experiencia y hacer carrera. El trabajar en una empresa grande de primer nivel mundial ofrece una serie de oportunidades/desafíos que para algunos (yo incluido) resultan sumamente atractivos.

Hace un par de días vengo pensando sobre este tema y se me ocurrieron dos estrategias posibles para competir con las grandes empresas:

  • Ser parte: conozco un par de casos de empresas pequeñas (menos de 50 empleados) que a partir de una estructura casi horizontal cuentan con mecanismos para hacer participes a su gente del rumbo de la empresa. Un caso de esto es @10Pines.  Otro caso similar pero un poco distinto es Tecso, que tiene la particularidad de ser bastante más grande (creo que son más de 200 empleados). Creo que el “ser parte” en este sentido puede resultar muy incentivo muy importante y muy difícil de lograr en las grandes empresas (aclaración: tener acciones de la empresa no necesariamente te “hace parte”)
  • Plan de carrera: este punto es justamente una de las falencias de muchas empresas chicas, no tienen planes de carrera, cosa que si suelen tener las grandes empresas. A pesar de esto creo que si las empresas chicas invirtieran en armar planes de carrera, podrían ofrecer a sus empleados alternativas incluso más interesantes que las ofrecidos por las grandes empresas. Un situación común en las grandes empresas es que a partir de cierto punto para crecer hay que ocupar una posición de gestión, o sea los planes de carrera para perfiles técnicos suelen ser muy limitados. Una empresa pequeña que me consta supo tener en algún momento un plan de carrera claramente definido y muy atractivo para gente de perfil técnico fue @Southworks.

¿Alguna otra idea o comentarios para sumar?

El equipo de DevOps

El equipo de DevOps

Como mencioné anteriormente ya estamos en producción y dado que el cliente no tiene un area de sistemas está acordado que nosotros mismos nos encarguemos de la operación. Para esto armamos el equipo “DevOps”, y para ser sincero debo admitir que inicialmente el nombre no me cerró, yo lo habría llamado directamente “operaciones”. Pero creo que la intención al llamarle “DevOps” fue ya desde el nombre intentar transmitir el mindset con el que se quiere trabajar. En fin, en punto del nombre no es tan relevante. Creo que lo interesante es la forma en que estamos intentando trabajar. En este momento somos 3 personas:

  • Una persona con skills de operaciones/sysadmin y automatización (en particular usando Chef)
  • Una persona proveniente del equipo de UI (js/html/css)
  • Una persona proveniente del equipo de desarrollo server-side (C#). Este soy yo, que adicionalmente estoy oficiando de “facilitador” del equipo

Para la coordinación/organización del equipo estamos usando las siguientes herramientas:

  • Una lista de correo
  • Un canal de Slack
  • Un tablero Kanban (en Jira)

Respecto de la dinámica de trabajo, trabajamos en un flujo continuo, limitando el work-in-progress e intentando planificar semanalmente. En este sentido cada lunes reportamos los items completados la semana anterior e identificamos los items más prioritarios para trabajar en la semana actual. Luego con el correr los días se van sumando a nuestro backlog nuevos items que debemos atender en forma inmediata. En todos los casos estos items “urgentes y no planeados” los registramos en el Jira para que quede constancia de nuestro trabajo.

Respeto del tipo de tareas que realizamos, en este momento tenemos 3 hilos de trabajo principales:

  • Automatizar el provisionamiento de toda nuestra infraestructura
  • Armar la arquitectura de build y el pipeline de deployment
  • Atender pedidos puntuales de los equipos de desarrollo (por ejemplo asistir a un equipo en la configuración de alguna herramienta cuya configuración aún no está automatizada)

Un punto que puede resultar curioso es que este equipo de operaciones no se encarga completamente de la operación, al menos no por ahora. En este momento tenemos una solo aplicación en producción pero es el equipo que la desarrolló quien la monitorea y atiende eventuales alertas.

Por el momento me gusta la forma en que esto está fluyendo, pero recién empezamos, ya veremos como evoluciona.

 

projifm: Estadísticas del primer release

Finalmente la semana pasada salimos a producción. El evento en cierto modo fue muy tranquilo ya que nuestra aplicación estaba instalada y funcionando en el ambiente productivo desde hacía varias semanas.
Comparto aquí algunas estadísticas:
Estadísticas de proceso
  • 7 iteraciones (2 semanas cada una) con un equipo de 5 ingenieros
  • 6 semanas de trabajo “on-demand” de un ingeniero monitoreando y realizando ajustes menores
  • 313 items de Jira resueltos
Estadísticas de código
(esto números son específicos del nuestra aplicación, pero el equipo también trabajó sobre componentes compartidos con otras aplicaciones que no está considerados aquí)
  • 138 test automatizados
  • 83.5% de cobertura
  • 67 clases (sin contar las clases de tests)
  • 7329 líneas totales de código
  • 4211 líneas de  código productivo (57%)
  • 3118 líneas de código de tests (43%)

Deuda técnica
Al momento de este primer release registramos los siguientes items de deuda técnica:

  • Código duplicado en los tests
  • Dependencias externas desactualizadas
  • Falta de monitoreo más granular de ciertos components

PCE-Evolution: An infrastructure pattern

Beyond which environments I use on different project/organisation there is one recurrent strategy that I have applied several times in different context. I may say it is a pattern.

The problem

Like any pattern explanation it should start with a problem, so here it is: it is very common production environments to be large in term of hardware capacity and also in size of data. This makes difficult (and/or very expensive) to replicate the production environment to test your application. If you test in an environment different from the production environment you are taking a risk, and the bigger the difference is the higher the risk you are taking.

The solution

Your application pass through different environments from you local development machine to the final production environment.  These two environments are the extremes of your pipeline, so you should make use that each intermediate environment is “closer” to the production environment.

Example

Local development environment (your workstation): here you run the whole application in an isolated way, you have a local DB installed and external services dependencies may be mocked. Your hardware is not comparable to production’s hardware. Even your OS may be different: you may use Windows 10 or Mac or Ubuntu Desktop, while your production server may run Windows Server or Ubuntu Server. In terms of the previously mentioned dimensions, all of them are different from production.

Development environment: your hardware is still far from production, but at least you have the same OS asp production but the other dimensions are still different.

Test Environment: here your layout is the same as production, that is: if you have a cluster for the production DB, then you also have a cluster for test DB but possibly your test DB cluster has less servers that the production one.

This way the closer to production the more Production-like, Complex and Expensive.

infra_pattern

Una visión formal/académica sobre DevOps

Ayer por la tarde “me interné” en un local de Barnes&Noble y recorriendo la sección de libros de tecnología me encontré con un libro cuya existencia desconocía: DevOps, a Software Architect’s Perspective de Len Bass y Cía.

Apenas leí el índice no dudé ni un instante en comprarlo ya que es el primer libro que veo sobre esta temática de una fuente “formal/académica” como es el SEI-CMU.

Anoche empecé a leerlo y por el momento pinta muy interesante.

devops_book_sei