Déjà que je suis limite un compulsif de la vérif de mail quand je suis derrière mon PC. Si en plus, je pouvais vérifier ça tout le temps, dès le réveil, ça deviendrait infernal...
Et puis, c'est vrai qu'attendre 5 min en faisant son café le matin, ou le temps d'aller aux chiottes, c'est vraiment trop'orible.
@+
Chron
[HOTLINE TECHNIQUE]
-
Tsuka
- Admin / Maniac
- Messages : 36504
- Enregistré le : sam. 20 avr. 2002, 4:07
- Localisation : Chez Bobby
Chron > Ben moi ça me fait clairement gagner du temps, et c'est plus économique (de plus quand on a un pc pas très véloce et pas très silencieux, ça fait vraiment gâchis de lancer tout ça pour checker des mails).
Il m'arrive même souvent de checker encore dans mon lit, après avoir éteint l'alarme, hop Opéra Mini, Gmail Mobile, Netvibes Mobile, le tout lancé et survolé en 2min, après j'ai plus qu'a me lever et me préparer.
D'autant plus que mon café je le prends sur la terrasse avec ma clope, donc là aussi je gagne du temps (car sinon c'est le dilemme café devant pc sans clope ou sur terrasse avec clope ><).
Bref tout dépend des usages et habitudes de chacun.
Et de son obsession d'optimiser son temps
Klaim > hé hé ! moi c'est un truc que j'ai jamais réussi a faire, laisser tourner mes pc en permanence ... je sais pas, toujours peur que ça crame quand je suis pas là ...
Il m'arrive même souvent de checker encore dans mon lit, après avoir éteint l'alarme, hop Opéra Mini, Gmail Mobile, Netvibes Mobile, le tout lancé et survolé en 2min, après j'ai plus qu'a me lever et me préparer.
D'autant plus que mon café je le prends sur la terrasse avec ma clope, donc là aussi je gagne du temps (car sinon c'est le dilemme café devant pc sans clope ou sur terrasse avec clope ><).
Bref tout dépend des usages et habitudes de chacun.
Et de son obsession d'optimiser son temps
Klaim > hé hé ! moi c'est un truc que j'ai jamais réussi a faire, laisser tourner mes pc en permanence ... je sais pas, toujours peur que ça crame quand je suis pas là ...
-
patrouchef
- Grenouille enragée
- Messages : 11285
- Enregistré le : mar. 09 juil. 2002, 23:24
- Localisation : Jardin des Hinata
- Contact :
-
cry
- Beau Booty
- Messages : 1541
- Enregistré le : mar. 25 févr. 2003, 17:37
- Localisation : 59
- Contact :
+2!patrouchef a écrit :"hé hé ! moi c'est un truc que j'ai jamais réussi a faire, laisser tourner mes pc en permanence ... je sais pas, toujours peur que ça crame quand je suis pas là ..."
+1
Mon blog: http://cryhouse.blogspot.com
Les chats sont les fils de Babylone.
Les chats sont les fils de Babylone.
-
Klaim
- Artisan Digital
- Messages : 10635
- Enregistré le : mar. 27 mai 2003, 13:13
- Localisation : Paris
- Contact :
Ha mais non on s'est mal compris, j'ai pas parlé de pc qui tourne en permanence...Klaim > hé hé ! moi c'est un truc que j'ai jamais réussi a faire, laisser tourner mes pc en permanence ... je sais pas, toujours peur que ça crame quand je suis pas là ...
Bon ya mon serveur mais je dors pas dans la même pièce et je m'en sert pas pour surfer ou autre.
Mais de toutes façons je triche, je sors quasimment toujours avec mon laptop.
-
jem
- CyberPet
- Messages : 5037
- Enregistré le : mar. 14 oct. 2003, 5:57
- Localisation : les collines gersoises
Question pour les développeurs :
J'aimerais mettre en place pour mon taf un système de suivi de bug qui fasse aussi base de connaissance pour l'équipe support.
Ce qui serait important c'est un bon moteur de recherche pour retrouver ce qu'on a déjà fait face à tel ou tel problème.
Le plus connu est BugZilla, on m'a conseillé Mantis, je ne connais aucun des deux.
Des idées ?
J'aimerais mettre en place pour mon taf un système de suivi de bug qui fasse aussi base de connaissance pour l'équipe support.
Ce qui serait important c'est un bon moteur de recherche pour retrouver ce qu'on a déjà fait face à tel ou tel problème.
Le plus connu est BugZilla, on m'a conseillé Mantis, je ne connais aucun des deux.
Des idées ?
I found my freedom now.
Funny how it feels just like being alone...
Funny how it feels just like being alone...
-
cry
- Beau Booty
- Messages : 1541
- Enregistré le : mar. 25 févr. 2003, 17:37
- Localisation : 59
- Contact :
J'ai déja utilisé Mantis mais pas Bugzilla, je peux pas trop t'aider donc 
Par contre Mantis ne m'as pas laissé de souvenir impérissable.
Par contre Mantis ne m'as pas laissé de souvenir impérissable.
Mon blog: http://cryhouse.blogspot.com
Les chats sont les fils de Babylone.
Les chats sont les fils de Babylone.
-
Klaim
- Artisan Digital
- Messages : 10635
- Enregistré le : mar. 27 mai 2003, 13:13
- Localisation : Paris
- Contact :
Yes j'en connais un bout sur la question et le premier critère de choix est : serait-ce sur un hebergement mutualisé (et donc limité aux application web style php) ou sur un serveur dont tu as le controle?
Dans le permier cas Mantis est le meilleur, point barre. C'est pas l'idéal de par les limitations qu'imposent un hebergement mutualisé, mais c'est largement suffisant pour la plupart des projets pas trop gros.
Dans le second cas, ton choix et plus large.
Bugzilla est une bonne référence, le plus "experimenté" je dirais.
Ses principaux défauts : d'abord comme c'est une application totalement concentrée sur le traitement de bugs, c'est pas simple de faire de la liaison automatique avec d'autres outils comme Subversion ou un wiki etc.
Sinon l'autre gros souci c'est que l'interface est loin d'être user friendly (j'ai pas vu de version depuis environ un an mais je pense pas que ça ai beaucoup changé) surtout si les utilisateurs n'ont pas de baggage technique ce qui est souvent le cas.
Alors pour palier a ce problème tu as la possibilité de désigner quelqu'un qui sait utiliser bugzilla pour récupérer les bugs (par exemple dans des mails, sur un forum etc) et les entrer lui même dans le bugzilla. MAis bon ça fais une couche intermédiaire pas forcément adequate. Je dirais que c'est selon le projet.
L'autre très bonne alternative c'est TRAC : http://trac.edgewall.org
En gros ça fais la même chose que Bugzilla, mais en plus user friendly, tout basé sur python, très facile a customiser et surtout lie les informations entre les tickets, les révisions de SVN, les pages de wiki etc.
C'est une sorte de grosse fusion. C'est ce qu'on utilise dans mon boulot et c'est ce que j'utilise sur mon serveur perso.
Le seul souci avec Trac c'est qu'il y a des features qui ne sont pas encore implémentées et qui dans certains cas sont pourtant totalement nécessaires.
Par exemple la gestion de plusieurs projets n'est pas mise d'office. Tu peux le faire toi même facilement en ayant des environnement différents selon les projets, et donc des url différentes pour chaque projet. Ya juste a lier les url au bon projet.
L'autre feature manquante c'est les relations entre les tickets, par exemple des dépendances du genre si tu veux valider le ticket/bug A, il faut d'abord avoir fermé les tickets/bug B, C et D.
Ya des plugins très simples a installé de dispo qui font ça. En même temps c'est pas sur que t'en ai besoin.
Dans le liens d'au dessus ya un boutton "roadmap" qui t'indique ce qu'il y a de prévu venir. La version en RC1 actuelle est très bien au passage.
Un truc vraiment excellent avec TRAC c'est qu'il t'ajoutes des liens automatiquement dans tous les textes où il repère des références a tes tickets (par exemple si je fais #214 il va faire un liens autour de ce bout de texte, vers la page décrivant le ticket 214), mais aussi les révisions SVN (avec un lien vers une page indiquant le commentaire du svn et les modifications effectuées dans les sources) et les pages du wiki intégré (qui peut donc te servir de doc interne au projet).
En gros ça permet d'avoir très facilement des recoupement d'informations entre tickets, page wiki, revision svn etc.
Mais attention, quel que soit l'outil que tu vas l'utiliser, il va falloir d'abord que tu réfléchisse éxactement aux processus que tu vas mettre en place pour gérer tickets/bugs. Je parle de comment est organisé ton équipe, qui est responsable de qui, quel est le cheminement de tes tickets, de quels etats vers quels etats etc. C'est fondamental, car sans ça tu te retrouveras avec un outil inutilisable car il refletera l'absence d'organisation clair.
Donc une fois que cette organisation est claire, tu as juste a parametrer ton outil( par exemlpe dans le trac ya les workflow dans la dernière version, qui te permettent de décrire la vie d'un ticket et qui est essentiel pour l'organisation de l'ensemble). Et a ce moment là seulemetn ça deviens vraiment utile.
Autrement, il y a des solution encore plus balaises, mais elles sont payantes, donc je sais pas si ça t'interesse.
Dans le permier cas Mantis est le meilleur, point barre. C'est pas l'idéal de par les limitations qu'imposent un hebergement mutualisé, mais c'est largement suffisant pour la plupart des projets pas trop gros.
Dans le second cas, ton choix et plus large.
Bugzilla est une bonne référence, le plus "experimenté" je dirais.
Ses principaux défauts : d'abord comme c'est une application totalement concentrée sur le traitement de bugs, c'est pas simple de faire de la liaison automatique avec d'autres outils comme Subversion ou un wiki etc.
Sinon l'autre gros souci c'est que l'interface est loin d'être user friendly (j'ai pas vu de version depuis environ un an mais je pense pas que ça ai beaucoup changé) surtout si les utilisateurs n'ont pas de baggage technique ce qui est souvent le cas.
Alors pour palier a ce problème tu as la possibilité de désigner quelqu'un qui sait utiliser bugzilla pour récupérer les bugs (par exemple dans des mails, sur un forum etc) et les entrer lui même dans le bugzilla. MAis bon ça fais une couche intermédiaire pas forcément adequate. Je dirais que c'est selon le projet.
L'autre très bonne alternative c'est TRAC : http://trac.edgewall.org
En gros ça fais la même chose que Bugzilla, mais en plus user friendly, tout basé sur python, très facile a customiser et surtout lie les informations entre les tickets, les révisions de SVN, les pages de wiki etc.
C'est une sorte de grosse fusion. C'est ce qu'on utilise dans mon boulot et c'est ce que j'utilise sur mon serveur perso.
Le seul souci avec Trac c'est qu'il y a des features qui ne sont pas encore implémentées et qui dans certains cas sont pourtant totalement nécessaires.
Par exemple la gestion de plusieurs projets n'est pas mise d'office. Tu peux le faire toi même facilement en ayant des environnement différents selon les projets, et donc des url différentes pour chaque projet. Ya juste a lier les url au bon projet.
L'autre feature manquante c'est les relations entre les tickets, par exemple des dépendances du genre si tu veux valider le ticket/bug A, il faut d'abord avoir fermé les tickets/bug B, C et D.
Ya des plugins très simples a installé de dispo qui font ça. En même temps c'est pas sur que t'en ai besoin.
Dans le liens d'au dessus ya un boutton "roadmap" qui t'indique ce qu'il y a de prévu venir. La version en RC1 actuelle est très bien au passage.
Un truc vraiment excellent avec TRAC c'est qu'il t'ajoutes des liens automatiquement dans tous les textes où il repère des références a tes tickets (par exemple si je fais #214 il va faire un liens autour de ce bout de texte, vers la page décrivant le ticket 214), mais aussi les révisions SVN (avec un lien vers une page indiquant le commentaire du svn et les modifications effectuées dans les sources) et les pages du wiki intégré (qui peut donc te servir de doc interne au projet).
En gros ça permet d'avoir très facilement des recoupement d'informations entre tickets, page wiki, revision svn etc.
Mais attention, quel que soit l'outil que tu vas l'utiliser, il va falloir d'abord que tu réfléchisse éxactement aux processus que tu vas mettre en place pour gérer tickets/bugs. Je parle de comment est organisé ton équipe, qui est responsable de qui, quel est le cheminement de tes tickets, de quels etats vers quels etats etc. C'est fondamental, car sans ça tu te retrouveras avec un outil inutilisable car il refletera l'absence d'organisation clair.
Donc une fois que cette organisation est claire, tu as juste a parametrer ton outil( par exemlpe dans le trac ya les workflow dans la dernière version, qui te permettent de décrire la vie d'un ticket et qui est essentiel pour l'organisation de l'ensemble). Et a ce moment là seulemetn ça deviens vraiment utile.
Autrement, il y a des solution encore plus balaises, mais elles sont payantes, donc je sais pas si ça t'interesse.
-
jem
- CyberPet
- Messages : 5037
- Enregistré le : mar. 14 oct. 2003, 5:57
- Localisation : les collines gersoises
Klaim> L'organisation de l'équipe, c'est assez simple :
Au niveau DEV on est ~1.15, potentiellement 1 de plus d'ici la fin de l'année.
Au niveau SUPPORT, ils sont ~2.5 dont 1 nouveau qui doit tout apprendre sur les produits, et potentiellement 1 autre bientôt.
Les produits sont installés chez ~150 clients, agriculteurs pour la plupart, qui ont souvent les même problèmes.
L'idée est simplement de réduire le plus possible les fois ou un mec du support vient me voir pour répéter une énième fois le workaround d'un bug.
Donc mettre en place une base de connaissance des bugs, de leur workaround ou de la version qui les corrige.
Pour la correction des bug, on fait souvent ca en live au moment de la détection et pour les évolutions on les liste dans un fichier excel, mais il y en a assez peu pour que ca reste gérable.
Pour la gestion de source, on utilise CVS.
Donc en gros tout le côté gestion de la pile des bugs, de l'affectation aux devs, de la gestion du temps passé etc... on en a pas besoin.
Au niveau plateforme, je veut un truc qui puisse s'installer sur le Windows Server 2003 qui ronronne à côté de moi dans le bureau.
En cherchant je suis tombé sur Trac qui a l'air pas mal mais très orienté *NIX, et par ailleurs c'est un peu con qu'il n'offre pas de compatibilité avec CVS. En fait pour CVS il y a CVSTRac mais c'est beaucoup moins joli : http://www.cvstrac.org/
Sinon je me tate pour BugTracker.NET http://ifdefined.com/bugtrackernet.html qui a l'air petit et simple quoique pas super folichon non plus.
Et Mantis, j'ai pas encore regardé.
Au niveau DEV on est ~1.15, potentiellement 1 de plus d'ici la fin de l'année.
Au niveau SUPPORT, ils sont ~2.5 dont 1 nouveau qui doit tout apprendre sur les produits, et potentiellement 1 autre bientôt.
Les produits sont installés chez ~150 clients, agriculteurs pour la plupart, qui ont souvent les même problèmes.
L'idée est simplement de réduire le plus possible les fois ou un mec du support vient me voir pour répéter une énième fois le workaround d'un bug.
Donc mettre en place une base de connaissance des bugs, de leur workaround ou de la version qui les corrige.
Pour la correction des bug, on fait souvent ca en live au moment de la détection et pour les évolutions on les liste dans un fichier excel, mais il y en a assez peu pour que ca reste gérable.
Pour la gestion de source, on utilise CVS.
Donc en gros tout le côté gestion de la pile des bugs, de l'affectation aux devs, de la gestion du temps passé etc... on en a pas besoin.
Au niveau plateforme, je veut un truc qui puisse s'installer sur le Windows Server 2003 qui ronronne à côté de moi dans le bureau.
En cherchant je suis tombé sur Trac qui a l'air pas mal mais très orienté *NIX, et par ailleurs c'est un peu con qu'il n'offre pas de compatibilité avec CVS. En fait pour CVS il y a CVSTRac mais c'est beaucoup moins joli : http://www.cvstrac.org/
Sinon je me tate pour BugTracker.NET http://ifdefined.com/bugtrackernet.html qui a l'air petit et simple quoique pas super folichon non plus.
Et Mantis, j'ai pas encore regardé.
I found my freedom now.
Funny how it feels just like being alone...
Funny how it feels just like being alone...
