Agile (アジャイル) is a development approach that goes from planning to review again and again in short cycles, growing working software a little at a time.
Pick the highest-priority requests
Build and test within a short period
Show users something that runs
Feed feedback into the next plan
Put the feedback and changed requests into the next round, then start over.
4 / 4
Each short cycle is called an iteration (イテレーション), and every one starts with the features that rank highest at the time. Instead of fixing every specification up front, the team keeps revising the scope while talking with users. Showing something that runs early and getting feedback counts for more than polishing documents in detail.
AnalogyIt is like a trip where you don't plan every minute before leaving, but rework the next day's plan each evening based on the weather and how you feel.
How to rememberThe English word agile means nimble and quick. Picture someone traveling light, with no heavy plan on their back, able to change direction easily.
Exam points
ExamThe strength of Agile (アジャイル) is that changes to specifications or requests midway can go into the plan for the next iteration. It copes with change better than the waterfall model (ウォーターフォール型), which moves through each phase once, in order.
ExamAgile puts working software ahead of detailed documentation and brings new customer requests into the product early.
A user story (ユーザーストーリー) is how Agile writes down requirements: a short sentence, from the user's point of view, saying who they are, what they want to do and why.
Element
Example
As whom
As a library user
What I want
To check my books' due dates on my phone
Why
So that I don't forget to return them
Each story is short enough to fit on a single card, and the finer conditions are settled with users just before it is built. Writing down the reason keeps the builders from losing sight of whose problem the feature solves. Stories are ranked by priority and built from the top in each iteration.
AnalogyIt is like a diner telling a restaurant, "I can't handle spicy food, so I'd like something my child can eat too." The kitchen and the diner work out the recipe details together.
How to rememberStory as in a tale: the hero is always the user, and the builders or the system never take the subject's place.
Exam points
Mix-upA user story (ユーザーストーリー) is a short requirement that states a goal in the user's own words. It plays a different role from a detailed specification that pins down every screen and process.
XP is a development method that sets out the Agile approach as a set of concrete habits (practices, プラクティス) to follow in day-to-day work.
XP practices (examples)
Write tests first
Write code in pairs
Tidy structure without changing behavior
Integrate changes often
It is aimed at fairly small teams that release in short cycles, keeping software quality high while keeping up with changing requirements. Its practices include test-driven development and pair programming, and each one means doing a habit known to work every time, without skipping it.
AnalogyIt is like a sports team that gets stronger by never skipping the basics: warming up, calling to each other on the field and reviewing each game afterward.
How to rememberThe two-letter name takes the X from Extreme and the P from Programming.
Exam points
ExamXP is one of the Agile (アジャイル) development methods. It releases many times in short cycles and aims for high-quality software while keeping up with changing requirements.
Mix-upAgile is the broad name for a development approach, while XP is one concrete method that puts it into practice.
Extreme Programming (エクストリームプログラミング) is the full name of XP, and both refer to the same development method.
The English name Extreme Programming carries the idea of pushing good development habits to the extreme. Its content is exactly the same as XP, so read either name as the same method.
How to rememberExtreme means going to the limit. The name reflects an attitude of carrying the basic habits all the way, with no shortcuts.
Exam points
ExamExtreme Programming (エクストリームプログラミング) and XP are the full name and the abbreviation, and they stand for the same Agile (アジャイル) development method.
Test-driven development (テスト駆動開発) is a way of working in which you first write the test for a feature, then write the code that passes it.
Write a test that fails for now
Write just enough code to pass
Tidy the code with tests still passing
Tidy the structure while the tests keep passing, then move on to the next test.
3 / 3
The test written first states what counts as done, so the specification is clear before any code exists. The small loop of writing a test, passing it and tidying up repeats many times, with the tests checking the behavior each round. Its abbreviation is TDD, and it is one of the signature practices of XP.
AnalogyIt is like deciding, before putting a shelf together, that it must hold 30 books without tilting, and only then starting to build.
How to remember"Driven" means pushed forward by something. Here the test leads the way and pulls the development along.
Exam points
Mix-upIn test-driven development (テスト駆動開発), writing the test is the first task. The order is the reverse of building everything and then testing it all at the end.
Pair programming (ペアプログラミング) is a way of developing in which two people sit side by side at one screen and write the same code while talking it through.
Role
What they do
Driver
Holds the keyboard and types the code
Navigator
Spots mistakes from the side and thinks about direction and design
Switching
Swap roles at set intervals
The person at the keyboard is the driver (ドライバー), and the one beside them who checks the work and thinks about direction is the navigator (ナビゲーター); they swap roles from time to time. Because a second person reads the code as it is written, mistakes are caught early, and knowledge and coding style spread across the team. It is one of the practices of XP.
AnalogyIt is like a rally car crew: the driver holds the wheel while the co-driver reads the map and calls out the route.
How to rememberA pair is two that go together, like shoes or gloves. Picture one desk with two chairs side by side.
Exam points
Mix-upA code review (コードレビュー) is a check in which someone else reads the code after it is finished. In pair programming (ペアプログラミング), the person alongside checks it at the moment it is written.
Refactoring (リファクタリング) is the work of reshaping a program's insides, such as names and structure, so it is easier to read and change, without altering its external behavior.
Category
Examples
What stays the same
Results returned for the same input, how screens behave
What changes
Unclear variable names, duplicated logic, overly long functions
External behavior here means the results returned for the same input and what users can see the program do. Even when that stays the same, removing duplication or splitting up the logic makes later fixes and new features easier. Running the tests after the cleanup confirms the behavior has not changed.
AnalogyIt is like tidying a room without throwing anything away, just re-dividing the drawers so things are easier to find.
How to rememberThink of re-factor as redoing a factorization in algebra: the value stays the same, and only the form of the expression is rearranged.
Exam points
ExamRefactoring (リファクタリング) touches only the internal structure. The functions and behavior users see stay as they are.
Mix-upReverse engineering (リバースエンジニアリング) analyzes an existing program to work out its specification. It works in a different direction from refactoring, where the code is rewritten and tidied.
Mix-upTest-driven development (テスト駆動開発) is a way of building that starts from the test, while refactoring tidies existing code and keeps its behavior intact.
Write the test first, then the code that passes it
Tidy the inside of existing code
Key differenceBehavior seen from outside
Adds new behavior defined by the tests
Stays the same
Key points
Agile is a development approach that shows working results at the end of each short cycle and carries user feedback and changing requests into the next one.
A user story states who, what and why in the user's own words, and the details are agreed just before building.
XP and Extreme Programming are the same method, which values carrying good development habits through every time.
In pair programming, the person typing and the person checking work side by side, so mistakes surface while the code is being written.
What defines refactoring is tidying only the internal structure while the behavior seen from outside stays the same.