Difference between revisions of "MethodoProject/Fr"

From TuxFamilyFAQ
Jump to navigationJump to search
(3 intermediate revisions by the same user not shown)
Line 28: Line 28:
 
** http://blog.useweb.fr/2011/05/10/faute-avouee-est-a-moitie-pardonnee/
 
** 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
 
** 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] :
 
* 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://devopsreactions.tumblr.com ce ne sont pas les devops qui vont nous sauver
 
** http://dbareactions.com/ les DBA aussi ont leur lot de boulets
 
** 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 ===
Line 43: 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)

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.

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)

Méthodologie de développement

Mais nous comprenons aussi les contraintes du développement :

D'autres s'y connaissent aussi en dév' (aka autres références)

Gestion de la sécurité

Maîtrise de la croissance

Pour les évolutions à venir (capacity planning ?), heureusement d'autres ont des idées pour nous