Una de las frases que más stress me causa es no funciona. Como desarrollador, administrador de sistemas o incluso líder técnico he tenido que escuchar esta frase acompañada del elemento que no funciona descrito de forma tan ambigua que la frase en sí no sirve de nada, ¿te ha pasado?
Leer más =>>
De todos es conocido que montar una empresa es una tarea arriesgada, tiene un alto porcentaje de fracasos y en el mundo de las startups es prácticamente lo mismo. Tener una idea y poder llevarla a cabo con o sin inversión, con o sin experiencia previa no es indicativo de éxito o fracaso, pero hay detalles que han marcado el fracaso de las startups, ¿sabes cuáles son estos puntos?
Leer más =>>
Producto Mínimo Viable, PMV o en anglosajón MVP se refiere a realizar una prueba mínima de un producto para minimizar la salida al mercado y validar la viabilidad de las hipótesis planteadas en el modelo de negocio. ¿Es realmente necesario? ¿Cómo y cuándo debemos hacerlo y cuándo no?
Leer más =>>
Eres desarrollador, has entrado en una empresa donde te muestran un trozo de código y te comentan algunas tareas de cómo implementar ideas no muy claras a alto nivel pero muy bien detalladas a bajo nivel. Se espera el trabajo entregado en una fecha predeterminada, no hay margen de cambio, ¿te suena esta historia?
Leer más =>>
Cuando comencé a utilizar git intentamos emplear también gitflow. Lo comentaba como algo factible en un artículo de 2012. En estos momentos y tras 9 años de trabajo con git, tengo que admitir que no emplearía gitflow, ¿quieres saber mis motivos?
Leer más =>>
Recuerdo una reunión reciente con los profesores de mis hijos. Nos recalcaron la inteligencia y buenas ideas pero su falta de iniciativa para compartirlas. Eso me hizo pensar en equipos de desarrollo donde no hay mucha confianza y donde exponer tu idea piensas que es exponerte a ti mismo, ¿tememos al fracaso porque nos importa ser exitosos o transmitir esa idea a los demás? o quizás, ¿tememos al rechazo de esas ideas porque consideramos ese rechazo personal y propio?
Leer más =>>
Hace unos días pregunté a unos amigos ¿cómo estimáis un proyecto de software? queriendo saber no las tarifas, precios o costes específicos a tener en cuenta sino el proceso y los factores a tener en cuenta y comprobar si lo hacía bien o mal, ¿cómo lo estimáis vosotros?
Leer más =>>
El libro Holacracia de Brian Robertson no solo aporta una visión diferente a la forma de organizar la empresa sino también a la forma de realizar las cosas por parte de cada trabajador y la interacción entre los mismos. En este artículo voy a centrarme en las reuniones. En Holacracia estas interacciones son las más beneficadas, ¿sabes por qué?
Leer más =>>
El pasado 22 de julio estuve dando una charla a un grupo de estudiantes de un curso de programación dado por Fernando de Sopinet y surgió la pregunta de ¿cómo mejorar en la programación? ¿qué podemos hacer para mejorar nuestra forma de programar?
Leer más =>>
Hoy he tenido una reunión en la que me han mencionado el problema de la planificación del tiempo. El problema parte de cómo se gestiona en sí el tiempo disponible y cómo lo hacen dos perfiles dentro del mismo entorno, un manager, gerente o directivo por un lado y un programador, creador o fabricante por otro lado. ¿Cuál es la diferencia?
Leer más =>>
A lo largo de los últimos meses he aceptado muchos proyectos. Todos los proyectos estimados según la forma de hacer de cada empresa y según sus necesidades. No importa. Pero, ¿qué sucede cuando una empresa solicita una tecnología nueva, en la que no tiene experiencia y necesitan aprender?
Leer más =>>
Llevamos 12 horas de caída del sistema, al final la copia de la base de datos se realizó, 45 millones de registros activos y una tabla de 20 GiB, vamos a reunión con la dirección y al entrar nos aplauden, abrazan y nos dan un café para comenzar una retrospectiva sobre qué hemos conseguido y qué podemos conseguir la siguiente vez, ¿no hay enfado, reprimendas ni sermones de horas? ¿Por qué?
Leer más =>>
Si programas con frecuencia y lees código de software libre, sabrás o te habrá llamado la atención el uso de ciertas etiquetas dentro de los comentarios del código que comienzan por TODO, o FIXME, o XXX... estas etiquetas se conocen con el nombre de codetags, ¿sabes para qué sirve cada una?
Leer más =>>
La mentalidad del empresario respecto a la visión de la empresa, la monetización de la misma y el conseguir más clientes, más valor y menos competencia es algo que me ha fascinado al verlo en diferentes entornos dentro y fuera de España. Pero desde que Internet llegó se ha acuñado a otro tipo de empresarios el nombre de emprendedores y a sus empresas el nombre de startup, ¿en qué se diferencia?
Leer más =>>
Una de las cosas que más parecidas puede tener un juego de rol con la actividad de un programador son las destrezas. En los videojuegos, las destrezas básicas de un personaje suelen ser: velocidad, fuerza, agilidad e inteligencia. ¿Cuáles serían las destrezas a medir entre los desarrolladores y administradores de sistemas?
Leer más =>>
Hace unos días Marga estaba enfrascada en el desarrollo de una solución para web basada en JSON-RPC y surgió la frase, por parte del cliente (Nothmann Research): piensa en el !11. Cuando me lo comentó no lo entendí de primeras. El factorial de 11, ¿por qué?
Leer más =>>
Hace poco que comencé a trabajar de forma activa con git. Antes había tenido algunas incursiones para saber qué era, pero sin quedarme del todo claro hasta entrar en la práctica con proyectos como ecomponent u otros internos que desarrollo dentro de la empresa en la que trabajo.
Leer más =>>
Una de las bases de las metodologías de desarrollo de software es definir cuándo una tarea ha sido realizada o terminada. Parece algo obvio pero muchas veces se fracasa debido a una mala estimación a causa de estimar tareas basadas en el tiempo medido entre su inicio y cuando se dice que se ha terminado.
Leer más =>>
En mi búsqueda de material (software sobre todo) realizado en Erlang para poder aprender mucho más sobre este lenguaje, sus virtudes, carencias y potencias, he topado con otra muy buena pieza de software: Zotonic, un CMS hecho en Erlang.
Leer más =>>
El término workaholic (o adicto al trabajo, o trabajólico) viene a reseñar una enfermedad que comienzan a sufrir, cada vez más y en mayor medida, los trabajadores de la profesión informática (aunque es extensible a la mayoría de trabajadores de oficina).
En mi caso, puedo decir que desde 2004 he sido bastante workaholic (ya nos lo llamó a mi y a unos compañeros una chica irlandesa sobre el año 2005), y al final, con el hecho de formar familia, he acabado dándome cuenta de que, ciertamente, si lo que estás haciendo no lo consigues acabar en ese mismo día. Mañana habrá más tiempo. ¿Corre prisa?, quizás habría que haber invertido previamente más tiempo, dinero, esfuerzo y dedicación porque si era importante, lo sería entonces también, ¿no? Al final, todo se reduce en más planificación y anticipación a los hechos.
Leer más =>>
Hace unos días, rondando una librería con mi mujer, topé con un libro que me llamó mucho la atención, por su título directo y su color amarillo chillón de la portada. El libro: Pensar es gratis; parece como un desafío en sí, desde el propio título. Leyendo un poco por encima me convencí de que podía ser un buen estímulo para andar siempre en el buen camino.
Tras casi la mitad de lectura, en un solo día, puedo decir que, bueno, hay de todo un poco, Lorente da unas buenas clases de experiencia en algo que ha visto y vivido tanto como es la vida, y deja sus conclusiones, acerca de situaciones vividas que, ante los ojos de algunos pueden ser irrelevantes, y ante otros ojos, pueden ser la respuesta a muchas dudas que se planteaban. En mi caso, después de otras lecturas, encontré algunas ideas muy buenas, y otras, pues lo normal.
Leer más =>>
Tener un plan, ya se llame roadmap, planning u objetivos, es algo muy importante, de cara al negocio propio de una empresa. Una empresa, como bien saben muchas personas que desarrollan planes de negocio, tiene, entre sus objetivos, definir a qué se va a dedicar la empresa, sus clientes potenciales (o reales si ya los tiene), sus proveedores, su marco social, cultural... etc, etc.
Esta información, no solo constituye un modelo formal que define a la empresa, sino la mentalidad propia de la empresa a la hora de tomar decisiones, que la hagan acercarse aún más a sus objetivos. Por ello, un plan es importante, nos hace centrarnos en un objetivo concreto, conocido y alcanzable mediante una serie de pasos. Esos pasos se pueden complicar generando otros menores que necesiten ser abarcados antes de proseguir, pero el objetivo, en ese momento sigue siendo el mismo.
Leer más =>>
Hace tiempo un compañero de trabajo, Juanse, me recomendó un vídeo de una persona que comentaba algunos conceptos algo alocados sobre la vida. En un mensaje de un compañero de la UNED esta semana he recibido un enlace al mismo vídeo por lo que aunque al principio me echó para atrás hay comentarios muy buenos en el vídeo que merece la pena ver.
Leer más =>>
Durante años, en las empresas en las que he estado siempre ha existido el mismo problema: las reuniones se eternizan. Se habla de muchos temas misceláneos y tras horas no se tiene la información clara sobre el tema principal y motivo por el que se organizó la reunión. ¿Cómo podemos mejorar esta situación?
Leer más =>>
Cuando comencé a leer libros sobre Extreme Programming, me llamó la atención una de las propiedades de esta metodología de desarrollo, que era la propiedad del código.
Por mi parte he sido siempre muy comunista con respecto al código, no tengo el menor reparo en mirar, ampliar y corregir código de otras personas y dejo que los demás vean, opinen y corrijan y/o agreguen cosas a mis códigos... es la mentalidad del software libre.
Pero en las empresas ocurre lo contrario. Es muy normal, yo diría que incluso enfermizo, llegar a ver cómo cuando entras en una empresa en la que hay más de tres programadores, cómo cuando algo falla, cuando hay que hacer una nueva mejora, ampliación, adaptación, siempre dice uno en voz alta: ese código es de fulanito; indicando que ni lo va a ver, ni lo piensa modificar.
Leer más =>>
El tema de la calidad ha llenado páginas y páginas de la literatura informática en todos los idiomas. Es tal la necesidad de la búsqueda de la calidad, que hay estudios, técnicas y departamentos dentro de empresas e incluso empresas dedicados a establecer parámetros de calidad a los productos y proyectos que se realizan en las empresas de desarrollo de software.
Dentro del tema de la calidad, visto como un amplio abanico de elementos que la conforman, nos topamos con uno bastante confuso y complejo al principio: la calidad interna.
Leer más =>>
Mi amigo Guillermo me remitió un email hace poco en el que detallaba un concepto que ya conocía hace tiempo, pero que no había visto tan bien explicado hasta el momento (sí, tenía que haber leído antes a Cunningham), el tema era: La deuda técnica en scrum, ¿lo revisamos?
Leer más =>>
En todas las empresas en las que he trabajado, siempre surge un problema, cuando algo nuevo aparece si la persona que ha motivado su introducción no sabe su nombre: se la inventa. No suele ser un problema porque toda la empresa conoce el término, la tecnología o el elemento dentro de sus sistema por ese nombre, pero para nuevas personas en el proyecto, puede resultar frustrante, ¿qué nombre elegir mejor?
Leer más =>>
Hace tiempo, en reuniones mantenidas por todo el departamento técnico, sobre todo la parte de I+D, de la empresa en la que trabajo, mi compañero Juan Sebastián me comentó: podemos hacer la documentación en un blog.
Leer más =>>
La respuesta rápida y obvia podría ser: que lo desarrollado cumpla con los requisitos pactados.
La realidad, muchas veces, nos demuestra que esto no su cumple, ya que, o los requisitos pactados se engordan, o nos fijamos más en que se cumpla el tiempo pactado, lo cual realmente no es un requisito, en muchos casos. Al final, parece que premia más el tiempo invertido y el dinero gastado que lo que se ha adquirido.
Leer más =>>
La técnica de pomodoro al igual que GTD (getting things done) o ZTD (zend to done), son técnicas para realizar las tareas diarias de forma ordenada y evitando distracciones.
Esta técnica debe su nombre a un reloj de cocina con forma de tomate (pomodoro), ya que, la propia técnica se basa en la medición del tiempo con un cronómetro, como los utilizados en la cocina.
Leer más =>>
El término de entrenador (coach) de desarrollo de software es un papel que suele ser muy importante en el quehacer diario de una empresa que tiene desarrollos de software, ya sean internos o para clientes externos.
Leer más =>>
La empresa en la que trabajo hace unas semanas ha comenzado a moverse para obtener una medición del coste de los desarrollos realizados internamente en el departamento. Es positivo y sirve para obtener datos de costes útiles para el desarrollador, programador y obviamente para los directivos que podrán tomar mejores decisiones basados en estos datos.
Leer más =>>
Después de haber aplicado un alto porcentaje de Scrum en los proyectos de software en los que trabajo, siento curiosidad por todas las demás metodologías ágiles que existen, sobre todo, para saber si hay alguna práctica que pueda emplear que me permita optimizar algún aspecto de la actividad diaria a desarrollar.
En este aspecto, he descubierto en Kanban un interesante aliado para aspectos de la metodología que quedaban algo descolgados, y son los procesos rutinarios, o solo tener presente la continuidad de las tareas, ya que las tareas que se realizan en Kanban pueden aparecer en el backlog en cualquier momento e ir haciéndose, según su importancia y/o prioridad.
Leer más =>>
Leyendo un artículo de una página de una empresa suiza (Crisp), he visto a lo que se refiere la planificación de póker. Voy a traducir gran parte del artículo para explicarlo.
Leer más =>>
Hace tiempo ya escribí algo relacionado con esto, en el artículo despide a tu jefe. Hoy, después de haber leído la definición del principio de Peter en la wikipedia, se le puede dar más forma, precisión y color :-P
Leer más =>>
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería del Software Asistida por Ordenador), son herramientas diseñadas para dar soporte al programador a través de una interfaz intuitiva y gráfica que le permita, mediante el posicionamiento de objetos gráficos concretos, relacionados entre sí siguiendo una nomenclatura específica, desarrollar la base de un programa automáticamente.
La programación siempre ha estado respaldada por el diseño de gráficos que, de un solo vistazo, den una imagen gráfica de lo que hace un programa, como se estructuran los datos que maneja, o cómo se organiza el código que se está escribiendo. Esto se hace mediante diagramas como los de flujo de datos, organigramas, entidad/relación, jackson, OMT y UML, entre otros.
Leer más =>>
En este cuento voy a intentar explicar lo que significa programar rápido y lo que significa programar de forma ágil. La primera forma sería la que se considera comenzar lo antes posible, para terminar lo antes posible... pero ciertamente, sin planificación, dar palos de ciego a ciertos niveles de implementación, es más lento que planificar la estrategia de desarrollo a priori. Vamos a verlo con el cuento de...
Leer más =>>
Mi última entrada sobre Scrum, hablaba de la implementación del gráfico Burndown, de esto hace ya casi 3 meses, aunque realmente, comenzamos la andadura en algo antes.
En principio, tengo que tener presente que he estado usando algunas otras metodologías, como la Espiral de Boehm y Metrica-3, con lo que, he podido ver y sufrir en mis propias carnes, lo que significa e implica usar una metodología ágil, las ventajas que aporta y lo fáciles que tienden a ser, realmente.
Leer más =>>
Citando a Kent Beck, de su libro Extreme Programming Explained:
Leer más =>>En La Gente del Bosque y La Gente de la Montaña, el antropólogo Colin Turnbull dibuja el contraste de dos sociedades. En las montañas, los recursos eran escasos y la gente estaba siempre al borde de la hambruna. La cultura a la que evolucionaron era horrible. Las madres abandonaban a sus bebés, los entregaban a hordas de niños salvajes errantes en cuanto tenían opciones mínimas de sobrevivir. Violencia, brutalidad y traición estaban a la orden del día.
Hay varios sitios en Internet, como Software Libre y Cooperación, El Blog de Juantomás García y el blog de La Pastilla Roja, en donde se habla de lo mismo. En el sector del software libre NO hay paro, sino que hay déficit.
Los que nos dedicamos a las tecnologías abiertas, libres e intentamos siempre poner algo estándar y abierto sobre otras soluciones propietarias, nos damos cuenta de que, aunque en temas de software libre se está haciendo mucho, hay mucha gente que estudia certificaciones y productos de compañías propietarias, cuya implementación en cualquier empresa, es más cara que el sueldo que se le pueda pagar, durante uno o dos años, al empleado que lo mantendrá.
Leer más =>>
En los tiempos que vivimos, donde en todos los medios y las comidillas de cada calle y esquina la palabra crisis acecha como la mayor preocupación de esta época, el paro crece desmesuradamente y, curiosamente, la informática y el sector del software libre es el único que registra aumento de contratación.
Hay un déficit real, antes y después de la crisis, de profesionales de la informática. Se piden conocimientos específicos en ciertas áreas. En estos tiempos, la más demandada, el software libre. Las empresas quieren economizar y, encontrar gente que conozca y domine software libre es una ventaja, tanto competitiva por prestar más servicios, como económica, porque el precio suele ser muy bajo o nulo.
Leer más =>>
Desde hace tiempo, la tendencia de uso de los sistemas de control de versiones, ha sido el uso centralizado mediante sistemas tan populares como CVS o Subversion. Ahora, desde que muchos grandes proyectos optaran por los sistemas de control de versiones distribuidos, cada vez hay más gente que se va cambiando a ellos y, sobre todo, proyectos grandes.
¿Será que es mejor el enfoque distribuido al centralizado?
Leer más =>>
En estos días, después de haber pasado más de 24 horas en el último Sprint, sin descansar, donde comenté la experiencia de haber usado Scrum y XP en [otro artículo][1], volvemos a la carga.
Esta vez, con dos semanas de Sprint, bastante más tiempo, podemos realizar algunas técnicas más para poder medir cuánto vamos a tardar realmente en terminar el proyecto que tenemos entre manos.
Leer más =>>
Hace un tiempo escribí sobre Srum y XP, en ese mismo artículo, comentaba que estas técnicas, tanto Scrum como XP, eran dos técnicas que me gustaban mucho y que probaría en un futuro... bueno, pues ese futuro ya es presente :-)
La semana pasada, tuvimos, en la empresa en que trabajo, la presión de entregar un proyecto de forma rápida. Pensé que, en estos casos, lo que más se necesita es, como no, la organización. No se puede estar haciendo una actividad de desarrollo entre varias personas y estar con la cabeza preguntando siempre: ¿qué queda por hacer?; así que, me lancé, cogí dos tacos de post-it, uno de tamaño normal para las partes a desarrollar y otro de tamaño más pequeño, para las tareas que hay dentro de cada una de las partes.
Leer más =>>
Después de darle un repaso al libro Scrum y XP desde las trincheras, he visto que muchas de las técnicas en las que se basa, son como las que usaban nuestros profesores dinámicos en el colegio para motivarnos a participar en clase.
En esencia, es eso, que cada analista/programador se involucre en lo que está haciendo, llegue a un diseño y una finalidad y, sobre todo, que la información sobre lo que se hace, fluya sin que las interrupciones hagan que el trabajo se pare.
Leer más =>>
Cuando una empresa se forma, se intenta organizar el trabajo entre las pocas personas que la inician y si su estructura es buena y sus productos/servicios asequibles para el mercado, la empresa crece y con ella su personal. Es el inicio de los problemas.
Leer más =>>
Le he estado dando vueltas hoy a herramientas de Business Intelligence (Inteligencia de Negocio) tales como Pentaho y ver cómo están estructurados todos los departamentos de negocio que he visto en muchas empresas.
Leer más =>>
Hoy he leído en el blog de Enrique Dans (le he dejado un comentario también ;-) ), que hay un artículo (en inglés) que habla sobre cómo prepararse para la crisis, haciendo lo que realmente pueda ayudar a una empresa recortando por arriba.
Leer más =>>