SOLUTIONS.forge
Den Projektfortschritt jederzeit einsehen
Sie schauen in dieselbe Ansicht, in der wir arbeiten. Lesend, mit einer Ausnahme: Tickets für Fehler und Ideen legen Sie selbst an.
Der übliche Projektstand ist ein Bericht, geschrieben von dem, über den berichtet wird, und vorgelegt alle zwei Wochen. Dazwischen liegt eine Strecke, auf der niemand außerhalb des Teams weiß, was passiert. Fällt in dieser Zeit eine Entscheidung, erfährt der Fachbereich sie im nächsten Termin, wenn sie schon umgesetzt ist.
Warum wir den Rückstand mitzeigen
Wer den eigenen Projektstand offenlegt, kann ihn nicht kleinreden. Genau das ist der Grund, aus dem die meisten es nicht tun, und der Grund, aus dem wir es anbieten. Es kostet uns die Möglichkeit, eine schlechte Woche zu glätten, und es spart Ihnen die Rückfrage, ob der Bericht vollständig ist.
Was Sie sehen, ist keine Kopie und keine für Kunden gebaute Zusammenfassung. Es ist der Bestand, in dem unsere Entwicklung arbeitet, gefiltert auf Ihr Projekt.
Was in der Ansicht steht
Vier Bereiche, alle lesend.
Die Aufgaben und ihr Zustand
Jedes Ticket trägt seine Art, von der Anforderung über den Fehler bis zur Verbesserung, und einen von elf Zuständen: von offen über in Arbeit, automatisierte Prüfung, Durchsicht, eingereichte Änderung und Testumgebung bis erledigt. Dazu die Sprints, in denen sie geplant sind.
Was wo ausgerollt ist
Je Projekt die Umgebungen mit dem Stand, der dort läuft: Entwicklung, Test, Vorproduktion, Produktion und, wo es sie gibt, eine Vorführumgebung. Damit ist beantwortbar, ob eine Änderung schon dort ist, wo Sie sie ausprobieren wollen.
Das Wiki zur Anwendung
Die Dokumentation entsteht neben der Entwicklung, nicht danach. Jede Seite führt ihre Fassungen mit, sodass nachlesbar bleibt, was sich wann geändert hat und warum.
Was tatsächlich geändert wurde
Zu einem Ticket stehen die eingereichten Änderungen und die Auslieferungen, in denen sie enthalten sind. Der Weg von der gemeldeten Beobachtung bis zur ausgerollten Fassung ist damit eine Kette und keine Erzählung.
Was Sie selbst anlegen können
Schreiben können Sie an genau einer Stelle, und die ist die wichtigste: Sie legen Tickets an, für Fehler und für Ideen. Beides landet im selben Bestand wie unsere eigenen Aufgaben und wird in derselben Planung besprochen, statt in einer Sammel-E-Mail zu warten.
Alles andere ist schreibgeschützt. Das ist Absicht: Der Projektstand soll bleiben, was er ist, und nicht zum zweiten Ort werden, an dem abgestimmt wird. Wer wo mitreden soll, entscheidet weiterhin die Runde, in der das hingehört, siehe Ablauf eines Softwareprojekts.
Warum der Name
Ein Hauswitz, der zufällig gut beschreibt, was passiert: SOLUTIONS.designer entwirft den Rohling, SOLUTIONS.forge schmiedet ihn fertig. Im Designer entsteht das Modell und daraus das Grundgerüst; alles, was danach von Hand dazukommt, wird hier geplant, gebaut, geprüft und ausgeliefert.
Damit deckt SOLUTIONS.forge den Teil ab, der nach der Generierung übrig bleibt, und der entscheidet darüber, ob aus einem Grundgerüst eine fertige Anwendung wird.
Wie belastbar das ist
Wir betreiben unser eigenes Geschäft damit, und das ist die härteste Referenz, die wir geben können.
107
Projekte im Bestand
439
Tickets
über alle Projekte
295
Wiki-Seiten
3.115
eingereichte Änderungen
mit ihren Tickets verknüpft
Wo die Grenze liegt
Es ersetzt kein Gespräch. Wer den Bestand liest, weiß, was passiert ist, aber nicht, warum eine Abwägung so ausgefallen ist. Dafür gibt es weiterhin den festen Ansprechpartner und den Termin.
Es ist kein Produkt, das Sie kaufen. SOLUTIONS.forge ist unser Arbeitsgerät, wie der Designer auch. Der Zugang gehört zur Zusammenarbeit und nicht zum Lieferumfang.
Und es ist freiwillig. Manche Häuser arbeiten täglich damit. Andere wollen einen Ansprechpartner und einen Termin. Beides ist in Ordnung; wir fragen einmal und richten uns danach.
Weiterlesen
Häufige Fragen
Bekommt jeder Kunde einen Zugang?
Auf Wunsch ja, und dann auf dieselbe Ansicht, in der wir arbeiten. Wir fragen einmal danach und richten uns nach der Antwort: Wer lieber einen festen Ansprechpartner und einen Termin hat, bekommt den Projektstand dort, so ausführlich wie gewünscht.
Was darf ich dort ändern?
Lesen dürfen Sie alles, was zu Ihrem Projekt gehört. Schreiben können Sie an genau einer Stelle: Sie legen Tickets an, für Fehler und für Ideen. Alles andere ist schreibgeschützt, damit der Projektstand das bleibt, was er ist, und nicht zum zweiten Abstimmungsort wird.
Sehe ich auch, was gerade wo läuft?
Ja. Zu jedem Projekt stehen die Umgebungen mit dem Stand, der dort ausgerollt ist, von der Entwicklung über Test und Vorproduktion bis zur Produktion. Die Frage „läuft der Fehler, den wir gemeldet haben, schon auf Test?“ beantwortet damit die Anwendung und nicht eine Rückfrage.
Woher weiß das System, wann ein Ticket weiterrückt?
Aus der Entwicklung selbst. Wird ein Zweig geöffnet, ein Änderungsvorschlag eingereicht, eine Prüfung bestanden oder etwas ausgerollt, meldet das Entwicklungswerkzeug das an SOLUTIONS.forge, und das Ticket wechselt seinen Zustand. Niemand pflegt einen Status von Hand nach, und deshalb stimmt er.
Was steht im Wiki?
Die Dokumentation Ihrer Anwendung, gepflegt neben der Entwicklung statt danach: Was die Anwendung tut, wie die Abläufe gedacht sind, was bei Betrieb und Wartung zu beachten ist. Jede Seite führt ihre Fassungen mit, sodass sich nachlesen lässt, was sich wann geändert hat.
Was passiert mit meinen Tickets nach dem Projekt?
Sie bleiben stehen, und das ist der Sinn. Ein Fehler, der vor zwei Jahren gemeldet und behoben wurde, ist nachlesbar, samt der Änderung, die ihn behoben hat. Für die Wartung ist das oft wertvoller als für das Projekt selbst.
Ist das ein Dienst, den wir lizenzieren?
Nein. SOLUTIONS.forge ist unser Arbeitsgerät, wie SOLUTIONS.designer, und der Zugang für Sie gehört zur Zusammenarbeit. Ein Nutzungsrecht brauchen die Dienste, die in Ihrer Anwendung laufen.
Sprechen Sie mit uns.
Wir melden uns umgehend bei Ihnen.