Documents HICSS 2010 : Besoin de relecteurs !

HICSS-43 PAPER SUBMISSIONS - Need reviewers with review deadline 14 Aug
Piste : Technologie des logiciels
Minitrack : Développement agile de logiciels : Lean, Distributed, and Scalable (allégé, distribué et évolutif)
Co-présidents : Jeff Sutherland et Gabrielle Benefield
5-8 janvier 2010
The Grand Hyatt Kauai Resort & Spa, Kaloa, Kauai, Hawaii

HICSS-43 offers a unique, highly interactive and professionally challenging environment that attendees find "very helpful -- lots of different perspectives and ideas as a result of discussion." HICSS sessions are comprised primarily of refereed paper presentations; the conference does not host vendor presentations. All papers are peer reviewed and accepted papers are published in the IEEE Digital Library.

Réviseurs

1. Vous devez avoir ou créer un compte sur le site d'examen à l'adresse suivante : https://precisionconference.com/~hicss43

2. Envoyez ensuite un courriel à jeff at scruminc.com en indiquant les numéros des articles ci-dessous que vous souhaitez consulter.

3. Les révisions sont faciles et courtes, en utilisant le formulaire sur le site de révision de l'HICSS.

4. Nous aimons avoir autant d'évaluateurs que possible pour chaque article afin de déterminer son utilité pour la communauté agile ainsi que son excellence technique.

Documents soumis

Papier 468
Entropie logicielle dans l'évolution agile des produits
Résumé : Alors que les principes et les méthodes de développement de logiciels agiles sont adoptés par les grandes organisations de production de logiciels, il est extrêmement important de comprendre le rôle de l'entropie logicielle. C'est-à-dire la façon dont la maintenabilité d'un système peut se dégrader au fil du temps en raison des changements continus. Il est important de comprendre comment cela affecte d'une part la capacité à agir de manière agile dans la planification et le développement, et comment les processus agiles, d'autre part, peuvent affecter la croissance de l'entropie. Nous présentons une étude de cas d'une organisation de production de logiciels qui a adopté la méthode de développement agile Evo. Nous expliquons comment le processus agile est affecté négativement par un cas grave d'entropie logicielle et, d'autre part, comment le processus agile renforce ce problème. Sur la base d'un aperçu approfondi de la recherche pertinente, nous discutons de la manière dont cette situation peut être résolue pour libérer le logiciel de l'entropie.e le plein potentiel de l'évolution agile des produits logiciels. 

Papier 696
Incarné Scrum
Résumé : De même qu'il n'est pas nécessaire qu'une fourmi comprenne la théorie des systèmes complexes pour être une bonne fourmi, il n'est pas nécessaire qu'une fourmi comprenne la théorie des systèmes complexes pour être une bonne fourmi.
Le maître de mêlée n'a qu'à comprendre les règles d'un "agent" de mêlée. Mais contrairement à la fourmi, le membre de l'équipe de mêlée a un sens émergent du libre arbitre et de l'agence qui peut rendre difficile l'adoption des règles simples et apparemment arbitraires du processus de mêlée. Une approche pour favoriser l'adhésion à la nature ascendante de scrum est d'enseigner aux maîtres de scrum les principes de base de la théorie des systèmes complexes, illustrant le pouvoir et l'ubiquité de l'auto-organisation, de l'émergence et de l'adaptation. Ce document représente une présentation possible de la théorie des systèmes complexes dans un langage accessible, destiné aux maîtres de mêlée. En outre, il met en évidence la pertinence des pratiques incarnées à la première personne pour développer une interprétation de haute qualité des signaux sensoriels, c'est-à-dire un empirisme radical.

Papier 465
Enterprise Scrum : Mise à l'échelle de Scrum au niveau exécutif 
Résumé : Notre entreprise gère 25 équipes réparties sur 6 produits à l'aide d'un seul Enterprise Scrum de haut en bas. Nous ne connaissons aucune autre entreprise qui procède de la sorte, et pourtant cela permet une visibilité et un contrôle extrêmes au niveau du CXO. Elle encourage la pensée agile à l'échelle de l'entreprise, en incitant les départements autres que ceux de l'ingénierie à adopter Scrum. Nous pensons que cela nous rend plus rentables. Nous estimons l'effort en mois d'équipe, nous organisons des sprints trimestriels, nous affectons des équipes entières à des histoires, nous nous réunissons lors de réunions hebdomadaires, etc. Nous démarrons, reportons ou annulons des projets entiers. Lorsque les priorités s'affrontent, nous décidons souvent en comparant les marges bénéficiaires des projets, c'est-à-dire la valeur actuelle nette par rapport à l'effort. Notre président est l'ultime propriétaire du produit. Au niveau des projets individuels, nous utilisons toujours des sprints de 2 à 4 semaines et tous les éléments du processus classique Scrum. De nouveaux défis se présentent : Le déplacement des équipes entre les projets nécessite une mise en place rapide de l'environnement de construction. Les architectes doivent justifier les projets d'infrastructure par leur valeur nette. Notre processus est devenu plus "léger" pour s'adapter au milieu du trimestre.

Papier 849
Gérer les ruptures dans la recherche constructive : La reconfiguration des méthodes dans le développement de systèmes agiles
Résumé : La recherche constructive requiert un ensemble de compétences et de pratiques différent de celui nécessaire à de nombreux autres types de recherche. Souvent, la construction et le perfectionnement d'un certain artefact informatique se situent en dehors du champ des compétences de base du ou des chercheurs. Afin de réaliser une recherche constructive impliquant l'étude de la construction et de l'utilisation de nouveaux artefacts, il est nécessaire de mettre en place une collaboration entre divers acteurs ayant des intérêts différents. Ce document aborde la nécessité de mieux comprendre comment les développeurs de systèmes devraient travailler afin de contribuer avec succès à la recherche constructive. Étant donné que ce type de recherche vise à développer des connaissances en créant quelque chose qui n'existe pas, il est essentiel de faire preuve de flexibilité et de prendre des mesures progressives dans ce type de processus de développement. Sur la base d'un projet impliquant des chercheurs et des développeurs de systèmes, des moyens de surmonter les échecs dans de tels processus de collaboration sont développés.

Papier 959
Sept dimensions de la maturité agile dans l'entreprise globale : Une étude de cas
Résumé : Les déploiements agiles ont souvent du mal à réussir dans les grandes organisations complexes. Cela est souvent dû à une mauvaise compréhension de la complexité des interdépendances entre de vastes équipes disparates qui existent souvent, ce qui se traduit par des optimisations locales limitées. Comprendre et cartographier la maturité des pratiques des équipes et unités interdépendantes fournit une méthode pour découvrir et supprimer les goulets d'étranglement entre les groupes qui permettent à l'organisation de s'améliorer en permanence. La maturité mise en correspondance avec un super-ensemble de pratiques techniques de style XP et de pratiques de gestion de programme Agile semble fournir un modèle puissant pour améliorer l'efficacité et l'alignement des équipes d'ingénierie interorganisationnelles. Il s'agit d'une étude de cas du modèle développé par BT Design, la division informatique de l'opérateur de télécommunications BT, qui a été mis en œuvre dans des flux de développement comprenant des centaines d'équipes et de composants afin d'améliorer l'agilité de l'organisation.

Papier 971
CAKE : Une solution de gestion des connaissances pour les équipes agiles
Résumé : Le développement de logiciels agiles repose sur une culture de l'abondance qui ne décrit pas toujours les organisations dans lesquelles elle est introduite. Cet article aborde la pénurie d'informations en décrivant un projet récent visant à cartographier les données à travers les niveaux, les systèmes et les domaines organisationnels en développant un outil basé sur le wiki et les processus sociaux qui l'accompagnent. L'ensemble du système de personnes, d'outils et d'informations a été baptisé CAKE pour "Community Authored Knowledge Exchange" (échange de connaissances créé par la communauté) et a été construit sur les principes de la stabilisation par les liens faibles. Ces principes privilégient la durabilité par rapport à l'optimisation, la participation par rapport au contrôle et l'ouverture par rapport à la fermeture, sans jamais perdre de vue la contribution de chaque partie à la solution finale. Parce que ces principes sous-tendent les mêmes liens faibles qui stabilisent les équipes agiles, je pense que l'ensemble CAKE de processus sociaux, d'outils et d'informations peut apporter une réelle valeur ajoutée aux organisations agiles.

Papier 1278
Soutien rigoureux à la planification flexible des lancements de produits - Une approche centrée sur les parties prenantes et sa première évaluation
Résumé : Cet article aborde le problème de la planification de la sortie d'un produit dans le cadre du développement itératif d'un produit. Nous proposons une méthode qui combine le soutien à la décision, au processus et à l'outil. Cette méthode, appelée SCERP, facilite l'implication active des parties prenantes dans les différentes étapes du processus de planification. SCERP est flexible quant au nombre de parties prenantes impliquées, à l'horizon de planification, au nombre et à la définition des critères de planification, et à la sélection du meilleur plan parmi un ensemble d'alternatives optimisées. Une preuve de concept de la méthode est donnée par une étude de cas de la planification des versions pour un outil appelé Agilefant, qui est développé avec un processus partiellement basé sur Scrum. Les avantages de la méthode démontrés par l'étude de cas sont les suivants : (i) de meilleures décisions par le propriétaire du produit en s'appuyant sur des informations plus objectives, (ii) une plus grande transparence des décisions de mise en production, et (iii) un soutien efficace de l'outil accompagnant l'ensemble du processus.

Papier 1277
Vers une documentation allégée des exigences
Résumé : La plupart des processus de gestion des exigences et des outils associés existants sont conçus pour le développement de logiciels guidés par des documents et, par conséquent, il est peu probable qu'ils soient adoptés pour répondre aux besoins d'une équipe de développement de logiciels agiles. Dans cet article, nous examinons comment et ce qui peut faire de la documentation traditionnelle des exigences un processus léger et moins lourd, adapté à l'élicitation des exigences des utilisateurs et au retour d'information. En outre, nous proposons un modèle de référence pour la phase de documentation des exigences et analysons quels types d'outils de documentation des exigences sont nécessaires pour soutenir un processus de développement logiciel agile. Nous présentons également Vixtory, un outil dérivé et utilisé pour la documentation des exigences légères dans les projets de développement d'applications web agiles.

Document 1397
Explorer la nature transitoire des pratiques de gestion de projets agiles
Résumé : Deux grands projets logiciels ont servi de toile de fond à cette recherche. L'un a étudié les processus agiles pour le développement de services urbains intelligents innovants ciblant la convivialité et le retour d'information des utilisateurs, dans une douzaine d'organisations urbaines géographiquement dispersées (principalement en Europe) de compétences et de tailles diverses, qui partageront une part considérable de la technologie du produit et du processus. L'autre projet portait sur les pratiques de gestion agile pour les grands projets distribués avec des délais de mise sur le marché très courts. Dans les deux cas, il était évident que le choix des pratiques de gestion de projet devait dépendre du contexte et des propriétés du système telles que la facilité d'utilisation, le délai de mise sur le marché, le retour d'information. Les pratiques émergentes n'étaient pas définitives. L'article rend compte de notre exploration de la nature transitoire des pratiques de gestion de projet agile.