DATE ET PRÉVISION D’HEURES DES SPRINTS

Durant la première semaine de ce travail, la rédaction du cahier des charges, les prises de rendez-vous avec le SEMO ainsi qu’avec le responsable du travail ont été effectuées. Les User Stories pour le Product Backlog ont été élaborés afin d’utiliser la méthodologie Agile dans la mise en place du système (voir Annexe I : Product Backlog et Annexe II : Sprint). Le tableau des sprints effectué et leurs temps effectifs sont insérés dans l’Annexe II : Sprints. Plusieurs différences au niveau de la planification des Story Points dans le Product Backlog et des heures effectuées dans les sprints sont apparues. Cela concernait principalement la génération de documents ayant posé plusieurs problèmes et rallongé de manière significative la durée des tâches sur le sprint 3. Pour effectuer ces différentes étapes, il a été défini une liste de sprint avec un certain nombre d’heures prévues. Cette répartition prend en compte les heures de cours des trois premiers sprints et des examens lors du quatrième sprint.

Flux de travail et génération de documents

Lors de la conception de l’application contenant des données spécifiques, il s’est avéré qu’il n’était pas possible de générer les documents via des flux de travail (version 2015). En effet, les documents générés n’étaient pas lisibles ou ne contenaient aucune donnée. Dans un premier temps, un message d’erreur indiquait que des flux SharePoint 2010 n’étaient pas possibles sur SharePoint 365 mais que seuls les flux de travail 2013 étaient autorisés. Cependant, une solution de contournement existe. Malheureusement, celle-ci ne propose que l’utilisation de flux de travail SharePoint 2010 et ne pouvait donc pas être reprise dans la résolution du message d’erreur. La proposition de solution fournie par Samuel Levsque n’a pas fonctionné immédiatement. Plusieurs essais ont été nécessaires avec le logiciel FeatureAdmin2010 pour résoudre le problème. Il semblerait qu’un fichier corrompu ait gêné la création de flux de travail 2010 au niveau de SharePoint Designer. Pour des raisons liée à problème critique ayant persisté durant approximativement une semaine, l’utilisation d’une autre application a été envisagée. Une solution ayant été trouvée, celle-ci a été abandonnée et n’est plus disponible (version d’essai expirée).

Gestion des check-box sur les documents

Une check-box sous Word peut être ajoutée via l’onglet « développeur ». Cependant, l’option permettant de cocher l’élément automatiquement n’est pas disponible dans les propriétés. Lorsque les propriétés sont affectées depuis les informations SharePoint par les composants QuickPart, elles n’ajoutent que l’élément « true » ou « false » en format texte. Il n’est alors pas possible de lier ces informations à la check-box de cette manière. Pour permettre l’automatisation des coches, l’utilisation d’un schéma prédéfini, puis la sélection de la valeur à affecter en tant qu’élément à cocher, comme présenté dans la Figure 31 Mappage XML sous Word 2013, est nécessaire. Dans l’affichage de ce schéma, Word 2013 va lier les propriétés du document (contenant les informations récupérées depuis SharePoint) pour ensuite permettre d’insérer un contrôle de contenu du type désiré. Dans ce cas, il s’agit d’une case à cocher (check-box).

C’est un des points qu’il est important de citer car SharePoint est un outil puissant, très complet, mais comportant beaucoup de « techniques » ou « astuces » à connaitre pour permettre la mise en service d’un site. Les 2 points précédents (6.1 Flux de travail et génération de documents et le point 6.2 Gestion des check-box sur les documents) en sont un bon exemple. Beaucoup de tutoriels sont encore expliqués pour la version 2010 de SharePoint et InfoPath, et seuls quelques sites parlent de la version 2013. Cela laisse beaucoup de place à l’interprétation et nécessite de prendre plus de temps à la recherche et/ou compréhension pour effectuer l’adaptation du système SharePoint 2010 vers la version 2013. De nombreux documents actuellement en fichiers Word peuvent être abandonnés au profit d’une gestion depuis l’interface SharePoint. Pour ce faire, chaque équipe doit, au préalable, faire l’inventaire de tous les documents utiles et de la manière dont le système peut apporter une plus-value à leur travail.

Actuellement, l’ergonomie du système est basée sur une utilisation à petite échelle. Le SEMO n’ayant pas encore utilisé le système en situation réelle, certains affichages et dispositions devront probablement être adaptés au fur et à mesure de l’évolution des données insérées dans le système. Actuellement, peu de filtres ou d’affichages sont prédéfinis. Pour permettre une visualisation plus efficace des informations, une utilisation plus poussée et des évaluations du système par les collaborateurs permettraient au SEMO de définir les filtres d’affichages pertinents pour une visualisation plus précise. Les flux de travail sont actuellement utilisés dans le cadre de la génération de documents. Cependant il serait pertinent d’implémenter des flux de travail suivant les processus BPMN définis lors du travail de Master de M. Kim Vocat (Vocat, 2014) dans le cadre du suivi de jeunes ou d’autres processus de travail. Le SEMO n’ayant pas émis le désir d’effectuer ce travail, ceux- ci n’ont pas été implémentés.