Über uns

triarc laboratories Ltd. wurde im März 2011 von Marco Bachmann, Serge Müller und Gabriel Katz gegründet. Unser Team besteht aus gut ausgebildeten Software-Ingenieuren, wobei sich einige nicht mehr dieser Arbeit widmen. Dennoch ist sichergestellt, dass alle das Handwerk der Softwareentwicklung kennen. Wir sind kommunikative, aufmerksame, kreative Denker,  die umsetzungsstark und hochmotiviert arbeiten.

Marco Bachmann

Senior Software Developer, Partner

Max Lüthi

Professional Software Developer

Pascal Bertschi

Professional Software Developer

Serge Müller

CEO, Partner

Detlef Engel

Sales

Elke Engel

Project Lead, Partner

Agiles Vorgehen nach triarc

... weil wir gerne wendig und flexibel bleiben

Grundsätzlich arbeiten wir agil nach Scrum. Jedoch interpretieren wir die Projektmethode nach unserem eigenen Gusto. Unsere Erfahrung zeigt, dass sich ein Prozess auch dem Team anpassen muss und dass ein kreativer Prozess auch immer weiterentwickelt werden muss.

In unserem Prozess gibt es drei Ebenen, die eng zusammenhängen:

  • das Projekt
  • der Sprint mit dem Kunden zusammen
  • der Sprint triarc intern

Formulierung der neuen Anforderungen

Um die Idee konkreter und greifbarer werden zu lassen, muss die Idee in Stückchen runtergebrochen werden. Wir nennen diese Stückchen User Stories. Eine User Story beschreibt aus der Sicht des Benutzers was er wo und wie erreichen will.

Bei der Erfassung der User Stories muss immer beachtet werden, dass man meistens nicht komplett auf der freien Spielwiese entwerfen kann. Dabei klären Sie die organisatorischen, prozesstechnischen und finanziellen Spielregeln. Wir prüfen die technischen.

Abklärungen zu den neuen Anforderungen

Aus der Erfassung und ersten Besprechung der User Stories ergeben sich häufig viele Fragen, die abgeklärt werden müssen. Dieser Punkt wird häufig unterschätzt, kann aber zu grossen zeitlichen Verzögerungen führen.

Betrieb und Wartung

Schliesslich geht die neue Funktionalität in den normalen Betrieb. Sollten noch Probleme auftreten, werden diese im Rahmen der Wartung behoben.

Sprint Planning

Im Sprint Planning definieren wir mit Ihnen zusammen den Inhalt des Sprints, d.h. welche Stories sollen umgesetzt werden. Dabei definieren Sie die Priorisierung der User Stories.

Sprint Review

Am Sprint Review demonstrieren wir Ihnen die Funktionen der einzelnen User Stories. Wir besprechen zusammen, ob dies so den Ansprüchen gerecht wird.

Testing

In diesem Testing testen Sie als Kunde die neuen Funktionalitäten. Für uns ist dieses Testing zentral, da Sie einerseits die Funktionalität kennenlernen, das Zusammenspiel mit Ihren internen Prozessen prüfen sowie die Funktionalität an sich.

Werden in diesem Testing Fehler gefunden, beheben wir diese zeitnah und spielen Ihnen eine korrigierte Version auf Ihre Testumgebung auf.

Wenn Sie den Sprint abnehmen, bereiten wir eine Installation auf der Produktivumgebung vor.

Integration

Die Integration beschreibt die Phase der Installation des Sprints auf Ihrer Produktivumgebung zu einem von Ihnen genannten Zeitpunkt. Zudem geht es unter Umständen um Datenmigrationen, Schulungen, Versand von Emails zu Beschreibung der neuen Funktionalitäten. Dies alles wird in Absprache mit Ihnen und in Abklärung mit Ihren internen Ressourcen umgesetzt.

Planning day

Der Planning day ist ein triarc interner Event. Am Planning day wird dem Entwicklerteam der geplante Sprint vorgestellt und zusammen wird die Umsetzung genauestens besprochen.

Die Entwickler erfassen detaillierte Arbeitspakete (Tasks) und schätzen den Aufwand zur Umsetzung.

Abschliessend wir anhand der zeitlichen Schätzung ein Merge Window definiert.

Entwicklung

In der Entwicklung gehts ans Handwerk: die User Stories werden umgesetzt.

Reviews

Wir haben die Erfahrung gemacht, dass es die Qualität und Produktivität steigert, Reviews durchzuführen.

Zu jeder grösseren User Story wird ein technisches Review mit einem anderen Entwickler durchgeführt. Die Entwickler besprechen die technische Umsetzung.

Jede demonstrierbare User Story wird der Projektleitung gezeigt und zusammen Funktionsweise und Usability nochmals besprochen.

Merge Window

Das Merge Window ist ein mit allen am Sprint involvierten Mitarbeitern definierter Termin auf den alle User Stories fertig gestellt werden sollen.

Testing

Nach dem Merge Window wird auf einer Testumgebung ein Release publiziert und vom Team ausgiebig getestet. Neben dem normalen „händischen“ Testen verwenden wir selbstverständlich schon in der Entwicklung Unit Tests und – wo möglich – automatisierte Tests. Im Testing werden vom Team Bugs erfasst.

Die im Testing gefundenen Bugs werden behoben. Die Codeänderungen werden von einem erfahrenen Entwickler gereviewt und zurück in den Programmcode gemerged.

Wenn der Sprint aus unserer Sicht voll funktionsfähig fertig gestellt ist, wird ein Release zusammen gestellt. Der Release wird auf einer dem Kunden zugänglichen Umgebung installiert.