Uno de los desafíos de mi proyecto actual está en lograr un entregable de valor en pocas semanas y la clave para lograr eso es poder cortar las funcionalidades bien «finitas», lo que en la jerga agile suele denominarse slicing.
El tema con el slicing es que no es fácil de hacerlo y en ocasiones se lleva a cabo de forma inapropiada por no involucrar a todos los perfiles necesarios. En este sentido, para poder hacer un buen slicing es necesario:
Gente de negocio que conozca perfectamente el negocio y particularmente el subdominio de la aplicación en desarrollo
Gente técnica que sea capaz de entender las funcionalidades y pueda dimensionarlas en términos de complejidad y costo de implementación.
Gente con poder de decisión
La falta de cualquiera de estos tres grupos resulta riesgoso ya que uno podría terminar generando un incremento funcionalmente pequeño pero técnicamente demasiado grande o un incremento técnicamente manejable pero sin valor de negocio o incluso un incremente pequeño, tanto funcional como técnicamente, pero sin apoyo «respaldo político» para su realización.
El sujeto C hace de intermediario, básicamente contacta A conB. Este sujeto C está intermediando, en cierto modo el negocio se produce gracias a él. Entonces ¿cuál es el valor de su servicio?
Estas situaciones son cada vez más frecuentes. Un ícono es Mercado Libre, pero hoy en día hay N ejemplos análogos: AirBnb, Uber, Globo, entre otros. El costo de intermediación como también el alcance del servicio que brinda el intermediario varía de un caso a otro.
Pero esta situación también ocurre fuera de la plataformas y es muy común en la provisión de servicios de TI. A mi personalmente me pasa muy seguido con mi actividad profesional. Una empresa A contacta a una empresa B para la provisión de un servicio. La empresa B no tiene la capacidad de brindar el servicio entonces me contacta a mi. En general yo termino haciendo el trabajo en forma solitaria, prácticamente sin apoyo ni intervención de la empresa B.
La empresa A abona un valor X por el servicio que yo brindo y la empresa B se lleva una tajada por haber traído el cliente y por algún costo de operación ¿Cuánto debería ser esa tajada de la empresa B?
Yo me he encontrado con distintas situaciones pero en términos simplificados hay dos extremos:
La empresa B (llamemosla tipo 1) que pretende asegurar una rentabilidad R en todo lo que factura. En este caso toma mi presupuesto y le aplica un % extra para cumplir con su expectativa de rentabilidad sin mayor cuestionamiento.
La empresa B (llamemosla tipo 2) que tiene su negocio propio negocio que no pasa por la intermediación y no le interesa asegurar una rentabilidad de un trabajo en el que no participa. En este caso la empresa sale del medio dejando a las partes transaccionar en forma directa o bien permanece dentro de la transacción pero aplicando un % que representa los costos operativos sin ninguna expectativa de rentabilidad adicional.
A todo esto se agrega un situación interesante. Luego de haber hecho un delivery exitoso, la empresa A me contacta en forma directa para otro proyecto. O sea: la empresa A no llama a la empresa B sino que me llama a mi, NicoPaez. Yo por una cuestión de «lealtad comercial», hago participe a la empresa B de la nueva propuesta. Y aquí se dan dos situaciones:
Si la empresa B es de tipo 2, en general me dice: «te llamaron a vos, es tuyo«
Si la empresa B es de tipo 1, toma el proyecto en sus manos y acciona de su forma habitual: me pregunta cuánto quiero y le agrega un porcentaje para asegurar su rentabilidad. Luego deja que yo me encargue por completo del delivery del proyecto.
Hasta el momento yo siempre he pasado mi presupuesto y dejado que la empresa B aplique el markup que guste, pero es algo que ya hace un tiempo me estoy replanteando porque al dejar que la empresa B establezca el libremente su % de rentabilidad se corre el riesgo de perder el proyecto por ser muy caro. Al mismo tiempo dado que estamos hablando de negocios entre empresas, si la empresa A está dispuesta a pagar X, yo que hago el delivery y asumo los riesgos quiero llevarme la mayor parte posible de ese X (e incluso sacar del medio a la empresa B si no está agregando valor).
Me gustaría leer opiniones, ya sea que se hayan encontrado con situaciones así o no.
En breve estoy empezando a trabajar en un nuevo proyecto con .Net. Es mi vuelta a tecnología .Net luego de casi 3 años. Pero una diferencia relevante respecto de mi último proyecto es que en este caso utilizaremos .Net Core. En mi proyecto anterior utilicé .Net Framework 4.6 y dado que yo «vivo en MacOS» utilicé una máquina virtual con Windows 7 y Visual Studio 2017, lo cual anduvo muy bien. En este caso, dado que .Net Core corre nativamente en MacOS estoy apostando a esa posibilidad. Para esto instalé .Net Core y estuve probando distintas alternativas de IDE.
Precisamente el tema del IDE es una de las novedades más importante del mundo .Net. Tradicionalmente trabajar con .Net implicaba casi irremediablemente utilizar Visual Studio, porque si bien había algunas otras alternativas, ninguna estaba lo suficientemente estable o contaba con las funcionalidades necesarias para el desarrollo profesional. Con la salida de .Net Core y la iniciativa de Omnisharp, hoy en día es posible elegir entre varias alternativas.
Lo primero que probé fue utilizar Visual Studio Code que tiene un plugin para .Net/C#. La experiencia está bastante lograda, es posible correr los tests y debuggearlos desde dentro VSCode. También ofrece soporte para algunos refactors. Con el agregado de algunos otros plugins y la combinación con el dotnet-cli es una alternativamente perfectamente válida. Pero no quise quedarme ahí así que continúe probando.
Lo segundo que probé fue Visual Studio para Mac, la prueba fue corta pues me resultó muy incómodo ya que es distinto al tradicional Visual Studio de Windows y me sentí desorientado. Da la sensación que quisieron adaptar el Visual Studio a ciertas cuestiones de UI/UX de MacOS y el resultado para mi no fue bueno.
Mi tercera prueba fue con Rider, el IDE de JetBrains. Desde hace bastante tiempo cuando trabajo con Java uso el IDE de JetBrains (IntelliJ) con lo cual tenía que probar Rider. Y no me defraudó, la experiencia me resultó muy buena ya que a nivel IDE es casi como trabajar con IntelliJ y la integración con las herramientas .Net está muy bien lograda.
Aún tengo que hacer algunas pruebas para ver el soporte y la integración con algunos frameworks/herramientas de desarrollo (specflow por ejemplo) pero en principio estaré entre Rider y VSCode.
Ya están abiertas las convocatorias para presentaciones/artículos para varias conferencias tanto industriales como académicas y varias tienen deadlines en breve.
Dentro del ámbito de industria está abierto el CFP de Agile 2020, la conferencia anual de la Agile Alliance en USA. Este año la conferencia será en Orlando del 20 al 24 de julio. Un punto interesante de este CFP es que si uno envía su propuesta antes del 5 de Febrero uno puede obtener feedback formal para mejorar su propuesta antes del envió final cuya fecha límite es el 9 de febrero. Este mecanismo ya está vigente desde hace un par de años y a mi personalmente me resultó muy valioso.
También dentro del ámbito industrial está abierto el CFP de NDC Oslo, la nueva versión de la original Norway Developer Conference, una conferencia dedicada principalmente a programadores de la industria. Hace ya un par de años y dada su popularidad, la Norway Developer Conference (NDC) fue renombrada a New Developer Conference y pasó de hacer exclusivamente en Noruega (Oslo) a hacerse en diversas partes del mundo. Es así que hoy en día hay NDC en diversas ciudades del mundo (Oslo, Londres, Sydney, etc). La fecha límite para envío de propuestas para Oslo es el 15 de febrero.
A mitad de camino entre industria y academia está la XP que tiene varios CFP, algunos académicos y otros de industria. Este año la XP se realiza en Copenhagen, Dinamarca del 8 al 12 de Junio. La fecha límite para el envío de trabajos de investigación es el 29 de febrero, mientras que la correspondiente para sesiones de industria & practica es el 5 de febrero.
Dentro de ámbito académico abrió hace unos días el CFP de ARGENCON, la conferencia bianual de IEEE Argentina . Esta edición 2020 se realizará en UTN Resistencia, Chaco del 24 al 26 de junio. La fecha límite para el envió de trabajos es el 15 de marzo.
La mayoría de la gente que conozco que trabaja en investigación lo hace con una alta dedicación. En general tienen un cargo de tiempo completo en la academia y dentro de ese contexto hacen investigación y algunas otras tareas como dar clases o participar de proyectos de extensión.
Pero en el grupo de investigación de que yo trabajo nadie tiene una dedicación de tiempo completo en la academia. Más aún algunos tienen dedicación de tiempo completo en la industria y la cuestión académica la hacen en «tiempo-extra». Solo el director del proyecto tiene dedicación de tiempo completo en la academia, pero aún así la mayoría de su tiempo está dedicado a cuestiones administrativas/operativas ya que además de dirigir nuestro proyecto es también el director de la carrera de grado.
En mi caso particular yo tengo un cargo docente de dedicación no-exlusiva para dictar una materia y hacer investigación y colaborar en cuestiones varias con la dirección de la carrera. El presupuesto que nos da el hecho de tener el proyecto formalmente radicado en la universidad está restringido para ser utilizado en viajes, entradas a conferencia, pago de algunos recursos, etc, pero no sueldos. Al mismo tiempo, como contraprestación tenemos que generar cierta cantidad de publicaciones.
Respecto de la dinámica de trabajo en nuestro grupo de investigación cada miembro trabaja en un línea de investigación de la cual es responsable y como tal establece el ritmo de trabajo y es quien «rema» para publicar los resultados de su línea de investigación. Al mismo tiempo cada uno colabora con alguna otra línea y obviamente el director del grupo está involucrado en todas las líneas. En mi caso mi línea de trabajo es en Métodos Agiles de Desarrollo de Software y colaboro con DiegoF quien trabaja en cuestiones de Usabilidad de Procesos. A su vez DiegoF colabora con mi trabajo. Mas allá de todos los experimentos, hallazgos y conclusiones que uno logre en su investigación el avance y aporte de un proyecto se mide en términos de publicaciones. Esto se debe a que la publicación tiene un doble cometido. Por un lado es un mecanismo de validación, previo a la publicación el trabajo es evaluado por un comité y solo es publicado si ese comité lo considera valioso y correcto. Por otro lado la publicación es la forma de difundir trabajos y sus hallazgos.
Conceptualmente uno debería hacer el trabajo de investigación y luego ver dónde publicar. Pero personalmente esto no me funciona, o sea, necesito poner un deadline para evitar el trabajo se extienda infinitamente. Por eso, cuando logro cierto grado de avance ya intento definir una conferencia para publicar y eso ya me establece un deadline de finalización.
Para este 2020 tengo en mi plan de trabajo hacer tres publicaciones, dos de las cuales ya tengo en mente donde. El número no es arbitrario sino que tiene que ver con tres hitos/avances esperados de mi proyecto de investigación.
Yo me sumé al grupo de investigación en 2016 con lo cual mi experiencia es bastante acotada, pero a pesar de ello en estos 4 años he publicado, dentro de mi línea de investigación, 5 artículos en conferencias locales y 4 en conferencias internacionales. Más allá de las publicaciones estoy muy conforme con lo logrado porque he aprendido mucho de los temas investigados y también de cuestiones de metodología de investigación.
Por estos días estamos planificando los próximos dos años del proyecto de investigación (las convocatorias de proyectos de UNTreF son bi-anuales). Personalmente creo que hemos consolidado el grupo y me parece que estamos en condiciones de sumar más gente, de hecho ya tenemos algunas incorporaciones confirmadas.
Continuando con el tema de patrones del post anterior, se me ocurrió compartir esta breve reseña de algunos libros de patrones diseño de mi biblioteca.
Design Patterns, de Gamma y amigos
Este es EL libro de patrones de diseño que acuñó el término. Es un clásico, tiene dos capítulos introductorios y luego presenta los patrones agrupados por tipo de patrón: de creación, de comportamiento, de estructura, etc. El conjunto de patrones presentados en este libro son comúnmente denominados «los patrones de Gamma». Una curiosidad del libro es que utiliza una notación gráfica para representar clases que es anterior (pero muy parecida) a UML. Por esas cosas de la vida que por momentos resultan inexplicables me compré la edición en castellano de este libro.
UML and Patterns, de Larman
Este es otro libro que para mi también es un clásico. Este libro tiene dos cuestiones que me gustan mucho. Por una la lado es un libro que presenta el uso de patrones de diseño en el contexto de un proceso de desarrollo en este caso el Proceso Unificado. Por otro lado, más allá de los patrones Gamma, este libro presenta un conjunto de patrones que denomina GRASP:
Este libro lo tomamos como referencia hace un par de año con @dfontde cuando armamos la primera versión de la materia Análisis y Diseño Orientado a Objetos en UNTreF.
Implementation Patterns, de Kent Beck
Tengo la sensación que este libro es muy poco conocido pero a mi me gustó mucho. Ma animaría a decir que es un libro de patrones de código, o sea son patrones «de bajo nivel». Si bien el código está en escrito en Java, muchas de las cuestiones son más de programación orientada a objetos y por lo tanto resultan aplicables incluso cuando uno no trabaje con Java. En InfoQ hay una interesante entrevista a Kent Beck sobre este libro.
C++ Coding Standards, de Sutter & Alexandrescu
El subtitulo del libro es «101 Rules, Guidelines and Best Practices» y si bien ni título ni subtítulo hacen referencia a patrones el libro perfectamente puede clasificarse como un libro de patrones. Las recomendaciones/patrones son específicas de C++ y en general no son extrapolables a otros lenguajes. Cuando los patrones son específicos de un lenguaje, como en este caso, se los suele llamar idioms. Este libro me llegó por mera casualidad hace unos 15 años en la época en que cursaba Taller de Programación 1 en Fiuba donde aprendí C++ en profundidad.
Applying Domain-Driven Design and Patterns, de Jimmy Nilsson
Este libro fue publicado en 2006, y si bien el subtítulo «With Examples in C# and .NET«, varias de las cuestiones expuestas son extrapolables a otras tecnologías. De hecho el libro es una bajada a C#/.NET de las ideas de dos libros: Patterns of Enterprise Applicacion Architecture (fowler) y Domain Driven Design (Evans). A pesar de ser un libro de que tiene ~15 años, creo que sigue vigente.
En un próximo post, escribiré sobre algunos otros libros que no son específicamente de patrones sino de temas muy relacionados.
Se fue un año movido a nivel personal y nivel país ni te cuento. Esto tuvo algún impacto en mi actividad profesional. De entrada a nivel profesional y comparado con años anteriores aumenté mi dedicación académica. Esto estuvo motivado por varias cuestiones, pero uno de ellas fue mi decisión de completar mi maestría en Tecnología Informática Aplicada en Educación.
En lo que hace a mi trabajo en la industria, hice muy poco training (~6 %), casi todo mi tiempo estuvo dividido en partes iguales entre tareas de consultoría con equipos de desarrollo y tareas de «devops».
Por otro lado participé de 6 conferencias en diversos países: Argentina, Uruguay, Brazil y España. Publiqué 3 papers y colaboré en un cuarto. Escribí 93 artículos este blog, colaboré con el libro de Fede Zuppa y fui jurado de la tesis de Maribel.
Para el 2020 espero completar mi postgrado en UNLP y dictar la primera edición del Seminario de Postgrado en Software Delivery en UNTreF. En términos de industria, voy a comenzar el año trabajando en un proyecto de desarrollo con .Net Core y Kubernetes de cara a reemplazar una aplicación legacy.
Blog de NicoPaez 