HICSS 2010 Papers: Necesitamos revisores

HICSS-43 PAPER SUBMISSIONS - Need reviewers with review deadline 14 Aug
Tema Tecnología de software
Minitrack: Desarrollo ágil de software: Esbelto, distribuido y escalable
Copresidentes: Jeff Sutherland y Gabrielle Benefield
Del 5 al 8 de enero de 2010
The Grand Hyatt Kauai Resort & Spa, Kaloa, Kauai, Hawaii

HICSS-43 ofrece un entorno único, altamente interactivo y profesionalmente estimulante que los asistentes consideran "muy útil: muchas perspectivas e ideas diferentes como resultado del debate". Las sesiones de HICSS se componen principalmente de ponencias arbitradas; la conferencia no acoge presentaciones de proveedores. Todas las ponencias son revisadas por expertos y las aceptadas se publican en la Biblioteca Digital del IEEE.

Revisores

1. Debe tener o crear una cuenta en el sitio de revisión en: https://precisionconference.com/~hicss43

2. A continuación, envíe un correo electrónico a jeff at scruminc.com con los números de los documentos que desea consultar.

3. Las reseñas son fáciles y breves si se utiliza el formulario del sitio de reseñas del HICSS.

4. Nos gusta contar con el mayor número posible de revisores para cada artículo, con el fin de determinar su utilidad para la comunidad ágil, así como su excelencia técnica.

Documentos presentados

Documento 468
Entropía del software en la evolución ágil del producto
Resumen: A medida que las grandes organizaciones de productos de software adoptan principios y métodos ágiles de desarrollo de software, resulta extremadamente importante comprender el papel de la entropía del software. Es decir, cómo la mantenibilidad de un sistema puede degradarse con el tiempo debido al cambio continuo. Es importante entender cómo esto, por un lado, afecta a la capacidad de actuar ágilmente en la planificación y el desarrollo, y cómo los procesos ágiles, por otro lado, pueden afectar al crecimiento de la entropía. Informamos a partir de un estudio de caso de una exitosa organización de productos de software que ha adoptado el método de desarrollo ágil Evo. Explicamos cómo el proceso ágil se ve afectado negativamente por un caso grave de entropía del software y, por otro lado, cómo el proceso ágil realmente refuerza este problema. Basándonos en una exhaustiva visión general de la investigación relevante, discutimos cómo puede resolverse esta situación para liberar la entropía del software.e todo el potencial de la evolución ágil de los productos de software. 

Documento 696
Encarnado Scrum
Resumen: Del mismo modo que no es necesario que una hormiga entienda la teoría de los sistemas complejos para ser una buena hormiga, un
El scrum master sólo tiene que entender las reglas para ser un "agente" de scrum. Pero a diferencia de la hormiga, el miembro del equipo scrum tiene un sentido emergente de libre albedrío y agencia que puede dificultar la adopción de las reglas simples y aparentemente arbitrarias del proceso scrum. Un enfoque para fomentar la adopción de la naturaleza ascendente de scrum es enseñar a los maestros de scrum los principios básicos de la teoría de los sistemas complejos, ilustrando el poder y la ubicuidad de la autoorganización, la emergencia y la adaptación. Este artículo representa una posible presentación de la teoría de los sistemas complejos en un lenguaje accesible, dirigido a los scrum masters. Además, se defiende la importancia de las prácticas corporales en primera persona para desarrollar una interpretación de señales sensoriales de alta calidad, es decir, un empirismo radical.

Documento 465
Enterprise Scrum: ampliación de Scrum a nivel ejecutivo 
Resumen: Nuestra empresa gestiona 25 equipos a través de 6 productos utilizando un único Enterprise Scrum de arriba abajo. No conocemos ninguna otra empresa que haga esto, y sin embargo proporciona una visibilidad y un control extremos a nivel de CXO. Promueve el pensamiento ágil en toda la empresa, impulsando a los departamentos que no son de ingeniería a adoptar Scrum. Creemos que nos está haciendo más rentables. Calculamos el esfuerzo en meses de equipo, hacemos Sprints trimestrales, asignamos historias a equipos enteros, nos reunimos semanalmente, etc. Empezamos, aplazamos o cancelamos proyectos enteros. Cuando las prioridades compiten, a menudo decidimos comparando los márgenes de beneficio de los proyectos, por ejemplo, el valor actual neto sobre el esfuerzo. Nuestro Presidente es el propietario último del producto. A nivel de proyecto individual, seguimos utilizando Sprints de 2-4 semanas y todos los adornos del proceso clásico Scrum. Surgen nuevos retos: Mover equipos entre proyectos requiere una rápida configuración del entorno de construcción. Los arquitectos deben justificar los proyectos de infraestructura con el valor actual neto. Nuestro proceso se hizo más "lean" para adaptarse a mediados de trimestre.

Documento 849
Gestión de las averías en la investigación constructiva: La reconfiguración de métodos en el desarrollo ágil de sistemas
Resumen: En la investigación constructiva se necesita un conjunto de habilidades y prácticas diferente al de muchos otros tipos de investigación. A menudo, la construcción y el perfeccionamiento de un determinado artefacto informático quedan fuera de las competencias básicas de los investigadores. Para llevar a cabo una investigación constructiva que implique el estudio de la construcción y el uso de nuevos artefactos, es necesaria la colaboración entre diversos agentes con intereses diferentes. En este artículo se aborda la necesidad de comprender mejor cómo deben trabajar los desarrolladores de sistemas para contribuir con éxito a la investigación constructiva. Dado que el objetivo de este tipo de investigación es desarrollar conocimientos mediante la creación de algo que no existe, la necesidad de flexibilidad y de dar pasos graduales en estos procesos de desarrollo resulta esencial. Sobre la base de un proyecto en el que participaron investigadores y desarrolladores de sistemas, se desarrollan formas de superar los fallos en tales procesos de colaboración.

Documento 959
Siete dimensiones de la madurez ágil en la empresa global: Un estudio de caso
Resumen: Los despliegues ágiles suelen tener dificultades para triunfar en grandes organizaciones complejas. Esto se debe a menudo a una incomprensión de la complejidad de las interdependencias de equipos muy dispares que suelen existir, lo que da lugar a optimizaciones locales limitadas. Comprender y mapear la madurez de las prácticas de equipos y unidades interdependientes proporciona un método para descubrir y eliminar los cuellos de botella entre grupos que permiten a la organización mejorar continuamente. La madurez asignada a un superconjunto de prácticas técnicas de estilo XP y de gestión ágil de programas parece proporcionar un potente modelo para mejorar la eficacia y la alineación de los equipos de ingeniería interorganizativos. Este es un estudio de caso del modelo desarrollado por BT Design, la división de TI del proveedor de telecomunicaciones BT, que se ha implantado en flujos de desarrollo formados por cientos de equipos y componentes para mejorar la agilidad organizativa.

Documento 971
CAKE: Una solución de gestión del conocimiento para equipos ágiles
Resumen: El desarrollo ágil de software se basa en una cultura de abundancia que no siempre describen las organizaciones en las que se introduce. Este artículo aborda la escasez de información describiendo un proyecto reciente para mapear datos entre niveles, sistemas y dominios organizativos mediante el desarrollo de una herramienta basada en wiki y sus procesos sociales de apoyo. Todo el sistema de personas, herramientas e información se denominó CAKE (Community Authored Knowledge Exchange) y se basó en los principios de estabilización por eslabones débiles. Estos principios valoraban la sostenibilidad por encima de la optimización, la participación por encima del control y la apertura por encima del cierre, pero sin perder nunca de vista la contribución de cada parte a la solución final. Dado que estos principios subyacen en los mismos eslabones débiles que estabilizan a los equipos ágiles, creo que el paquete CAKE de procesos sociales, herramientas e información puede añadir un valor real a las organizaciones ágiles.

Documento 1278
Apoyo riguroso a la planificación flexible de lanzamientos de productos: un enfoque centrado en las partes interesadas y su evaluación inicial
Resumen: En este artículo se aborda el problema de la planificación del lanzamiento de productos en el desarrollo iterativo de productos. Proponemos un método que combina el apoyo a la decisión, el proceso y la herramienta. El método, denominado SCERP, facilita la participación activa de las partes interesadas en las distintas fases del proceso de planificación. SCERP es flexible en cuanto al número de partes interesadas implicadas, el horizonte de planificación, el número y la definición de los criterios de planificación y la selección del mejor plan entre un conjunto de alternativas optimizadas. Una prueba de concepto del método es un caso práctico de planificación de versiones para una herramienta llamada Agilefant, desarrollada con un proceso parcialmente basado en Scrum. Las ventajas del método demostradas en el estudio son las siguientes (i) mejores decisiones por parte del propietario del producto al basarse en información más objetiva, (ii) mayor transparencia de las decisiones de liberación, y (iii) soporte eficiente de la herramienta que acompaña a todo el proceso.

Documento 1277
Hacia una documentación de requisitos ligera
Resumen: La mayoría de los procesos de gestión de requisitos existentes y las herramientas asociadas están diseñados para el desarrollo de software basado en documentos y, por lo tanto, es poco probable que se adopten para las necesidades de un equipo de desarrollo de software ágil. En este artículo analizamos cómo y qué puede convertir la documentación de requisitos tradicional en un proceso ligero y menos pesado, adecuado para la obtención de requisitos y la retroalimentación de los usuarios. Además, proponemos un modelo de referencia para la fase de documentación de requisitos y analizamos qué tipo de herramientas de documentación de requisitos son necesarias para dar soporte a un proceso de desarrollo de software ágil. También presentamos Vixtory, una herramienta derivada y utilizada para la documentación de requisitos ligeros en proyectos ágiles de desarrollo de aplicaciones web.

Documento 1397
Exploración de la naturaleza transitoria de las prácticas ágiles de gestión de proyectos
Resumen: Dos grandes proyectos de software sirvieron de base a esta investigación. Uno de ellos investigaba procesos ágiles para el desarrollo de servicios urbanos inteligentes e innovadores orientados a la usabilidad y a las opiniones de los usuarios, en una docena de organizaciones urbanas dispersas geográficamente (la mayoría en Europa), de diversa experiencia y tamaño, que compartirían una parte considerable de la tecnología de productos y procesos. El otro buscaba prácticas ágiles de gestión para grandes proyectos distribuidos con plazos de comercialización muy cortos. En ambos casos era obvio que la elección de las prácticas de gestión de proyectos debía depender del contexto y de las propiedades del sistema, como la usabilidad, el plazo de comercialización o la retroalimentación. Las prácticas que surgieron no eran definitivas. El artículo da cuenta de nuestra exploración de la naturaleza transitoria de las prácticas ágiles de gestión de proyectos.