Difference between revisions of "MethodoProject/Fr"
From TuxFamilyFAQ
Jump to navigationJump to searchLine 27: | Line 27: | ||
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 | + | * [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) |
Revision as of 15:55, 5 October 2013
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)
- 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é
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
- 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
- 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
- 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