Discussion :

[zecreator]

Je sais à peine ce que c'est un projet agile hein, non j'ai jamais dev autrement que mes p'tits truc perso et comme j'ai dis j'ai 15 piges. J'en sais pas grand chose, même quasiment rien. Libre à toi de me reprendre si je dis n'importe quoi.

Je dirai, : Ne te laisse pas formatter. Acquière juste ce qu'il ne faut en terme pour passer les entretiens, de toute façon, y a peu de chance que tes collègues en sachent plus que toi. Mais garde ta passion, tente des petits projets sur des technos que ton boss ne maîtrise pas. Deviens indispensable. Une épée. Là où t'es collègues s'arrêteront, tu dois continuer, car c'est toi qui aura raison. Et dis-toi que toute cette énergie, cette connaissance, que certain te diront obsolète, ben en fait, ce sera ta putain de force car tu auras refusé de suivre les dictas et tu auras préféré ta passion, et être fidèle à soi même c'est ce qui il y a de mieux.

[zecreator]

Tain de T9 lol desole

[el_slapper]

Bof. A un moment ou à un autre, il faut concevoir la décision. Avec code ou avec boiboite, ça ne change rien, ça demande à peu près les mêmes qualités cognitives. Ce ne sont plus des codeurs, ce sont des paramétreurs, mais le fonds de leur activité est le même : définir toutes les décisions que le système doit prendre.

Ca peut être un avantage de masquer toujours plus la technique,mais c'est tout. Les non-programmeurs qui font ça, soit ils ont le niveau pour devenir programmeurs, soit ils seront remplaçés par des programmeurs reconvertis.

[viper1094]

Je dirai, : Ne te laisse pas formatter. Acquière juste ce qu'il ne faut en terme pour passer les entretiens, de toute façon, y a peu de chance que tes collègues en sachent plus que toi. Mais garde ta passion, tente des petits projets sur des technos que ton boss ne maîtrise pas. Deviens indispensable. Une épée. Là où t'es collègues s'arrêteront, tu dois continuer, car c'est toi qui aura raison. Et dis-toi que toute cette énergie, cette connaissance, que certain te diront obsolète, ben en fait, ce sera ta putain de force car tu auras refusé de suivre les dictas et tu auras préféré ta passion, et être fidèle à soi même c'est ce qui il y a de mieux.

Merci des conseils, bien que je le sais déjà x).
Par contre faudrait que je pense à me laisser formater un tout 'tit peu, ça fait 2 ans que j'vais quasiment pas en cours ( une fois tous les 6 mois ça compte ?).
Selon la psy du lycée et l'infirmière c'est parce que j'aurais du sauter 3 classes mais que finalement j'en ai sauté qu'une, à cause de problème administratif, et que j'suis thpi donc que je m'intègre pas avec des gens de mon age.
J'espère avoir le courage d'aller en cours l'année prochaine ( normalement on me laissera passer mon bac avant mes 16 ans, ça sera déja ça même si j'aurais du le passer à 13.)
Je note ce que tu m'as dis dans un coin de ma tête, je m'en rappellerai quand je serais 'face à l'adversité' ( c'est pas comme si j'avais pas l'habitude haha).
Bref je raconte un peu ma vie là je crois xD.

[yukihira]

Je veux bien croire que je me vend mal, mais bon, après 24 candidatures, toujours rien....

Je baisse les bras...

Ne te lasse jamais de retravailler ton CV. Il suffit d'un rien pour que les "recruteurs" aient le déclic pour s'intéresser à ton CV: forme générale (disposition, pagination, style), mise en avant de certaines formations (énumérer un peu les cours les plus pertinents) ou de certaines expériences (quelques petits détails sur des responsabilités ou sur des technologies), etc... Et surtout, dis-toi bien que si tu as vraiment confiance en tes valeurs, alors, ce sont les entreprises qui t'ont recalé qui ne te méritaient pas.
A titre d'expérience, je me suis vu recaler (ou n'atteignais même pas le stade de l'entretien) à plusieurs postes auxquels je croyais vraiment avoir des atouts indéniables. Et puis, 2 mois plus tard, et quelques candidatures plus tard (une vingtaine aussi), je me suis vu proposer un super poste avec une rémunération qui excède largement mes prétentions initiales (qui étaient déjà au dessus du marché). J'avais tellement confiance en mes valeurs (ce que je pourrai apporter), et je n'acceptais pas du tout de baisser mes exigences (sur le salaire, les responsabilités, la localisation...) quitte à laisser passer plusieurs offres.
En plus, si tu es encore en poste, tu peux prendre tout ton temps pour trouver chaussures à tes pieds.

[Invité]

C'est quoi un sori y (je dois sans doute connaître le concept, mais pas le terme anglais)?

Aucune idée. Par contre un sprint, c'est en gros la période de temps où l'équipe développe un paquet de fonctionnalités qui donnera lieu à une nouvelle "version" du projet.

De toute façon, qu'elle que soit mon niveau d'expérience, c'est pas ça qui est recherché en entreprise.

J'ai beau mettre en avant des chiffres, des Wins, des références (les gars avec qui j'ai bossé attendent toujours des coup de fil), c'est dead....

Franchement, je ne suis pas RH et je n'ai pas de conseil miracle à te donner. Par contre, je sais que l'agile n'est pas qu'un buzzword, il faut plutôt voir ça comme une façon de s'organiser et des outils correspondants. Ce n'est pas forcément difficile à apprendre ou à mettre en place et ça peut même être assez agréable à utiliser.

[Invité]

Je sais à peine ce que c'est un projet agile hein, non j'ai jamais dev autrement que mes p'tits truc perso et comme j'ai dis j'ai 15 piges. J'en sais pas grand chose, même quasiment rien. Libre à toi de me reprendre si je dis n'importe quoi.

Ah oui, ok. Mais du coup, si tu ne connais pas un truc, ne te sens pas obligé de faire des suppositions, potentiellement irréalistes. Si l'informatique t'intéresse c'est bien mais à mon avis tu ferais mieux de consacrer ton temps à l'apprendre et à la pratiquer vraiment.

[viper1094]

J'ai pas fait des suppositions mais donné mon avis, car comme j'l'ai dit plus haut, je sais ce que sais mais seulement théoriquement. Après, étant donné que j'ai 0xp, mon avis vaut rien, et je l'ai immédiatement dit juste après avoir mon avis
"Mon avis vaut ce qu'il vaut". Et je savais que d'autres gens donnerait leur avis et compléterait ma réponse juste après vu que la discussion est active. Aucune necessité de se montrer condescendant parce que j'ai donné mon opinion, en ayant même fait l'effort de préciser qu'il n'était que l'opinion d'un lycéen qui n'a pas d'exp juste après. Merci

[foetus]

Ce n'est pas forcément difficile à apprendre ou à mettre en place

Perdu

Scrum est une méthode de développement basée sur la gestion de projets - avec quelques documents, une planification des tâches, des réunions quotidiennes, ...
Donc difficile de faire cela tout seul - et c'est d'ailleurs pour cela que les E.S.N.s ne prient que par elle : des documents, des réunions, on peut maîtriser la progression du développement - tout pour rassurer le client.

[viper1094]

Perdu

Scrum est une méthode de développement basée sur la gestion de projets - avec quelques documents, une planification des tâches, des réunions quotidiennes, ...
Donc difficile de faire cela tout seul - et c'est d'ailleurs pour cela que les E.S.N.s ne prient que par elle : des documents, des réunions, on peut maîtriser la progression du développement - tout pour rassurer le client.

Ouais fin en fait, c'est quoi concrètements à part de l'administratif Scrum ? Parce que dans le concret, j'arrive vraiment pas à cerner l'utilité du truc pour le dev lambda.

[el_slapper]

Ouais fin en fait, c'est quoi concrètement à part de l'administratif Scrum ? Parce que dans le concret, j'arrive vraiment pas à cerner l'utilité du truc pour le dev lambda.

Coordonner les développements. Coup vécu récemment au scrum du matin : je dis que j'essaye de tester les écrans de restitution de la compta auxiliaire(je suis testeur, sur ce projet), et soudain, regard embarrassé - ils avaient oublié de développer les écrans d'alimentation. Donc je n'avais pas de données pour tester, puisque je ne pouvais pas en créer - ce qui expliquait pourquoi je pédalais dans la semoule. Les devs ont changé leur fusil d'épaule(et je n'ai pas demandé comment ils ont testé les écrans de restitution, je n'ai pas voulu les mettre dans l'embarras).

Dans un développement en cascade, si le plan initial a oublié un truc de ce genre, on peut perdre des mois. Là, on a perdu que 48 heures. Et ce genre de décalage, dans un projet, arrive tout le temps. Planifier 100% des tâches à faire, c'est usuellement illusoire. D'ou l'utilité d'un regard fréquent et critique sur ce qui se passe, de la part de tout le monde. Sur cet exemple de compta auxiliaire, je ne jette la pierre à personne, ça arrive tout le temps, à tout le monde. Et Scrum(plus généralement, une démarche agile ou on ajuste le plan de manière fort régulière) permet de limiter l'impact négatif(en termes de charge et de délais) de toutes ces petites erreurs ordinaires.

[Xelland]

(Agile ? C'est quoi)

c'est surtout financier (le blabla autour c'est pour faire croire à une amélioration des process; mais dans tous les cas, c'est le pognon a le dernier mot)

tu as l'équipe de dev et l'équipe qui va tester (celle qui demande les dev)


en mode non agile :
l'équipe qui va tester doit attendre la fin de la totalité des dev
donc pendant ce temps, elle doit faire autre chose (souvent pré étude des versions futures), sinon elle est payée à attendre
s'il y a des modifications à apporter, elles sont faites à la fin
l'utilisateur final ne voit les dev qu'à la fin, donc possible méfiance quant à la tenue des délais

en mode agile :
les 2 équipes travaillent presque en même temps
les dev sont découpés en petits bouts et chaque petits bouts est testé au fur et à mesure
s'il y a des modifications à apporter, elles peuvent être faites en cours de dev
donc "gain" de temps (et donc d'argent) au final
l'utilisateur final voit les progrès des dev donc il pense avoir une meilleure vision des délais


mais bon, ça c'est la théorie


et quand on voit les pubs où le mot agile est utilisé (compte épargne, fusil nerf, renault clio, ... )
pour la voiture (et autre produit), du côté acheteur ce n'est pas agile : on a acheté le produit final, on n'a pas pu tester pendant la conception

[Glutinus]

(Agile ? C'est quoi).

Agile, c'est quand ton projet au final est de faire un carré, et qu'en cycle en V on est tellement dans un effet tunnel que ça finit toujours pas faire au mieux un cercle, au pire une "patatoïde".
Du coup on met en place et on engage des personnes pour faire du bon sens : on trace un côté, c'est OK ? on trace un deuxième, perpendiculaire au premier et de longueur pareil. C'est OK ? on continue.
Les spécialistes sont là pour recibler et aller au plus simple, pragmatique, utile et efficace.
Au final le client est très content de garder ce qui l'intéresse (des stand-up meetings quotidiens ? génial ! Mais on va les faire assis, histoire que ça prenne 1h30 au lieu de 10 minutes, et on va dériver).
Le Coach agile est mis de côté parce que dès qu'il met le doigt sur un truc où ça fait mal, le client aime pas, ça grince. Il finit par faire un bore-out.

Le projet devient un patatras pas possible, c'est un projet à l'A-rrache mais le client est très content lorsqu'il recrute des nouveaux devs qui vont bosser 200 jours avant leur première release qu'il bosse en Agile.

C'était clair ? Pas trop...

[zecreator]

Mais comment sont gérés les coûts en Agile, car si le projet n'est jamais fermé, on peut y passer beaucoup de temps et le temps c'est de l'argent comme tout le monde le sait)?

Par rapport à une gestion basée sur des besoins bien définis et un budget fermé, n'est-ce pas au final, donner plus de temps au client et donc avoir une facture plus importante à la livraison ?

[Glutinus]

Mais comment sont gérés les coûts en Agile, car si le projet n'est jamais fermé, on peut y passer beaucoup de temps et le temps c'est de l'argent comme tout le monde le sait)?

Je ne fais pas d'Agile, mais à un moment ou un autre les utilisateurs vont dire "Voilà, c'est ce qu'on veut" ou "Bon, c'est pas parfait mais c'est suffisant".

A l'inverse, tu penses vraiment que te dire de faire un projet à des centaines de milliers d'euros, de jours / hommes etc. en sachant pertinemment qu'à un moment du projet, des développeurs vont se tourner les pouces parce que le serveur n'est toujours pas arrivé, ou qu'on va pousser la livraison en recette et que tous les utilisateurs partent en vacances cette semaine là ?

Pour moi, il y a moins de risque de bosser en Agile, puisqu'on tombe sur tous les écueils du cycle et à force de faire des itérations on améliore le process (le coach agile est là pour ça, théoriquement, il prend la températeur et change le process, d'où l'Agilité...).
Dans un cycle en V classique, t'as un effet tunnel et forcément à la mise en prod tout est en catastrophe, on met des chevilles partout, des solutions temporaires qui deviennent définitives et des fonctionnements de bouts de morceau.

[gangsoleil]

Il y a la théorie, et la réalité -- et en matière d'Agile, il y a absolument de tout.

En théorie, le client est censé être impliqué, et dans ce cas là il y a effectivement des aller-retours avec lui qui permette d'avoir son retour, et d'avancer dans la bonne direction de ce qu'il veut.

En pratique, la relation avec le client reste souvent très formelle, comme "à l'ancienne", et donc il y a un contrat qui dit "vous aurez un logiciel qui fait du café, pour 2 millions d'euro", ce qui se traduit en interne par "vous avez 40 jours pour développer un logiciel qui fait du café, c'est tout ce que j'ai comme specs, démerdez-vous".

Donc comme tu es en agile, tu découpes ça en petites sous-tâches (des story), du genre "il faut un bac pour l'eau" --> trop gros, donc on fait d'abord un bac puis on fera l'étanchéïté dans une 2ème phase, etc...
En itérant ainsi, tu es censé pouvoir mieux avancer, et les problèmes sont vus plus tôt, et donc tu peux les corriger plus vite etc...

Il reste que tu as 40 jours pour le faire, peu importe comment tu le découpes : si tu le fais en 30 jours tu auras en plus une tape dans le dos, si tu le fais en 41 jours tu auras un blame et on te demandera des comptes pendant 37 réunions de 3h chacunes pour savoir pourquoi tu as dépassé de 7h.

[viper1094]

Ouais fin résultat c'est une façon de bosser où on force la communication si elle est pas déjà là à travers des réunions, en théorie. Si on applique au plus proche de la théorie, c'est sympa, sinon ça devient de la merde patatoïde. (J'simplifie volontairement).
Enfin, merci pour vos explications

[gangsoleil]

De mon point de vue, c'est surtout globalement très mal aplliqué.

Une méthodologie, que ce soit Agile (SCRUM, kanban, XP, ou n'importe quelle autre implémentation), Waterfall, cycle en V, n'importe quoi, lorsque tu ne prends que les bouts qui t'intéresse, ça ne donne que très rarement de bons résultats.

Donc oui, il vaut beaucoup mieux un bon chef d'équipe (attention, c'est très rare) qui travaille sans méthodologie formelle plutôt qu'une méthodologie quelconque mal appliquée. Mais ce n'est pas ce qui se passe actuellement, où Agile est clairement à la mode (SCRUM notamment, mais pas que), et donc il faut en faire. À tout prix.

[Invité]

Je rigole quand on me parle de scrum en entrevue : au bout de deux-trois questions de ma part, ça arrive rapidement qu'en fait, on s'inspire de la méthode scrum et que l'on prend juste les bouts qui nous intéressent...
Il y a 20 ans, il fallait être ISO 9002, maintenant, il faut faire être Scrum ! Question de mode...

[Jean-Philippe André]

Des méthodes agiles, la plus bourrine ca reste le RAD (Rapid Application Dev), qui consiste en du dev commando, sans test ou trop peu ^^