Blog & Noticias

Durante la última década, ha habido un movimiento entre la comunidad de desarrolladores de software de emplear algún tipo de "desarrollo ágil" en lugar de la metodología de desarrollo de software tradicional. La creencia es que estas metodologías ágiles conducen a software de mayor calidad y ciclos de desarrollo más rápidos. Más recientemente, la aplicación del desarrollo ágil de software ha hecho la transición no sólo desde las pequeñas empresas a las grandes empresas, sino también a las empresas en desarrollo de aplicaciones de consumo no críticas, a las del desarrollo de software para aplicaciones médicas, aviación, militares, y los sistemas financieros, donde la presencia de error humano es alta o existe riesgo económico. Con estas transiciones, los pofesionales de la propiedad intelectual (PI) deben adoptar sus enfoques de abogacía tradicionales para capturar y asegurar los derechos de PI (especialmente la patente). El hecho de no reconocer y adaptarse al entorno de desarrollo de software ágil dará lugar a un fracaso de los profesionales del derecho de propiedad intelectual cuyo trabajo esencial es la función de ayudar a crear o mantener la rentabilidad del cliente y permitir el crecimiento del negocio a largo plazo. Desarrollo de software tradicional Antes de entender lo que los enfoques de desarrollo ágil de software son, primero discutimos el enfoque de desarrollo de software "tradicional". Descrito por primera vez en 1970, el enfoque de desarrollo de software tradicional (a menudo llamado el "enfoque en cascada") consiste en un proceso secuencial de cinco pasos de flujo descendente. Los proyectos de cascada comienzan con una fase de requisitos donde toda la funcionalidad, los requisitos técnicos y de marketing de software están documentados antes de pasar a la fase de diseño. Allí, la arquitectura de software del producto se documenta antes de pasar a la codificación real de todos los requisitos. Una vez que la codificación está completa, el software se prueba (y depurando) antes de que se implemente en un entorno del cliente. Esta secuencia "tirarlo por encima del muro", donde los diseñadores, desarrolladores y probadores no interactúan durante cada paso del proceso, se lleva a cabo en el transcurso de varios meses o incluso años. De este modo, los usuarios finales normalmente sólo llegan a ver los resultados al final del proyecto cascada. El principal inconveniente del enfoque de cascada es que todos los requisitos de un producto de software son definidos al comienzo de un proyecto, cuando los miembros del proyecto rara vez tienen información perfecta. Por lo tanto, las decisiones de diseño más importantes se hacen con la menor cantidad de conocimientos. Además, como los cambios del mercado, inevitablemente causan que las necesidades de los usuarios cambien en el transcurso de un proyecto de años de duración, cambiar al conocer el panorama competitivo es costoso (y casi imposible). Desarrollo ágil de Software En contraste con el enfoque secuencial y de cascada está el enfoque de desarrollo de software ágil. En términos generales, el enfoque ágil emplea pequeños equipos multi-funcionales, de diseñadores, programadores y probadores de trabajo a través de múltiples iteraciones (llamadas "carreras") que duran de dos a cuatro semanas con el fin de producir un producto potencialmente entregable. Después de cada sprint cada entrega de un producto de software a medida que aumenta la funcionalidad hay una oportunidad para los clientes (internos y externos) para revisar la versión más reciente incremental. El desarrollo ágil se basa en la idea de que a veces los clientes necesitan ver el producto con defectos antes de que puedan expresar lo que realmente necesitan. El movimiento de desarrollo ágil de software tiene sus raíces en un grupo de 17 desarrolladores de software influyentes que, en 2001, publicó un Manifiesto para el Desarrollo de Software ágil y luego formaron la Alianza ágil sin fines de lucro. El manifiesto destila la filosofía de desarrollo ágil en 12 principios, el primero de ellos dice lo siguiente: "Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y continua de software valioso." Hoy en día, no existe una definición aceptada por separado de lo que constituye el desarrollo ágil. De hecho, mientras que una encuesta de 2013 entre más de 3.500 profesionales de software llegó a la conclusión de que el 88 por ciento de las organizaciones estaban usando algún tipo de desarrollo ágil, en una encuesta de 2012 de 200 empresas se encuentran más de 100 definiciones de lo que se entiende por el término. Desde entonces , numerosas aproximaciones al desarrollo ágil se han desarrollado (por ejemplo, Scrum, Extreme Programming (XP), Feature-Driven Development (FDD), Kanban, Lean, etc.), todos más o menos son la adhesión a los 12 principios para lograr un mayor software de calidad en un corto periodo de tiempo a través de equipos de auto-organización que colaboran con los clientes con menos documentación y plazos de comercialización. Como se muestra en la figura 2, los proyectos ágiles proceden de forma iterativa donde las nuevas características se integran para ampliar las capacidades de software. Es decir, cada sprint ofrece características probadas, trabajando-deseado por el usuario, y. Cada iteración consiste generalmente en cuatro fases distintas: la planificación, desarrollo, revisión de usuario, y retrospectivas. En la fase de planificación, todas las partes interesadas (es decir, los diseñadores, los probadores, los codificadores y gestión de productos) se reúnen para decidir y documentar que nuevas características se van a agregar al software, o qué cambios en las características existentes necesitan ser hechos. Una vez decidido, el orden de finalización de entidad o el cambio se da prioridad. A continuación, el equipo de desarrollo crea una lista de tareas técnicas necesarias para crear cada una de las una o más características deseadas, y asigna un tiempo y estimación de recursos para cada una de esas tareas. Esta fase llega a su fin cuando todos los operadores aceptan las características a ser implementadas dentro de las limitaciones de tiempo y de recursos dados. En la fase de desarrollo, el equipo de desarrollo trabaja para codificar, probar y depurar las una o más características acordadas entre la gestión de productos y otras partes interesadas durante la fase de planificación. A continuación, en la fase de revisión de usuario, el equipo de desarrollo demuestra el software y sus características o cambios en la gestión de productos (y tal vez los clientes potenciales / asesores de productos) recientemente implementados. La gestión de producto (product management) luego decide si el software está correcto y completo. Por lo tanto, las características completas se eliminan de la lista de características que necesitan otra fase de planificación, y las características incompletas son más candidatas para futuras versiones. Por último, en la fase retrospectiva, el equipo de desarrollo se reúne para reflexionar sobre la última iteración y discutir esas tareas, técnicas, y las interacciones del equipo en el que trabajan y los que necesitan mejorar. En suma, las organizaciones de la aplicación de enfoques de desarrollo ágil creen que el proceso de desarrollo de software de mejora a través de "requisitos más estables, la detección temprana de fallos, menos tiempos de espera para la prueba, el aumento de la comunicación, y el aumento de la capacidad de adaptación." Con respecto a la medición de la eficacia de diversos enfoques de desarrollo ágil, un proponente afirma que es mejor: Cuando se trata de mediciones, agilistas tienen una filosofía diferente a los tradicionalistas. Creemos que las métricas tales como la variación de los gastos, variación de programación, los requisitos de la varianza, y la varianza de trabajo son virtualmente un sin sentido. En su lugar tiene sentido medir el éxito de los esfuerzos de desarrollo de software mediante la entrega de software que funciona. Desafíos para la captura y protección de la PI dentro del desarrollo ágil No se ha escrito mucho y debatido sobre la patentabilidad del software (y, más en general, las invenciones implementadas en ordenador). A pesar de esto, el software provee un ingreso anual de $ 600 millones de dólares y emplea dos millones de personas de la industria de TI, tan sólo en EE.UU.. Allí el software es no solamente elegible para la protección de la patente, sino que representa más del 50 por ciento de las patentes emitidas en EE.UU.. Dicho esto, pasamos ahora a los desafíos de la captura y la protección de la propiedad intelectual dentro de un entorno de desarrollo de software ágil. Como se discutió anteriormente, el desarrollo ágil de software hace hincapié en plazos cortos y ( "sprints") ciclos de trabajo de ritmo rápido. Mientras que el desarrollo ágil produce innovaciones que merecen ser protegidas, los límites impuestos por una metodología ágil causan estragos en el flujo de trabajo tradicional de un practicante de PI. Por ejemplo, las metodologías de captura de PI tradicionales se basan en un flujo más relajado de la divulgación de la invención, la evaluación, la estrategia, y la adquisición de los derechos de propiedad intelectual, que se desarrolla durante un período de varios meses, durante (o, a veces después) de un ciclo de desarrollo del producto tradicional. En un entorno ágil, sin embargo, es necesario un proceso de presentación y evaluación de la idea de ritmo más rápido, condensado que se produce en el transcurso de unos pocos días o semanas. Del mismo modo, el rápido ritmo de carreras cortas deja a los desarrolladores con muy poco tiempo para planear estrategias, analizar, documentar y capturar el potencial de la propiedad intelectual. Por lo tanto, mientras que los requisitos para la protección de patentes de software están aumentando, el tiempo disponible para evaluar y proporcionar detalles sobre dicha protección de software disminuye dentro de un entorno ágil. En Chile el software no es patentable por sí mismo, sino sujeto a derechos de autor pero puede ser protegido por patentes cuando se incorpora a una máquina o proceso transformador. Para complicar aún más los esfuerzos de captura de PI está la realidad de que cualquier Sprint dado sólo puede dar lugar a la terminación de una parte de un producto, en lugar de un producto totalmente funcional. Con sólo pequeñas porciones de un producto finalizado completadas en cada sprint, puede ser difícil determinar cuándo se ha producido suficiente innovación para justificar la búsqueda de protección. Además, el uso de muchas carreras discretas y sus respectivos entregables puede provocar que los clientes pierdan la perspectiva y dejen de apreciar que una serie de innovaciones más pequeñas puede conducir a una mayor producción creativa digna de protección PI. Es decir, los desarrolladores ágiles a menudo "no pueden ver el bosque por los árboles", ya que se centran en las prestaciones de velocidad, más pequeñas y manejables. Por último, el acortado de los plazos ágiles y un enfoque en las prestaciones de velocidad puede contribuir a una disminución en la comunicación entre los miembros del equipo y el personal jurídico, que también afecta negativamente a la identificación de, y la acción sobre la propiedad intelectual protegible. En resumen, un enfoque en pequeñas entregas más inmediatas en un plazo de tiempo corto puede causar que los participantes pierdan de vista sus cualidades innovadoras entregables "cuando se enfrentan con procedimientos ágiles específicos y a una carrera para entregar dentro de los plazos de una carrera de velocidad. El énfasis en el suministro continuo e iterativo puede tener el efecto secundario desafortunado de devaluar contribuciones innovadoras a los ojos de muchos en el equipo de desarrollo. Es decir, pasar de un sprint al siguiente con frecuencia puede trabajar en contra de la reflexión y reconsideración de carreras anteriores, ya que el proceso ágil obliga a los participantes a centrarse exclusivamente en lo que se necesita para el sprint actual. Empujar los requisitos de un sprint al siguiente puede crear la falsa sensación de "bueno, estamos simplemente poniéndonos al día en donde queríamos estar en el último sprint," en lugar de apreciar la innovación que ya se ha hecho. Mientras que la fase retrospectiva pide a los miembros del equipo considerar lo que ocurrió en ese último sprint, que a menudo no incluyen consideraciones PI para el proyecto en su conjunto.