Reprise du message précédent :

En fait, ce que je fais, c'est, dans le planning prévisionnel, une tâche bugfix/dev de  travail fixe au moment de la validation. Et ensuite, lors du suivi, j'ajuste le travail réel en remplaçant cette tâche par les bugs au fur et à mesure.

Parce qu'il est très souvent relou, et je suspecte qu'il doit lui-même rendre des comptes. Mais globalement, je me suis fait allumer parce que je ne tenais pas les plannings à jour. J'avais grossièrement sous-estimé le temps que cela me prendrait. Quand à la liste des bugs corrigés, il peut l'avoir à tout moment et la MOA la tient à jour. L'intérêt de les lister dans le planning est en effet discutable. Enfin ça le serait si on pouvait discuter avec lui.
Par contre, il y a bien dans le planning toutes les évolutions prévues jusqu'à la fin de l'année. Détaillées en sous-tâches dev/test u/intégration par sous-composant, comme monsieur l'a demandé...
J'en suis à environ 800 tâches.

gfive/jubi : nodejs en entreprise : http://dejanglozic.com/2014/03/24/ [...] e-why-not/

ça marche sous safari (à part le bug de layout à l'ouverture)
 
( https://github.com/nodebox/opentype.js/pull/22 pour les curieux )

Oh shit
Et dans 1 mois ce sera déjà faux, pas par incompétence mais parce que ça peut pas marcher.

je suivrais les tickets à part, dans un outil de tiketing qui permet de tracer le temps passé (ils doivent tous le permettre je pense), et du coup je ne trackerai qu'une macro tache :
- ça te fait 1 item projet, pas 200
- via des extracts de l'outil de ticketing, tu peux donner tout le reporting que tu veux...un bon vieux Mantis peut faire l'affaire
 

800 c'est pas bon, t'en a à mon avis 2-4x trop...
c'est quoi la taille de l'équipe projet ? quel est le work moyen par tache ? Est-ce que toutes tes taches ont des livrables identifiés ?
 
si ton chef veut rendre compte de la progression, y'a des méthodes qui t'obligent pas à découper en taches hyper fines. Tu peux t'inspirer du Earn Value Management : http://en.wikipedia.org/wiki/Earned_value_management, avec la méthode des 50% (en gros tu considères une tache comme non commencée tant qu'elle est à moins de 50% de competion, et finie dès qu'elle dépasse 50% pour calculer la Earned Value, et les index CPI et SPI). C'est une méthode très simple qui permet de reporter rapidement si tu es en retard / en avance par rapport à ton planning et à ton budget.
 

je pense que le progiciel vs home made, ça suit des cycles. Je pense aussi qu'on approche de la fin d'un cycle "progiciel", et typiquement si on devait partir sur du home made, node.js pourrait etre un choix possible.
il me semble aussi que le mobile a brouillé les lignes, en obligeant les boites à avoir de fait plusieurs technos dans leur stack. Après ça reste vrai pour du front, je pense qu'on restera sur des grosses technos "éprouvées" pour le back (pour être franc j'irais pas faire un système financier avec node + mangoDB par ex, ou faut aimer se faire mal)
 
La grande force de node c'est de reposer sur une techno qui peut déjà être disponible dans un boite (on a des front dev chez nous qui sont fluent en JS, et tous les devs ont une base).

Franchement avec un bon avocat, il doit y avoir moyen de faire condamner la SNCF

Il y a aussi un changement de mode de fonctionnement : des serveur lean, qui ne gèrent que l'authent, l'accès aux données et la persistance + des front de plus en plus riches, adaptés aux différents format. le retour du client serveur

http://www.koreus.com/video/the-expert.html

J'ai déjà vécu cette réunion

Vu dans les toilettes du bar: Boobies > Jesus
 
Y a pas a dire, Le quartier de MIT c est la classe

entre 2 attentats, c'est pas mal

La liberté de religion, oui !!!
 
 Ça et le bourbon. J ai. Beaucoup appris sur cette fabuleuse boisson, je deviens un petit expert local sur le whisky, scotch, rye et autre bourbon

Côté serveur, on n'y pense pas pour le moment: trop d'existence, des trucs vieux à continuer de faire marcher,  une plate forme stable relativement simple à faire évoluer....Et côté client, pour le moment le JS est envisagé seulement pour les applis mobiles.

Pourquoi ? C'est pas parce qu'il est de 42 que le décret n'est plus valable...
 
En plus l'article ne dit pas tout : le gamin avait pas le casque sur les oreilles mais "autour du cou", en gros il écoutait booba a fond en faisant chier le monde autour, et il a insulté le mec de la SNCF qui lui a demandé de la boucler.

Sans compter que ça change tout le temps.

Ouais, on utilise Bugzilla, et il sait faire ça aussi.
On a toutes les demandes de modif dedans, que ce soit bugs ou évolutions. Si je me limitais à un enhancement request = 1 ligne dans project (avec éventuellement quelques sous-tâches pour les grosses évolutions), ça réduirait déjà considérablement la taille du planning. Là, je fais du micromanagement qui n'apporte presque rien.

7 devs, l'allocation des tâches entre eux est sympathique. Le work par tâche de développement varie grosso modo entre 10 et 25j-h (c'est du C++). J'ai deux autres projets plus réduits, mais ils posent moins de pb.

Je ne connaissais pas. Ce que je fais, c'est non commencé tant qu'on n'a pas atteint 50%, et terminé seulement quand le bug est passé à résolu.

On en fait aussi en Web, mais via GWT. Le choix à été fait il y a 6 ans, donc on a beaucoup d'existence, d'une part et beaucoup de contraintes d'intégration que GWT résoudre nativement, sur lesquelles in aurait beaucoup de boulot pour les reimplementer en JS.

A la fois, je comprends la démarche ( ne pas toucher à un truc qui marche), mais une approche type github avec certaines pages qui sont adaptées sous mobile (parceque ça a un sens en terme de fonctionnalité par exemple) et les autres qui restent optimisée pour grands écran est pas mal aussi, et évite de devoir maintenir plusieurs version en parallèle.
 
Sauf si tu veux partir sur du natif ( ou pltôt du web encapsulé dans une appli native ) ou tu vas forcement avoir un peu plus de dfférence dans ton code et ton UI

pour prendre le train tout les jours, la plupart du temps il suffit de demander de baisser

De toute façon, tu vas ré implémenter les fonctionnalités pour le site mobile, non?
Et ca peut se faire très progressivement, en ajoutant , côté serveur une API à côté du GWt, puis en recodant en vrai JS la fonctionnalité.

Les problématiques que tu cites sont gérées par l'intégration, ce qui donne 3 camps :
- les systèmes fronts, qui consomment les données et la logique métier du back (chez nous c'est l'e-commerce, le mobile, les systèmes boutique, etc
- l'intégration, qui expose les services provenant de x systèmes back. Il y a aussi quelques petits services offerts directement par cette couche, genre geoloc, etc...
- les systèmes back, qui sont maître sur certaines données + logique métier.

Je vois bien node sur la première couche, et pour les services légers de la deuxième, mais pas trop pour le back

Y'a aussi une grosse mode du "connecteur", vendu par les progiciels / gros langages, ie le fait d'avoir des connecteurs natifs vers d'autres technos. Je présume que Node en a moins (par ex je doute qu'il y ait un connecteur natif SAP CRM).
Mais bon, après avoir creusé on s'est fait baisé à chaque fois (SAP - Hybris, Oracle - ATG, CQ5 - Hybris, etc) donc un architecte avec des couilles devrait arriver à expliquer que c'est pas un critère de choix

D'une part, l'article donne l'impression de l'utilisation arbitraire d'un décret (mais l'article prend plutôt le parti du gamin).
 
D'autre part, on pourrait prouver que le décret n'a plus été appliqué depuis longtemps et du coup serait abusive. Je passerai sur le fait que le décret date de Paris sous l'Occupation
 
Maintenant si ça s'est passé comme tu le dis (ce qui m'étonnerait pas, remarque), alors je veux bien qu'on aille jusqu'à le pendre par les couilles, ce petit con

Les applis mobiles n'ont pas les mêmes fonctionnalités que les applis Web desktop. Pour plein de raisons (taille des écrans, complexité du métier, immobilisme des clients, intégration avec des.applis client lourd, avec partage de contexte...)
Bref, on a mis du temps à avoir une stack Web qui marche et qui fait à peu près tout ce qu'on veut, nos clients ont des cycles longs....donc on n'en changera pas simplement pour aller sur une technologie qui n'est pas fondamentalement différente.

Par contre, on peut profiter du mobile, ou les applis seront plus petite, ou les clients n'ont rien pour le moment, et où on n'aura pas besoin de faire collaborer les applis avec des vieux bousins en c++ pour voir ce que donne cette techno.

On est d'accord, d'autant plus que node encaisse bien la gestion de services qui ont parfois des temps de réponses longs, du fait de son côté non bloquant. Je pense  aussi que c'est là ou il apportera une plus value : sur le reste , le gain en perf/fonctionnalité ne vaudra pas la prise de risque.
De mon point de vue, le système front va de plus en plus être côté navigateur, avec des applis riches.

Ca ferai converger vers un système
back ( métier, entreprisy, avec du oracle du sap , ..) <-> couche d'intégration ( node , reactphp, java léger) <-> client riche web , éventuellement encapsulé dans une app (IOS, android ,...)

Au niveau ecosystème, c'est clair que node est super récent. Même si il se construit vite, en capitalisant sur l'expertise acquise par ses prédécesseurs (java, .net) ou par les efforts de normalisation ( je pense par exemple a CMIS qui permet d'acceder facilement à la majeure partie des ECM)

Je connais *un peu* les différences , et j'ai bien précsié que seuls certains écrans  peuvent/doivent  être portées sur mobile

Et puis le mobile , ca veut tout dire et rien dire : le tablettes sont de quel côté ? mobile ou desktop ? et les phablets ?

'tain y'a pas moyen d'avoir les résultats partiels des élections ?

En résumé, si j'ai bien suivi, la gauche s'est pris une branlée et Ayrault s'accroche à son siège.

tu en as pas mal là : http://elections.interieur.gouv.fr/MN2014/

c'est bon merci, en fait sur les site des mairies on les trouve.

http://odieuxconnard.wordpress.com [...] olitiques/

Ca tacle dur (et juste)

je crois aussi que personne veut prendre son siège

Je suis sur que s'il le proposait à Ségolène...

 
Nan, mais quand je disais que c'est pas les mêmes fonctionnalités, c'est plus large que "certains écrans", et c'est pas du portage.
 
Les applis mobiles ne seront pratiquement que des choses qu'on ne propose pas (ou sur client lourd) pour le moment. Y'a quelques trucs qu'on récupère du web, mais finalement pas tant que ça.
 
Sinon, "le mobile", c'est tablettes et téléphones.
 
Pour le moment, on est centrés sur des applis au pied du patient (exemple : avoir les constantes médicales dans le temps, et les prises de médocs correspondantes. Mais pour le moment, il n'est pas encore question d'y mettre la prescription. Parce que le moteur d'aide à la prescription est un machin super chelou, avec une UI type ligne de commande Donc sur mobile ça le fait moyen tant qu'on a ça  
 
 

a noter que ca s'applique aussi ( et srutout) aux emploi de seconde main : directeur de cabinet, Directeur Général des Service, ....
Ils sont souvent en dispo, ou en détachement et après les élections apf ils reviennent dans leur collectivité d'origine
 
C'est comme ça que mon petit frère a eu un prof d'histoire qui a été adjoint à la mairie de Roanne.

Mon ancien maire, qui occupait ce poste depuis 18 ans, était auparavant prof d'histoire dans un lycée. Ce qui lui avait permis de se présenter comme un "spécialiste de l'éducation" pendant les débats sur la réforme des rythmes scolaires.

Chaude soirée à l'UMP en réaction aux victoires aux municipales :
 

Et après elle se représenterait aux présidentielles

Plop les experts,

Je souhaiterais mettre en place un catalogue des données de référence dans ma société afin de pouvoir les enrichir avec des données complémentaires que l'on ne retrouve pas dans nos outils.

Exemple: Notre ERP gère la production mais les fiches produits ne sont pas assez flexible pour permettre d'y associer toutes les informations dont on a besoin pour des machines-outils spécifiques.

La partie DataWarehouse avec un processus ETL est déjà outillée par contre je souhaiterais pouvoir mettre ce catalogue à disposition des utilisateurs sans avoir à faire programmer des interfaces CRUD à chaque fois que l'on rajoute des informations.

Est-ce quelqu'un aurait déjà été confronté à ce genre de problématique ? Si oui, comment l'avez-vous résolue ?

(J'ai en tête le concept de liste dans Sharepoint qui permet aux utilisateurs de facilement manipuler de l'information au travers de tableur et de formulaire)

Bin si tu utilises des cubes de données, ça s'interface bien avec Excel. Après je maîtrise pas le bouzin, mais ça doit pouvoir résoudre certains de tes problèmes.

Ce n'est pas de la BI que je souhaite faire mais juste une base de données de référence pour certaines informations. Le mot clé c'est MDM (master data management) mais je suis noyé dans les solutions et la plupart me semble être des usines à gaz avec l'ETL intégré ce dont je n'ai pas besoin.