A retrospective (ふりかえり) is an activity in which, each time a period of work ends, the team reviews how it works and decides on an improvement to try in the next period.
Finish one iteration
Share what went well and what got in the way
Choose an improvement to try next
Carry out the improvement in the next iteration
The chosen improvement is tried in the next iteration, and its effect is reviewed at the following session.
4 / 4
What gets reviewed is the way the work is done, such as how tasks are organized and how members coordinate. A common format is KPT, where people give views under Keep, Problem and Try. Repeating this every iteration makes the team's way of working a little better each time.
AnalogyIt is like jotting down, after each meal you cook, which steps went smoothly and what you want to change, then trying those notes the next time you cook.
How to rememberIn kanji it is written 振り返り, meaning to turn and look back. Picture turning around to check the road behind you, then facing forward again to choose your next step.
Exam points
Mix-upThe purpose of a retrospective (ふりかえり) is not to find and blame whoever made a mistake. It is to improve how the whole team works in the next iteration.
Retrospective (レトロスペクティブ) is the English-derived name for a retrospective (ふりかえり). In Scrum, it is defined as an event called the sprint retrospective (スプリントレトロスペクティブ), held at the end of each sprint (the unit of one development iteration).
Its content is the same as a retrospective: the team looks back at people, methods, tool use and the like in the sprint just finished and decides on improvements for the next sprint. In Scrum, it comes after the sprint review (スプリントレビュー), where the finished work is shown to stakeholders for feedback.
How to rememberRetro means backward and spective means looking. It is the same retro as in retro fashion, so "looking backward" is exactly what 振り返り means.
Exam points
Mix-upA sprint review (スプリントレビュー) checks the finished work, while a Retrospective (レトロスペクティブ) examines how the team works. They look at different things.
CI is the practice in which developers frequently merge small source code changes into a shared repository (the place where the team keeps its common code), and each merge automatically triggers a build (assembling a working program from source code) and tests.
Make a small change
Merge into the shared repository
Automatic build and tests
Send results straight back to the developer
A failure triggers an immediate alert, and the cause narrows to the small change just made.
4 / 4
If everyone's changes are merged together only near the end of development, conflicts surface all at once, and tracking down which change caused a problem takes a lot of effort. CI shortens the gap between merges and returns automated test results every time, so when a defect turns up, the range of possible causes is already small.
AnalogyIt is like a large group writing one anthology: each time someone finishes a page, it is bound in right away and the whole thing is read through, so mismatches in the story get fixed on the spot.
How to rememberC stands for Continuous (going on without a break) and I for Integration (bringing things together into one).
Exam points
Mix-upWhat CI runs automatically each time stops at building and testing the merged changes. Automatically carrying changes that pass the tests to a state where they can go to production at any time is called continuous delivery (継続的デリバリー, CD).
Continuous Integration (継続的インテグレーション) is the full name of CI, and refers to the same practice.
Integration (インテグレーション) means combining, here bringing each developer's changes together into one program. Continuous means repeating that integration routinely while development is still under way.
How to rememberIntegrate shares its root with integer (a whole number with nothing missing), and means turning scattered parts into one complete whole.
Exam points
Mix-upThe continuous in Continuous Integration (継続的インテグレーション) means integration is not done once at the end of development but repeated with every small change.
DevOps is an approach in which the people in charge of development and those in charge of operations work together, using automation to keep delivering software changes quickly and reliably.
Development (new features, fixes)
Automate testing and release
Operations (running, monitoring)
Feed operational findings back to development
Issues found in operations go back to development for the next improvement, and the loop keeps turning.
4 / 4
In the past, developers who wanted to ship new features fast and operators who did not want the system to go down worked separately, and every handover tended to take time. With DevOps, both sides share goals and adopt automation such as CI, so they can respond to specification changes at short intervals. It is not the name of a particular tool but a way of thinking that includes how the organization cooperates and builds its processes.
AnalogyIt is like a restaurant where the kitchen that cooks and the floor staff who serve act as one team, share customers' reactions and keep refining the menu quickly.
How to rememberThe word joins Dev and Ops, so the name itself shows the two roles merged into one.
Exam points
ExamDevOps is an approach where development and operations staff cooperate and use automation to deliver new and changed features to users quickly.
ExamAutomation in DevOps is not limited to development work. It also covers operations work such as releasing to the production environment.
Mix-upAgile (アジャイル) is a way of developing bit by bit in short iterations, while DevOps is about setting up teams so that development and operations together speed up delivery. The two are often used in combination.
MLOps applies the thinking of DevOps to systems that use machine learning, keeping a model (a mechanism that learns from data to make predictions or judgments) cycling continuously from development through operation and updates.
Collect training data
Train and evaluate the model
Deploy into the production system
Monitor accuracy and retrain
If prediction accuracy drops during operation, the model is retrained on new data and swapped in.
4 / 4
MLOps links data preparation, training, evaluation, deployment and monitoring into one continuous flow and automates whatever it can. Like DevOps, it relies on data analysts, developers and operators working together.
AnalogyIt is like a weather forecaster who checks every day whether the forecasts were right and, once misses start piling up, rebuilds the forecasting method from new observation data.
How to rememberThe name is DevOps with Dev swapped out for ML (Machine Learning).
Exam points
Mix-upRunning a model under MLOps does not end once it is deployed to production. When the trends in the data it handles shift, accuracy falls, so monitoring and retraining are repeated.
DevOps vs. MLOps
Aspect
DevOps
MLOps
Target
Software in general
Systems that use machine learning
Key differenceWhat is managed
Mainly programs (source code)
Programs plus training data and models
What triggers updates in operation
New features or bug fixes
Those, plus accuracy loss from changing data
Key points
A retrospective (ふりかえり; English-derived name Retrospective, レトロスペクティブ) is an activity where the team reviews how it works after each iteration and decides what improvement to try next.
CI (Continuous Integration, 継続的インテグレーション) merges small changes frequently and runs the build and tests automatically each time.
DevOps is an approach where development and operations cooperate and use automation to keep delivering changes quickly and reliably.
MLOps applies DevOps thinking to systems that use machine learning.