Devops for Growth
112.5K views | +1 today
Follow
Devops for Growth
For Product Owners/Product Managers and Scrum Teams: Growth Hacking, Devops, Agile, Lean for IT, Lean Startup, customer centric, software quality...
Curated by Mickael Ruau
Your new post is loading...
Your new post is loading...

Popular Tags

Current selected tag: 'gestion des risques'. Clear
Scooped by Mickael Ruau
November 7, 2019 3:47 AM
Scoop.it!

Event chain methodology - Wikipedia

Event chain methodology

Event chain methodology is a network analysis technique that is focused on identifying and managing events and relationship between them (event chains) that affect project schedules. It is an uncertainty modeling schedule technique. Event chain methodology is an extension of quantitative project risk analysis with Monte Carlo simulations.

Mickael Ruau's insight:

Event chain methodology helps to mitigate the effect of motivational and cognitive biases in estimating and scheduling.[2][3] It improves accuracy of risk assessment and helps to generate more realistic risk adjusted project schedules.[4]

No comment yet.
Scooped by Mickael Ruau
November 7, 2019 3:41 AM
Scoop.it!

IT risk - Wikipedia

IT risk

Information technology risk, IT risk, IT-related risk, or cyber risk is any risk related to information technology. While information has long been appreciated as a valuable and important asset, the rise of the knowledge economy and the Digital Revolution has led to organizations becoming increasingly dependent on information, information processing and especially IT.

No comment yet.
Scooped by Mickael Ruau
November 7, 2019 3:26 AM
Scoop.it!

IT risk management - Wikipedia

IT risk management

IT risk management is the application of risk management methods to information technology in order to manage IT risk, i.e.: The business risk associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise or organization Different methodologies have been proposed to manage IT risks, each of them divided into processes and steps.

No comment yet.
Scooped by Mickael Ruau
November 4, 2019 6:20 AM
Scoop.it!

Risk management, safety and dependability looking back from 1990 to 2015, which future - IMdR

Risk management, safety and dependability looking back from 1990 to 2015, which future - IMdR | Devops for Growth | Scoop.it

The article then explains how uncertainty is treated during these 25 years: model and propagate uncertainty, manage and analyze the uncertain data, decide in an uncertain context. The article concludes with the different actions that should be involved in the near future.

Mickael Ruau's insight:
No comment yet.
Scooped by Mickael Ruau
September 18, 2019 3:28 AM
Scoop.it!

How to combine risk management process with agile software development? - Part 1 - Software in Medical Devices, by MD101 Consulting

How to combine risk management process with agile software development? - Part 1 - Software in Medical Devices, by MD101 Consulting | Devops for Growth | Scoop.it
This post comes after a series of three posts where I exposed my thoughts about development of software medical devices with agile methods. These posts were focussed on software
No comment yet.
Scooped by Mickael Ruau
August 20, 2019 4:20 AM
Scoop.it!

Risk Burndown Chart | SCRUMstudy Blog

Risk Burndown Chart | SCRUMstudy Blog | Devops for Growth | Scoop.it

In Scrum, the risk management activities are divided among various roles with some responsibility resting with everyone in the Scrum Team and the Scrum Master facilitating the process. Risk management is integral to ensuring value creation; therefore, risk management activities are performed throughout the project lifecycle and not just during project initiation.

Mickael Ruau's insight:

Each risk could be assessed using different Risk Assessment tools. However, the preferred tool for assessing risks to create a Risk Burndown Chart is Expected Monetary Value (EMV

No comment yet.
Scooped by Mickael Ruau
July 10, 2019 8:42 AM
Scoop.it!

Ma conception – Antifragile

Une approche complexe

Cette dernière approche, qui est celle que je propose, se base sur le constat de l’imprédictibilité des crises et de la dimension d’improvisation nécessaire venant compléter la préparation de l’organisation.

« crisis is an unexpected, undesirable, unpredictable and unthinkable, which most of the time produces uncertainty and disbelief« (Milasinovic et al., 2010 ; Heat et al., 2009)

Cette approche met en évidence la nature complexe de l’organisation impactée et la non-proportionalité (ou non-linéarité) de l’événement. L’organisation et les acteurs sont confrontés à une situation totalement inattendue, imprévisible et dans une incertitude omniprésente dans laquelle il devient fondamental de s’adapter aux moyens disponibles, voire d’improviser, afin de limiter au mieux les conséquences.
No comment yet.
Scooped by Mickael Ruau
March 18, 2019 5:46 AM
Scoop.it!

Antifragile – Nassim Nicholas Taleb

Antifragile : le dernier élément de la triade : fragile – robuste – antifragile. Ce qui est fragile se casse avec le temps (et donc le hasard), ce qui est robuste résiste, ce qui est antifragile se renforce.
Heuristique : une heuristique est une hypothèse pratique que l’on formule sous forme de règle et qui est validé par la pratique sans que l’on sache nécessairement expliquer pourquoi. Pour Taleb plus les heuristiques sont anciennes plus elles sont « sûres ».
#skininthegame : seules les personnes qui payent les conséquences de leurs décisions doivent en prendre. C’est sa position que j’adapte en disant que ceux qui sont #skininthegame sont ceux qui « savent », c’est-à-dire qu’ils choisissent les conseils qu’on leur donne et que si ils refusent le conseil donné, c’est eux qui ont raison, même si ils sont incapables de vous expliquer pourquoi.
Conséquences : pour étudier une décision risquée (et donc difficile) il vaut mieux se fier à l’analyse des conséquences (négatives et positives) qu’aux probabilités.
No comment yet.
Scooped by Mickael Ruau
October 5, 2018 1:27 AM
Scoop.it!

Gestion du risque dans un projet Agile

Comment définir le risque et le gérer dans le cadre d'un projet Agile ? • quel type de risque ? • priorisation et risque • quels outils et techniques ?
No comment yet.
Scooped by Mickael Ruau
September 26, 2018 10:45 AM
Scoop.it!

Collaborative games for agile risk management

Collaborative games for agile risk management | Devops for Growth | Scoop.it
Agile methods incorporate many mechanisms for dealing with late breaking changes (an easily reprioritized backlog, short iterations, frequent inspection, and re-planning, etc.) that also lend themselves to proactively responding to risks. We can insert risk avoidance and risk reduction actions into the backlog to proactively attack the risks before they have an impact on the project. This paper describes a set of collaborative team games used to engage the whole team in opportunity and risk management activities. It outlines an approach that overcomes many of the "correct-but-not-sufficient" aspects of risk management seen too often on projects: poor engagement; done once; not revisited enough; not integrated into the project life cycle; and not engaging, poor visibility. The paper begins with an explanation of the risk management strategies implicit in the agile life cycle, and then describes a series of team games to explicitly tackle risk and opportunity management.
No comment yet.
Scooped by Mickael Ruau
August 9, 2018 4:55 AM
Scoop.it!

La fiche action risque

La fiche action risque | Devops for Growth | Scoop.it
La fiche action risque liste les actions spécifiques qui vont être menées pour traiter les risques identifiés. Elle est élaborée par le responsable du risque, avec l'aval du chef de projet pour l'obtention des ressources associées. Les actions décidées sont intégrées dans l'organigramme des tâches, le planning et le budget du projet. Des budgets leur sont alloués. L'avancement de ces actions est maîtrisé et les résultats produits sont reportés dans cette fiche. Il est alors possible de décider de continuer les actions ou de les arrêter.
No comment yet.
Scooped by Mickael Ruau
August 17, 2017 2:26 AM
Scoop.it!

Tips for Managing Common ERP Risk Factors

Manage 3 common ERP Risk factors - including cost, time, complexity. Proper planning and building a solid foundation to your ERP project is key.
No comment yet.
Scooped by Mickael Ruau
April 28, 2017 10:16 AM
Scoop.it!

Évaluation du niveau de SIL requis des Fonctions Instrumentées de Sécurité (SIF) – Allocation du niveau de SIL

Évaluation du niveau de SIL requis des Fonctions Instrumentées de Sécurité (SIF) – Allocation du niveau de SIL | Devops for Growth | Scoop.it

Une SIF a pour objectif de réduire un risque. Pour définir le niveau de SIL à allouer (SIL requis) à une SIF, il est nécessaire de mener une démarche rigoureuse.

Pour déterminer le SIL requis d’une SIF, la norme IEC 61511 introduit trois méthodes qui sont de ce fait les plus répandues dans le secteur des industries de procédés :

  • graphe de risque ;
  • matrice de criticité ;
  • LOPA.

Dans la pratique, ces trois méthodes ont des étapes communes, qui peuvent, suivant la méthode, être explicites ou implicites :

  • estimation de la criticité du risque « initial » (c’est-à-dire sans prendre en compte la SIF dont on cherche à déterminer le SIL requis) ;
  • confrontation de la criticité du risque à des critères d’acceptabilité, qui permettent de déterminer le facteur de réduction du risque (FRR) que la SIF doit introduire pour rendre le risque acceptable ;
  • estimation du niveau de SIL requis à partir du FRR.

Étapes :

 
No comment yet.
Scooped by Mickael Ruau
November 7, 2019 3:43 AM
Scoop.it!

Risk analysis (engineering) - Wikipedia

Risk analysis (engineering)

Risk analysis is the science of risks and their probability and evaluation. Probabilistic risk assessment is one analysis strategy usually employed in science and engineering. Risk analysis should be performed as part of the risk management process for each project.

No comment yet.
Scooped by Mickael Ruau
November 7, 2019 3:32 AM
Scoop.it!

MEHARI - Wikipedia

MEHARI

MEHARI ( MEthod for Harmonized Analysis of RIsk) is a free, open-source information risk analysis assessment and risk management method, for the use of information security professionals. MEHARI enables business managers, information security/risk management professionals and other stakeholders to evaluate and manage the organization's risks relating to information, information systems and information processes (not just IT).

No comment yet.
Scooped by Mickael Ruau
November 4, 2019 6:22 AM
Scoop.it!

Quelques methodes d’analyse de diagnostic et de pronostic utilisées en fiabilité et maintenance industrielle - IMdR

Quelques methodes d’analyse de diagnostic et de pronostic utilisées en fiabilité et maintenance industrielle - IMdR | Devops for Growth | Scoop.it

L'exposé présentera quelques-unes des méthodes utilisées à l'heure actuelle pour résoudre ce problème. Ces dernières s'appuient principalement sur les connaissances disponibles issues du retour d'expérience (données historiques, données mesurées), de l'expertise et de modèles de comportement fiabiliste ou physique.

No comment yet.
Scooped by Mickael Ruau
October 23, 2019 7:54 AM
Scoop.it!

Méthodologie d'atténuation des risques "Bowtie" ou "Noeud papillon"

Méthodologie d'atténuation des risques "Bowtie" ou "Noeud papillon" | Devops for Growth | Scoop.it

1. PRINCIPE DE LA MÉTHODOLOGIE « BOWTIE » OU « NOEUD PAPILLON »

Le « Bowtie » est une approche probabiliste d’évaluation du risque. Elle résulte de la combinaison d’un arbre de défaillances et d’un arbre d’événements, centré sur un même événement redouté. L’application de cette méthode dans le milieu industriel est de plus en plus répandue. La méthode de « Bowtie » présente l’avantage d’apporter un modèle pour la Maîtrise des Risques. Le mode de représentation sous forme de nœud papillon a donné son nom à la méthodologie.

2. OBJECTIFS DE LA MÉTHODOLOGIE « BOWTIE » OU « NOEUD PAPILLON« 

Concrètement cette approche permet de :

  • représenter les relations entre les dangers leurs causes et leurs effets ;
  • évaluer la contribution de chaque cause et la gravité de chaque risque ;
  • positionner des barrières de prévention et de protection ;
  • évaluer les facteurs aggravants diminuant l’efficacité des barrières ;
  • évaluer la robustesse et la contribution des barrières à l’atténuation des risques ;
  • évaluer l’impact de ces barrières sur la cotation générale du risque.
No comment yet.
Scooped by Mickael Ruau
September 17, 2019 10:55 AM
Scoop.it!

How to differenciate Bugs, Software Risks and Software Failures - Part 1 - Software in Medical Devices, by MD101 Consulting

How to differenciate Bugs, Software Risks and Software Failures - Part 1 - Software in Medical Devices, by MD101 Consulting | Devops for Growth | Scoop.it

If my PACS viewer can't read 100% DICOM compliant data, it's a defect.
If my PACS viewer can't read corrupted data, it's a software failure.
You can see in this case that, this software failure doesn't mean that the software is guilty. Data were corrupted through the network, when burning the CDROM ... not by the PACS viewer.

Mickael Ruau's insight:

IEC 62304 prefers using the term Anomaly. It is defined at the beginning of the document and is used many times in the standard. That means that IEC 62304 focuses a big part of the efforts to reduce the amount of anomalies that remains when a software is delivered to end-users.

Characterization of defect

Defects can be so numerous, diverse and annoying that software engineers have defined a lot of attributes to characterize and categorize them. A bit like entomologists do with real bugs.
A defect has a title and an explanation plus a bunch of criteria. The most used criteria are:

  • Severity: how it affects the use of software,
  • Frequency: how often it appears,
  • Version of Software: on which version of software,

Other "administrative" criteria are also useful:

  • Status: is it open (still there), closed (fixed), pending (being fixed),
  • Creation date: when it was found,
  • Creator: who found it,
  • Owner: who's in charge to fix it.

Some companies like to add a looong list of criteria in their databases to characterize defects. This is not very useful, as most of engineers only use a small set of them.

Severity, the most important criterion

Most of times, the severity is defined by values like:

  • Critical: software stops or can't be used,
  • Major: software doesn't give expected results, but there is a workaround,
  • Minor: software gives a result with a non-significant discrepancy compared to expected result.

Some engineers like to add the Cosmetic value, for very minor things. When a word is misspelled in the user interface, but the whole thing remains understandable, then that defect can be set as cosmetic.

Severity is the most important criterion for software engineers because this is the one which is usually taken to sort defects by priority. The critical defects are fixed at first. The cosmetic ones are fixed when time remains.
This way of sorting defects can lead to epic situations when beta testers and engineers review and choose the defects that have to be fixed at first.
If you are an end-user that already participate to this kind of meeting, you already had to get along with a stubborn engineer that didn't want to set a high priority to a damned annoying bug!
If you are a software engineer, you already participate to this kind of meeting, and you already had to get along with a stubborn end-user that didn't understand anything to the way your software works and wanted to break something that works pretty well!
If you are a project manager, you know how long this meeting is going to be! :-)

No comment yet.
Scooped by Mickael Ruau
August 6, 2019 8:24 AM
Scoop.it!

Nous avons découvert l’ennemi, et c’est… la prévision

Les prévisions sont en général à peu près justes, mais lorsqu’elles s’avèrent inexactes, les effets peuvent être spectaculaires. Cela arrive rarement, et parce que la probabilité de tels évènements est faible, nous pensons que nous pouvons nous en tirer à bon compte. Cependant, comme l’a observé Nassim Taleb en formulant l’expression « Cygne noir », des évènements de faible probabilité peuvent cependant avoir un très fort impact. En fait, on peut même avancer que nos efforts pour réduire la survenance de tels évènements, c’est à dire réduire la volatilité dans le langage de Ben Bernanke, ne font que contribuer à augmenter leur impact quand ils surviennent, car ils finissent toujours par survenir (leur probabilité n’est jamais nulle, seulement faible). En substance, moins un évènement est probable, plus sa survenance est coûteuse.
No comment yet.
Scooped by Mickael Ruau
May 8, 2019 8:25 AM
Scoop.it!

EBIOS — Expression des Besoins et Identification des Objectifs de Sécurité | Agence nationale de la sécurité des systèmes d'information

EBIOS — Expression des Besoins et Identification des Objectifs de Sécurité | Agence nationale de la sécurité des systèmes d'information | Devops for Growth | Scoop.it
La méthode EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) est un outil complet de gestion des risques SSI conforme au RGS et aux dernières normes ISO 27001, 27005 et 31000.
Mickael Ruau's insight:

L’ANSSI a publié la nouvelle version de la méthode d’analyse de risque EBIOS RM en 2018.

EBIOS Risk Manager est issue d’un long héritage. Fruit d’une collaboration étroite, elle positionne pleinement la sécurité numérique au niveau des enjeux stratégiques et opérationnels des organisations. Elle offre ainsi un véritable cadre en matière de management du risque numérique.

Découvrez EBIOS RM

 

 

 

  • pdf

    EBIOS 2010 : la méthodologie

    1.36 Mo

  • pdf

    EBIOS 2010 : plaquette de la méthode

    481.82 Ko

  • pdf

    EBIOS 2010 : plaquette de la méthode (RSSI)

    627.76 Ko

  • pdf

    EBIOS 2010 : étude de cas

    1.31 Mo

  • pdf

    EBIOS 2010 : la bases de connaissances

    609 Ko

  • pdf

    EBIOS 2004 : référentiel de compétences

    101.21 Ko

  • zip

    EBIOS v.2 (2004)

    83.14 Mo

No comment yet.
Scooped by Mickael Ruau
March 13, 2019 1:05 PM
Scoop.it!

Managing Risk in Scrum, Part 2

Managing Risk in Scrum, Part 2 | Devops for Growth | Scoop.it
In my previous post, I discussed the five risk areas found on most projects and how Agilemanaging risk in scrum agile addresses them.

Managing risk is prevalent in Scrum on a daily basis. Discovery, analysis, and mitigation for risk happens organically in Agile, and particularly in Scrum. Let’s compare risk management practices between traditional/”waterfall” project management and Scrum.
No comment yet.
Scooped by Mickael Ruau
September 26, 2018 10:47 AM
Scoop.it!

Scrum Alliance - Scrum Alliance Member-Submitted Informational Articles

Scrum Alliance - Scrum Alliance Member-Submitted Informational Articles | Devops for Growth | Scoop.it
To help provide current and aspiring Agile professionals with additional information and guides for Scrum, we have compiled a list of member-written articles from a wide variety of experts. We have articles that cover a wide range of topics to help you learn everything you need to know.
Mickael Ruau's insight:

Scrum is great at handling immediate issues more commonly referred to as "impediments." The team raises these issues daily via the Daily Scrum. Some teams like to keep track of all of these impediments by using an "issues snake" or an "issues calendar."

How this works

  • Every time an issue is raised at the Daily Scrum, you write it on a post-it and place it somewhere visible.
  • If the same issue is raised more than once, you add another post-it-note to the board.
  • This helps keep track of blockages and disruptions and can be used to drive conversation at the end-of-sprint retrospective or at the end-of-sprint review.
  • This approach also helps you to quickly identify reoccurring issues or blockages.
No comment yet.
Scooped by Mickael Ruau
August 13, 2018 12:20 PM
Scoop.it!

Le registre des risques

Le registre des risques | Devops for Growth | Scoop.it
Le registre des risques permet d'agréger en un document unique la totalité des risques identifiés pour un projet. Il facilite par ailleurs la mise en commun des risques d'un portefeuille de projets de l'entreprise. Il comprend les données descriptives essentielles de chacun des risques. Il est mis à jour au fur et à mesure de l'avancement du projet. Un registre des risques peut contenir des risques de maturité différente : certains risques ont été identifiés depuis le début du projet et ont déjà fait l'objet d'actions de réduction. Les risques les plus récemment identifiés n'ont pas forcément été traités.
No comment yet.
Scooped by Mickael Ruau
January 23, 2018 2:13 AM
Scoop.it!

RiskStorming - Maping Risks with TestSphere

RiskStorming - Maping Risks with TestSphere | Devops for Growth | Scoop.it

Why RiskStorming? Beren van Daele and Andreas Faes were chosen to give a workshop at the Agile & Automation days in Krakau.

Mickael Ruau's insight:

Beren van Daele and Andreas Faes were chosen to give a workshop at the Agile & Automation days in Krakau. In that workshop, they were going to utilize the famous TestSphere Cards as a tool to create a test strategy.

No comment yet.
Scooped by Mickael Ruau
April 28, 2017 10:18 AM
Scoop.it!

Sûreté de fonctionnement : normes CEI 61508 et SIL | Fersil

Une analyse des risques permet de déterminer comment la sûreté de fonctionnement permettra d’assurer une protection adéquate contre chacun des risques qui peuvent survenir. Ces dangers sont donc traités de manière appropriée pendant la phase de conception pour que le système final soit exempt de défaut.
En effet, les fonctions de sécurité sont la résultante des systèmes électriques, électroniques ou électroniques programmables qui sont habituellement complexes, ce qui a pour conséquence de rendre très difficile la détermination des défaillances. L’objectif est donc de concevoir le système d’une manière qui évite un maximum de pannes et qui les contrôle si elles apparaissent

Les pannes peuvent provenir de nombreux facteurs différents :
> Erreurs sur le logiciel,
> Erreur humaine,
> Influence de l’environnement,
> Panne matérielle aléatoire des mécanismes,
> Etc…

Ainsi, la sécurité de fonctionnement dépend du bon fonctionnement d’un système global ou d’un équipement en réponse à ses entrées.
C’est pourquoi la norme IEC 61508 (CEI 61508 en français) fut créée.

Mickael Ruau's insight:

SIL ou Security Integrity Level

Le SIL est un niveau d’intégrité de sécurité. La notion de SIL découle directement de la norme IEC 61508. Le SIL peut se définir comme une mesure de la sûreté de fonctionnement qui permet de déterminer les recommandations concernant l’intégrité des fonctions de sécurité à assigner aux systèmes E/E/PE concernant la sécurité.

> Il existe 4 niveaux de SIL : le SIL 4 étant le système de sécurité le plus élevé, le SIL 1 le moins élevé.

> Il s’agit d’une probabilité moyenne de défaillance sur sollicitation PFDavg (Probability of Failure on Demand) sur une période de 10 ans.

No comment yet.