DSN_XP y la bitácora del movimiento AgileEc

Agilismo en Ecuador

Esta es la historia del movimiento ágil en Ecuador bajo la perspectiva de DSN_XP, como tal, somos responsables por su contenido y en ningún momento se podrá decir que representamos o somos la voz oficial del movimiento @AgileEcuador 

Línea de tiempo

Los orígenes del movimiento Agile en Ecuador [2009-2010] 

La idea de formar una comunidad ágil en Ecuador surgió en entre varios simpatizantes de SCRUM que el destino reunió en un proyecto de desarrollo en el valle de tecnología de la Universidad Técnica Particular de Loja (UTPL)

Equipo UTPL/SoftwareFactory/Samasat/Bayteq/EnovaTraining/AQASolutions 
Para esta época DSN_XP necesariamente tenía que robustecerse para lograr enfrentar el reto de recuperar un proyecto mediante la adopción de SCRUM.

DSN_XP reconoce de forma pública que cuando llegamos al proyecto, existían ya conceptos ágiles que habían sido puestos en práctica por la empresa BAYTEQ gracias al aporte de Byron Rosales, adicionalmente, los conceptos de TDDBDD son introducidos en nuestra investigación gracias al apoyo de Jorge Gamba quien coordinaba con este equipo aspectos de desarrollo de software.

DSN_XP también deja constancia que existían conceptos ágiles en el estilo de programación mediante TDD por parte de los miembros del Valle de Tecnología de la UTPL

Certificaciones como Scrum Master [2009]

Gracias al apoyo de la UTPLSAMASAT BAYTEQ, se pudo lograr un primer objetivo, que varios miembros del equipo se certifiquen como Scrum Master en un evento de la comunidad ágil de Perú y la empresa Open Edge Technologies y aprendan de esta comunidad como se utiliza Scrum en proyectos tecnológicos de desarrollo de software.
Curso Certificado de Scrum Master en Lima - Perú

Scrum aplicado al proyecto UTPL.SYLLABUS+ [2010]

Con la información, técnicas y artefactos que nos fueron impartidos en el curso, logramos un segundo objetivo, que la UTPL confíe en SAMASAT y adopte SCRUM como método para la gestión del proyecto SYLLABUS+ .
DSN_XP pudo ser aplicada al proyecto gracias al apoyo de SAMASAT y su gestión ágil para la recuperación y administración de proyectos tecnológicos.
Nota: Para DSN_XP, este es el primer registro completo que tenemos sobre la adopción de SCRUM en Ecuador. Este registro estará disponible para la comunidad académica del Ecuador en este blog bajo los lineamientos de la licencia Creative Commons.
Esquema de adopción de Scrum al proyecto SYLLABUS+ by DSN_XP
Para nosotros, históricamente, este es el primer proyecto ágil en Ecuador y lo consideramos así porque es el primer proyecto tecnológico del cual existen registros de la aplicación de SCRUM para el desarrollo de software bajo los lineamientos de DSN_XP.

Nota: Se refiere a la fase del proyecto SYLLABUS+ en la cual tomamos el control del proyecto y aplicamos los principios ágiles bajo los lineamientos de DSN_XP y cuyo resumen se expresa en este video de autoría de José Sandoval. Para mayor información del proyecto existirá una entrada que definirá los detalles de la adopción de Scrum. Respecto al diseño y planificación del producto esto es de propiedad intelectual de terceros por lo que no mencionaremos nada del diseño.



Hecho en Ecuador, la primera generación [2010-2011]

Reuniones técnicas de desprogramación extrema e integración continua
Un grupo de amigos decidimos fundar el movimiento ágil en Ecuador, esta página lleva una bitácora de las reuniones del movimiento en las cuales hemos colaborado como DSN_XP y también de aquellos eventos en los cuales, no hemos participado pero que se publican para un registro histórico del desarrollo del agilismo en Ecuador.

Para cuando inicialmente se edita este post, no existen registros google de que otras personas hayan propuesto el nombre de Comunidad Agile en Ecuador, adicionalmente, quienes somos mencionados en este relato histórico somos agilistas que de una u otra forma tenemos el reconocimiento de la comunidad internacional y que por lo tanto podemos ser considerados como referentes del Agilismo en Ecuador, al menos para DSN_XP.

Traslado del control del proyecto a la PMO 

Una de las ventajas que obtuvimos al aplicar los principios ágiles, fue el lograr estabilizar el proyecto, una vez estable, la UTPL decidió trasladar su gestión a la oficina de proyectos (PMO).
Para esta fecha, como Scrum Master y por ende responsable de la implementación de SCRUM en el proyecto, debía resolver los conflictos presentados tanto por las herramientas clásicas propuestas por la PMO como por las herramientas disruptivas propuestas por SCRUM para la recuperación del proyecto.
Para la transferencia del proyecto desde nuestra administración como SAMASAT hacia la PMO de la UTPL, fue necesario la creación de la denominada AgilePMO, siendo esta iniciativa a la vez, el primer registro que tenemos de la escalabilidad de Scrum y los principios Agile en una organización ecuatoriana.

La transición del proyecto en consecuencia implicaba un riesgo, para minimizarlo, se consideraron varias liberaciones y una estrategia adecuada para la obtención del producto, sin embargo, cambiaron las estructuras de control sobre el proyecto por lo que no nos fue posible el seguir los lineamientos de DSN_XP y esto motivó a ceder nuestro rol de Scrum Master de Scrum Masters.
Para DSN_XP no existen más registros sobre el estado del proyecto y su culminación, por lo que podemos definir que, bajo el concepto de iteraciones, la iteración en la cual participamos generó un producto de confianza para el cliente y se pudo retornar la inversión durante la jornada contratada, adicionalmente se pudo reconocer la potencia de SCRUM adaptado por DSN_XP.
Sabemos también que los nuevos administradores del proyecto utilizan una variante de SCRUM denominada XScrum o SCRUM para ejecutivos y se forma la AgilePMO de la UTPL.
Nota: Se respetan los criterios de la UTPL pero lo expresado en esta sección se establece en base a nuestros registros, más detalles de todo el proyecto, aquí.


Primeros esfuerzos de la comunidad Agile Ecuador [2011]

Una vez que todos estuvimos fuera del proyecto, cada cual por su parte seguía con la convicción en los principios ágiles y con las ganas de hacer algo más grande, que permita de una vez por todas, hacer conocer al mundo entero que en Ecuador existen personas que se identifican con el movimiento ágil y que están dispuestas a poner en práctica este conocimiento en la gestión de proyectos tecnológicos, sin embargo, hacía falta un elemento disparador que inicie esta revolución...
Como DSN_XP, hemos promulgado el agilismo en Ecuador en cada proyecto en el cual participamos pues estamos convencidos del potencial que se genera cuando se aplican los conceptos ágiles de forma holística.

Nuestra forma de aplicar de forma experimental y "customizada" las herramientas, artefactos y principios ágiles, no fue aceptada por los otros miembros de la comunidad, por lo que no reconocen a DSN_XP como marco de trabajo ágil, pero aclaran que si les interesaba la participación de su mentalizador en la comunidad (como cualquier otro miembro que sume al movimiento).

Nota: DSN_XP se considera a si misma como proveniente del espíritu ágil, sin embargo, en lugar de adoptar una metodología en especial, nuestro trabajo consiste en definir un marco personalizado de trabajo ágil para la gestión de proyectos.

El apoyo de la comunidad Agile de Chile [2011]

¿Cómo formar una comunidad? ¿Qué pasos son necesarios para ello? ¿Estamos en condiciones para hacerlo? ¿Es posible armar un movimiento a nombre del Ecuador?...

Estas y otras inquietudes existían en el ambiente y no permitían que se de el paso inicial para crear la comunidad, gracias al impulso, apoyo y la transferencia de experiencias de otras comunidades y en especial de la comunidad ágil de Chile, tres personas decidieron dar este paso y arrancar la comunidad ágil de Ecuador con miras a sumar más miembros al movimiento y lograr hacer reconocer los principios ágiles y su validez en la gestión de proyectos tecnológicos.
Nota: Para DSN_XP, los principios ágiles son objeto de estudio y su aplicación se destina a mejorar continuamente nuestras herramientas. Como metodología, creemos que somos muy pocos los que llevamos registros científicos de su aplicación en Ecuador.

Nota: DSN_XP también tiene registros aislados de varios intentos externos de generar la comunidad ágil en Ecuador por otros miembros y empresas ecuatorianas como LogicStudio.

Nota: Scrum impacta a toda Latinoamérica y empresas que son internacionales y tienen una representación en Ecuador comienzan su propio viaje de transformación tal como lo haríamos en la UTPL pero a un mayor compromiso por parte de quienes integran la organización y nos referimos a Seiba

Posesión de dominio en redes sociales e Internet [julio/2011]

Teníamos que definir los canales autorizados por el movimiento para la transferencia de ideas sobre el manifiesto ágil y las experiencias adquiridas en Ecuador y se define esta fecha como la fecha de lanzamiento oficial de la comunidad ágil en Ecuador.
Se creó una cuenta en twitter @AgileEcuador y desde la misma se envió al mundo entero la noticia de que se había creado la comunidad ágil en Ecuador.
Se adoptó como logotipo a la ilustración que se muestra en este blog.
Logotipo adoptado por DSN_XP para el movimiento ágil Ecuador
Se comenzó a publicar entonces contenido desde esta cuenta y se oficializa el nacimiento del movimiento ágil en Ecuador.

Finalmente, la comunidad ágil en Ecuador para agosto del 2011 se conformaría por tres miembros que son:

Byron Rosales

Se encargaría de coordinar las actividades de relaciones interinstitucionales y del dominio del sitio Web además de la publicación de contenido ágil y el uso de herramientas para la gestión de proyectos tecnológicos.

José Lubín Sandoval

Se encargaría de la comunidad como community manager y de los aspectos de diseño gráfico del logotipo final además de la publicación y difusión de contenido ágil.

Francisco Toscano Morales

Se encargaría de la emisión de contenido ágil y de aspectos organizativos de la comunidad.

Nota: DSN_XP es referida en sus propios canales de distribución de información.

Edwin Vargas Lara (más tarde se nos uniría)

Sin responsabilidades definidas todavía pero contábamos con su apoyo.

Experiencias ágiles en Ecuador:

José Sandoval promulga el agilismo en un proyecto tecnológico con una institución pública financiera (no poseemos registros sobre los resultados de su proyecto compartidos por él).

Byron Rosales promulga estos mismos objetivos en otra institución pública (tampoco tenemos registros sobre los resultados de su proyecto compartidos por él).

Francisco Toscano y Edwin Vargas promulgan los mismos principios en una institución pública (Distrito Metropolitano de Quito) con excelentes resultados para el proyecto.

Nota: DSN_XP tiene registros multimedia y por escrito de su intervención en este proyecto, pero derechos de propiedad intelectual establecidos por acuerdos comerciales no nos permiten compartir esta información con terceros.

DSN_XP y su separación temporal [septiembre/2011]

Descubrimos como DSN_XP que no fuimos lo suficientemente comprometidos con la causa del movimiento ágil en Ecuador :o(, si bien es cierto, cada miembro empezó a promulgar los principios ágiles por su cuenta, no fue posible para nosotros madurar la idea de una comunidad virtual como movimiento ágil en Ecuador.

Para efectos de dejar una constancia de la historia del movimiento bajo la perspectiva de DSN_XP, tomamos la decisión de separarnos temporalmente de la comunidad porque nuestras ideas ágiles no eran compatibles con las ideas ágiles de los otros miembros :o), esto implicaba en primer lugar el definir hacia dónde llevaríamos el movimiento como tal, la difusión de las ideas ágiles y las diversas escuelas ágiles existentes en el mercado como SCRUM entre otras (recuérdese que 3 de los 4 miembros originales éramos Scrum Master Certificados y casi los primeros certificados en SCRUM del Ecuador).

Nota: DSN_XP comienza a dejar SCRUM como método actual de experimentación y comienza a analizar Kanban más profundamente..

DSN_XP y la certificación en SCRUM [octubre/2011]

Una de las discusiones más fuertes que existió al interior de la comunidad fue acerca de la concepción de las certificaciones. Para DSN_XP las certificaciones obligan al mercado a reclutar candidatos que cumplan con tales requerimientos y bajo nuestros registros, este tipo de certificaciones tienen un alto impacto en el proceso de contratación del mercado nacional e internacional.
Por otro lado, en América Latina, las certificaciones de la Alianza Scrum dominan el mercado y esto implica la introducción de socios estratégicos; una comunidad también debe tratar estos temas :o)

La posibilidad de que el movimiento ágil de Ecuador se convierta en la voz autorizada para definir quien es ágil o no, o tratar temas como las certificaciones como negocio y el control del movimiento para fines comerciales, son temas que deben ser enfrentados adecuadamente y con fundamentos.

Nota: DSN_XP quiere dejar en claro y de forma pública su agradecimiento a las empresas Open Edge Technologies, Massimus y Kleer por apoyar a la comunidad ágil de Ecuador con sus eventos abiertos.

Por un lado, la idea comercial es importante (ya que el movimiento debe auto sustentarse para crecer como organización por los costos de mantenimiento) y por otro lado, la simple idea de que un organismo se convierta en la voz autorizada para decidir quién es ágil y quién no, rompe el concepto mismo de comunidad ágil virtual :o)

Octubre es entonces cuando tomamos la decisión de separarnos del movimiento por no concordar entre nosotros sobre algunos aspectos inherentes a la palabra #agile :o(

Nota: Existen registros de que este mismo fenómeno les ocurrió a los mentalizadores del movimiento ágil..

Experiencias:

Francisco Toscano comienza a promulgar KANBAN en instituciones públicas (hemos trabajado con 2 empresas dependientes de empresas públicas en Quito) bajo los lineamientos propuestos por DSN_XP

José Sandoval y su patrocinador logran un objetivo importante para Ecuador, al traer la primera certificación en SCRUM a Quito, esta idea no fue comentada ni divulgada correctamente al interior de la comunidad (por recomendaciones del patrocinador) por lo que los demás miembros nos enteramos una vez que dicho evento fue publicado en las redes sociales, esto, más la falta de participación activa de los miembros para publicar contenido en la comunidad provocó nuestro alejamiento.
DSN_XP sin embargo felicita esta iniciativa porque al menos se logra una actividad importante para la comunidad, pues como comunidad ágil en Ecuador, si se reconoce a SCRUM como una escuela de pensamiento ágil.


DSN_XP deja constancia de que no apoyamos la certificación de cualquier tipo por el impacto en el proceso de contratación de profesionales para la gestión de proyectos. Consultamos este comportamiento y descubrimos que otras comunidades habían pasado por lo mismo en su debido tiempo y de cuyo resultado se determinaba las tendencias de cada país en el proceso de adopción del agilismo.

Los registros que obtuvimos del primer evento de certificación SCRUM en Quito:

Primer curso certificado de Scrum en Ecuador por José Sandoval

DSN_XP y SCRUM sin certificaciones [noviembre/2011]

Mientras uno de los miembros fortalece la escuela de SCRUM mediante las certificaciones pagadas, nosotros como DSN_XP, apoyamos indirectamente al movimiento ágil de Ecuador con una serie de conferencias pequeñas en la ciudad de Quito gracias al apoyo de la Fundación Runakawsai donde se imparte SCRUM bajo los lineamientos de DSN_XP como una de las materias curriculares que se enseña a la comunidad de Quito.

Pensamiento holístico y ágil bajo los lineamientos DSN_XP
Talleres de difusión FaceToFaces
Esta narración puede comprenderse como una rivalidad existente entre los miembros originales de la comunidad, pero para nosotros, como DSN_XP, es una cuestión mucho más importante que el ego de cualquiera de los miembros fundadores. 

Debido a que no existe una posición oficial por parte de la comunidad ágil hasta este entonces, decidimos realizar una campaña informativa en Twitter a través de nuestra cuenta (@DSN_XP) sobre nuestra posición respecto a SCRUM y nuestro rechazo frontal a las certificaciones pagadas por un entrenamiento mínimo de 2 días (tal cual lo promulga la Alianza Scrum) y si un apoyo frontal también a los eventos gratuitos o pagados de difusión y entrenamiento sin la necesidad de un certificado autorizado como válido por la Alianza Scrum.
DSN_XP aplica los principios ágiles (FaceToFace) y decide conversar con cada uno de los otros miembros de la comunidad para aclarar que más allá de los procesos ágiles que se apliquen, nos interesa el equipo como tal :o) sin embargo seguimos alejados del movimiento ágil Ecuador.

Noviembre es un mes en el cual en el mundo entero se discute lo que estábamos viviendo como comunidad ¿Cuál es tu posición respecto a las certificaciones Scrum? una clara señal de que lo que experimentamos como comunidad era un proceso normal de las comunidades ágiles.

Nota: Las comunidades ágiles de Brasil, Perú, Colombia, Venezuela, Bolivia y Argentina ya resolvieron este dilema y escogieron (bajo nuestra interpretación de los hechos) a la escuela SCRUM, mientras que la comunidad ágil de Chile no adoptó esta posición y es lo que queremos como DSN_XP para Ecuador.

Primer Agile Tour en Quito [noviembre/2011]

En noviembre José Sandoval realiza un segundo evento importante para la comunidad como es el organizar el Agile Tour en la ciudad de Quito evento al cual no pudimos asistir y que para variar tampoco tenemos un registro sobre el resultado de este evento que haya sido expuesto por él :o(
Agile Tour 2011 Quito by Samasat (José Sandoval)

La cosecha SCRUM y el renacimiento de la comunidad 

DSN_XP y un café con JOE :o) [diciembre/2011]

En diciembre y mediante twitter notamos la presencia de un nuevo personaje a quien empezamos a seguir porque si llevaba registros de su adopción de SCRUM y claramente demostraba que era una de las personas que siguió el curso certificado en Ecuador.


Para DSN_XPJoe (José Franco) representa un gran potencial para el movimiento pues su círculo de influencias permitiría expandir algunas de las bases del agilismo a lugares diferentes del Ecuador :o)

José trabaja directamente con la escuela de pensamiento del PMI y actualmente está apoyando fuertemente a las certificaciones ágiles bajo los lineamientos del PMI (Comunidad de Práctica Ágil Agile CoP)
José al pasar del tiempo se convierte en uno de los mayores exponentes del agilismo en Ecuador tanto por sus aportes a la comunidad y sus representaciones en los diversos eventos que impactan en la madurez de una comunidad fuerte en la ciudad de Guayaquil.

DSN_XP y la arquitectura empresarial ágil+Kanban [enero/2012]

Una vez que profundizamos el marco de trabajo propuesto por KANBAN, estábamos experimentando también con formas de introducir el agilismo en las organizaciones mediante los artefactos planteados por TOGAF como arquitectura empresarial.

Nota: Este esfuerzo sería reconocido más tarde por la comunidad como "escalar agile en las organizaciones"

Como DSN_XP comenzamos a buscar aplicaciones prácticas del agilismo en empresas privadas del Ecuador mediante una serie de conferencias gratuitas sobre TOGAF y KANBAN.

Desconferencias DSN_XP sobre arquitectura empresarial ágil en Ecuador

Kleer una empresa que mira a Ecuador [enero/2012]

En enero tenemos la grata visita de varios personajes del mundo del agilismo en Ecuador, entre estos grandes personajes está la empresa argentina Kleer quienes traen para el Ecuador las capacitaciones y certificaciones ágiles en SCRUM.

Segunda temporada de la Comunidad Agile Ecuador [2012]

A partir del 2012 surgen en Ecuador una serie de eventos relacionados con el agilismo, como DSN_XP no tenemos registros a nivel internacional sobre las discusiones y temas que impactan a la comunidad Latinoamericana.

Resultado de estos eventos dispersos, surgen varias tendencias profundamente marcadas en el Ecuador y en la región y se trata de las capacitaciones y el proceso de certificación SCRUM. 

Este aspecto nuevamente es discutido a nivel de comunidades sobre ¿cuál puede ser el rol de la comunidad y sus miembros respecto a la culturización de los temas ágiles y por ende su certificación?

Durante este período, un grupo de programadores extranjeros (españoles en la mayoría) realizan una serie de talleres de capacitación de técnicas ágiles de programación y son quienes dan la pauta para la regeneración de la comunidad Agile en Ecuador que para ese entonces se mantenía inactiva.

Jaume Cardona un esfuerzo de autogestión [febrero/2012]

Jaume es un actor fundamental para la segunda temporada de la comunidad Agile en Ecuador, como DSN_XP tenemos un agradecimiento profundo por que nos ayudó con su esfuerzo a sostener todo lo que veníamos logrando como comunidad en el proceso de difusión lenta de los marcos de trabajo que implican AGILE especialmente en el desarrollo de software.
Nota: Para estas mismas fechas ya se estaban promoviendo eventos ágiles por parte de Jaume Cardona y su patrocinador BECODE (nos referimos al primer coding dojo en Ecuador)

Nota: Este es para nosotros un segundo registro sobre escalamiento de conceptos ágiles en universidades y el agilismo en Ecuador, el primer registro para DSN_XP fue la UTPL.

El segundo coding dojo by Kleer [abril/2012]

Asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del Yoseki Coding Dojo y su impacto en la comunidad ágil de Ecuador.



Nota: Para DSN_XP además del equipo del valle de tecnología de la UTPL, Samasat, Byteq no teníamos registros de que existen empresas que aplican metodologías ágiles para el desarrollo de software.  Sumamos a nuestros registros entonces al Grupo Provedatos.

El primer Agile Open Space en Quito por Kleer [abril/2012]

Asistimos a este evento y de a poco iremos detallando en esta sección los conceptos básicos de la tecnología de espacios abiertos y su impacto en la comunidad ágil de Ecuador.

Un amante del agilismo Johnny Ordoñez Ortiz [abril/2012]


Una de las cosas más claras que como DSN_XP encontramos en Johnny fue su capacidad de modelado y el uso de herramientas administrativas avanzadas para la generación de estos modelos que demostraron la influencia de una escuela de diseño y pensamiento ágil desarrollado a su propia naturaleza.

Johnny y su equipo de trabajo nos pone de frente ante la expectativa de que en Ecuador existen otros grupos de personas que utilizan fuertemente y profesionalmente las metodologías ágiles, sin embargo, tampoco tenemos registros de terceros sobre el impacto que tienen en sus organizaciones el utilizar los marcos de trabajo asociados a las metodologías ágiles.

Nota: Con el pasar del tiempo, Johnny se volvería un claro referente de todo el proceso de escalamiento de la agilidad en organizaciones de alto impacto en el sistema financiero del Ecuador.

Alistair Cockburn y su acercamiento al agilismo en Ecuador [mayo/2012]

Mediante facebook, Alistair nos pregunta sobre las tendencias del agilismo en Ecuador y respondemos sobre el impacto de Scrum y nuestros experimentos con Kanban.
I should ask - how is agile doing in Ecuador?

Las clínicas ágiles y LeanSight [julio/2012]

Asistimos a este evento de forma virtual y comprendimos este concepto por lo que abriremos un post especial para detallar las clínicas ágiles, LeanSight y DSN_XP y su impacto en la comunidad ágil de Ecuador.

Clínica Ágil de Liderazgo, contenidos:

  • Principios de Lean Thinking y Cultura Ágil
  • Kanban Personal
  • Kanban de Equipos
  • Scrum
  • Mejora Continua: Retrospectivas/Kaizen
  • Gamestorming
  • Estimación Ágil de Requerimientos

El PMI Ecuador y el agilismo [septiembre/2012]

No asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos y su impacto en la comunidad ágil de Ecuador.

Coding Dojo en Guayaquil [agosto/2012]

No asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos y su impacto en la comunidad ágil de Ecuador.

Este evento fue auspiciado por el PMI Capítulo Ecuador

DSN_XP y oficinas en transición [diciembre/2012]

DSN_XP fue introducida en el sector público para la mejora continua de los servicios por Francisco Toscano Morales, iniciando así un registro del impacto del agilismo en instituciones públicas del Ecuador.

Nota: DSN_XP tiene registros de referencia de que se aplica SCRUM en el SRI pero no tenemos registros de ello.

Charlas ágiles en la ESPOCH [diciembre/2012]

No asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del evento y su impacto en la comunidad ágil de Ecuador.


LevelUp y el Code Retreat [diciembre/2012]

Asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del evento y su impacto en la comunidad ágil de Ecuador.


Levelap y sus continuos coding dojo [febrero/2013]


Levelap es un proyecto del equipo Provedatos en el cual Jaume Cardona junto a su equipo promocionan continuamente los coding dojo para la mejora de la elegancia en la codificación.


Café ágil de ThoughtWorks [febrero/2013]

Asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del evento y su impacto en la comunidad ágil de Ecuador.

.

El proceso de contratación ThoughtWorks y DSN_XP [febrero/2013]

Por tratarse de un tema más relacionado con Francisco Toscano Morales, trataremos este tema en un post aparte. Se lo menciona aquí porque DSN_XP analizó justamente el proceso de contratación propuesto por ThoughtWorks en el cual participamos y no fuimos seleccionados.

Dejamos pues nuestra versión más honesta de los hechos siempre aportando al agilismo en Ecuador.

El encanto femenino con Gemma Hornos [febrero/2013]

Uno de los efectos de poder asistir al evento convocado por Thoughtworks fue el poder conocer a la nueva temporada de agilistas en Ecuador.

Dentro de este grupo selecto de personas destaca por su frescura de mirar Gemma con toda la experiencia de su trabajo en Telefónica y sus talleres para escalar el agilismo en las organizaciones.

Andrés Robalino y su presencia en el desarrollo de software [febrero/2013]

Mientras tanto en Guayaquil, de a poco notamos la presencia de una persona que comenzaba a poner retos a los programadores y mencionaba ya estructuras ágiles para el desarrollo de software.


Andrés tiene su propia experiencia basada en su conocimiento y contactos internacionales que requiere de un post aparte para analizar su aporte al agilismo en el Ecuador.

 

La presencia de Andrés más tarde tendría mucho impacto a la hora de comenzar a desplegar el nombre de la comunidad agile ecuador a nivel internacional y traer a nuestro país eventos y personajes del mundo del agilismo que aporten culturalmente a la comunidad agile del Ecuador.

Gira AGILE Ecuador by Johnny Ordóñez [marzo/2013]

Una idea: qué les parece armar una gira ágil por todo Ecuador? Agilistas montados en una Van recorriendo universidades con charlas y dojos; difundiendo ágil, conociendo gente, viviendo grandes experiencias, documentar con fotografías.
Yo sé, suena un poco loco....pero acaso no hay algo de locura en ser agilista?? Te animas?

El reto SpaceApps y los agilistas en Ecuador [abril/2013]

No participamos de este evento y no tenemos registros de su impacto en la comunidad agile Ecuador.

La aparición de Agilec.org [abril/2013]

No participamos de este evento y no tenemos registros de su impacto en la comunidad agile Ecuador.

Nota: Este es el segundo curso certificado de un proceso de certificación en SCRUM que como DSN_XP tenemos en nuestros registros.


También notamos por primera vez que se estudien aspectos relacionados con el TeamView y su impacto en las organizaciones.

El primer equipo ThoughtWorks [agosto/2013]

Thoughtworks Ecuador inicia con lo mejor de los agilistas radicados en Ecuador.

Esta selección impacta notablemente en el movimiento ágil de Ecuador ya que se introduce en la cancha un nuevo enfoque agilista que le es propio para ThoughtWorks ante SCRUM como marco generalmente aceptado por la tercera temporada de la agilidad en Ecuador.

El equipo Agile Ecuador by ThoughtWorks [octubre/2013]



Para esta época, quienes formaron el primer equipo ThoughtWorks de Ecuador fueron quienes pusieron la pauta sobre lo que sería la comunidad ágil Ecuador en en su tercera versión debido al respaldo internacional que posee ThoughtWorks.  Esto se puede comprender cuando se menciona su impacto en el tablero de la industria nacional del software más adelante.

De las reuniones planteadas a la comunidad, por los medios disponibles para la comunidad, permitieron agrupar a un gran número de simpatizantes sobre el movimiento Agile que se dió en Ecuador por la presencia de ThoughtWorks en Ecuador.

El equipo Agile de Ecuador integraba a personal de Guayaquil, Ibarra, Cuenca, Quito e incluso logró sumar en su esfuerzo a las organizaciones y empresas que desarrollan software en Ecuador y que adoptan Scrum principalmente.

El TourCode en la UDLA [noviembre/2013]

No participamos de este evento y no tenemos registros de su impacto en la comunidad agile Ecuador.

Café ágil de ThoughtWorks segunda edición [febrero/2014]


No asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del evento y su impacto en la comunidad ágil de Ecuador.

El manifiesto de la comunidad Agile Ecuador [febrero/2014]

Luego de un par de reuniones virtuales y de la lectura y aprobación de quienes participamos en su aprobación como comunidad Agile Ecuador se logró cristalizar el manifiesto para los practicantes y promotores del agilismo en Ecuador.

El TourCode en la UTE [marzo/2014]

No participamos de este evento y no tenemos registros de su impacto en la comunidad agile Ecuador.


El despliegue internacional de ThoughtWorkers [mayo/2014]

Para esta época, la mayoría de agilistas con los cuales teníamos contacto dejaron ThoughtWorks y no tenemos registros sobre el impacto del agilismo aplicado bajo los lineamientos una de las empresas más grandes en la industria del software.

Los agilistas ecuatorianos internacionales [octubre/2014]


Este es el equipo que nos representó en las Séptimas Jornadas Ágiles Latinoamericanas.


De a poco van surgiendo agilistas en el Ecuador e iremos contando sus historias conforme a los registros obtenidos por nuestras investigaciones como DSN_XP ya que no contamos con aportes de estos miembros sobre el impacto de aplicar el agilismo en sus respectivos lugares.


Paralelamente comienza a suceder un nuevo hecho en nuestra comunidad y se trata del impacto de estos agilistas en la región Latinoamericana  y el fenómeno de adopción de las metodologías ágiles en Latinoamérica gracias a los registros de facebook de las Jornadas Ágiles Latinoamericanas.

El Agile Open Space en Quito [noviembre/2014]

Este fue un esfuerzo por juntar a la nueva generación de agilistas una vez que la mayoría se separa de Thoughtworks Ecuador y deciden emprender cada cual por su propia cuenta. Para dar un impulso a la comunidad José Lubín provoca que se realice este espacio en el Centro Cultural El Tinku gracias al apoyo de la Fundación Runakawsai.

El impacto de ThoughtWorks en el Ecuador [2014]

DSN_XP se limita en este espacio a definir aquellos aspectos de impacto en el agilismo del Ecuador, bajo ningún concepto estaremos opinando sobre ThoughtWorks Ecuador pero si resaltamos que en nuestras investigaciones, ThoughtWorks Internacional representa efectivamente una escuela de diseño y posee su propio modelo metodológico organizacional.

Uno de los primeros impactos que aporta a la comunidad la empresa ThoughtWorks es la fuerza motivadora que se emplea para brindar mayores oportunidades de mejora continua a las mujeres programadoras del Ecuador, hecho que como DSN_XP estamos muy agradecidos por lo que implica en un futuro cosechar estos esfuerzos.


ThoughtWorks definitivamente tiene una seria participación en la industria del software en Ecuador llegando a profundizar con su presencia aspectos relacionados inclusive a temas de política pública aplicada a la industria del software.

FuerzaTres y su presencia en la comunidad [febrero/2015]

No asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del evento y su impacto en la comunidad ágil de Ecuador.



Agradecemos profundamente a Ingrid Astiz por contactarnos durante su presencia y poder tener como DSN_XP un registro de su visita a Quito y el impacto de su presencia en la comunidad agile de Ecuador.


Nota: En este registro aparece una nueva empresa Jaguar sobre quienes no tenemos datos para nuestra bitácora del agilismo en Ecuador

El AgileOpenSpace en Guayaquil [febrero/2015]

Asistimos a este evento y realmente quedamos encantados del proceso de organización, convocatoria y profesionalismo que el equipo de Guayaquil demostró con este evento, para nosotros..., este fue el impulso que necesitaba la comunidad ágil de Ecuador para poder mostrarse internacionalmente.

Detrás de todo este esfuerzo estaba la presencia de José Franco y su equipo, quienes tomaron el agilismo tan en serio que más tarde impactarían en Ecuador con su presencia.

Economía líquida en Buen Trip [marzo/2015]

Este fue un evento promocionado por José Sandoval gracias a la presencia de Alan Cyment para con la comunidad.

Agile Open Space Quito Trip [marzo/2015]

Luego de toda la adrenalina obtenida con el evento en Guayaquil, se logró concretar un segundo evento en Quito y se tenía programado un tercer evento en Cuenca.

En este segundo evento pudimos observar el crecimiento inclusive de la comunidad en Quito, esto fue posible también por la presencia de grandes del agilismo que compartieron sus experiencias.


Escalando el agilismo con Etna Estrella [marzo/2015]

Pocas mujeres brillan por su impacto en la comunidad ágil de Ecuador, dentro de estas agilistas se puede contar con Etna Estrella una arquitecta tecnológica que tiene en su sangre al arte y su proceso de transformación de comunidades.

Etna tiene una mirada artística que le permite introducir el agilismo mediante un diseño profundo del conocimiento y experiencias artísticas que impactan en todos aquellos que cursan con su entrenamiento profesional.

Etna es a nuestro entender una de las exponentes femeninas que brillan por su propio esfuerzo internacionalmente.

El Agile Open Space en Cuenca [abril/2015]

No asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del evento y su impacto en la comunidad ágil de Ecuador.


Regional Scrum Gathering [abril/2015]


Y bueno, asistimos a este evento y aprendimos más sobre Scrum, pero la nota amarga que debe ser registrada en nuestra bitácora sobre el agilismo en el Ecuador, tiene que ver con la falta del reconocimiento por parte de terceros que introducen eventos, talleres sobre el agilismo en Ecuador a la comunidad ágil de Ecuador y su posicionamiento internacional.

Esto es importante discutir, no por temas de ego (de los miembros que nos consideramos como comunidad Agile Ecuador), sino por las estrategias que pueden acordarse entre los actores detrás del mundo del agilismo y quienes nos hemos esforzado por dejar en alto el marco de trabajo del agilismo en el Ecuador; ahora bien, cualquier comunidad como la comunidad Scrum Ecuador y quienes no quisieron hablar con nosotros, no deberían ignorar a la comunidad Agile Ecuador porque tarde o temprano tendrán que reconocer que oficialmente estamos representando como comunidad a todo el movimiento Agile Internacional en Ecuador.

Para DSN_XP era necesario separar la industria de la capacitación y certificación sobre el interés genuino que tenemos sobre nuestro estudio del impacto del agilismo en el Ecuador (como miembros que iniciamos con esta comunidad), por ello, tiempo atrás nos separamos y nos reintegramos en esta ocasión para apoyarla  en su crecimiento

Lo positivo es que conocimos a los grandes del agilismo en el mundo gracias al esfuerzo de quienes realizaron este evento, colocando nuestro país dentro del mapa de la Alianza Scrum.

Open Space Guayaquil by Hiroshi Hiromoto [abril/2015]

No asistimos a este evento pero registramos una nueva universidad que se integra al mapa de espacios en los cuales se ha difundido el agilismo en el Ecuador. [Universidad de Especialidades Espíritu Santo]


Hiroshi introduce conceptos como Coaching Dojo


Pensamiento Agile aplicado al software y a las empresas [mayo/2015]

No asistimos a este evento realizado por Alex Benavides y Johnny Ordoñez pero destacamos la continua participación en universidades.


Las Octavas Jornadas Latinoamericanas Ágiles [octubre/2015]

No asistimos a este evento pero lo registramos en esta bitácora porque quienes participan en el evento internacional, son miembros activos de la comunidad Agile Ecuador y también miembros de organizaciones ecuatorianas que se capacitan continuamente en los avances que se ofertan en estos espacios para toda la comunidad Latinoamericana de Agilismo.

Es en este evento que se postula a Ecuador para efectos de traer las jornadas ágiles latinoamericanas a nuestro país, ratificando con ello que la presencia y posicionamiento de la comunidad Agile Ecuador.

Como DSN_XP llevamos un registro del impacto de las jornadas en toda la región.


La comunidad Agile y la UDLA [2016]

No asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del evento y su impacto en la comunidad ágil de Ecuador.

Reporte de experiencia agilismo en Ecuador [junio/2016]

No asistimos a este evento pero recogemos lo que hemos encontrado en los registros de la página Facebook de la comunidad.
La comunidad Agile Ecuador invitan al reporte de experiencia del agilismo en empresas tradicionales, un evento iniciado por José Lubín Sandoval.
Queremos compartir nuestra experiencia trabajando con el agilismo en una empresa grande y tradicional, a nivel nacional, involucrando al negocio. Con experimentos cortos, con foco en los clientes, en sprints de negocio y de desarrollo de software. La idea es visibilizar el caso e inspirar a agilistas con lo realizado, también recibir feedback e ideas por parte de la comunidad.

Experiencias ágiles en Quito by Kleer [junio/2016]

Participamos de este evento y de a poco estaremos subiendo el material relacionado.

Despliegue para Ágiles Ecuador 2016 [octubre/2016]

  • Las coordinaciones para el evento 
  • Nuestra participación en la sección de convocatoria 
  • Nuestra participación en la obtención de la sede
  • Las convocatorias al evento

    Las Octavas Jornadas Ágiles Latinoamericanas [octubre/2016]

    No asistimos a todo el evento por cuestiones de salud pero crearemos un post aparte sobre este evento y la forma en la cual participó DSN_XP en su organización como voluntario.

    • Improvement Kata by Hiroshi (#Agiles2016)

    La separación de la comunidad por Jhonny Ordoñez [2016]

    No tenemos detalles sobre el impacto de la organización en los miembros de la comunidad, resultado de este esfuerzo, uno de los miembros decide separarse y continuar con su aporte a la comunidad de forma personal.

    Se menciona este evento dentro de la bitácora del agilismo en Ecuador porque sería justamente Jhonny quien más tarde estaría participando de procesos internacionales de escalamiento del agilismo en organizaciones.



    La comunidad Agile Ecuador cuarta versión [2016]

    Realmente luego de las Jornadas Latinoamericanas, el esfuerzo que realizó la comunidad AGILE Ecuador fue inmenso, resultado de este esfuerzo energético la comunidad toma un nuevo impulso (gracias al múltiple aporte del equipo radicado en Guayaquil).


    La mayor parte de nuestros representantes comunitarios tienen ya un nivel internacional y con ello se proyectan mejoras para sus carreras profesionales, golpeando también en la comunidad y la necesidad de impulsar y sostener un esfuerzo que poco a poco está impactando en Ecuador.

    El despliegue de la comunidad en Guayaquil [2017]

    En Guayaquil, Ecuador cuenta con la mayoría de los grandes representantes del agilismo, este espacio está dedicado dentro de la bitácora de nuestros registros del agilismo en el país, a todo un conjunto de esfuerzos comunitarios por introducir el agilismo en esta importante ciudad.

    Lean Change Management con Luis Mulato [febrero/2017]

    Luis mulato es un personaje muy importante para nuestros registros del agilismo en la región Latinoamericana.


    Las reuniones en las Novenas Jornadas Ágiles [2017]

    No asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del evento y su impacto en la comunidad ágil de Ecuador.


    Scrum Gathering y su impacto en la comunidad [2017]

    Como DSN_XP habíamos hablado desde un principio sobre el impacto que tendría el modelo de certificación propuesto por la Scrum Alliance en la gestión de proyectos del Ecuador.

    Como evidencia de nuestros estudios, dejamos constancia que DSN_XP respeta a Scrum como marco de trabajo, pero también dejamos constancia que una vez experimentado con este marco en el proyecto SYLLABUS+, dejamos Scrum como referente y nos interesamos mucho en profundizar KANBAN por su enfoque en el estudio de flujos y esto para DSN_XP es un área de investigación continua.

    La proliferación de entrenamientos SCRUM [2017]

    Uno de los impactos registrados en el agilismo en Ecuador fue la proliferació de entrenamientos ligeros en Scrum y la aparición de la necesidad de un nuevo rol que sería muy compatible con la estructura que se desea imponer desde la mirada clásica de control y que se entendería como Agile Coach.

    DSN_XP y la psicología Agile con Marcelo Luj [diciembre/2017]

    Realizamos este evento pero por su pronto lanzamiento tuvimos la mínima acogida esperada gracias al apoyo de Marcelo y de Etna.

    La creación de la cuenta MeetUp Agile Ecuador [abril/2018]

    Meetup como plataforma es administrada por Andrés Robalino como miembro de la comunidad.


    Si te interesa aprender y compartir tus experiencias con las metodologías ágiles te esperamos en nuestras reuniones. No tienes que ser experto para participar o incluso para dar una charla.
    La idea es compartir. Súmate al grupo y ayúdanos a cambiar y hacer más creativo nuestro trabajo.

    La comunidad Agile y Alistair Cockburn [2018]

    No asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del evento y su impacto en la comunidad ágil de Ecuador.



    Andrés Robalino y el Meetup Agile Ecuador [junio/2018]

    No asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del evento y su impacto en la comunidad ágil de Ecuador.



    Por definir [2018]

    No asistimos a este evento y de a poco iremos detallando en este espacio los conceptos básicos del evento y su impacto en la comunidad ágil de Ecuador.

    DSN_XP y el lienzo Mobius

    Mobius como lienzo

    Lienzo de innovación
    DSN_XP entra en contacto con el lienzo Mobius, gracias al aporte realizado por un miembro de la comunidad Agile Ecuador.

    Lienzo del bucle Mobius

    Lienzo para definición de la estrategia de innovación
    Compuesto de siete (7) componentes de construcción, el lienzo permite establecer la estrategia en base al problema a resolver mediante el lazo continuo de aprendizaje.
    • Problemática
      • Identifica y comprende el o los problemas que deseas resolver desde sus causas posibles.
    • Entregables
      • Establece definiciones claras y mediciones para determinar el éxito del esfuerzo aplicado.
    • Valor
      • Define los parámetros que te ayudan a identificar la entrega de valor tanto en su desarrollo o creación, en su seguridad y en proteger la ganancia durante el esfuerzo.
    • Opciones
      • Desarrolla las potenciales soluciones a la problemática encontrada, o define la hipótesis que deseas validar como posible solución a la problemática encontrada.
    • Entrega
      • Investiga, experimenta e implementa con todos los factores que influyen en el proceso de entrega de valor al cliente final.
    • Medición continua
      • Examina y actúa en base al conocimiento ganado en el proceso de mejora continua de todo el esfuerzo realizado.
    • Adáptate
      • Descubre las opciones disponibles para continuar o desarrollar resiliencia y continuidad en el tiempo.

    DSN_XP y la ingeniería documental

    Ingeniería Documental

    DSN_XP considera a la ingeniería documental como una perspectiva de conocimiento que tuvimos que desarrollar para poder aplicar los conocimientos adquiridos en el modelado de desarrollo de software mediante UML como lenguaje unificado para la generación de documentos técnicos de proyectos de desarrollo que fueron analizados por nuestro marco de trabajo DSN_XP.

    La documentación técnica como ingeniería

     Documento original

    Pensamientos tomados desde Internet...

    "El diseño de tipos de documentos es una actividad generalizada en la práctica profesional desde hace años.  Sin embargo, la generalización del lenguaje XML como medio para codificar e intercambiar documentos a través de redes y la aparición de distintos métodos para codificar las características de los tipos de documentos (esquemas XML, RelaxNG, etc.) y sus metadatos descriptivos y administrativos ha hecho manifiesta la necesidad de contar con una aproximación más estructurada para formalizar el diseño de tipos de documentos y su implementación mediante estándares XML."
    Esto se une a los requisitos de la nueva aproximación tecnológica para la integración de aplicaciones software -los llamados servicios Web o arquitectura SOA (Service Oriented Architecture)- que basan la interacción entre sistemas en el intercambio de documentos XML cuya estructura debe definirse con precisión.
    La principal aproximación teórica a este problema lo encontramos en el trabajo del académico de Robert J. Glushko, con el nombre de Ingeniería Documental.


    Este autor propuso la utilización del término ingeniería documental para referirse a las distintas técnicas y tecnologías que se utilizan para establecer modelos que hagan posible el intercambio de documentos entre organizaciones. Su obra sobre este tema está formada por diversos artículos y contribuciones a congresos, así como de manera especial por el libro escrito en colaboración con Tim McGrath (Glushko-Mcgrath, 2005) , en el que se analiza y describe el alcance de esta disciplina desde una perspectiva conceptual y práctica.

    Concretamente Glushko la define como “la disciplina dedicada a especificar, diseñar e implementar los documentos electrónicos que se usarán en los intercambios de información en internet para solicitar la ejecución de procesos de negocio, o para devolver los resultados obtenidos por la ejecución de estos procesos a través de servicios web”. Otra definición propuesta por el autor señala que “la ingeniería documental estudiaría los métodos de análisis y diseño y los modelos formales para describir la información requerida por los procesos de negocio, así como la secuencia o coreografía mediante la cual estos procesos se coordinan” (Glushko, 2003).

    Vemos que el término agrupa distintas técnicas: diseño de tipos de documentos, análisis de procesos y modelos de transacciones, así como los procedimientos necesarios para el intercambio de información y documentos a través de la Red. Podríamos decir que son tres sus objetivos:
    • Modelar procesos y transacciones entre empresas, y representarlos en un formato que haga posible su procesamiento automatizado.
    • Modelar la estructura de los documentos que se intercambian en esos procesos. Normalmente mediante XML.
    • Implementar soluciones informáticas capaces de ejecutar y auditar estas transacciones en entorno internet, garantizando la autenticidad, confidencialidad y seguridad de los datos.

    Data e Información

    Para DSN_XP, la ingeniería documental se estudia desde la perspectiva de la DATA y sus relaciones en el proceso macro denominado Información.  A partir de esta perspectiva todas aquellas ramificaciones del estudio de conceptos aplicados al proceso de desarrollo de información son estudiados bajo una serie de disciplinas que se integran en la arquitectura de información que se establece sobre la cultura de la organización y la tecnología aplicada al procesamiento de la DATA en información.

    La ingeniería documental como disciplina aplica un enfoque de flujo de datos para toda la organización, identificando y modelando mediante documentos los cuales se envían internamente entre los distintos procesos de la organización y sus contenidos.

    Los documentos en cuestión puede ser documentos transaccionales (EDI, XML) o publicaciones (HTML, PDF, DTD) o una mezcla de estos formatos.
    La ingeniería documental no es ingeniería de software, tampoco es una temática exclusiva de TI, no es tampoco publicaciones Web, tampoco es arquitectura empresarial ni re-ingeniería de procesos de negocios, pero es común a todas estas disciplinas porque es un tema transversal a toda la organización.
    La ingeniería documental es, por supuesto, algo más sofisticado que un simple flujo de datos, el análisis también abarca los signos y los aspectos de ruteo de mensajes.

    La ingeniería documental considera como principio de diseño, soluciones altamente automatizadas en base a una arquitectura orientada a servicios altamente desacoplados.


    Inicialmente la normalización documental para intercambio de documentos comerciales EDI (Electrónic Data Interchange) y sus formatos están altamente acoplados a la capacidad de transferencia de datos mediante redes de TELECOM.

    Como DSN_XP trabajamos aprendiendo el formato EDIFACT para la transferencia de bloques de información entre diversas entidades de diversas líneas de negocio dentro de un contexto comercial como lo es la transacción comercial para aerolíneas.

    Actualmente la cobertura de los formularios electrónicos en la transferencia de bloques de información y su normalización a motivado al desarrollo de iniciativas como los lenguajes HL7, xrl o HR-XML.

    La importancia entonces de la ingeniería documental radica en que, la normalización no solo implica la necesidad de establecer acuerdos sobre el formato y el contenido de los documentos, sino también sobre su utilización prevista y los procesos de trabajo de los que forman parte.

    En este punto la ingeniería documental se relaciona notablemente con la ingeniería procedural y de automatización de procesos, por lo tanto, la normalización debe considerar numerosas metodologías de representación y optimización de los procesos administrativos cuyo núcleo como bloque de construcción informativa es el formulario electrónico.

    Al normalizar se deben considerar:
    • Los aspectos técnicos relacionados con la transmisión física de los mensajes a través de redes de comunicaciones.
    • Los aspectos documentales vinculados a los datos que se deben incluir en los documentos y a la forma de organizarlos.
    • Los aspectos organizativos en relación a los procesos en los que se usarán los documentos, el orden en el que deben intercambiarse y las dependencias que existen entre ellos.

    DSN_XP y el desarrollo centrado en casos de uso

     Casos de uso 2.0


    IVAR JACOBSON, IAN SPENCE, AND BRIAN KERR

    El Hub del desarrollo de software

    Los casos de uso han existido durante casi 30 años como un enfoque de requisitos y han sido parte de la inspiración para técnicas más recientes como las historias de usuario.  Ahora la inspiración ha volado en la otra dirección. 
    Use Case 2.0 es el nuevo modelo de generación de desarrollo basado en casos de uso; ligero, ágil y lean; inspirado en las historias de usuarios y las metodologías ágiles Scrum y Kanban.

    Use-Case 2.0 tiene todos los valores populares del pasado:

    No solo para los requisitos de soporte, sino también para la arquitectura, el diseño, la prueba y la experiencia del usuario y es fundamental para el modelado de negocios y la reutilización de software.

    Use-Case 2.0 se ha inspirado en historias de usuarios para ayudar con backlogs a la Scrum y flujo de una pieza con Kanban, con la introducción de un nuevo concepto importante, el uso en rebanadas del caso.
    Este artículo presenta el argumento de que los casos de uso incluyen esencialmente las técnicas proporcionadas por el usuario: historias, pero ofrecen mucho más para sistemas más grandes, equipos más grandes y desarrollos más complejos y exigentes.
    Son tan livianos como las historias de usuario, pero también pueden escalar en una forma suave y estructurada de incorporar tantos detalles según sea necesario. Lo más importante es que conducen y conectan muchos otros aspectos del desarrollo de software.

    Casos de uso: ¿Por qué sigue siendo exitoso y popular?

    Los casos de uso se introdujeron en OOPSLA 87 (Sistemas de programación, lenguajes y aplicaciones orientados a objetos), 6 aunque no fueron ampliamente adoptados hasta la publicación del libro de 1992 Ingeniería de software orientada a objetos: un enfoque basado en casos de uso.7 


    Desde entonces muchos otros autores han adoptado partes de la idea, en particular Alistair Cockburn 2
    sobre los requisitos y Larry Constantine 4 sobre diseñando para mejores experiencias de usuario. 

    Los casos de uso fueron adoptados como parte del estándar UML (Lenguaje unificado de modelado1 ) y sus diagramas (el caso de uso y el actor como iconos) se encuentran entre las partes del lenguaje más utilizadas. Se han escrito muchos otros libros y artículos sobre los casos de uso para todo tipo de sistemas, no solo para software, sino también para negocios, sistemas (como sistemas integrados) y sistemas de sistemas. Centrándonos en el presente y el futuro, las últimas macro tendencias, IoT (Internet de las cosas) e Internet industrial, han elegido los casos de uso.

    La práctica de casos de uso ha evolucionado a lo largo de los años, inspirada por ideas de muchas personas diferentes, con las ideas más nuevas incorporadas en los casos de uso 2.0. Una nueva idea es cortar un uso en porciones de caso de uso. 5,8 La idea de dimensionar estas rebanadas para convertirse en elementos adecuados del backlog y relacionarlos con las historias de usuario es el núcleo de Use-Case 2.0.

    Los casos de uso pueden y deben usarse para impulsar el desarrollo de software. No prescriben cómo debe planificar o administrar su trabajo de desarrollo, o cómo debe diseñar, desarrollar o probar su sistema. Sin embargo, proporcionan una estructura para la adopción exitosa de su seleccionado prácticas de gestión y desarrollo.

    La razón del éxito del enfoque de casos de uso no es solo que sea una técnica muy práctica para capturar requisitos desde una perspectiva de uso o para diseñar prácticas experiencias de usuario, pero impacta en todo el ciclo vital de desarrollo. Los casos de uso clave, o para ser más precisos, las porciones clave de casos de uso (una porción es una parte cuidadosamente seleccionada de un caso de uso): ayuda sistemáticamente a encontrar la arquitectura de la aplicación. Impulsan la identificación de componentes u otros elementos de software en el diseño de software . Ellos son los elementos que deben someterse a pruebas y realmente respaldan el diseño basado en pruebas. Son los elementos a poner en el backlog al planificar los sprints o para poner en el tablero usando Kanban. 

    Los casos de uso de una empresa son los procesos del negocio; por lo tanto, la ventaja de hacer modelos de negocios con casos de uso es que conduce directamente a encontrar el uso según casos del sistema a desarrollar para dar soporte al negocio.

    Además, los casos de uso ayudan a encontrar puntos en común, que dirigen el trabajo de arquitectura para lograr la reutilización del software. Hay muchos más valores similares en la aplicación de casos de uso, pero lo más importante es que la idea de casos de uso es intuitiva y se puede capturar. Se trata de una herramienta ligera, esbelta y ágil, escalable, enfoque versátil y fácil de usar. Mucha gente que escucha acerca de los casos de uso por primera vez los toma en serio; muchos empezar a usar el término en situaciones de la vida cotidiana sin pensar en todos los detalles que ayudan en tantos aspectos del desarrollo de software, los aspectos que son los rayos de la rueda de desarrollo de software en la que los casos de uso son el eje o hub (ver figura 1)
    Por tanto, parece claro que los casos de uso han superado la prueba de tiempo y tenga un futuro muy saludable

    Principios para la adopción de Casos de Uso

    Hay seis principios básicos en el corazón de cualquier aplicación de casos de uso éxito:
    1. Hágalo sencillo contando historias.
    2. Comprenda el panorama general.
    3. Céntrese en el valor.
    4. Construya el sistema en porciones.
    5. Entregue el sistema en incrementos.
    6. Adáptese a las necesidades del equipo.

    Principio 1: hazlo simple contando historias

    La narración es el medio por el cual las culturas sobreviven y progresan; es la forma más sencilla y eficaz de transmitir conocimientos de una persona a otra. Es la mejor forma de comunicar lo que un sistema debería hacer y hacer que todos trabajen en el sistema para centrarse en los mismos objetivos.
    Los casos de uso capturan los objetivos del sistema. Comprendemos un caso de uso, contando historias. Las historias cubren cómo lograr el objetivo y cómo manejar los problemas que ocurren en el camino. Los casos de uso proporcionan una forma de identificar y capturar todas las diferentes historias pero relacionadas de una manera simple pero de manera completa. Esto permite que los requisitos del sistema sean fácilmente capturados, compartidos y entendidos.

    Principio 2: Comprenda el panorama general

    Ya sea que el sistema que se está desarrollando sea grande o pequeño, ya sea un sistema de software, un sistema de hardware o un sistema empresarial, comprender el panorama general es esencial. Sin una comprensión del sistema en su conjunto, resulta imposible tomar las decisiones correctas sobre lo que se incluye en el sistema, qué omitir, cuánto costará y qué beneficio proporcionará.

    Un diagrama de casos de uso es una forma sencilla de presentar una descripción general de los requisitos de un sistema. La figura 2 es el diagrama de caso de uso de un sistema telefónico simple. Esta imagen muestra todas las formas en que se puede utilizar el sistema, quién inicia la interacción y cualquier otra parte involucrada. Por ejemplo, un suscriptor por llamada puede realizar una llamada local o de larga distancia, llamar a cualquiera de los suscriptores llamables del sistema. También se puede ver que los usuarios no tienen que ser personas, sino que pueden ser otros sistemas y en algunos casos, ambos (por ejemplo, el papel del suscriptor llamado puede ser un contestador automático y no un
    persona)

    Principio 3: Centrarse en el valor

    Al intentar comprender cómo se utilizará un sistema, es siempre es importante centrarse en el valor que aportará a sus usuarios y otras partes interesadas. El valor se genera solo si se utiliza realmente el sistema, por lo que es mucho mejor centrarse en cómo se utilizará el sistema que en largas listas de las funciones o características que ofrecerá.

    Los casos de uso proporcionan este enfoque al concentrarse en cómo el sistema se utilizará para lograr un objetivo específico para un usuario. Abarcan muchas formas de utilizar el sistema: aquellas que logren con éxito las metas y las que manejen cualquier problema que pueda ocurrir.

    La Figura 3 muestra una narrativa de casos de uso estructurada en esta forma para el caso de uso de retiro de efectivo de un cajero automático. La forma más sencilla de lograr el objetivo se describe mediante el flujo. Los demás se presentan como flujos alternativos. En esta manera de crear un conjunto de flujos que estructuran y describen las historias, ayudando a encontrar los casos de prueba que completan su definición.

    Principio 4: Construya el sistema en porciones

    La mayoría de los sistemas requieren mucho trabajo antes de poder utilizarse y estar listo para su uso operativo. Tienen muchos requisitos, la mayoría de los cuales dependen de otros requisitos implementados antes de que puedan cumplirse y entregarse valor.

    Siempre es un error intentar construir un sistema así de una vez. El sistema debe construirse en porciones, cada una de las cuales tiene un claro valor para los usuarios.

    La receta es bastante sencilla:
    • Primero, identifique los más útiles cosa que el sistema tiene que hacer y enfocarse en eso.
    • Entonces tome esa única cosa y córtela en rodajas más finas
    • Decidir por los casos de prueba que representan la aceptación de esas porciones.
    • Elija el corte más central que recorra todo el concepto de un extremo a otro, o lo más cerca posible de eso.
    • Estimarlo en equipo y empezar a construirlo.
    Este es el enfoque adoptado por Use-Case 2.0, donde un caso de uso se corta para proporcionar elementos de trabajo de tamaño adecuado y donde el propio sistema evoluciona corte a corte.  Aunque los casos de uso se han utilizado tradicionalmente para ayudar a comprender y capturar los requisitos, siempre han sido mucho más que esto. Las secciones de casos de uso analizan más que solo los requisitos; también cortan todos los otros aspectos del sistema y su documentación, incluyendo el diseño, la implementación, los casos de prueba y los resultados de las pruebas.

    Principio 5: Entregue el sistema en incrementos

    La mayoría de los sistemas de software evolucionan a lo largo de muchas generaciones. No se producen de una sola vez; están construidos como una serie de lanzamientos, cada uno basado en el anterior. Incluso los lanzamientos en sí mismos a menudo no se producen de una vez pero evolucionan a través de una serie de incrementos. Cada incremento proporciona una versión demostrable o utilizable del sistema. Esta es la forma en que deben producirse todos los sistemas.

    La figura 4 muestra el desarrollo incremental de un lanzamiento del sistema. El primer incremento contiene solo un segmento: el primer segmento del caso de uso 1. El segundo incremento agrega otra porción del caso de uso 1 y la primera porción del caso de uso 2. Luego se agregan más rebanadas para crear el tercer y el cuarto incremento. El cuarto incremento se considera lo suficientemente completo y útil para ser lanzado.

    Principio 6: Adaptarse para satisfacer las necesidades del equipo

    Desafortunadamente, no existe una solución única para todos los desafíos del desarrollo de software; diferentes equipos y diferentes situaciones requieren diferentes estilos y diferentes niveles de detalle. Independientemente de qué prácticas y técnicas seleccione, debe asegurarse de que sean adaptables lo suficiente para satisfacer las necesidades continuas del equipo.

    Use-Case 2.0 está diseñado con esto en mente y puede ser tan ligero como se desee. Los equipos pequeños y colaborativos pueden tener narrativas de casos de uso muy ligeras que capturan lo básico, lo esencial de las historias. Estos se pueden escribir a mano en simples fichas. Los equipos grandes distribuidos pueden tener más detalles narrativos de casos de uso presentados como documentos. Depende del equipo para decidir si necesitan ir más allá de los esenciales, agregando detalles de una manera natural a medida que se encuentran problemas que lo esencial no puede afrontar.

    La práctica de los casos de uso 2.0

    La práctica de los casos de uso 2.0 describe los conceptos clave para trabajar con ellos, los productos de trabajo son utilizados para describirlos y a un conjunto de actividades.

    Conceptos con los que trabajar

    El caso de uso 2.0 abarca los requisitos, el sistema a ser desarrollado debe cumplir con los requerimientos y las pruebas utilizadas para demostrar que el sistema cumple con los requisitos. El corazón del caso de uso 2.0 son el caso de uso, el segmento del caso de uso y la historia.

    Los casos de uso capturan los requisitos y cada caso de uso se gestiona el alcance de uso, dividiéndolo en un conjunto de porciones de casos de uso que se pueden trabajar de forma independiente. Contando historias se establecen puentes sobre las brechas entre las partes interesadas, los casos de uso y las porciones de casos de uso. Así es como las partes interesadas comunican sus requerimientos y se exploran los casos de uso. La comprensión de las historias es también el mecanismo para encontrar el uso correcto de porciones de casos de uso para impulsar la implementación del sistema

    Casos de uso

    Un caso de uso es: 
    • Una secuencia de acciones que realiza un sistema que produce un resultado observable de valor para un usuario en particular.
    • Ese comportamiento específico de un sistema, que participa en colaboración con un usuario para ofrecer algo de valor para ese usuario.
    • La unidad de actividad más pequeña que proporciona un resultado para el usuario.
    • El contexto de un conjunto de requisitos relacionados.
    El conjunto de todos los casos de uso agrupan todos los requisitos funcionales del sistema. La forma de entender un caso de uso es contando historias. Estas historias cubren tanto el cómo lograr una meta así como cómo el manejar cualquier problema que ocurra en el camino. Ayudan a los desarrolladores a comprender el caso de uso e implementarlo segmento por segmento.

    Un caso de uso sufre varios cambios de estado definidos, comenzando con solo tener su objetivo establecido , a través de la estructura de la historia entendida , historia más simple cumplida, las suficientes historias cumplidas, todas las historias cumplidas. Los estados constituyen puntos de referencia importantes en la comprensión e implementación del caso de uso.

    Rebanadas de casos de uso

    Los casos de uso cubren muchas historias relacionadas de diversa importancia y prioridad. A menudo hay demasiadas historias para contar en un lanzamiento único y, en general, demasiadas para trabajar en un solo incremento. Por lo tanto, es necesario dividir los casos de uso en piezas más pequeñas.

    Un segmento de caso de uso es una o más historias seleccionadas de una caso de uso para formar un elemento de trabajo que tiene un valor claro para el cliente. Actúa como marcador de posición para todo el trabajo requerido para completar la implementación de las historias seleccionadas. El segmento de caso de uso evoluciona para incluir los segmentos correspondientes a través del diseño, implementación y prueba. El segmento de caso de uso es el elemento más importante del Caso de Uso 2.0, ya que se utiliza no solo para ayudar con los requisitos, sino también para impulsar el desarrollo de un sistema para cumplirlos.

    Un segmento de caso de uso sufre varios cambios de estado, desde su identificación inicial donde tiene el alcance , a través de ser elaborado, analizado, implementado y finalmente, verificado. Estos estados permiten la planificación y el seguimiento de la comprensión, implementación y prueba del segmento de caso de uso.

    Para el observador casual que mira los estados, esto podría parecer a un proceso en cascada. Sin embargo, hay una gran diferencia ya que se trata de un segmento de caso de uso individual. Al otro lado del set de rebanadas, todas las actividades podrían estar sucediendo en paralelo. Mientras se está verificando un segmento de caso de uso, se está verificando otro segmento de caso de uso que se está implementando, se está preparando un tercero que está siendo analizado.

    Cuentos

    Contar historias es la forma en que los desarrolladores exploran casos de uso con las partes interesadas. Cada historia de valor para los usuarios y otros stakeholders es un hilo conductor a través de uno de los casos de uso. Las historias pueden ser de naturaleza funcional o no funcional.

    Una historia se describe mediante una parte de la narrativa del caso de uso, uno o más flujos y requisitos especiales, y uno o más casos de prueba. La clave para encontrar historias efectivas es comprender la estructura de la narrativa de los casos de uso.

    La red de flujos puede pensarse como un mapa que resume todas las historias necesarias para describir el caso de uso. En el ejemplo de cajero automático anterior de la figura 3, podría identificar historias específicas como "Retirar un monto estándar  de $ 100”,“ Retirar un monto no estándar de $ 75 y obtenga un recibo” o “Responda a una tarjeta no válida”.

    Cada historia atraviesa uno o más flujos que comienzan con el caso de uso al comienzo del flujo básico y terminando con el caso de uso al final del flujo básico. Esto asegura que todas las historias están relacionadas con la consecución del mismo objetivo, son completos y significativos y son complementarios, ya que todos se basan en la historia simple descrita por el flujo básico.

    Productos del trabajo

    Los casos de uso y los segmentos de casos de uso son compatibles con varios productos de trabajo que el equipo utiliza para ayudar a compartir, comprender y documentarlos. Un modelo de caso de uso visualiza los requisitos como un conjunto de casos de uso, proporcionando un panorama general del sistema a ser construido. El modelo define los casos de uso y proporciona el contexto para la elaboración de casos de uso individuales.

    Los casos de uso se exploran contando historias. Cada caso de uso es descrito por (1) una narrativa de caso de uso que describe sus historias como un conjunto de flujos; y (2) un conjunto de casos de prueba que completan la historia. Estos se pueden complementar con un conjunto de requisitos que se aplican a todo el caso de uso y que a menudo son no funcionales. Estos influirán en las historias, ayudarán a asignar las historias correctas para los segmentos de casos de uso para la implementación y, lo más importante, definir los casos de prueba adecuados.

    El modelo de casos de uso se complementa con el soporte de información . Esto captura las definiciones de los términos utilizados en el modelo de caso de uso y al describir las historias en las narrativas de casos de uso. También captura cualquier sistema de todos los requisitos que se aplican a todos los casos de uso.

    Se puede crear una realización de caso de uso para mostrar cómo los elementos del sistema colaboran para realizar un caso de uso. Piense en la realización del caso de uso como un "cómo" para complementar el "qué" de la narrativa del caso de uso. Maneras comunes de expresar realizaciones de casos de uso incluyen tablas simples, guiones gráficos o diagramas de secuencia.

    Trabajar con los casos de uso y los segmentos de casos de uso

    Además de crear y rastrear los productos de trabajo, los desarrolladores necesitan rastrear los estados y propiedades de los casos de uso y sectores de casos de uso. Esto se puede hacer de muchas formas y con muchas herramientas. Los estados se pueden rastrear de manera muy simple usando notas adhesivas u hojas de cálculo. Si se requiere más formalidad, entonces uno de los muchos requisitos disponibles comercialmente-herramientas de gestión, gestión de cambios o seguimiento de defectos puede ser usado.


    La Figura 5 muestra un caso de uso y algunas de sus porciones capturadas en un conjunto de notas adhesivas. El caso de uso que se muestra es “7. Explorar y comprar” desde una aplicación de compras. 

    Las secciones 1 y 2 del caso de uso se basan sobre historias individuales derivadas del flujo básico: "Seleccione y Compre 1 producto” y “Seleccione y compre 100 productos”. Rebanada 3 se basa en múltiples historias que cubren la disponibilidad de varios sistemas de soporte involucrados en el caso de uso.

    Las propiedades esenciales para un caso de uso son su nombre, estado y prioridad. En este caso, el popular MoSCoW (Must, Should, se ha utilizado el esquema de priorización podría, lo haría).  También deben estimarse los casos de uso. Aquí un esquema simple se ha utilizado la evaluación del tamaño y la complejidad relativas.

    Las propiedades esenciales para un segmento de caso de uso son: 
    1. Una lista de sus historias; 
    2. Referencias al caso de uso y los flujos que definen las historias; 
    3. Referencias a las pruebas y los casos de prueba que se utilizarán para verificar su cumplimiento; y 
    4. Una estimación del trabajo necesario para implementar y probar la rodaja. 
    En este ejemplo, las historias se utilizan para nombrar el segmento y las referencias al caso de uso están implícitas en los números de segmentos y lista de flujos. Se han agregado las estimaciones más tarde después de consultar con el equipo. Estos son los grandes números hacia la parte inferior derecha de cada nota adhesiva. En el caso de que el equipo haya jugado Planning Poker para crear una relación de estimaciones utilizando puntos de historia. Los casos de uso y las porciones de casos de uso también deben ser ordenados de modo que los más importantes se aborden primero.

    Mantener los productos de trabajo tan livianos como sea apropiado Todos los productos de trabajo se definen con una serie de niveles de detalle. El primer nivel define lo esencial, la cantidad mínima de información que se requiere para prácticamente poder trabajar. Se definen más niveles de detalle para ayudar al equipo a enfrentarse a cualquier circunstancia especial que pueda encontrarse. 

    Esto permite que los equipos pequeños y colaborativos tengan narrativas de casos de uso muy ligeras definidas en un índice simple de tarjetas y grandes equipos distribuidos para tener un uso más detallado de relatos de casos presentados como documentos. Los equipos pueden entonces hacer crecer las narrativas según sea necesario para ayudar con la comunicación o definir a fondo lo importante o crítico para la seguridad de los requisitos.

    La buena noticia es que siempre comienzas de la misma manera, con lo esencial. El equipo puede adaptarse continuamente al nivel de detalle en sus narrativas de casos de uso para cumplir con sus necesidades emergentes.

    Cosas para hacer

    Use-Case 2.0 divide el trabajo en una serie de elementos de actividades esenciales que deben realizarse si los casos de uso deben proporcionar valor real para el equipo. La actividad Buscar actores y casos de uso produce un modelo de casos de uso que identifica a los casos de uso, que serán posteriormente cortados en rodajas . Estos segmentos de casos de uso serán preparados describiendo las historias relacionadas en la narrativa de los caso de uso y la definición de los casos de prueba. 

    Se analiza la rebanada para averiguar cómo interactuarán los elementos del sistema al realizar el caso de uso, luego es implementado y probado como una rodaja. El caso de uso 2.0 se puede considerar una forma de prueba de desarrollo, ya que crea los casos de prueba para cada segmento en la delantera. Finalmente, todo el sistema se prueba para garantizar que todas las rodajas funcionen juntas cuando se combinan.

    Las actividades en sí mismas se realizarán muchas veces en el curso de su trabajo. Incluso una actividad simple como Buscar, es posible que los actores y los casos de uso deban realizarse muchas veces para encontrar todos los casos de uso y se puede realizar en paralelo con, o después, las otras actividades. 

    Por ejemplo, mientras continúa para encontrar actores y casos de uso, también puede estar implementando algunas de las secciones de los casos de uso que se encontraron anteriormente. A medida que avanza el proyecto, las prioridades cambian, las lecciones se aprenden y se solicitan cambios. Todos estos pueden tener un impacto en los casos de uso y porciones de casos de uso que ya se hayan implementado, así como los que aún están a la espera o en progreso. Esto significa que habrá una inspección y adaptación de la actividad a los casos de uso. Esto también adaptará la forma de trabajar con la práctica del caso de uso 2.0 para ajustar el tamaño de las rebanadas o el nivel de detalles en los productos de trabajo para cumplir con diferentes demandas del proyecto y del equipo.

    Utilizando USE-CASE 2.0

    Mucha gente piensa que los casos de uso son aplicables solo a usuarios de sistemas intensivos que tienen mucha interacción entre los usuarios humanos y el sistema. Esto es extraño porque la idea original de los casos de uso provino de la conmutación de sistemas de telecomunicaciones, que tienen tantos usuarios humanos (suscriptores, operadores) y usuarios de máquinas, en forma de otros sistemas interconectados. Los casos de uso son aplicables a todos los sistemas que se utilizan, es decir, todos los sistemas. 

    No es solo para aplicaciones de uso intensivo de usuarios.

    De hecho, los casos de uso son igualmente útiles para sistemas embebidos con poca o ninguna interacción humana, ya que son para uso intensivo. La gente está usando casos de uso en el desarrollo de todo tipo de software embebido en diversos dominios como motor, electrónica de consumo, militar, aeroespacial e industrias médicas. Incluso sistemas de control de procesos en tiempo real utilizados para plantas químicas se pueden describir por casos de uso en los que cada caso de uso se centra en una parte específica del comportamiento del proceso de la planta y las necesidades de automatización.

    No es solo para el desarrollo de software

    La aplicación de casos de uso no se limita al desarrollo de software. También pueden ayudar a comprender los requisitos de negocios, analizar negocios existentes, diseñar nuevos y mejores procesos de negocio y explotar el poder de TI para transformar el negocio. Mediante el uso de casos de uso de forma recursiva para (1) Modelar el negocio y sus interacciones con el mundo exterior y (2) modelar los sistemas necesarios para apoyar y mejorar el negocio, los desarrolladores pueden identificar sin problemas dónde los sistemas afectarán al negocio y qué sistemas se necesitan para respaldar el negocio.

    Manejo de todo tipo de requisitos

    Aunque son una de las técnicas más populares para describir la funcionalidad de los sistemas, también se utilizan casos de uso para explorar características no funcionales. La más simple forma de hacer esto es capturarlos como parte del caso de uso en sí mismo, por ejemplo, relacionar el requisito de desempeño al tiempo transcurrido entre los pasos específicos de un caso de uso o enumerar los niveles de servicio esperados para un caso de uso como parte del propio caso de uso.  Algunas características no funcionales son más sutiles que esto y se aplica a muchos, si no a todos, los casos de uso. Esto es particularmente cierto cuando se construyen arquitecturas en capas, incluyendo componentes de infraestructura como seguridad, gestión de transacciones, servicios de mensajería y administración de datos.

    Los requisitos en estas áreas aún pueden ser expresados ​​como casos de uso: casos de uso separados centrados en el uso técnico del sistema. Estos casos de uso adicionales se denominan casos de uso de infraestructura, 8 ya que los requisitos que contiene impulsará la creación de la infraestructura sobre la que la aplicación se ejecutará.

    Aplicable a todos los enfoques de desarrollo

    Use-Case 2.0 funciona con todos los enfoques del desarrollo de software popular, que incluyen:
    • Enfoques iterativos impulsados ​​por el backlog, como Scrum, EssUP y OpenUP.
    • Enfoques basados ​​en flujo de una sola pieza, como Kanban.
    • Enfoques todo en uno, como la cascada tradicional.
    Caso de uso 2.0 e iteraciones impulsadas por el backlog

    Antes de adoptar cualquier enfoque basado en el backlog, debe comprender qué elementos se incluirán en la cartera de pedidos. Existen diversas formas de trabajos pendientes que los equipos utilizan para impulsar su trabajo, incluyendo productos, lanzamientos y trabajos atrasados ​​del proyecto. Sin importar la terminología utilizada, todos siguen los mismos principios.

    El trabajo pendiente acumulado (backlog) en sí es una lista ordenada de todo lo que podría ser necesario y es la única fuente de requisitos para cualquier cambios a realizar.


    En el caso de uso 2.0, los segmentos del caso de uso son los principales elementos de la cartera de pedidos. El uso de porciones de casos de uso asegura que los elementos de la cartera de pedidos están bien formados, ya que son naturalmente independientes, valiosos y comprobables. La estructuración de la narrativa del caso de uso que los define se asegura de que sean estimables y negociables y la división de casos de uso, es el mecanismo les permite cortarlos tan pequeños como sea necesario para apoyar al equipo de desarrollo.

    Cuando se adopta un enfoque impulsado por el backlog, es importante darse cuenta de que la acumulación en el backog no esté construida y completada por adelantado, pero se trabaja y perfecciona continuamente. La secuencia típica de actividades para un trabajo guiado por el backlog, de enfoque iterativo se muestra en la figura 6.

    Caso de uso 2.0 y flujo de una pieza

    El flujo de una pieza es una técnica tomada de la manufactura esbelta LEAN que evita la agrupación de los requisitos vistos en los enfoques iterativos y en cascada. Cada elemento de requisitos fluye rápidamente a través del proceso de desarrollo, pero para trabajar efectivamente, esta técnica necesita artículos pequeños y de tamaño regular.

    Los casos de uso serían de tamaño demasiado irregular y demasiado grandes para fluir a través del sistema. Sin embargo, las porciones de casos de uso se pueden dimensionar adecuadamente y sintonizados para satisfacer las necesidades del equipo. El flujo de una pieza no significa que solo haya un elemento de requisitos en el que se trabaja a la vez o que no es solo una pieza de trabajo entre una estación de trabajo y la siguiente. Es necesario que haya suficientes elementos en el sistema para mantener al equipo ocupado. Los límites de trabajo en curso se utilizan para nivelar el flujo y evitar que se acumulen atrasos inútiles.


    La figura 7 muestra un tablero Kanban simple para visualizar el flujo del caso de uso rebanado en rodajas. Los límites de trabajo en curso se muestran en rojo. Leer de izquierda a derecha, puede ver que los cortes deben identificarse y delimitados antes de que sean aportados al equipo. En esta figura el límite de trabajo en curso es cinco, y los clientes, producto propietario o equipo de requisitos que son la fuente de los requisitos tratan de mantener cinco porciones de casos de uso listas para la implementación en todo momento.

    Tenga en cuenta que no existe un tablero Kanban definitivo o un conjunto de límites de trabajo en curso; depende de la estructura del equipo y prácticas laborales. La junta y el trabajo en curso los límites deben ajustarse al igual que las prácticas. Los estados para las porciones de casos de uso son una gran ayuda para este tipo de diseño de trabajo ya que pueden definir claramente en qué estado debe estar el segmento cuándo se va a pasar a la siguiente parte de la cadena.

    Caso de uso 2.0 y cascada

    Por varias razones, es posible que deba desarrollar software dentro las limitaciones de alguna forma de modelo de gobernanza en cascada. Por lo general, esto significa que se hará algún intento de capturar todos los requisitos por adelantado antes de que se entreguen a un tercero para el desarrollo. En un enfoque en cascada, los casos de uso no son continuamente trabajados y refinados para permitir que surja el sistema final pero se definen de una sola vez al inicio del trabajo.

    La naturaleza de una cosa a la vez del enfoque de cascada significa que la composición del equipo cambia continuamente con el tiempo, por lo que la capacidad de utilizar la comunicación cara a cara al compartir las historias es muy limitado. Para hacer frente a esto, se necesita aumentar el nivel de detalle de los productos de trabajo, yendo más allá de lo esencial.

    Caso de uso 2.0: no es solo para un tipo de equipo

    Otro aspecto importante de Use-Case 2.0 es su capacidad para adaptarse a las estructuras de equipo existentes y las funciones laborales mientras anima a los equipos a eliminar el desperdicio y aumentar eficiencia. Con este fin, Use-Case 2.0 no predefine ningún tipo de roles o estructuras de equipo particulares, pero define un conjunto de estados para cada uno de los elementos centrales (el caso de uso y el segmento del caso de uso)

    Como se ilustra en la discusión sobre el caso de uso 2.0 y el flujo de una pieza, los estados indican cuándo los elementos están en reposo y podría pasar de una persona o equipo a otro. Esto permite que la práctica se utilice con equipos de todas las formas y tamaños, de pequeños equipos multifuncionales con poca o ningun traspasos a grandes redes de equipos especializados donde cada cambio de estado es responsabilidad de otro especialista.

    Seguimiento de los estados y traspasos de estos elementos permite que el flujo de trabajo a través del equipo (o equipos) sean monitoreados y equipos para adaptar su forma de trabajo para mejorar su desempeño de forma continua.

    Escalar para satisfacer sus necesidades: dentro, fuera y hacia arriba

    Ningún enfoque predefinido se adapta a todos, por lo que el uso del caso de uso 2.0 debe escalarse en varias dimensiones:
    • Los casos de uso se amplían para proporcionar más orientación a menos profesionales con experiencia (desarrolladores, analistas, probadores, etc.) o profesionales que deseen o necesiten más orientación.
    • Se amplían para cubrir todo el ciclo de vida, sin cubrir solo análisis, diseño, codificación y prueba, pero también el uso operacional y el mantenimiento.
    • Se amplían para admitir sistemas grandes y muy grandes como como sistemas de sistemas: sistemas empresariales, líneas de productos y sistemas en capas. Tales sistemas son complejos y típicamente desarrollado por muchos equipos que trabajan en paralelo en diferentes sitios, posiblemente para diferentes empresas, y reutilizando muchos sistemas heredados o soluciones empaquetadas.
    Independientemente de la complejidad del sistema bajo desarrollo, el equipo de desarrollo siempre comienza en la misma manera mediante la identificación de los casos de uso más importantes y creando una gran imagen que sintetiza cuáles son las necesidades para ser construidas. El caso de uso 2.0 se puede adaptar para cumplir con las necesidades del equipo. De hecho, la práctica del caso de uso 2.0 insiste en que inspeccione y adapte continuamente su uso para eliminar el desperdicio, aumentar el rendimiento y mantener el ritmo de demandas siempre cambiantes del equipo.

    Historias de usuarios y casos de uso: ¿Cuál es la diferencia?

    La mejor manera de responder a esta pregunta es mirar las propiedades comunes de las historias de usuario y casos de uso: las cosas que hacen que ambos funcionen bien como elementos de la lista de trabajos pendientes y habilita tanto para apoyar enfoques ágiles populares como Scrum, Kanban, o el desarrollo impulsado por pruebas y especificación por ejemplo. Las secciones de casos de uso y las historias de usuario 3 comparten muchas características. Por ejemplo:
    • Ambos definen partes de la funcionalidad que los equipos pueden terminar en un sprint.
    • Ambos se pueden cortar en rodajas si son demasiado grandes, resultando en más artículos más pequeños.  
    • Ambos se pueden escribir en fichas.
    • Ambos dan como resultado en casos de prueba que representan los criterios de aceptación.
    • Ambos son marcadores de posición para una conversación y se benefician de las tres C inventadas por Ron Jeffries: tarjeta, conversación y confirmación
    • Ambos pueden estimarse con técnicas como planificación de póquer. 
    Entonces, dado que comparten tantas cosas en común, ¿Qué es eso lo que los hace diferentes? Casos de uso y las rebanas de casos de uso aportan un valor añadido:
    • Un panorama general para ayudar a las personas a comprender el alcance del sistema y su valor.
    • Mayor comprensión de lo que hace el sistema y cómo lo hace.
    • Mejor organización, comprensión, aplicación y mantenimiento de los activos de prueba.
    • Fácil generación y análisis de casos de prueba.
    • Soporte para análisis de impacto continuo.
    • Gestión activa del alcance que permite enfocarse fácilmente en proporcionar el producto mínimo viable.
    • Documentación flexible y escalable para ayudar a afrontar trazabilidad u otras limitaciones contractuales.
    • Soporte para sistemas simples, sistemas complejos y sistemas de sistemas.
    • Identificación más sencilla de funciones redundantes y faltantes.
    La pregunta sigue siendo: ¿Qué técnica debería utilizar, que, una vez que va más allá de las preferencias personales, es muy dependiente del contexto? Considere los siguientes factores: cómo hay mucho acceso a SMEs (expertos en la materia); y cuán severos serán los errores de requisitos si escapan a un ambiente vivo.

    El punto óptimo para las historias de usuario se logra cuando hay fácil acceso a un SME y la gravedad de los errores es baja. Usar los casos y los segmentos de casos de uso son más adecuados cuando no hay
    acceso a un SME o cuando las consecuencias son elevadas.

    Dado que el enfoque de caso de uso puede reducirse a un paquete de historias de usuarios, sin embargo, es posible que desee aplicarlos. Si el sistema de sujetos siempre estará en el punto óptimo de historias de usuarios, las historias de usuarios están bien, pero si lo espera para crecer fuera de esa área, debe considerar los casos de uso y porciones de casos de uso.

    Conclusión

    El caso de uso 2.0 existe como una práctica probada y bien definida que es compatible con muchos otros programas de desarrollo de software y sus prácticas como la integración continua, arquitectura intencional y desarrollo impulsado por pruebas. También funciona con todas las prácticas de gestión populares. En particular, tiene la ligereza y flexibilidad para apoyar a los equipos que trabajan en un modo ágil o Lean. También tiene la integridad y el rigor necesario para apoyar a los equipos que trabajan de una manera más formal o en entorno de cascada.

    Más detalles sobre prácticas de casod de uso 2.0 completamente documentado están disponibles en http://www.ivarjacobson.com.