[Retour | Afficher cette page en format imprimable]
Page soumise par manu - [Note : 5.00 (1 votes) | Noter ça !]
Introduction
Après trois années de développement autour de SQLManagerX, notre équipe a souhaité effectuer un travail autocritique sur son mode de fonctionnement actuel. Le résultat de cette analyse est présenté dans ce document. Le but de celui-ci n’est pas de refaire un historique du projet SQLManagerX mais vraiment de faire un état des lieux et de se donner une vision du projet à un an.
Etat des lieux SQLManagerX
SQLManagerX est actuellement en Version 5-RC (ReleaseCandidate). Le projet est compatible avec un nombre assez conséquent de bases (MySQL, PostgreSQL, Oracle, FireBird, SQLite, ADO).
L’équipe projet est composée de 3 personnes :
- Frédéric Emprin,
- Daniel Vauterin,
Les activités s’articulent autour de 3 pôles :
- Développement de DLL,
- Développement de classes WinDev dites classes d’accès et de leur imbrication dans la classe mère SQLManagerX,
- Amélioration constante de la classe mère SQLManagerX (revue de code, optimisation, réutilisation).
Introduction du concept découvert
Plutôt que de faire du plagiat, je vous conseille fortement la lecture du document de Regis Medina : "L’Extreme Programming".
Je vous cite les principaux éléments du fonctionnement de l’Extreme Programming (repris dudit document)
- Cycles itératifs pilotés par le client : Le projet progresse au rythme d’itérations très courtes, dont le contenu fonctionnel est déterminé par le client.
- Travail d’équipe auto-organisé : L'équipe travaille réellement... en équipe. Les développeurs organisent eux-mêmes leur travail, interviennent sur l’ensemble du code, travaillent systématiquement en binômes, et synchronisent leurs développements plusieurs fois par jour.
- Programmation pilotée par les tests : Les développeurs écrivent des tests automatiques pour chaque portion de code qu’ils conçoivent, et ils s’appuient sur ces tests pour affiner et améliorer sans cesse la conception de l’application sans craindre de régression.
En quoi SQLManagerX gère l’XP ?
Ci-dessous un tableau reprenant les principaux points présentés dans le document de Regis Medina. On pourra remarquer que même sans connaître l’XP, nous avons réussi à en exploiter certains de ses principes ! Ceci à notre grand bonheur.
|
Pilotage du projet |
|
|
Le rôle de « client XP » |
Notre client c'est vous : l'utilisateur développeur mais aussi nous. Nous sommes donc dans certains cas juge et partie. |
|
La phase initiale d'exploration |
La phase initiale de SQLManagerX ne concernait que la base MySQL. Le périmètre était donc faible et la phase initiale a donc été très courte. |
|
Planification du projet |
La planification projet n'existe pas en tant que telle. Nous priorisons cependant les évolutions. |
|
Première mise en production |
Elle date maintenant… et le projet à changé de nom. |
|
Livraisons suivantes |
A chaque demande utilisateur ou remontée d'anomalie, l'équipe tente de répondre dans de délais brefs. C'est le versionning rapide. Un autre versionning interne prévoit des mises en place de nouveautés fréquemment. |
|
Suivi du projet |
C'est un des points sur lequel nous nous devons de progresser. Sauf que pour vous fournir de nouvelles fonctionnalités il nous faudrait un retour plus soutenu de la part de la communauté utilisatrice. |
|
Tests de recette automatiques |
SQLManagerX V4 a permis de créer une méthode TestAll. Cette méthode reprend toutes les méthodes des classes d'accès utiles à SQLManagerX. Ceci à de multiples avantages :
- Toute nouvelle classe d'accès connaît donc les méthodes minimales pour être compatible SQLManagerX.
- TestAll fournit le résultat attendu. Donc on sait si le comportement de la classe candidate est correct.
- En cas de modification de la classe d'accès, on peut facilement tester la régression éventuelle de celle-ci.
|
Travail d'équipe auto-organisé |
|
Définition et partage des tâches |
Les tachées sont parfaitement connues de l'équipe de développement, chacun ayant sont domaine de prédilection (DLL, WinDev, Documentation utilisateur). |
|
Responsabilité collective du code |
L'équipe entière s'attache au bon fonctionnement de l'ensemble des classes qui vous sont fournies. |
|
Travail en binômes |
Chaque évolution ou idée est présentée aux deux autres. Si cette idée se confirme, l'instigateur la développe et la soumet aux deux autres. C'est ainsi que nos nouvelles fonctionnalités naissent d'un commun accord global. |
|
Stand-up meetings |
La technologie de nos jours permet une communication accrue. Nous utilisons allègrement le forum spécifique SQLManagerX pour évoquer l'état d'avancement des travaux de chacun (pas tous jours néanmoins). |
|
Le rôle du coach |
Nous sommes 3 coachs. |
|
Règles de codage et métaphore |
En imposant un nommage des méthodes dans les classes d'accès on s'assure d'une uniformisation des développements |
|
Intégration continue |
A chaque petite évolution ou correction le projet est mis à jour. |
|
Rythme durable |
Trois ans déjà … |
|
Programmation pilotée par les tests |
|
|
Mise en place intensive de tests unitaires |
La période où vous effectuiez nos tests unitaires est révolue. Les tests de non régression sur les classes existantes sont en place. La création d'un nouvel accès n'est effective que lorsque ce qui est mis à disposition fonctionne. |
|
Remaniement du code |
SQLManagerX étant en open source, les sources peuvent être modifiés, retravaillés par tout développeur. Toute aide est la bienvenue. |
|
Conception simple |
Même si l'architecture SQLManagerX semble complexe elle est cependant abordable : une classe mère qui encapsule des classes d'accès qui communiquent avec une base de données au travers d'une DLL. | |
[Retour | Afficher cette page en format imprimable]
Page soumise par manu - [Note : 5.00 (1 votes) | Noter ça !]
