Die Necromancer-Challenge entführt Sie auf eine spannende Reise in die Tiefen einer digitalen Gruft. Mit Kali Linux und jeder Menge Neugier spüren Sie versteckte Flaggen auf und stellen sich am Ende dem Duell mit dem Necromancer. Was zunächst wie ein Computerspiel klingt, entpuppt sich als intensive Hacking-Rätselei in einem sicheren, isolierten Netzwerk.

Im Webinar „Die Necromancer-Challenge: Lerne zu hacken“ führt c’t-Redakteur Wilhelm Drehling durch diese besondere CTF-Challenge (Capture The Flag).

Praxisnahe Einblicke in Hacking-Werkzeuge

Drehling hackt sich im Webinar durch alle elf Level. Um zum Ziel zu gelangen, greift er auf unterschiedliche Hacking-Tools zurück: Er klopft Server mit nmap ab, knackt Passwörter mit Hydra und analysiert den Netzwerkverkehr mit Wireshark. Dabei verzichtet er bewusst auf Fachchinesisch und trockene CVE-Tabellen. Stattdessen erwarten die Teilnehmer viele Aha-Momente. Sie gewinnen ein Gefühl dafür, wie man eine solche CTF-Challenge systematisch angeht und erfahren, wie sie ein eigenes, sicheres Hacking-Netzwerk aufsetzen.

Konzentrieren Sie sich während des Webinars zunächst auf das Geschehen am Bildschirm und werden Sie erst später selbst aktiv. Als Teilnehmer erhalten Sie Zugriff auf die Aufzeichnung sowie die begleitenden c’t-Artikel, um das Gelernte im eigenen Tempo nachzuvollziehen.

Vom Zusehen zum Selbermachen

Das c’t-Webinar richtet sich an alle Menschen, die Lust aufs Hacken haben, egal ob Anfänger oder mit Vorkenntnissen. Sie entwickeln ein Gespür für Angriffsmethoden und lernen, Schwachstellen zu identifizieren. Wilhelm Drehling gibt außerdem wertvolle Tipps zu Lernplattformen, Kali-Alternativen und hilfreichen Tools.

Das Webinar findet am 16. September von 15 bis 18 Uhr statt. Zur Teilnahme benötigen Sie lediglich einen aktuellen Browser. Sichern Sie sich jetzt Ihren Platz zum Frühbucherpreis von 59,00 Euro und stellen Sie sich der Herausforderung, den Necromancer zu besiegen! Alle weiteren Informationen sowie Details zur Anmeldung finden Sie auf der Webseite von heise academy.

(abr)

Wie spannend und neuartig wird Apples erstes iPhone-Foldable? In einem Bericht hat die Finanznachrichtenagentur Bloomberg nun die möglichen Hardware-Details eingeordnet, die das im Herbst 2026 erwartete Gerät mitbringen soll. Zwar gilt die alte Apple-Annahme, dass der Konzern mit seinen Produkten zwar nicht als Erstes auf den Markt kommt, aber letztlich das beste Produkt einer Kategorie ausliefert, weiter. Beim faltbaren iPhone besteht jedoch die Gefahr, dass es „nicht der innovative Durchbruch wird, den wir gewohnt sind“, so der Bericht.

Nah an Samsung gebaut?

Der Grund: Apple ist diesmal sehr spät in dem Markt. Konkurrent Samsung hatte bereits vor sieben Jahren damit begonnen, Foldables zu verkaufen und verbesserte diese stetig. Das Galaxy Z Fold 7 aus diesem Jahr ist nun nochmals dünner und leichter geworden. Apples wichtigste Innovation beim ersten iPhone-Foldable soll ein faltenloses Display im aufgeklappten Zustand sein. Das will der Konzern über spezielle Metallplatten erreichen. Allerdings ist bereits zu hören, dass auch Samsung im kommenden Jahr auf diesen Ansatz setzen könnte. Zudem dürfte das erste faltbare Apple-Smartphone auch nicht das dünnste Gerät auf dem Markt werden, schätzen Beobachter.

Bloomberg schreibt weiter, dass Samsung den Markt für Apple vorbereitet habe. „Samsung hat bereits viel der Schwerstarbeit geleistet.“ Beim iPhone-Foldable sei zudem nicht damit zu rechnen, dass der Hersteller ein „radikal neues Interface“ oder eine „transformative Hardware“ plane. Stattdessen werde das iPhone-Foldable „ein ähnliches Design wie das Galaxy Z Fold“ haben, „mit vielen der gleichen Kernkomponenten“. Tatsächlich soll etwa das flexible OLED-Display von der Samsung-Bildschirmtochter Samsung Display stammen.

Die Nachfrage bei Apple ist real

Allerdings könnte Apple mit dem ersten iPhone-Foldable dennoch eine wichtige Nische erobern: Der Grund: Foldables an sich sind noch kein Massengeschäft. Das liegt unter anderem am Preis (Apple plant angeblich 2000 Euro und mehr), andererseits auch daran, dass nicht jeder Smartphone-Käufer den Formfaktor schätzt. Doch bei Apple gibt es unter iPhone-Fans eine große Gruppe, die Lust darauf hat, etwas Neues auszuprobieren. „Diese aufgestaute Nachfrage ist real, und Apple weiß das“, schreibt Bloomberg.

Außerdem plane Apple, zumindest einige wichtige Defizite der Technik anzugehen. Dazu gehört besagte „Faltenfreiheit“ ebenso wie ein deutlich verbesserter (und haltbarer) Klappmechanismus. Hinzu kommen Software-Funktionen, die speziell für die Plattform angepasst sind: Bereits jetzt scheinen Vorbereitungen zu laufen. Schließlich könnte ein iPhone-Foldable auch in China punkten, wo die Geräte schon jetzt eine relativ beliebte High-End-Kategorie sind – mit Modellen, die bislang gar nicht offiziell im Westen gelandet sind.

(bsc)

User Stories sind aus der agilen Produktentwicklung kaum wegzudenken, dennoch verursachen sie regelmäßig Reibung, Missverständnisse oder sogar echten Schaden im Entwicklungsprozess. In dieser Folge schauen sich Oliver Winter und Tim Klein die größten Fehler bei der Arbeit mit User Stories an und sprechen offen darüber, wie sie selbst immer wieder in diese Fallen getappt sind.

User Stories: Die fünf häufigsten Fehler

Die größten Fehler im Umgang mit User Stories sind kurz formuliert:

1. Wir schreiben User Stories
2. Wir nehmen User Stories ab
3. Wir definieren Lösungen
4. Wir schneiden User Stories falsch
5. Wir pressen alles ins User-Story-Format

Ein häufiger Fehler beginnt schon beim Schreiben: Statt sich gemeinsam ein Bild vom Nutzerproblem zu machen, werden Stories im stillen Kämmerlein formuliert und (nur) in Schriftform ins Sprint Planning gebracht. Dabei soll die Story eher ein Erinnerungspunkt für ein Gespräch sein, nicht das Gespräch ersetzen. Die Diskussion über das zugrundeliegende Problem, also das gemeinsame Verstehen der Nutzerbedürfnisse, ist der Schlüssel. Storytelling und Entwickeln von Problemempathie mit dem Team führen zu besseren Lösungen. Und genau dafür braucht es ein Gespräch, kein perfekt ausgefülltes Template oder „Ticket“.

Der nächste Trugschluss: User Stories müssten irgendwie „abgenommen“ werden. Diese Idee stammt noch aus einer Projektlogik und widerspricht dem agilen Grundgedanken. Akzeptanzkriterien dienen nicht als Vertrag, sondern als Einladung zur gemeinsamen Einschätzung: Haben wir das gemeinsam verstandende Problem gut genug gelöst? Abnahme-Rituale im Sprint Review mit „Daumen hoch oder runter“ führen hier meist in die Irre. Vielmehr geht es um Reflexion, ob die gefundene Lösung zum Nutzerproblem passt – im besten Fall sogar mit Feedback der eigentlichen Nutzerinnen und Nutzer.

Besonders schädlich wird es, wenn Product Owner anfangen, in User Stories ihre Lösungen detailliert vorzugeben. Dann bleibt wenig Raum für Kreativität oder bessere Ideen aus dem Team. Eine gute User Story wird im Problemraum formuliert und darf dabei auch gerne eine Lösungsidee mitbringen. Sie macht Wirkung und Ziel verständlich – nicht den genauen Umsetzungspfad. Wenn alles schon vorgegeben ist, gibt es keine echte Zusammenarbeit mehr.

Auch beim Schneiden von User Stories wird viel Potenzial verschenkt. Zu große Storys, die sich über mehrere Sprints ziehen, nehmen uns die Chance für kurzfristiges Feedback und verlangsamen damit die Lernkurve. Und wenn denn geschnitten wird, sorgen horizontale Schnitte entlang technischer Komponenten eher für Abhängigkeiten statt echten Mehrwert. Der Weg zu kleinen, vertikal geschnittenen Stories ist nicht immer leicht, aber entscheidend für schnelles Feedback bezüglich der erwünschten Wirkung (Outcome).

Und dann wäre da noch das „Connextra“-Template. Es kann helfen, den Einstieg zu finden. Aber wer alles in das Format „Als (Nutzer) möchte ich …, damit …“ zwängt, läuft Gefahr, das Denken zu verengen. Nicht jede Aufgabe ist eine User Story und nicht jede User Story braucht eine feste Form in diesem Template. Es braucht ein Gefühl für das Problem, nicht nur eine korrekt ausgefüllte Schablone.

Der größte Fehler ist oft der Versuch, mit der falschen Haltung an User Stories heranzugehen. Wenn das Format über das Verständnis gestellt wird, wenn Gespräche durch Jira-Tickets ersetzt werden, wenn Stories zu Mikro-Aufträgen oder Fachfeinspezifikationen verkommen, geht der Sinn für die Arbeit mit User Stories verloren. User Stories sind ein Mittel zur Zusammenarbeit, kein bürokratischer Selbstzweck. Wer das versteht, nutzt sie, um gemeinsam zu denken, nicht nur um Aufgaben im Team zu dokumentieren.

Weitere Podcastfolgen

Die Podcaster verweisen in dieser Folge auf eine ganze Reihe früherer Episoden:

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Die fünf größten Fehler bei der Arbeit mit User Stories„.

(mai)