Skriv a 3 mois : la version bêta arrive

Skriv existe depuis maintenant 3 mois, et a rejoint un incubateur en septembre. C’est le moment de vous tenir un peu au courant.

Une copie d’écran pour attiser votre curiosité 😉

Le service est toujours en cours de développement. Beaucoup de travail a été réalisé ; les principaux concepts ont été implémentés et le but est de sortir une version bêta dans le mois à venir.

Maintenant je suis à la recherche de personnes et d’équipes qui souhaitent tester Skriv.
Je vous demande de l’utiliser réellement, sur les projets de votre équipe − pas juste faire un petit test de cinq minutes. Je sais que ça demande une implication forte, et cela doit être récompensé ; en échange de votre aide, vous aurez un accès gratuit et illimité jusqu’à fin 2018, pour vous et votre équipe.

Un rappel de l’intérêt de Skriv par rapport à la concurrence :

  • Skriv est orienté workflow
    La gestion de tâches, ça n’existe pas ; cela revient à jongler entre les tâches. La gestion de projets devrait être meilleure que ça.
  • Skriv rend votre équipe plus productive
    Le travail des chefs de projets n’est pas d’assigner des tâches encore et encore tout au long de la vie des projets. Les intervenants ne devraient pas être ralentis par les tâches administratives de leurs chefs de projets.
  • Skriv est simple d’utilisation
    Je sais, tous les autres logiciels prétendent être faciles à prendre en main. Mais alors pourquoi ressemblent-ils au tableau de bord d’une navette spatiale ?

Si vous voulez participer au bêta-test de Skriv, c’est assez simple :

  1. Envoyez un email à contact@skriv.com pour montrer votre intérêt. Parlez-moi de votre équipe, des types de projets sur lesquels vous travaillez et de comment vous les gérez.
  2. Nous passerons de 15 minutes à une heure ensemble, afin que je vous présente le fonctionnement de Skriv. On peut faire ça par téléphone, mais une rencontre de visu sera plus efficace.
  3. Toutes les semaines, je vous contacterai pour savoir comment les choses se passent. Pendant ce temps, vous pourrez faire des remontées de bogues sur une interface dédiée.

J’espère qu’ensemble nous pourrons créer le meilleur outil de gestion de projets.
Je vous remercie d’avance pour votre temps et votre aide.

Tests unitaires et intégration continue

Je vais vous parler de deux notions qui sont assez connexes, et que certaines personnes ont tendance à mélanger un peu.

Les tests unitaires

Le but des tests unitaires est d’automatiser les tests de non-régression. Quand on développe un logiciel, on peut facilement faire des modifications sans se rendre compte qu’elles introduisent des bugs dans certains cas particuliers. C’est ce qu’on appelle des bugs de régression, en ce sens qu’on introduit de nouveaux bugs à la suite d’une évolution fonctionnelle. Comme il n’est pas humainement possible de tester systématiquement tous les cas d’utilisation possible, ces bugs peuvent se retrouver déployés en production, avec tous les problèmes que cela comporte.

Une des notions importantes, quand on fait du développement, est de savoir que plus un bug est détecté tôt, plus il sera facile à corriger. Les gros soucis arrivent quand on fait du « sur-développement » par-dessus un bug de régression ; il devient très difficile de faire un retour en arrière sur le code incriminé, car cela impliquerait de supprimer des fonctionnalités. Il faut alors corriger ce nouveau code, en essayant de trouver une aiguille dans une botte de foin.

Concrètement, les tests unitaires consistent en un ensemble de scripts, qui ont chacun en charge la validation d’un morceau de code (ou d’une classe si vous faite de la programmation orientée objet). Il est assez évident de tester de la sorte les bibliothèques de fonction : les « librairies » peuvent être vues comme des boîtes noires, avec des entrées et des sorties. Il suffit d’injecter certaines données en entrée, et vérifier la conformité de ce qu’on obtient en sortie.
Pour du code applicatif, c’est un peu plus délicat, car on est parfois obligé de mettre en place un environnement de test sophistiqué (bases de données avec lots de test, génération de données aléatoires, gestion des tentatives de hack, …). Mais bien heureusement il existe de très nombreux frameworks pour vous aider à y arriver ; suivant votre plate-forme de développement, vous pouvez vous intéresser à JUnit (Java), SimpleTest (PHP), CppUnit (C++), JSUnit (Javascript), ASUnit (ActionScript), Test::Unit (Ruby), Test::Unit (Perl), unittest (Python), NUnit (.NET), …

Continuer la lecture de « Tests unitaires et intégration continue »

Le cycle en V

Le cycle en V est une méthode d’organisation très connue dont l’origine remonte à l’industrie et qui a été adaptée à l’informatique dans les années 80. C’est l’une des premières méthodes qu’on apprend à l’école après le cycle en cascade, et elle reste toujours d’actualité.

La grande force du cycle en V, c’est qu’il définit assez précisément la manière dont les choses devraient se passer.

 

On peut y distinguer 3 grandes parties : La phase de conception, la phase de réalisation (codage) et la phase de validation. Les phases de conception et de validation se découpent en plusieurs parties. Chaque étape ne peut être réalisée qu’une fois que l’étape précédente est terminée, ce qui diminue les prises de risque sur le projet.
Ce qui est bien visible sur le diagramme, c’est que chaque étape de conception possède son alter ego de validation. Il devient alors assez aisé de valider un projet, car le référentiel de test est connu très précisément.

Les différentes étapes

Le cycle en V est constitué de 8 étapes qui ont toutes leur importance.

Continuer la lecture de « Le cycle en V »