Et si on n'a pas les gens qui vont bien, on peut mettre en place toutes les méthodes qu'on veut, le résultat ne sera jamais terrible et ça prendra toujours plus longtemps que nécessaire. La clé, c'est de recruter les bonnes personnes pour construire une équipe efficace et qui se complète bien. Le reste, ça va plutôt tout seul.
Entre deux équipes qui sont bien constituées, celle qui met en place (en plus) des méthodes de travail sera probablement meilleure.
Personnellement, un des trucs qui m'a toujours le plus plu dans ce métier (note : on bossait sur des applications métier, pas des sites web),
Je ne sais pas ce que tu entends par "faire des sites web" ; on ne fait pas de sites web, on fait des applications web. On ne peut pas comparer "développer une application métier" et "développer une application web" car il s'agit d'aspects orthogonaux : une appli web, ça parle des technologies, une appli métier de la finalité.
c'est la capacité à découvrir des métiers totalement différents et de s'en imprégner, c'est vraiment super enrichissant et motivant. Et je pense qu'on devrait mettre cela plus en avant.
Je te rejoints totalement, et c'est bien pour ça qu'on développe des applications web et non des sites web.
Notre métier n'est pas de faire du graphisme mais de comprendre les besoins des utilisateurs (professionnels ou pas) et de leur proposer des outils qui résolvent un certain nombre de leurs problèmes.
Deux exemples sur des projets qu'on a fait l'an dernier :
une plateforme de mise en relation entre éditeurs de logiciels et acheteurs. C'est pas notre métier, nous on est réalisateurs. Mais notre client c'est son métier de faire ça, et ce qu'on développe c'est un outil qui répond à ses besoins (il faut donc comprendre son métier)
une plateforme de multidiffusion d'annonces immobilières. C'est pas notre métier de faire de l'immobilier, mais une fois que tu comprends le quotidien des agents immobiliers ciblés, tu comprends rapidement quelle valeur ajoutée tu peux/dois leur proposer.
C'est sûr on fait aussi du graphisme, on construit des écrans "responsive", mais notre différenciateur, ça n'est pas de faire un site beau et qui s'adapte à l'écran de l'utilisateur - ça tu prends n'importe quelle agence web et si tu paies correctement tu es sûr d'avoir un bon résultat ; notre différenciateur c'est d'être capable de comprendre les besoins exprimés et non exprimés et de conseiller et accompagner le client.
Bref, tout ça pour dire qu'on fait bien des applications métier et qu'on est très content de le faire - pour les même raisons que toi :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Réduire les coûts sans se soucier des impacts ou seulement de la qualité, je ne trouve pas que ça soit "naturel".
Personne n'a dit que c'était sans se soucier des impacts. Réduire les coûts c'est naturel, et toute personne qui met en concurrence 2 offres le fait. Qu'il s'agisse de professionnels et de particuliers.
Ca ne veut pas dire ne pas se soucier des impacts ni de la qualité, ça veut juste dire : "si tu peux payer moins cher pour le même produit/service, tu le fais". En tout cas, quand tu achètes, ça entre en ligne de compte.
La question "est-ce que c'est le même service" est une autre question et c'est de la responsabilité des personnes concernées d'expliquer que non ça n'est probablement pas le même service.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire
Pas du tout: c'est justement quand on ne sait pas exactement ce qu'il faut faire qu'il faut réfléchir.
On sait ce qu'on veut à court terme, mais on est en général incapable de savoir ce qu'il faudra avoir dans 1 an ou dans 2 ans. Et dans ces conditions on n'anticipe pas sur la flexibilité à implémenter pour d'hypothétiques fonctionnalités qui pourraient arrivent dans quelques années.
Plus tu réfléchis en début de projet à toutes les problématiques, plus tu retardes la sortie et en particulier la sortie de la v1. Donc plutôt que retarder ta v1 pour "mieux prévoir ta v2, v3 et autre", tu sorts ta v1 au plus vite, et tu capitalise sur l'expérience de ta v1 pour définir ta v2. Et tu vas de proche en proche.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Le point 8 signifie : plus ton code est utilisable/testable par quelqu'un qui ne connait rien à rien de ta pile technologique, mieux c'est.
Si tu fais une appli web avec mongodb, redis, nginx, etc, si tu es capable de donner un outil qui "en un clic ou en une ligne de commande" fait tout le setup et permet à n'importe qui de le tester, c'est du temps gagné car des personnes non compétentes pourront te remonter des bugs (donc tu pourras arriver à un niveau de qualité équivalent en passant toi-même moins de temps à tester)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Dans l'hypothèse où l'on aurait commencé par le développement, puis écrit les tests, outre le fait qu'on prend le taureau par les cornes (on écrit la solution avant d'avoir écrit les spécifications), le risque est d'avoir conçu une solution qui ne va pas répondre à 100% des besoins, ce qui veut dire qu'on doit faire du refactoring ou qu'on accepte une couverture partielle des besoins.
Pour moi tu passe à coté. Ce n'est pas le fait de commencer par l'un ou par l'autre qui va changer quoi que ce soit. C'est le fait ta façon de communiquer avec l'utilisateur/le product owner/le client (appel le comme tu veux) qui va changer cela. Et le TDD n'aide pas vraiment à faire ça. C'est plus le BDD car il va permettre de faire valider les tests par le client (l'objectif théorique étant que ce soit le client qui écrive les tests).
Bah le TDD permet d'écrire la spec (en termes de dév, certes, mais au moins ça définit le fonctionnement). Le BDD est une extension de ça et va plus loin.
Mais globalement ce que j'essaie d'exprimer c'est ce que tu dis (avec probablement un vocabulaire plus modeste sur le sujet;)
le principe est simple : "un module = une responsabilité". Et inversement.
Si le concept est simple son application ne l'est pas vraiment. C'est quoi une responsabilité ? C'est quoi un module ? Une classe ? Une fonction ? Quelle est la granularité de tes responsabilités ? Je pense savoir faire un découpage correct et appliquer des pattern qui vont me permettre de définir les abstractions correctes entre les responsabilités, mais de là à affirmer que je produit quelque chose de bon, je ne m'avancerais pas.
Il n'y a pas de règle pour dire "granularité trop faible" ou "granularité trop importante". Ce qui compte, c'est déjà de se poser la question, et souvent naturellement on va se rendre compte que des composants sont à responsabilité multiple ou responsabilité éclatée.
Et on travaille rarement seul, donc si tu discute sur un module donné, tu vas probablement arriver à un consensus.
Enfin qu'est-ce qu'un module, bah tout dépend du niveau de vision que tu as. Ca peut être une classe, une fonction, un ensemble de classes… tout dépend des technos que tu utilises, mais globalement "plus tes composants peuvent être considérés comme des boîtes noires, mieux c'est".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Souvent les développeurs veulent faire des choses compliquées, et exploiter les fonctionnalités d'un langage au maximum. Mais la réalité c'est qu'un logiciel qui est écrit simplement fonctionne aussi bien qu'un logiciel exploitant toutes les particularités d'un langage.
C'est exact, mais cela néglige complètement l'aspect maintenance (et aussi l'aspect apprentissage). Si une version, en plus d'être plus courte, est plus facile à maintenir, il n'y a aucune raison de ne pas la retenir!
Non justement, l'aspect maintenance est au coeur de cette remarque. Tu ne peux pas présumer du niveau d'expertise du développeur qui fera la maintenance de ton code. Pour caricaturer, si ton code est maintenable par un développeur qui ne connait pas ta techno, c'est une bonne chose.
En python (la techno sur laquelle je travaille beaucoup), il y a des moyens de rendre le code tellement concis que tu es obligé de le lire à voix haute, voire de le réécrire en structure classique pour être sûr de ce qu'il fait (et encore). C'est 3 lignes de code économisées pour un niveau de crainte complètement disproportionné quand tu cherches à comprendre/faire évoluer le code.
Exemple de code trop concis :
msg = "Hi " + ("there" if not name else ("Neo" if name == "Anderson" else name))
(ne ris pas, ça existe ce genre de code;)
(et encore, là c'est pas imbriqué dans des boucles et des set de listes de générateurs;)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Technique n°2 — se limiter strictement au cahier des charges
Parfois, en tant que développeur, on se dit "ah mais si je fais ça de telle manière, ça prend juste quelques jours de plus et ça permet d'avoir un système plus évolutif". Et en général plus complexe, donc plus fragile.
Oui et non, vu que très certainement il va falloir faire la maintenance du logiciel, cela peut être une bonne chose de s'y préparer – avec discernement, mais c'est justement ce discernement que peut apporter l'expérience au travers d'une palette de techniques éprouvées et validées qui résolvent justement ce problème.
D'une manière générale (et je m'inclus dans le lot), la tendance est de sur-anticiper les attentes des futurs développements. Si tu as une bonne couverture de test, tu peux faire du refactoring conséquent en limitant les risques.
Je te rejoins sur le fait que c'est avec l'expérience qu'on est capable de mieux en mieux de déceler ce qu'il serait bon d'anticiper et ce qui ne l'est probablement pas. Sans jamais en être certain.
Disons que si on se limite strictement au cahier des charges de façon la plus littérale qui soit, on peut dans certains cas torcher un programme tout mal fichu “qui fait le job” mais dont les évolutions sont impossibles à partir de 4-5 itérations, et là on se retrouve dans la pire situation, avec un bug en prod et un logiciel tellement mal conçu que réécrire tout ou partie est un a priori nécessaire à la réparation! (Vécu.)
Dans ce contexte, je parles d'un cahier des charges qui vient aussi avec des perspectives d'évolution.
Dans le contexte dans lequel je suis, je prends en compte non seulement les possibilités d'évolution, mais aussi les coûts associés. Et ça, peu de développeur le perçoivent. L'anticipation d'une feature qui viendra peut-être et qui fragilise le code au point que tu passes des plombes à stabiliser c'est un paquet d'argent perdu (ou investi) d'une manière ou d'une autre (et dans le cas où on considère que c'est investi, c'est un investissement avec quel chance d'être rentable ?)
Si tu sens qu'il y a une limitation dans le cahier des charges et que tu penses qu'il faut vraiment anticiper tel ou tel aspect, je te renvoie au point n°1 : en discuter avec le client. Ca ne t'apportera peut-être pas de réponse, mais ce qui est certain c'est que si tu n'en parles pas c'est un pari que tu fais.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Merci pour tes retours, qui m'invitent à leur tour à des remarques
Réduire les coûts sans sacrifier la qualité est évidemment intéressant pour l'entreprise ou le client car :
- soit vous avez la même chose pour un coût inférieur,
- soit vous avez un périmètre fonctionnel plus étendu pour le même prix.
Ce n'est pas totalement vrai. Les plus gros défauts des analyses de coûts que je peux lire sont systématiquement 1. qu'elles font l'hypothèse que l'univers peut être modélisé avec des additions et dans quelques cas extrêmes des multiplications, et 2. qu'elles ne décrivent pas assez soigneusement le système qu'elles étudient. Ici c'est le 2, car lorsque tu as livré ton produit, ton entreprise n'est plus la même! Tu as des développeurs qui ont acquis des connaissances, soit purement techniques, soit plus conceptuelles (techniques de programmation, techniques de génie logiciel, gestion de projet par exemple), par exemple.
Il n'empêche que c'est intéressant pour l'entreprise de pouvoir réduire les coûts pour une qualité équivalente. Ça n'est pas forcément LA solution à retenir (et en tout cas surtout pas la solution à retenir systématiquement). Après il faut savoir faire la distinction entre les cas où c'est à mettre en oeuvre et les cas où c'est à proscrire.
Et je te rejoins sur le fait que certains projets peuvent ne pas être concernés par "une rentabilité optimale en terme de temps de dév". Mais sur certains projets (au hasard, des dév sur des technos vieillissantes et des produits qui sont condamnés), on peut réduire les temps de dév sans "bacler le travail", ce qui permet de consacrer plus de temps à d'autres projets.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Il ne faut surtout pas écrire de script de setup. A moins de vraiment savoir ce qu'il faut faire (et encore) c'est probablement pas quelques heures et probablement un script sur lequel il faudra revenir.
Maintenant sur le besoin je suis parfaitement d'accord. Mais il ne faut surtout pas réinventer la roue. Utiliser ansible, chef, puppet ou, celui que je préfère, terraform. Du Terraform, une ou plusieurs machines sous CoreOS, des containers et ça en devient juste super agréable tout ça pour un coût limité, une très bonne répétabilité et un démarrage rapide.
Si certains veulent essayer voici un exemple qui montre par exemple comment faire tourner facilement un ElasticSearch en container sur un CoreOS via Terraform. C'est un exemple comme un autre mais je trouve qu'il montre plutôt bien l'intérêt de ces solutions.
Mettre au point un déploiement ansible/chef/puppet juste pour permettre à quelqu'un de faire un test, c'est clairement pas un gain de temps court-terme.
Un "script" tu mets ce que tu veux dedans - l'idée c'est que tu as en quelques heures un outil qui permet à n'importe qui de setup son environnement sans rien connaitre. Si tu veux mettre un docker derrière, CoreOS via terraform ou n'importe quoi, peu importe : ça dépend des compétences que tu as et des outils que tu connais.
Mais ce qui compte c'est que tu sois capable de fournir à un testeur, à un chef de projet, à un admin sys ou à n'importe qui une solution du type "tu lances cette commande et tu as l'appli dispo à telle adresse et configurée avec les données de base".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
De manière plus générale, tu essaie de vendre l'idée que la qualité c'est simple, que ça ne prend pas de temps, etc et je ne te rejoins pas du tout là dessus.
Ce n'est pas du tout ce que je dis. Ce que je dis, c'est que pour un développement donné, tu peux souvent gagner en temps de travail sans réduire la qualité en mettant en oeuvre une certaine méthodologie
Je me cite : "Les stratégies 1 et 2 sont moins couteuses que la 3, mais la qualité est partiellement sacrifiée et le niveau de finition également en faveur d'un temps de développement réduit (à court terme)"
Faire de la qualité c'est compliqué, sinon tout le monde le ferais. Non seulement c'est compliqué, mais en plus c'est long à mettre en place.
On est d'accord :)
C'est un mensonge de commercial d'affirmer qu'on peut faire de la qualité en un minimum de temps à coût 0.
Personne ici n'a dit ça. Le seul truc que j'ai dit c'est que tu peux réduire ton temps de développement sans forcément perdre en qualité, je n'ai à aucun moment dit "tu peux faire du haut-de-gamme au prix du low-cost".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Je ne trouve pas du tout évident que la méthode 3 soit la plus coûteuse ou la plus lente. Partir sur un projet sans architecture et sans conception (en supposant que le projet soit assez simple pour le permettre) maximise les coûts très rapidement à cause du nombre de choses à faire et refaire, du nombre de bugs ou des mauvaises performances.
Si tu considères uniquement le temps de travail technique (développement, tests, conception, etc), la technique 3 est la plus économique. Mais cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire (si techniquement ce n'est pas un problème, c'est souvent un problème en terme de parts de marché)
Les techniques 1 et 2 sont les plus rapides pour arriver à un périmètre fonctionnel donné, ce qui permet rapidement :
de valider ou d'invalider des hypothèses,
dans le cas où on commercialise, de rentrer de l'argent et prendre des parts de marché.
Le time-to-market est un élément très important à prendre en compte, et dans ce contexte, plus tôt tu as un produit commercialisable (même si limite techniquement), plus tôt tu acquiers des clients, des parts de marché, donc également de la légitimité. Il faut bien voir l'économie comme une compétition et en particulier le monde des startups est féroce.
Pour ceux qui connaisent des jeux tels que starcraft, il y a une stratégie quand tu as les Zergs qui est d'aller tuer dans l'oeuf tes ennemis car en début de partie les Zergs ont un moment où ils sont en supériorité pour une durée donnée. C'est exactement la même chose avec les startups : faire un produit qui est sur le marché le plus vite possible va largement compliquer la vie des concurrents et donc conforter la place de leader du premier arrivé - et donc paradoxalement faire un produit un peu pourri techniquement pour arriver le premier est le meilleur gage de pérennité.
Par exemple le module pour integrer piwik est a plus de trente balle
30 balles ? Tu parles de faire du ecommerce et 30€ ça te bloque ? Je suis curieux de voir ton business plan.
(alors que c'est un truc ultra simple et que je parie que leur sonde n'est meme pas compatible cross canal (lan, wan, tor)).
Si c'est simple, je comprends pas pourquoi tu t'emm… à regarder les plugins au lieu de le faire toi-même.
En plus des modules proprio, voila quoi… > (Je prefere le systeme de bounty*1 d'autres cms)
*1 un site ou tu fais une annonce genre "j'ai besoin de telle fonctionnalité je met 50, 100, 200 euro" et le premier qui la code empoche le bounty et la fonctionnalité reste libre
Tu parles de faire du commerce… C'est du business.. Aucun pro ne développe sérieusement des fonctionnalités pour 50€.
Je suis curieux de savoir quel est ton métier et combien tu gagnes de l'heure.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
certains marchands ont des configurateurs en ligne pour associé Carte mere/proc/ram qui sont le plus difficile à gerer.
ensuite SSD, carte video, carte son, ce sont des accessoires à mettre dans la machine, pour la compatiblité video/son, il faut fouiller sur le net.
Demande au support commercial materiel.net. ils taident à faire des choix, par mail, et sont sérieux et compétents. J'achète quasi tout mon matos pro chez eux
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Le principe de la politique n'est-il pas d'organiser la société ? Peut-on parler d'organisation si le pouvoir est entre les mains de court-termistes ? Dans ces conditions, si le système actuel n'est pas en mesure de favoriser le pouvoir des gens qui "réfléchissent" ou qui ont une vision long terme, c'est peut-être que le système politique est inadapté, non ?
Personnellement, plus le temps passe et plus je me dis que la démocratie n'est pas adaptée car basé sur la séduction (des électeurs) donc ça finit tôt ou tard de manière court-termiste.
Pour faire un parallèle avec le monde économique, c'est un peu comme la gestion d'une entreprise cotée en bourse ou une entreprise familiale. Les investisseurs (les électeurs) veulent des résultats à court terme, là où une direction "plus forte" peut faire des sacrifices à court terme pour un meilleur rendu à long terme.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Si les "non populistes" n'ont pas compris les techniques qui fonctionnent, il serait temps qu'ils les comprennent. Si ils les ont comprises, pourquoi ne les appliquent-ils pas ?
(merci de ne pas répondre "parce que ça ne se fait pas" ou "parce que ça n'est pas éthique" : ils sont exceptionnels ceux qui ne font rien qui ne soit pas éthique/moral/légal/raisonnable… et il ne sont quasiment jamais dans la course à la présidentielle)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Et pour répondre à ta question :
Un système de "validité" de l'annonce devrait être mis en place, par envoi de mail à la personne qui à publiée l'annonce.
Chaque semaine par exemple, si pas de réponse … re mail au bout de 4 jours puis 2 jours puis fin de l'annonce
A condition que l'interface soit sécurisée et ergonomique et que cela ne dure que quelques secondes.
En fait on ne publie pas directement d'annonces sur pyjobs : c'est un agrégateur, donc on ne peut pas contacter l'annonceur
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Suite au commentaire de Pol'Ux ci-dessus, question à ceux d'entre vous qui cherchent un taff (de manière passive ou active) :
vous préférez louper des opportunités ou avoir du bruit dans les annonces que vous identifiez ?
à partir de quel "vieillesse" vous considérez qu'une annonce est "morte". Exemple : une annonce qui a 1 an n'est très probablement plus pertinente, une annonce qui a une semaine est probablement encore pertinente… mais où situez-vous le seuil ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Le sujet que tu soulèves c'est le fait d'accepter des faux-positifs ou d'accepter des faux-négatifs. Intégrer Pôle Emploi ou de ne pas l'intégrer, c'est exactement la même question.
Par exemple, si tu cherches sur Grenoble et jusqu'à 25km aujourd'hui, tu as une annonce pour un développeur ERP Python (boite : Objectif PI) qui est une vraie annonce (et que tu trouves a priori seulement sur Pole Emploi et sur Developpez.com)
Est-ce qu'on veut louper ce type d'annonce ? Je dirais que non.
Est-ce qu'il n'y a pas moyen d'améliorer les choses par rapport au cas que tu remontes ? C'est certain qu'il y a matière. Par exemple en proposant une fonctionnalité de signalement d'une annonce erronée / invalide.
Je pense qu'un dév qui cherche du boulot préfère avoir du bruit que de louper une bonne opportunité (en tout cas c'est comme ça que je réagissais à l'époque où je cherchais) ; je peux me tromper, ça ne me me pose pas de problème :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Je te rejoins sur le fait que j’ai des collègues qui ne mettront pas de commentaire à cause de l’élitisme… c’est dommage, il vaut mieux se tromper et apprendre quelque chose que de se taire.
La question posée est de savoir comment avoir plus de contributions, pas de savoir si les gens ont raison de se réagir comme ils réagissent :-)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Un collaborateur que j'ai embauché en janvier dernier a écrit un journal sur son simulateur de fourmies qui a reçu un accueil vraiment très bon. Pourquoi il l'a écrit ? Parce que je l'ai "tanné" ; il doutait de la bonne perception par le public et peur du "linchage". Le pb c'est que :
si tu écrits un truc qui a bonne presse, tu veux que ton identité numérique y soit associée
si ton article n'a pas bonne presse tu aimes autant ne plus y être associé.
Dans le doute, tu t'abstiens.
Est-ce qu'il ne faudrait pas un mécanisme pour pouvoir écrire en anonyme mais se le réattribuer en cas de succès ? Genre une sorte de double identité et qu'on puisse basculer un article / un journal de l'une à l'autre.
Un des freins, également c'est l’âpreté des discussions dans les commentaires. C'est un frein également (après, j'avoue que je ne sais pas trop comment on pourrait faire pour "limiter" ça)
Un aspect plus global, à mon avis, c'est que le contenu de LinuxFR n'est plus tant "linuxfr" que "logicielslibresfr" voire "informatiquelibrefr" (dont musique, électronique, openhardware, business, etc). Peut-être que l'identité de LinuxFR devrait évoluer ?
Par ailleurs je pense comme dit plus haut que des news courtes devraient faire leur apparition. Dans un journal comme le dauphiné libéré (exemple pris parce que je suis de ce coin là du monde;), il y a des articles détaillés, des articles intermédiaires et des faits divers. On torche le truc, ceux qui aiment lisent, ceux qui n'aiment pas ne lisent pas.
Chacun devrait pouvoir proposer des dépêches longues ou courtes (une dépêche n'étant pas un journal qui est plutôt un "vis ma vie").
Ces idées n'engagent que moi et celles/ceux qui y croient :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Les gens.
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
Entre deux équipes qui sont bien constituées, celle qui met en place (en plus) des méthodes de travail sera probablement meilleure.
Je ne sais pas ce que tu entends par "faire des sites web" ; on ne fait pas de sites web, on fait des applications web. On ne peut pas comparer "développer une application métier" et "développer une application web" car il s'agit d'aspects orthogonaux : une appli web, ça parle des technologies, une appli métier de la finalité.
Je te rejoints totalement, et c'est bien pour ça qu'on développe des applications web et non des sites web.
Notre métier n'est pas de faire du graphisme mais de comprendre les besoins des utilisateurs (professionnels ou pas) et de leur proposer des outils qui résolvent un certain nombre de leurs problèmes.
Deux exemples sur des projets qu'on a fait l'an dernier :
C'est sûr on fait aussi du graphisme, on construit des écrans "responsive", mais notre différenciateur, ça n'est pas de faire un site beau et qui s'adapte à l'écran de l'utilisateur - ça tu prends n'importe quelle agence web et si tu paies correctement tu es sûr d'avoir un bon résultat ; notre différenciateur c'est d'être capable de comprendre les besoins exprimés et non exprimés et de conseiller et accompagner le client.
Bref, tout ça pour dire qu'on fait bien des applications métier et qu'on est très content de le faire - pour les même raisons que toi :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pas pour moi
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
Personne n'a dit que c'était sans se soucier des impacts. Réduire les coûts c'est naturel, et toute personne qui met en concurrence 2 offres le fait. Qu'il s'agisse de professionnels et de particuliers.
Ca ne veut pas dire ne pas se soucier des impacts ni de la qualité, ça veut juste dire : "si tu peux payer moins cher pour le même produit/service, tu le fais". En tout cas, quand tu achètes, ça entre en ligne de compte.
La question "est-ce que c'est le même service" est une autre question et c'est de la responsabilité des personnes concernées d'expliquer que non ça n'est probablement pas le même service.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pas évident
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 2.
On sait ce qu'on veut à court terme, mais on est en général incapable de savoir ce qu'il faudra avoir dans 1 an ou dans 2 ans. Et dans ces conditions on n'anticipe pas sur la flexibilité à implémenter pour d'hypothétiques fonctionnalités qui pourraient arrivent dans quelques années.
Plus tu réfléchis en début de projet à toutes les problématiques, plus tu retardes la sortie et en particulier la sortie de la v1. Donc plutôt que retarder ta v1 pour "mieux prévoir ta v2, v3 et autre", tu sorts ta v1 au plus vite, et tu capitalise sur l'expérience de ta v1 pour définir ta v2. Et tu vas de proche en proche.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: script de setup d'un environnement fonctionnel
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 10.
Le point 8 signifie : plus ton code est utilisable/testable par quelqu'un qui ne connait rien à rien de ta pile technologique, mieux c'est.
Si tu fais une appli web avec mongodb, redis, nginx, etc, si tu es capable de donner un outil qui "en un clic ou en une ligne de commande" fait tout le setup et permet à n'importe qui de le tester, c'est du temps gagné car des personnes non compétentes pourront te remonter des bugs (donc tu pourras arriver à un niveau de qualité équivalent en passant toi-même moins de temps à tester)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pleins de remarques
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 2.
Bah le TDD permet d'écrire la spec (en termes de dév, certes, mais au moins ça définit le fonctionnement). Le BDD est une extension de ça et va plus loin.
Mais globalement ce que j'essaie d'exprimer c'est ce que tu dis (avec probablement un vocabulaire plus modeste sur le sujet;)
Il n'y a pas de règle pour dire "granularité trop faible" ou "granularité trop importante". Ce qui compte, c'est déjà de se poser la question, et souvent naturellement on va se rendre compte que des composants sont à responsabilité multiple ou responsabilité éclatée.
Et on travaille rarement seul, donc si tu discute sur un module donné, tu vas probablement arriver à un consensus.
Enfin qu'est-ce qu'un module, bah tout dépend du niveau de vision que tu as. Ca peut être une classe, une fonction, un ensemble de classes… tout dépend des technos que tu utilises, mais globalement "plus tes composants peuvent être considérés comme des boîtes noires, mieux c'est".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Hypothèse fondamentale discutable
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
Non justement, l'aspect maintenance est au coeur de cette remarque. Tu ne peux pas présumer du niveau d'expertise du développeur qui fera la maintenance de ton code. Pour caricaturer, si ton code est maintenable par un développeur qui ne connait pas ta techno, c'est une bonne chose.
En python (la techno sur laquelle je travaille beaucoup), il y a des moyens de rendre le code tellement concis que tu es obligé de le lire à voix haute, voire de le réécrire en structure classique pour être sûr de ce qu'il fait (et encore). C'est 3 lignes de code économisées pour un niveau de crainte complètement disproportionné quand tu cherches à comprendre/faire évoluer le code.
Exemple de code trop concis :
msg = "Hi " + ("there" if not name else ("Neo" if name == "Anderson" else name))(ne ris pas, ça existe ce genre de code;)
(et encore, là c'est pas imbriqué dans des boucles et des set de listes de générateurs;)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Hypothèse fondamentale discutable
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
D'une manière générale (et je m'inclus dans le lot), la tendance est de sur-anticiper les attentes des futurs développements. Si tu as une bonne couverture de test, tu peux faire du refactoring conséquent en limitant les risques.
Je te rejoins sur le fait que c'est avec l'expérience qu'on est capable de mieux en mieux de déceler ce qu'il serait bon d'anticiper et ce qui ne l'est probablement pas. Sans jamais en être certain.
Dans ce contexte, je parles d'un cahier des charges qui vient aussi avec des perspectives d'évolution.
Dans le contexte dans lequel je suis, je prends en compte non seulement les possibilités d'évolution, mais aussi les coûts associés. Et ça, peu de développeur le perçoivent. L'anticipation d'une feature qui viendra peut-être et qui fragilise le code au point que tu passes des plombes à stabiliser c'est un paquet d'argent perdu (ou investi) d'une manière ou d'une autre (et dans le cas où on considère que c'est investi, c'est un investissement avec quel chance d'être rentable ?)
Si tu sens qu'il y a une limitation dans le cahier des charges et que tu penses qu'il faut vraiment anticiper tel ou tel aspect, je te renvoie au point n°1 : en discuter avec le client. Ca ne t'apportera peut-être pas de réponse, mais ce qui est certain c'est que si tu n'en parles pas c'est un pari que tu fais.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Hypothèse fondamentale discutable
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 1.
Merci pour tes retours, qui m'invitent à leur tour à des remarques
Il n'empêche que c'est intéressant pour l'entreprise de pouvoir réduire les coûts pour une qualité équivalente. Ça n'est pas forcément LA solution à retenir (et en tout cas surtout pas la solution à retenir systématiquement). Après il faut savoir faire la distinction entre les cas où c'est à mettre en oeuvre et les cas où c'est à proscrire.
Et je te rejoins sur le fait que certains projets peuvent ne pas être concernés par "une rentabilité optimale en terme de temps de dév". Mais sur certains projets (au hasard, des dév sur des technos vieillissantes et des produits qui sont condamnés), on peut réduire les temps de dév sans "bacler le travail", ce qui permet de consacrer plus de temps à d'autres projets.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: script de setup d'un environnement fonctionnel
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 4.
Mettre au point un déploiement ansible/chef/puppet juste pour permettre à quelqu'un de faire un test, c'est clairement pas un gain de temps court-terme.
Un "script" tu mets ce que tu veux dedans - l'idée c'est que tu as en quelques heures un outil qui permet à n'importe qui de setup son environnement sans rien connaitre. Si tu veux mettre un docker derrière, CoreOS via terraform ou n'importe quoi, peu importe : ça dépend des compétences que tu as et des outils que tu connais.
Mais ce qui compte c'est que tu sois capable de fournir à un testeur, à un chef de projet, à un admin sys ou à n'importe qui une solution du type "tu lances cette commande et tu as l'appli dispo à telle adresse et configurée avec les données de base".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pleins de remarques
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 6.
Ce n'est pas du tout ce que je dis. Ce que je dis, c'est que pour un développement donné, tu peux souvent gagner en temps de travail sans réduire la qualité en mettant en oeuvre une certaine méthodologie
Je me cite : "Les stratégies 1 et 2 sont moins couteuses que la 3, mais la qualité est partiellement sacrifiée et le niveau de finition également en faveur d'un temps de développement réduit (à court terme)"
On est d'accord :)
Personne ici n'a dit ça. Le seul truc que j'ai dit c'est que tu peux réduire ton temps de développement sans forcément perdre en qualité, je n'ai à aucun moment dit "tu peux faire du haut-de-gamme au prix du low-cost".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pas évident
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 8.
Si tu considères uniquement le temps de travail technique (développement, tests, conception, etc), la technique 3 est la plus économique. Mais cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire (si techniquement ce n'est pas un problème, c'est souvent un problème en terme de parts de marché)
Les techniques 1 et 2 sont les plus rapides pour arriver à un périmètre fonctionnel donné, ce qui permet rapidement :
Le time-to-market est un élément très important à prendre en compte, et dans ce contexte, plus tôt tu as un produit commercialisable (même si limite techniquement), plus tôt tu acquiers des clients, des parts de marché, donc également de la légitimité. Il faut bien voir l'économie comme une compétition et en particulier le monde des startups est féroce.
Pour ceux qui connaisent des jeux tels que starcraft, il y a une stratégie quand tu as les Zergs qui est d'aller tuer dans l'oeuf tes ennemis car en début de partie les Zergs ont un moment où ils sont en supériorité pour une durée donnée. C'est exactement la même chose avec les startups : faire un produit qui est sur le marché le plus vite possible va largement compliquer la vie des concurrents et donc conforter la place de leader du premier arrivé - et donc paradoxalement faire un produit un peu pourri techniquement pour arriver le premier est le meilleur gage de pérennité.
Cette explication est assez simpliste, mais c'est la réalité (alors bien sûr l'enjeu est aussi en général de lever des fonds mais à fonds levés égaux, celui qui prendra le premier la place sur un marché sera souvent celui qui survit. Je t'invite à lire l'article suivant : http://www.newyorker.com/tech/elements/in-silicon-valley-now-its-almost-always-winner-takes-all
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: En bas ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Empêcher Libreoffice de masquer/afficher les barres d'outil de manière intempestive. Évalué à 2.
Je voudrais éviter une config spécifique à cette application - sur toutes les autres les barres d'outils sont en haut.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pas anormal
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Que pensez-vous du comportement de Prestashop?. Évalué à 2.
30 balles ? Tu parles de faire du ecommerce et 30€ ça te bloque ? Je suis curieux de voir ton business plan.
Si c'est simple, je comprends pas pourquoi tu t'emm… à regarder les plugins au lieu de le faire toi-même.
Tu parles de faire du commerce… C'est du business.. Aucun pro ne développe sérieusement des fonctionnalités pour 50€.
Je suis curieux de savoir quel est ton métier et combien tu gagnes de l'heure.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: lolix-v2
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Lolix down ?. Évalué à 8.
Dans une phase de creux de mon activité, j'avais contacté Rodolphe pour proposer de contribuer à prix coûtant. Je n'avais eu aucune réponse.
Ca m'avait du coup "un peu" blasé d'avoir contribué financièrement…
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Autre "avantage" que j'ai oublié de mentionner...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Stage de fin d'étude en pré-embauche - développeur backend python/go sur Grenoble. Évalué à 2.
On est abonné aux magazines des éditions Diamond : Linux Magazine France, Linux Pratique, Misc et Hackable.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: des pistes
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message De nomade à sédentaire, je cherche un PC à tout faire!. Évalué à 2.
Demande au support commercial materiel.net. ils taident à faire des choix, par mail, et sont sérieux et compétents. J'achète quasi tout mon matos pro chez eux
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# celery + rabbitmq
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Réagir à des données expirées (date) en DB. Évalué à 5.
A la creation de ton événement, tu ajoutes une tache dans rabbitmq qui devra s'exécuter à la date d'expiration.
Ca marche bien, c'est fait pour ça, et celery/rabbitmq s'intègre très bien dans django.
J'ai mis en place ces technos pour envoi/expiration automatique de notifications.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: La vraie victoire...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Élections américaines. Évalué à 2.
Le principe de la politique n'est-il pas d'organiser la société ? Peut-on parler d'organisation si le pouvoir est entre les mains de court-termistes ? Dans ces conditions, si le système actuel n'est pas en mesure de favoriser le pouvoir des gens qui "réfléchissent" ou qui ont une vision long terme, c'est peut-être que le système politique est inadapté, non ?
Personnellement, plus le temps passe et plus je me dis que la démocratie n'est pas adaptée car basé sur la séduction (des électeurs) donc ça finit tôt ou tard de manière court-termiste.
Pour faire un parallèle avec le monde économique, c'est un peu comme la gestion d'une entreprise cotée en bourse ou une entreprise familiale. Les investisseurs (les électeurs) veulent des résultats à court terme, là où une direction "plus forte" peut faire des sacrifices à court terme pour un meilleur rendu à long terme.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: La vraie victoire...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Élections américaines. Évalué à 2.
Si les "non populistes" n'ont pas compris les techniques qui fonctionnent, il serait temps qu'ils les comprennent. Si ils les ont comprises, pourquoi ne les appliquent-ils pas ?
(merci de ne pas répondre "parce que ça ne se fait pas" ou "parce que ça n'est pas éthique" : ils sont exceptionnels ceux qui ne font rien qui ne soit pas éthique/moral/légal/raisonnable… et il ne sont quasiment jamais dans la course à la présidentielle)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Commentaire à destination des personnes qui cherchent du boulot
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal pyjobs - améliorer l'écosystème professionnel francophone python. Évalué à 4.
Pyjobs intègre un annuaire de sociétés (il faut le remplir… en mode collaboratif en partie) ; effectivement faire le lien est une bonne idée :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Commentaire à destination des personnes qui cherchent du boulot
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal pyjobs - améliorer l'écosystème professionnel francophone python. Évalué à 3.
En fait on ne publie pas directement d'annonces sur pyjobs : c'est un agrégateur, donc on ne peut pas contacter l'annonceur
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Commentaire à destination des personnes qui cherchent du boulot
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal pyjobs - améliorer l'écosystème professionnel francophone python. Évalué à 4.
Suite au commentaire de Pol'Ux ci-dessus, question à ceux d'entre vous qui cherchent un taff (de manière passive ou active) :
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Sympa, mais ...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal pyjobs - améliorer l'écosystème professionnel francophone python. Évalué à 4.
Le sujet que tu soulèves c'est le fait d'accepter des faux-positifs ou d'accepter des faux-négatifs. Intégrer Pôle Emploi ou de ne pas l'intégrer, c'est exactement la même question.
Par exemple, si tu cherches sur Grenoble et jusqu'à 25km aujourd'hui, tu as une annonce pour un développeur ERP Python (boite : Objectif PI) qui est une vraie annonce (et que tu trouves a priori seulement sur Pole Emploi et sur Developpez.com)
Est-ce qu'on veut louper ce type d'annonce ? Je dirais que non.
Est-ce qu'il n'y a pas moyen d'améliorer les choses par rapport au cas que tu remontes ? C'est certain qu'il y a matière. Par exemple en proposant une fonctionnalité de signalement d'une annonce erronée / invalide.
Je pense qu'un dév qui cherche du boulot préfère avoir du bruit que de louper une bonne opportunité (en tout cas c'est comme ça que je réagissais à l'époque où je cherchais) ; je peux me tromper, ça ne me me pose pas de problème :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Le haut niveau d'exigence effraie...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à 5.
La question posée est de savoir comment avoir plus de contributions, pas de savoir si les gens ont raison de se réagir comme ils réagissent :-)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Le haut niveau d'exigence effraie...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à 10.
Un collaborateur que j'ai embauché en janvier dernier a écrit un journal sur son simulateur de fourmies qui a reçu un accueil vraiment très bon. Pourquoi il l'a écrit ? Parce que je l'ai "tanné" ; il doutait de la bonne perception par le public et peur du "linchage". Le pb c'est que :
Dans le doute, tu t'abstiens.
Est-ce qu'il ne faudrait pas un mécanisme pour pouvoir écrire en anonyme mais se le réattribuer en cas de succès ? Genre une sorte de double identité et qu'on puisse basculer un article / un journal de l'une à l'autre.
Un des freins, également c'est l’âpreté des discussions dans les commentaires. C'est un frein également (après, j'avoue que je ne sais pas trop comment on pourrait faire pour "limiter" ça)
Un aspect plus global, à mon avis, c'est que le contenu de LinuxFR n'est plus tant "linuxfr" que "logicielslibresfr" voire "informatiquelibrefr" (dont musique, électronique, openhardware, business, etc). Peut-être que l'identité de LinuxFR devrait évoluer ?
Par ailleurs je pense comme dit plus haut que des news courtes devraient faire leur apparition. Dans un journal comme le dauphiné libéré (exemple pris parce que je suis de ce coin là du monde;), il y a des articles détaillés, des articles intermédiaires et des faits divers. On torche le truc, ceux qui aiment lisent, ceux qui n'aiment pas ne lisent pas.
Chacun devrait pouvoir proposer des dépêches longues ou courtes (une dépêche n'étant pas un journal qui est plutôt un "vis ma vie").
Ces idées n'engagent que moi et celles/ceux qui y croient :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo