Difference between revisions of "MethodoProject/Fr"
From TuxFamilyFAQ
Jump to navigationJump to search(17 intermediate revisions by the same user not shown) | |||
Line 19: | Line 19: | ||
** (ni [http://fr.wikipedia.org/wiki/Principe_de_Dilbert celui de Dilbert]) | ** (ni [http://fr.wikipedia.org/wiki/Principe_de_Dilbert celui de Dilbert]) | ||
** même si la [http://fr.wikipedia.org/wiki/Loi_de_Parkinson loi de Parkinson nous touche] surtout [http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality celle sur la trivialité] (oui aussi appelée, bikeshedding) | ** même si la [http://fr.wikipedia.org/wiki/Loi_de_Parkinson loi de Parkinson nous touche] surtout [http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality celle sur la trivialité] (oui aussi appelée, bikeshedding) | ||
+ | ** jamais [http://www.commitstrip.com/en/2014/10/31/a-coder-nightmare/ le vendredi] ! (oh, non, jamais... /o\) | ||
+ | ** de toute façon [https://www.estcequonmetenprodaujourdhui.info/ il y a un site pour savoir si on peut mettre en prod' aujourd'hui] | ||
* tout cela ne vous évitera pas http://www.doingitwrong.com/ :/ | * tout cela ne vous évitera pas http://www.doingitwrong.com/ :/ | ||
** ou encore [http://freeworld.thc.org/root/phun/unmaintain.html le pire du pire] (ou pas, certains tenant absolument à nous le rappeler, incessamment, au jour le jour, à se taper la tête contre les murs, régulièrement, comme si la [http://fr.wikipedia.org/wiki/Les_Shadoks#Devises devise shadock] « Ce n'est qu'en essayant continuellement que l'on finit par réussir. Autrement dit : plus ça rate, plus on a de chances que ça marche. » était <u>vraiment</u> à prendre au pied de la lettre) | ** ou encore [http://freeworld.thc.org/root/phun/unmaintain.html le pire du pire] (ou pas, certains tenant absolument à nous le rappeler, incessamment, au jour le jour, à se taper la tête contre les murs, régulièrement, comme si la [http://fr.wikipedia.org/wiki/Les_Shadoks#Devises devise shadock] « Ce n'est qu'en essayant continuellement que l'on finit par réussir. Autrement dit : plus ça rate, plus on a de chances que ça marche. » était <u>vraiment</u> à prendre au pied de la lettre) | ||
** il y en a [http://www.ioccc.org/ qui ont essayé] | ** il y en a [http://www.ioccc.org/ qui ont essayé] | ||
** il y en a [http://failblog.org qui ont déjà échoué] | ** il y en a [http://failblog.org qui ont déjà échoué] | ||
+ | * de toute façon, cela va foirer un jour, autant vous y préparer comme les plus grands : | ||
+ | ** http://blog.useweb.fr/2011/05/10/faute-avouee-est-a-moitie-pardonnee/ | ||
+ | ** http://nils.hamerlinck.fr/blog/2011/11/16/faute-avouee-est-a-moitie-pardonnee/#more-149 | ||
+ | ** la différence entre un bon admin et un mauvais admin, c'est que l'un a déjà fait une grosse bêtise en prod', l'autre va la faire bientôt | ||
+ | * Vu sur [https://linuxfr.org/users/reynum/journaux/humour-d-informaticien LinuxFr.org] : | ||
+ | ** http://devopsreactions.tumblr.com ce ne sont pas les devops qui vont nous sauver | ||
+ | ** http://dbareactions.com/ les DBA aussi ont leur lot de boulets | ||
+ | * bien sûr, pour le stockage, la nature ayant horreur du vide : | ||
+ | ** il y a la loi de Parkinson https://fr.wikipedia.org/wiki/Loi_de_Parkinson#G.C3.A9n.C3.A9ralisation_de_la_loi_des_gaz | ||
+ | ** le bike-shedding ou abri à vélos n'est pas non plus l'explication https://fr.wikipedia.org/wiki/Loi_de_futilit%C3%A9_de_Parkinson | ||
+ | ** les changements de dernière minute : http://devopsreactions.tumblr.com/post/149120401826/major-change-request-1-day-before-the-release | ||
=== Méthodologie de développement === | === Méthodologie de développement === | ||
Mais nous comprenons aussi les contraintes du développement : | Mais nous comprenons aussi les contraintes du développement : | ||
* [http://lesjoiesducode.tumblr.com/ parce que nous aussi nous sommes humains] | * [http://lesjoiesducode.tumblr.com/ parce que nous aussi nous sommes humains] | ||
+ | * [http://www.jwz.org/doc/cadt.html les bugs non corrigés qui désespèrent les utilisateurs] | ||
+ | ** [http://plasmasturm.org/log/6debug/ 6 manières d'aborder les corrections de bugs] | ||
* les [http://coding.abel.nu/2012/06/programmer-time-translation-table/ distortions temporelles] affectant les développeurs | * les [http://coding.abel.nu/2012/06/programmer-time-translation-table/ distortions temporelles] affectant les développeurs | ||
* il n'y a rien de tel que le cycle en V : http://michel.arboi.free.fr/humeur/cycleV.html (spa faux, vous mettez quand en prod' ? non, nous ne demandons pas quand ça tombera en marche vu qu'il n'y a pas d'engagement) | * il n'y a rien de tel que le cycle en V : http://michel.arboi.free.fr/humeur/cycleV.html (spa faux, vous mettez quand en prod' ? non, nous ne demandons pas quand ça tombera en marche vu qu'il n'y a pas d'engagement) | ||
Line 33: | Line 48: | ||
** http://pascal.gugenberger.net/thoughts/waterfall-accident.html une confirmation que le cycle en V est moins optimal que de l'itératif | ** http://pascal.gugenberger.net/thoughts/waterfall-accident.html une confirmation que le cycle en V est moins optimal que de l'itératif | ||
** l'intégration continue https://github.com/codedance/Retaliation viser SCRUMM ou 2 TUP ou l'XP cf. [http://en.wikipedia.org/wiki/List_of_software_development_philosophies liste] | ** l'intégration continue https://github.com/codedance/Retaliation viser SCRUMM ou 2 TUP ou l'XP cf. [http://en.wikipedia.org/wiki/List_of_software_development_philosophies liste] | ||
+ | ** https://12factor.net/fr/ les 12 facteurs pour le développement | ||
* la gouvernance est un principe fort http://www.mega.com/fr/product/mega_library/mega_itil/index.asp?l=fr (nous écrire quand vous le comprenez, nous pas) | * la gouvernance est un principe fort http://www.mega.com/fr/product/mega_library/mega_itil/index.asp?l=fr (nous écrire quand vous le comprenez, nous pas) | ||
** il y a aussi le stratège et le tacticien http://www.areyouagile.com/2012/06/introduction-a-la-strategie-et-la-tactique-du-product-owner/ (le premier qui a tout suivi nous écrit aussi) | ** il y a aussi le stratège et le tacticien http://www.areyouagile.com/2012/06/introduction-a-la-strategie-et-la-tactique-du-product-owner/ (le premier qui a tout suivi nous écrit aussi) | ||
Line 41: | Line 57: | ||
** faites appel à la poudre verte http://www.poudreverte.org/ ! | ** faites appel à la poudre verte http://www.poudreverte.org/ ! | ||
** ou [https://imgur.com/r/funny/Q8kV8 appliquez la méthode du geek comme nous] | ** ou [https://imgur.com/r/funny/Q8kV8 appliquez la méthode du geek comme nous] | ||
+ | ** avec [https://github.com/AntJanus/programmers-proverbs#proverbs un peu de recul et d'humour], non vous n'êtes pas aigri, c'est ''notre réalité'' | ||
* rien de tel qu'un gestionnaire de version, svn, git ou encore [http://roland.entierement.nu/blog/2008/01/22/cpold-la-poudre-verte-du-suivi-de-versions.html CPOLD] | * rien de tel qu'un gestionnaire de version, svn, git ou encore [http://roland.entierement.nu/blog/2008/01/22/cpold-la-poudre-verte-du-suivi-de-versions.html CPOLD] | ||
* nous subissons (ou pas) quelques lois inhérentes à notre activité | * nous subissons (ou pas) quelques lois inhérentes à notre activité | ||
Line 47: | Line 64: | ||
** [http://fr.wikipedia.org/wiki/Loi_de_Pareto 20% qui bossent] /o\ [http://fr.wikipedia.org/wiki/Kaamelott#cite_ref-42 spa faux] | ** [http://fr.wikipedia.org/wiki/Loi_de_Pareto 20% qui bossent] /o\ [http://fr.wikipedia.org/wiki/Kaamelott#cite_ref-42 spa faux] | ||
** [http://swizec.com/blog/why-programmers-work-at-night/swizec/3198 pourquoi coder la nuit] | ** [http://swizec.com/blog/why-programmers-work-at-night/swizec/3198 pourquoi coder la nuit] | ||
− | * et si aucune methodo ne veut fonctionner, [http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html vous pouvez en parler à un canard] :-) | + | ** en [http://www.bitnative.com/2012/10/22/kill-the-zombies-in-your-code/ faisant attention aux zombies !1!!] |
+ | * et si aucune methodo ne veut fonctionner, | ||
+ | ** [http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html vous pouvez en parler à un canard] :-) | ||
+ | ** ou [http://fr.wikitranslation.com/en/En_pensant_%C3%A0_l%27ext%C3%A9rieur_de_la_bo%C3%AEte penser hors de la boîte] | ||
D'autres s'y connaissent aussi en dév' (aka autres références) | D'autres s'y connaissent aussi en dév' (aka autres références) | ||
* http://www.quora.com/What-are-some-popular-myths-in-software-development | * http://www.quora.com/What-are-some-popular-myths-in-software-development | ||
* pourquoi plutôt utiliser [http://grep.be/blog/en/computer/cluebat/mysql_toy_argument PostgreSQL que MySQL] | * pourquoi plutôt utiliser [http://grep.be/blog/en/computer/cluebat/mysql_toy_argument PostgreSQL que MySQL] | ||
+ | |||
+ | === Gestion de la sécurité === | ||
+ | * EBIOS | ||
+ | * ISO 27001 | ||
+ | * analyse SWOT - Strength, Weakness, Opportunities, Threats ou en français : Forces, faiblesses, opportunités, menaces (FFOM o_O) | ||
+ | * du concret avec [http://fr.wikipedia.org/wiki/Open_Web_Application_Security_Project OWASP] | ||
+ | * une [http://comicsanscriminal.com/ communication utilisant une bonne police] | ||
+ | * si vous connaissez /b/ ou [http://www.roadkilltshirts.com/I-GOT-A-DIG-BICK-YOU-THAT-READ-WRONG-YOU-READ-THAT-WRONG-TOO-T-SHIRT-P13269.aspx lisez de travers] on va dire que vous faites partie des « créatifs » | ||
+ | * autant [http://www.framablog.org/index.php/post/2013/12/20/geektionnerd-permis-internet-axa enseigner aux enfants des réponses toutes faites] ou [http://blogs.mediapart.fr/blog/robert-chaudenson/051213/pisa-un-temoignage-precieux-et-authentique pas]... | ||
+ | * d'autres choses | ||
=== Maîtrise de la croissance === | === Maîtrise de la croissance === |
Revision as of 09:24, 6 February 2019
En tant qu'hébergeur, tuxfamily.org est sensible aux bonnes pratiques de gestion de production et autres méthodos. Nous les appliquons à nos projets et pour recruter.
Contents
Gestion de production
Nous ne saurions vous recommander la-rache qui est la plus efficace et généralement appliquée, nous prenons aussi en compte des choses plus standards (dissaïdor pressé oriented)
- ITIL est recommandé et sera appliqué quand possible (il nous manque une vraie pré-production) http://www.itil.co.uk/
- la version française d'ITIL nous plaît plus : table des matières d'ITIL
- la gestion de configuration est effectuée selon au moins une des définitions classiques de SCM (mais laquelle ?!)
- et nous maîtrisons notamment la communication
- grâce à un pipotron élaboré
- même si nous préférons lcdlp
- (attention le business loto avec sa grille reste souvent à portée !)
- ainsi que motivation et la productivité de nos troupes
- tout en appliquant quelques principes
- de bon sens
- un fonctionnement ad hoc parfois le principe de subsidiarité prenant plus de temps en palabres
- (ce n'est pas le principe de Peter qui risque de nous toucher...)
- (ni celui de Dilbert)
- même si la loi de Parkinson nous touche surtout celle sur la trivialité (oui aussi appelée, bikeshedding)
- jamais le vendredi ! (oh, non, jamais... /o\)
- de toute façon il y a un site pour savoir si on peut mettre en prod' aujourd'hui
- tout cela ne vous évitera pas http://www.doingitwrong.com/ :/
- ou encore le pire du pire (ou pas, certains tenant absolument à nous le rappeler, incessamment, au jour le jour, à se taper la tête contre les murs, régulièrement, comme si la devise shadock « Ce n'est qu'en essayant continuellement que l'on finit par réussir. Autrement dit : plus ça rate, plus on a de chances que ça marche. » était vraiment à prendre au pied de la lettre)
- il y en a qui ont essayé
- il y en a qui ont déjà échoué
- de toute façon, cela va foirer un jour, autant vous y préparer comme les plus grands :
- http://blog.useweb.fr/2011/05/10/faute-avouee-est-a-moitie-pardonnee/
- http://nils.hamerlinck.fr/blog/2011/11/16/faute-avouee-est-a-moitie-pardonnee/#more-149
- la différence entre un bon admin et un mauvais admin, c'est que l'un a déjà fait une grosse bêtise en prod', l'autre va la faire bientôt
- Vu sur LinuxFr.org :
- http://devopsreactions.tumblr.com ce ne sont pas les devops qui vont nous sauver
- http://dbareactions.com/ les DBA aussi ont leur lot de boulets
- bien sûr, pour le stockage, la nature ayant horreur du vide :
- il y a la loi de Parkinson https://fr.wikipedia.org/wiki/Loi_de_Parkinson#G.C3.A9n.C3.A9ralisation_de_la_loi_des_gaz
- le bike-shedding ou abri à vélos n'est pas non plus l'explication https://fr.wikipedia.org/wiki/Loi_de_futilit%C3%A9_de_Parkinson
- les changements de dernière minute : http://devopsreactions.tumblr.com/post/149120401826/major-change-request-1-day-before-the-release
Méthodologie de développement
Mais nous comprenons aussi les contraintes du développement :
- parce que nous aussi nous sommes humains
- les bugs non corrigés qui désespèrent les utilisateurs
- les distortions temporelles affectant les développeurs
- il n'y a rien de tel que le cycle en V : http://michel.arboi.free.fr/humeur/cycleV.html (spa faux, vous mettez quand en prod' ? non, nous ne demandons pas quand ça tombera en marche vu qu'il n'y a pas d'engagement)
- http://humor.beecy.net/geeks/web-design/web-design.gif maitrisez vos projets web grâce à ces métriques
- http://www.aubryconseil.com/post/2007/01/23/162-le-cycle-de-vie-en-v-n-existe-pas un lien vers une page sérieuse s'est caché dans ces lignes, sauras-tu la trouver ?
- http://pascal.gugenberger.net/thoughts/waterfall-accident.html une confirmation que le cycle en V est moins optimal que de l'itératif
- l'intégration continue https://github.com/codedance/Retaliation viser SCRUMM ou 2 TUP ou l'XP cf. liste
- https://12factor.net/fr/ les 12 facteurs pour le développement
- la gouvernance est un principe fort http://www.mega.com/fr/product/mega_library/mega_itil/index.asp?l=fr (nous écrire quand vous le comprenez, nous pas)
- il y a aussi le stratège et le tacticien http://www.areyouagile.com/2012/06/introduction-a-la-strategie-et-la-tactique-du-product-owner/ (le premier qui a tout suivi nous écrit aussi)
- http://www.sixside.com/fast_good_cheap.asp [en] coût-qualité-délai en français, 2 au choix pas plus !
- http://blog.idleman.fr/?p=1259 le KISS illustré d'exemples concrets
- les contraintes fortes faisant accepter n'importe quoi ou rien, sans faire de différence (ça vous regarde) http://www.bernardbelanger.com/computing/NaDa/
- au besoin
- faites appel à la poudre verte http://www.poudreverte.org/ !
- ou appliquez la méthode du geek comme nous
- avec un peu de recul et d'humour, non vous n'êtes pas aigri, c'est notre réalité
- rien de tel qu'un gestionnaire de version, svn, git ou encore CPOLD
- nous subissons (ou pas) quelques lois inhérentes à notre activité
- loi de Brooks illustrée par le mythe du mois-homme, là ça va, nous ne sommes pas assez nombreux
- la silver bullet n'a pas été trouvée (même à HAR)
- 20% qui bossent /o\ spa faux
- pourquoi coder la nuit
- en faisant attention aux zombies !1!!
- et si aucune methodo ne veut fonctionner,
D'autres s'y connaissent aussi en dév' (aka autres références)
- http://www.quora.com/What-are-some-popular-myths-in-software-development
- pourquoi plutôt utiliser PostgreSQL que MySQL
Gestion de la sécurité
- EBIOS
- ISO 27001
- analyse SWOT - Strength, Weakness, Opportunities, Threats ou en français : Forces, faiblesses, opportunités, menaces (FFOM o_O)
- du concret avec OWASP
- une communication utilisant une bonne police
- si vous connaissez /b/ ou lisez de travers on va dire que vous faites partie des « créatifs »
- autant enseigner aux enfants des réponses toutes faites ou pas...
- d'autres choses
Maîtrise de la croissance
Pour les évolutions à venir (capacity planning ?), heureusement d'autres ont des idées pour nous
- http://linuxfr.org/~yellowiscool/27300.html de la répartition de charge, de la redondance
- http://fun.drno.de/pics/raid.jpg tout est en RAID dans le datacenter