Ga naar hoofdinhoud

Walking Skeleton

De bronnen uit de bronnen sectie zijn leidend, dus neem er enkele door.

Onderstaande quotes geven aan wat een Walking Skeleton is. De volgende twee secties zeggen iets over de verschillen (en overeenkomsten) tussen een Walking Skeleton en een MVP en (een Walking Skeleton en) een backbone die je in eerdere courses tegenkwam. En koppelen het wat meer aan de praktijk van je opdracht.

walking skeleton

Figuur 1: Walking Skeleton vs Backbone vs MVP (AIM/ChatGPT, 2025)

1. Wat is een Walking Skeleton?​

Martin Fowler geeft misschien wel de kortste definitie:

"A minimal implementation of a system that is functional from end to end.”

Maar wat is dan precies een 'minimal implemenation'? Het gaat om de minimale benodigde features implementeren:

"In essence, it's a very simple, yet working, proof of concept that executes an end-to-end process to demonstrate how something may work in practice. It is a 'skeletal' version of a system - bare bones functionality will be included only - but it is executable, hence 'walking'." 67bricks.com

Bij WebTech leerde je al paper prototypes te maken. Dit vond je wellicht veel werk, maar het idee is juist hiermee jezelf veel werk besparen door te voorkomen dat als je iets helemaal in HTML en CSS hebt uitgewerkt je dan pas ontdekt dat het toch heel anders moet. Een Walking Skeleton doet hetzelfde maar dan niet van UI design, maar voor de hele software architectuur. Dit geeft ook Joris van de Aalsvoort uitlegt:

"It is used to ensure that nobody invests too much time in implementing an architecture based on hypotheses. It should be the simplest, working version of your system that implements all major components — UI, backend, database, you name it…" Joris van de Aalsvoort

Clint Shank (z.d.):

"The bigger the system, the more important it is to use this strategy. In a small application, one developer can implement a feature from top to bottom relatively quickly, but this becomes impractical with larger systems."

2. Het is GEEN Minimum Viable Product (MVP)​

Om misconcepties te voorkomen, is het goed om het verschil te zien tussen een Walking Skeleton en een MVP - Minimum Viable Product.

Hier nog meer quotes, eerst een van een zeker Czubajewski (2024):

"I hear this question all the time, so let's set the record straight:

  • A Walking Skeleton is a technical proof of concept, built to validate that all parts of the system work together. It's minimal in features but complete in architecture.
  • An "MVP" (Minimum Viable Product) is a business-driven approach — just enough features to be useful to early adopters and gather user feedback.

"The difference hides in their scope. A walking skeleton focuses more narrowly on the core functionality needed to test assumptions in initial user trials. It's even lighter and faster to develop than a full MVP."

Nunes & Lewis (2020):

"In our example [...] the walking-skeleton would have consisted of the entire MVP user journey but with little time invested in the fidelity of the user interface. Moreover, all API integrations would be stubbed with any data mocked and hard-coded. The intention isn't for the walking-skeleton to be used by a customer, but for the work that couples the product teams to each other to be mostly resolved before the teams proceed with delivery of their own backlogs. Moreover, once the walking-skeleton is built it allows all teams to continuously integrate their code mitigating the risk of late integration."

3. Het is meer geïntegreerd dan de 'backbone' uit SoEx​

In het vak SoEx heb je ook een Backbone gemaakt, namelijk een verzameling van PoCs - proof of concepts. Dit is een soortgelijke aanpak, maar in een walking skeleton is de code MEER geïntegreerd.

Dit is ook omdat je een build proces voor je product/producten hebt. Dus alles compileert samen, en er is ook al enige mate van code kwaliteit en consistentie in de code via het gebruiken van dezelfde linters voor back-end en front-end. Zorg dat je als team een product hebt, zowel functioneel. Er geldt ook:

"When we follow this property, a user familiar with one part of a system feels comfortable using another part, as the features and user interface remain consistent."

Dit is overigens de design property conceptual integrity die we bij SoEx lessen tegenkwamen (Valente, 2023). Dus alle code zit meer een project, of set van soortgelijke projecten bv. front-end en back-end. Denk aan een project met 1 pom.xml, behalve dan dat je waarschijnlijk geen Java/Maven project hebt, maar een project in een andere technologie/programmeertaal en/of ontwikkelstack.

Merk hierbij overigens op dat 'backbone' in SoEx weer anders is dan de backbone die je in DoEx kreeg, namelijk de backbone van de user story map (USM).

4. Je skeleton is typisch 'full stack'​

Aangezien volgens de quote van '67 bricks people' een Skeleton "an end-to-end process" proces demonstreert, en 'bare bones functionality will be included' kun je deze typisch ook een front-end geven naast een back-end. In de 3 weken van SoEx was geen tijd voor een front-end en waren wat fictieve screenshots al gegeven in de opdracht.

Gil Zilberfeld (2023) geeft ook aan dit direct vanaf het begin te bouwen:

"Well, a walking skeleton is a metaphor for a thin start of an end-to-end application. Whatever it is, it's running from the start. And as we're adding features, it continues to run." "Now, that's cool and all, but this doesn't just happen. You need to create an application like that, so it runs from the first build. It just doesn't need to do everything."

De developers die na de elaboration jullie project oppakken en de construction fase ingaan moeten dus al zo'n skeleton applicatie hebben.

In dit grotere project met een externe opdrachtgever is een mock-up of zelfs al deels gerealiseerde deels implementatie ervan een goed middel om:

  • domein onzekerheden/risico's uit te sluiten (via demo's geven aan OG/PO)
  • en ook een technische goede integratie van front-end en back-end te valideren/demonstreren

walking skeleton

Figuur 1: Walking Skeleton met front-end en back-end (Zilberfeld, 2023)

Zeker als je 'Usability' een relevante Quality Attribute hebt ligt een front-end voor de hand. Een Desktop UI zoals Figuur 1 (Zilberfeld) toont is wellicht minder voor de handig liggend. Hoewel als een opdrachtgever je dit vraag je je 'Web skills' (HTML, CSS, React. etc.) ook prima kan inzetten met kort onderzoek naar GUI technologieen als Electron, Tauri, etc.

iso 25010

Figuur 2: ISO 25010 (Souza, 2024)

Ook zeker als integratie van front-end en back-end niet de standaard AJAX/RESTful API interface is die je tot aan dit semester hebt geoefend en leren kennen. Een desktop app (Bijvoorbeeld: als je iets als GraphQL gaat gebruikenof een andere technologie die nog niet in course voorkwam, geavanceerdere technologieen als RabbitMQ, Kafka, gRPC, of gewoon REST interface maar een mobiele app als front-end hebt. Zelfs een uitgebreidere Command Line Interace (CLI/Console) applicatie kun je als front-end beschouwen.

NB: Er zijn ook projecten waar een front-end niet van toepassing is of risico vormt of uitsluit, maar dit zal wel de uitzondering zijn, dus stem dit af met je begeleiders en Opdrachtgever (OG).

5. USM backbone vs Code backbone​

Er is wel een relatie tussen deze twee backbones, namelijk de USM backbones toont de essentiele features van je product (te pndersteunen user activities) zoals je eliciteert bij de opdrachtgever (en kan checken of het klopt). De code backbone bevat een uitwerking van technisch riskante activities of delen van activities uit je 'USM backbone'.

Bronnen​

tip