Devops for Growth

On dit qu’un modèle possède la propriété de Markov si son état à un instant T dépend uniquement de son état à l’instant T-1. Si on peut observer les états dans lesquels se trouve le modèle à chaque instant, on parle de modèle de Markov observable. Sinon, on parle de modèle de Markov caché.

Dans cet article, nous allons illustrer ces modèles pour comprendre leur fonctionnement et leur utilité.

DesignPattern

Name: [name]

Type: ''[Design | Organizational | ...]

Problem: [what you really want to solve; present a simple concrete example]

Context: [context]

Forces: [forces]

Proposed Solution: [explain in terms of your concrete example]

Resulting Context: [what happens when you apply it, good and bad]

Design Rationale: [rationale]

Related Patterns:

AntiPatterns you should beware of:

Pattern Category: [classify it]

Also Known As: [other names]

Examples in the Literature:

Examples in Practice:

Starting from “The Mist”, we will do a guided tour through several of the best practices of Scrum, being mined, gathered, and documented by the ScrumPLoP group…

This is the backup collection of the material for the forthcoming book, "Scrum Patterns: The Spirit of the Game," replicating the material at https://sites.google.com/a/scrumplop.org/published-patterns/home. Only the "Published Patterns" appear here - that is, those that are held to be fairly close to their final appearance in the book.

For additional historical context, see also http://www.scrumorgpatterns.com and http://orgpatterns.com.

The ScrumPLoP Product Backlog is on the Product Backlog Spreadsheet.

Stop development when the cost of continuing exceeds the benefit that the client enterprise will receive from the development.

✥      ✥      ✥

The vendor works to deliver to the client as long as ongoing work continues to increase the overall value (such as net present value) of all Product Increments.

In addition to ensuring that value to the client doesn’t decrease, also make sure that stopping development at these points won’t cripple the vendor’s profitability or value. The client may agree to pay a termination fee to the vendor in the event that it terminates the agreement early, but the client still pays much less than if it had pursued the agreement to the end. One can argue in all fairness that such a fee covers the vendor’s opportunity costs while lining up new business. It is best that the vendor ensures, from the beginning, that each deliverable (Sprint) has positive value to the client, so that the client doesn’t put the vendor at risk over the life-cycle development.

For an example, see “Change for Free and Money for Nothing” in [1] (Chapter 8, ff. 193), that describes a pay-as-you-go contract where the client negotiated the right to terminate the contract at the end of any Sprint—as long as they paid 20 percent of the cost of remaining development. The client paid $3.2 million for a product bid at $10 million and got it 17 months early, thanks to incremental delivery and being able to stop development when the feature set was complete. Furthermore, the client also used Change for Free to redirect some of the work into areas of higher value. In the meantime, the vendor, who had set up the contract to give a profit margin of 15 percent, ended with a net profit margin of 60 percent. Released from the contract early, the vendor was able to pursue additional contracts instead of having to wait 17 months to do so.

Intent: Minimize stock-on-hand to one item so as to deliver value more quickly and reduce waste

This is the talk I gave at the Japanese Scrum Gathering on 28 February 2015. I'm uploading it at the request of Osamu Tomita who thought that others would like…

An introduction of the 6 symptoms, with the symptom ‘No validation with stakeholders’ explained in detail.

• Complex collaborative development such as knowledge work requires high-quality communication to be effective. It is difficult to predict the timing, frequency, and duration of this communication necessary for success.

•  Collocate the team members, ideally in a room of their own, within talking distance.

Swarming is when an Agile team need all available personnel to work on a single problem. In this article, we offer a quick review of Swarming and how to use it.

Just as software design patterns have dramatically accelerated the speed of quality software development, we are seeing hardware design patterns provide repeatable solutions to common challenges faced by hardware scrum team. The “Gang of Four” format is being used to describe patterns:

• Pattern Name and Classification: A descriptive and unique name that helps in identifying and referring to the pattern.
• Intent: A description of the goal behind the pattern and the reason for using it.
• Also Known As: Other names for the pattern.
• Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used.
• Applicability: Situations in which this pattern is usable; the context for the pattern.
• Structure: A graphical representation of the pattern. Class diagrams and Interaction diagrams may be used for this purpose.
• Participants: A listing of the classes and objects used in the pattern and their roles in the design.
• Collaboration: A description of how classes and objects used in the pattern interact with each other.
• Consequences: A description of the results, side effects, and trade offs caused by using the pattern.
• Implementation: A description of an implementation of the pattern; the solution part of the pattern.
• Sample Code: An illustration of how the pattern can be used in a programming language.
• Known Uses: Examples of real usages of the pattern.
• Related Patterns: Other patterns that have some relationship with the pattern; discussion of the differences between the pattern and similar patterns.

This page was adapted from Hubert Smit's work on XM patterns.

In the software industry until the 1980's, programs were developed on a procedural model. This led to extremely complex, unmaintainabl

Proverbs: That which is owned by everyone ends up being owned by no-one

agile pattern for test driven development, or TDD, also known as test first or red green refactor.

Explore the phenomenon of No Single Product Owner in organizations using Agile and Scrum for software development: Causes, smells, and remedies.

These notes give a short definitive summary of patterns (by example) and pattern languages. Next, they introduce basic Scrum patterns that the Scrum PLoP® effort has gathered over the past five years. After that we look at the "Scrum secrets" — Scrum fundamentals that most practitioners either aren't aware of or which usually go unheeded. Patterns help tease out the tradeoffs ("forces") for these forms in a way that makes them memorable. Last, we give a glimpse of how to use these patterns as a powerful way to evolve your own Scrum implementation to excellence.