Veeam Indoor Kitchen: Wie der F & E-Prozess funktioniert

Der Abend. Ein weiteres F & E-Interview geht zu Ende und unsere Interviewer sind auf unerwartete Fragen eines zukünftigen Kollegen eingestellt. Aber keine Überraschungen: Auch hier funktioniert das von Wilfredo Pareto abgeleitete Verhältnis. In 80% der Fälle hören wir vier Fragen - ungefähr 20% der Gesamtzahl der eingegangenen Fragen. Wie ist Ihr Prozess aufgebaut? Was werde ich tun? Wie werde ich in einem Jahr Senior / Teamleiter? Was ist mit dem Umzug nach Europa?

In diesem Beitrag werden wir die erste Frage beantworten und über den Entwicklungsprozess in Veeam sprechen - von Team zu Team ändert sich diese Antwort am wenigsten.



Also der Prozess. Dies ist eine wiederholbare Folge von Aktionen, die jeden Tag oder zumindest manchmal zum Erfolg führen. Sie haben gelernt, wie man Borschtsch kocht, und jedes Mal ist es gleich lecker - ein Prozess. Das Parken ist kein Klopfen - beherrscht den Prozess. Der Prozess ermöglicht es dem Gehirn, nicht jedes Mal über eine Routine nachzudenken und sie in mechanische Arbeit umzuwandeln. Das Gehirn ist frei für Kreativität.

Der Entwicklungsprozess ist eine Abfolge von Aktionen, die die Wünsche der Benutzer in greifbare Produkte verwandeln. Diese Wünsche werden von Analysten und Produktmanagern formuliert, von Entwicklern implementiert, von Testern kritisch bewertet und von technischen Redakteuren beschrieben.

Wir bei Veeam stellen massive Produkte für die Sicherung und Replikation von Rechenzentren her, damit nichts verloren geht. Ein klassisches Boxprodukt ohne einen bestimmten Kunden. Auf den ersten Blick ist die Sache einfach, aber es gibt Nuancen, also machen wir es für das zweite Jahrzehnt.

Schauspieler

Jede Veröffentlichung ist das Ergebnis mehrerer Gruppen:

• Produktmanager oder Analysten . Sie priorisieren ihre Arbeit und kommunizieren mit der Außenwelt - Kunden und Partnern. Partnerschaft kann technologisch sein. Zum Beispiel kann ein Händler sagen, was ihm fehlt, um den Umsatz zu steigern, und ein Hersteller eines Hypervisors kann über Pläne für die Zukunft berichten. Für dieses Team sind „Sprechfähigkeiten“, die Fähigkeit, Trends in einem stürmischen Meinungsstrom zu erfassen und zu priorisieren, wichtig. Und dann verteidigen Sie die gewählte Position, sagen Sie nein, erklären Sie, warum etwas auf diese Weise getan wurde und nicht anders. Es spielt keine Rolle in Pressemitteilungen, auf Konferenzen oder privat. Diese Leute bilden die Welt des Verkaufs aus.
  
• Technischer Support Helpline für unsere Kunden. Die wichtigsten Indikatoren eines Teams sind die Reaktionszeit auf ein Problem und seine Lösungszeit (SLA). Im Laufe des Monats werden etwa einige tausend Anrufe bearbeitet. Das Team ist vielschichtig und umfasst sowohl Gruppen der Interaktion mit Kunden als auch Gruppen der Analyse von Anrufen, die Entwicklung von Problemumgehungen usw. Basierend auf den Informationen, die der Support erhalten hat, wird eine Liste mit Verbesserungen und Dringlichkeit formuliert - ob in einem privaten Fix implementiert, das nächste Update durchgeführt oder auf die Hauptversion verschoben werden soll.
  
• F & E-Entwickler . Personen, die Anfragen in Code umwandeln.
  
• Tester oder Qualitätssicherung . Erste Tester, ein Tankprüfbereich und ein Vibrationsstand gleichzeitig. Sie überprüfen nicht nur, was bereits implementiert wurde, sondern werden auch bereits in der Konzeptionsphase mit der Arbeit verbunden. Wenn Sie die Aufgaben von Administratoren in einer kampfnahen Infrastruktur wiederholen, ist es einfacher zu verstehen, wie bequem die erstellte Schnittstelle ist oder wie die ausgewählten Algorithmen produktiv sind. Wenn der technische Support zu dem Schluss kommt, dass das Produkt fehlerhaft ist, reproduziert die Qualitätssicherung die problematischen Szenarien und überwacht die Korrekturen.
  
• Team von technischen Redakteuren. Sie erstellen Endbenutzerdokumentationen sowie spezifische Dokumente wie „Funktionsweise“ und „Bereitstellungshandbuch“. Sie erhalten Material für die Arbeit von Entwicklern, Testern und Analysten.
  

Einige Teams bevorzugen Freiflächen, aber häufiger - Schränke

Teams sind über ein Anforderungsabrechnungssystem miteinander verbunden. Wir haben es auf der Basis des Microsoft Team Foundation-Systems implementiert, da wir es in der Vergangenheit als Speichersystem für die Quellversion verwendet haben. Das System speichert Anforderungen (Anforderungen), Fehler (Bugs) und Supportanrufe (Probleme), die die Teilnahme von QS und Entwicklern erfordern. An jeder Ausgabe sind Hunderte von Teilnehmern beteiligt, die an Tausenden von Aufgaben, Anforderungen und Fehlern arbeiten. Das System hilft dabei, all dies beizubehalten und, was noch wichtiger ist, die Last gleichmäßig zu verteilen und den Entwicklern Priorität einzuräumen.

Baumringe: Entwicklungszyklen

Die Entwicklung unseres Produkts erfolgt zyklisch. Jeder Zyklus endet mit der Veröffentlichung der nächsten Version - der Veröffentlichung. Folgendes spiegelt sich in den Veröffentlichungen wider:

• Lang anhaltende Markttrends . Zum Beispiel Virtualisierung und die Entstehung von Cloud-Infrastrukturen. Das Ändern der Paradigmen der IT-Arbeit dauert Jahre - zu diesem Zeitpunkt wechseln Benutzer von Misstrauen und Verleugnung ("Was zum Teufel ist das") zu Massenerkennung ("Ja, jeder tut es"). Die Virtualisierung von Rechenzentren auf einmal führte zu Veeam, da unter Virtualisierungsbedingungen alte Produkte zum Sichern von Maschinen unwirksam waren.
  
• Unterstützung für neue Plattformen . Es war einmal, dass Veeam nur für virtualisierte Rechenzentren gedacht war, die auf der VMWare-Plattform basieren. Angesichts der wachsenden Anzahl und Größe von Kunden besteht die Notwendigkeit, neue Plattformen zu unterstützen. Neben VMWare wurden weitere Hypervisoren (Hyper-V), physische Server, Cloud-Plattformen (AWS, Azure) usw. angezeigt.
  
• Taktische Veränderungen im Markt . Die nächsten Versionen von Betriebssystemen und Hypervisoren werden veröffentlicht. Erfahrungen werden mit früheren Versionen unseres Produkts gesammelt. Auf diese Weise erhielten wir beispielsweise Unterstützung auf Elementebene - selektive Wiederherstellung von gängigen Anwendungsservern wie Microsoft Exchange, Microsoft SQL Server, Oracle-Datenbanken usw.
  
• Mängel . Trotz all unserer Bemühungen ist das Leben ein Nein-Nein und es bietet Überraschungen. Natürlich versuchen wir sie zu minimieren.
  

Jedes Quartal erhalten wir Updates (Updates), ungefähr einmal im Jahr - Hauptversionen (Hauptversionen). Sie sind insofern gut, als sie den Aufwand für die Erstellung volumetrischer Funktionen im Zusammenhang mit der Unterstützung neuer Plattformen und dem Paradigmenwechsel minimieren. Aufgrund der Budgetangaben sind die IT-Abteilungen der Kunden zum Jahresende am aktivsten. Daher führen wir derzeit auch große Releases ein.

Vierteljährliche Updates haben hauptsächlich zwei Ziele: Unterstützung für neue Versionen geschützter Server und Fehlerbehebung. In Updates sammeln wir alle Korrekturen von Fehlern, die Kunden seit der Veröffentlichung der Hauptversion entdeckt haben. Mithilfe von Updates reagieren wir außerdem schnell auf Änderungen an unterstützten Plattformen. Gemäß den Bestimmungen des SLA muss Veeam die neue Version des Hypervisors in nicht mehr als drei Monaten unterstützen .
Und was ist, wenn das Produkt für einen bestimmten Kunden nicht funktioniert? In diesem Fall geben wir einen privaten Fix aus - mit anderen Worten eine Krücke. Solche Korrekturen werden jede Woche veröffentlicht und sind nicht immer mit Produktfehlern verbunden. Beispielsweise sind die Client-Sicherheitseinstellungen möglicherweise nicht mit dem Produkt kompatibel. Durch die Ausgabe eines privaten Fixes analysieren wir die Häufigkeit des Problems und entscheiden, ob der Fix in das nächste vierteljährliche Update aufgenommen werden soll.

Von morgens bis abends: Chronik veröffentlichen

Jeder Release-Zyklus beginnt mit der Planung - auf Produktebene als Ganzes und auf der Ebene einer einzelnen Anforderung. Im ersten Fall werden das Problem der Geschäftsprioritäten und die Verteilung der Anforderungen zwischen den Teams gelöst. Zunächst werden die dringendsten Anforderungen oder Epen besprochen. Auf eine gute Weise sollten nicht mehr als 60% des gesamten Arbeitsvolumens an der Veröffentlichung dem Epos zugewiesen werden, damit es ein Zeitpolster gibt. Die Produktplanung erfolgt auf der Ebene der Abteilungsleiter - Produkte, Tester, Entwickler.

Entwickler und Tester sind in Teams unterteilt. Die optimale Anzahl von Personen in einem Team beträgt fünf. Teams sind sowohl funktional als auch universell. Im letzteren Fall ist das Team autark und enthält Entwickler mit Fachkenntnissen in mehreren Bereichen. Funktionsbefehle sind enger fokussiert - sie wirken sich auf die Benutzeroberfläche, Systemkomponenten usw. aus. Mitarbeiter aus verschiedenen Funktionsteams bilden virtuelle Teams, die mit der Implementierung von Anforderungen beginnen. Hier versammeln sich zumindest Vertreter der PM-Gruppe, der Entwicklungs- und Testteams. Dem Teamleiter wird der Teamleiter eines der Funktionsteams zugewiesen.

Die Arbeit an der Anforderung beginnt. Das virtuelle Team trifft sich wöchentlich. Die Teilnehmer sprechen über die Erfolge der vergangenen Woche und planen die Arbeit für die nächste.
Der für die Moderation verantwortliche Teamleiter moderiert die Besprechungen und zeichnet die Ergebnisse auf. Er löst auch Probleme, die in einem virtuellen Team nicht gelöst werden können. Zum Beispiel, wenn Sie Daten verschieben oder einen Teil der Aufgaben verschieben müssen.

Innerhalb der Funktionsentwicklungs- oder Testteams sind die Kontrollpunkte enger beieinander angeordnet. Ein Wochenplan ist in der Regel in Aufgaben unterteilt, die nicht länger als zwei bis drei Tage dauern. Einige Teams haben Wurzeln in der Scrum-Praxis mit täglichen flüchtigen Bestandteilen geschlagen. Irgendwo arbeitet die Punkt-zu-Punkt-Interaktion zwischen dem Teamleiter und dem Team effizienter.


Typischer Besprechungsraum zur Erörterung des aktuellen Status des Projekts

Die gesamte Entwicklung ist in wöchentliche oder vierzehntägige Iterationen unterteilt. Während der ersten Iterationen müssen Sie eine minimal funktionierende Funktion erstellen, die anschließend zu Fleisch wird - beispielsweise eine erweiterte Benutzeroberfläche, eine API für Clients usw. Und am wichtigsten ist, dass das Vorhandensein eines Skeletts es Testern bereits ermöglicht, eine Funktion zu erhalten.

Der Release-Zyklus umfasst Alpha- und Beta-Releases. Mit ihrer Hilfe zeigen wir der Außenwelt neue Funktionen und sammeln im Voraus Feedback. Bei Bedarf werden Entscheidungen über Architektur oder Funktionalität geändert. Szenarien werden nicht sofort, sondern stapelweise in den Status Alpha und Beta versetzt. In der Regel befinden sich im Release-Zyklus etwa zwei Beta-Versionen.

Nach der Beta-Phase wechseln die Teams in den Regressionstestmodus. Zu diesem Zeitpunkt funktioniert das Produkt insgesamt bereits, die Benutzeroberfläche und die Skripte sind bereits gehärtet und ändern sich mit geringerer Intensität. Ein Team von technischen Redakteuren kommt ins Spiel. Gleichzeitig werden technische Supportteams geschult.

Regressionstests werden in zweiwöchigen Zyklen durchgeführt. Die Zykluszeit wird durch die Zeit bestimmt, die zum Anzeigen aller Produktszenarien erforderlich ist. Je größer das Produkt, desto mehr Szenarien und dementsprechend Zyklen. Vor der letzten Schleife wird ein Codeblock deklariert. Dies bedeutet, dass nur kritische Änderungen am Produkt vorgenommen werden - und dies erst nach zahlreichen Codeüberprüfungen. Solche drakonischen Methoden sind erforderlich, um nicht versehentlich neue Defekte in das Produkt einzuführen.

Je näher der Release-Moment rückt, desto mehr Freizeit haben die Entwickler und desto weniger alle anderen. Produktmanager müssen Pressemitteilungen erstellen und die Arbeit der Marketingdienstleistungen koordinieren. Tester sollten nach Korrekturen suchen und endgültige Regressionstests durchführen. Technische Redakteure fügen Benutzerdokumentation hinzu. Zu diesem günstigen Zeitpunkt entwickeln Entwickler Forschungsaktivitäten für die Anforderungen der nächsten Version.

Und hier ist es ein aufregender Moment namens RTM - Ready To Market. Dies bedeutet, dass das Produkt bereits zur Verteilung an die Verbraucher bereit ist. Innerhalb von zwei Wochen wird er von Journalisten und Dienstleistern gequält. Es wird bei Präsentationen gezeigt. Zwei Wochen später wird das Produkt für alle verfügbar sein. Zu diesem Zeitpunkt finden auch interne Änderungen statt: Neue Entwicklungszweige werden vorbereitet, Code wird hinterlegt. Und natürlich steigt die Build-Infrastruktur für die nächste Version. Nach der Veröffentlichung (GA) ist es eine heiße Zeit für technischen Support. Und der Rest arbeitet bereits an der nächsten Version.

Über Prioritäten

Und zum Schluss noch ein bisschen Hardware. Wie Sie wissen, können Sie in der Dreifaltigkeit "schnell, qualitativ hochwertig, kostengünstig" maximal zwei Optionen auswählen. Qualität, Timing und Funktionalität kämpfen ständig miteinander. Bei unserem Boxprodukt steht Qualität an erster Stelle. Hmm, aber in welchem ​​Bereich spielt Qualität keine Rolle? Natürlich nicht. Die ganze Frage ist die Qualitätsdefinition.
Qualität ist für uns:

• Wahrung der Zuverlässigkeit und Leistung in den Zoo-Konfigurationen . Ein Client verfügt über ein bescheidenes Rechenzentrum mit zwei Servern aus der Zeit der Schlacht von Borodino, während der andere über eine High-End-Infrastruktur in einem nahe gelegenen Hangar mit Amazon verfügt. Das Produkt sollte in beiden Fällen ausreichend funktionieren.
  
• Benutzerfreundlichkeit . Der Benutzer sollte sich mindestens anstrengen und ohne Anweisungen zurechtkommen. Eine ähnliche Einfachheit verbirgt sich jedoch keineswegs immer hinter der äußeren Einfachheit - versuchen Sie, sich nahtlos mit einem Igel zu kreuzen.
  
• Vererbung Die Investitionen in den Unternehmen sind langfristig und CFOs werden nicht ohne guten Grund für IT ausgegeben. Sie müssen also die Kompatibilität mit früheren Versionen und verwandten Produkten gewährleisten. Während des Wiederaufbaus von Rechenzentren werden häufig E-Mail-Server der 80er Jahre in der Wand eingemauert. Und sie alle summen und denken nicht daran zu sterben.
  

Mit solch einer Reihe von Prioritäten zur Erhaltung der Qualität müssen Sie immer etwas kombinieren, sowohl für Entwickler als auch für Tester. Kleine Änderungen im Verhalten von Funktionen können zu erzwungenen Integrationstests des Löwenanteils des Produkts führen. Versuchen Sie, dem Produkt Unterstützung für asiatische Ländereinstellungen hinzuzufügen, und verstehen Sie, worum es geht. Daher ist das Thema Prioritäten eine Frage der gemeinsamen Diskussion von PMs, Testern und Entwicklern.

Die zweite, fast unzerstörbare Priorität ist das Timing. Bei Aktualisierungen werden die Veröffentlichungstermine von der SLA festgelegt, bei großen Veröffentlichungen - vom Geschäftskalender. Laut Statistik werden in jedem Veröffentlichungszyklus fast 50% der Zeit für die Entwicklung aufgewendet, 50% für die Erinnerung an das Produkt (Bugfix-Phase).

Was sich ändern kann, ist die Funktionalität der nächsten Version. Hier hilft eine priorisierte Liste von Anforderungen oder ein Rückstand. Theoretisch ist alles einfach: Wählen Sie die nächste Prioritätsfunktion aus dem Backlog und sehen Sie sich die verbleibende Zeit an. Wenn die Zeit zu Ende ist, stoppen Sie und geben Sie die nächste Version des Produkts frei. Der Teufel ist in den Nuancen verborgen:

• Unsicherheit der Anforderungen . Beispielsweise kann die Anforderung, das Sichern physischer Maschinen unter OS Linux zu unterstützen, weiter verfeinert werden. Welche Kerne sollten unterstützt werden? Welche Distributionen? Welche Dateisysteme? Ein und dieselbe übergeordnete Anforderung kann in einem Monat oder einem Jahr implementiert werden. Die Frage ist vollständig.
  
• Teams haben Spezialisierungen . Nicht jede Anforderung kann von jedem Team übernommen werden. Der C # -Entwickler schreibt keine Treiber, der Entwickler von Systemkomponenten wird die Webentwicklung nicht immer bewältigen.
  
• Anforderungen hängen voneinander ab . Dies ist auf der Ebene der Benutzerszenarien nicht immer sichtbar, aber es gibt solche Beziehungen im Inneren. Aus Sicht der Außenwelt kann die Sicherungsunterstützung von NTFS- und ExtFS-Dateisystemen Anforderungen mit unterschiedlichen Prioritäten sein. Im Inneren müssen Sie jedoch zuerst eine gemeinsame Engine schreiben.
  
• Die Anforderungen werden in aufgeschobene und nicht aufschiebbare unterteilt . Wenn der Markt in der nächsten Version auf eine Funktion wartet und diese angekündigt wurde, funktioniert es nicht, sie zu verschieben.
  
• Ein Teil der Anforderungen betrifft die Forschung . Ohne die Ergebnisse der Forschung ist es unmöglich, die Komplexität der Aufgabe zu planen (vielleicht ist es überhaupt unmöglich), und es kann schwierig sein, diese Ergebnisse vorherzusagen.
  

Hier kommt die agile Entwicklung ins Spiel. Agile Entwicklung bedeutet für uns die Notwendigkeit einer regelmäßigen Sanierung. Neue Umstände wurden bekannt - veränderte Pläne. Neue Prioritätsanforderungen zum Rückstand hinzugefügt - geänderte Pläne. Wir haben keine Zeit mit unverzögerten Anforderungen - wir schneiden einen Teil der Aufgaben ab oder ändern die Anforderung. In der Theorie der technischen Steuerung wird dies als Rückkopplungssystem bezeichnet. Denken Sie daran, wie der Autopilot funktioniert.

Jede Planung unter den oben genannten Bedingungen beruht auf Expertenmeinung. Eine Expertenbewertung des Teamleiters ist das Element, das den gesamten nachfolgenden Prozess klar und strukturiert macht. Ein anderer Name für die Expertenbewertung ist „die leninistische Schielmethode“, wie Alexander Orlov von Stratoplan gerne wiederholt. Dies ist der Zeitpunkt, an dem Sie eine Entscheidung treffen, die auf früheren Erfahrungen und Ihrer Intuition basiert. Trotz möglicher Kritik funktioniert dies. Es funktioniert wie alle oben beschriebenen Prozesse. Wenn Sie noch Fragen dazu haben, bitten wir Sie um einen Kommentar.

Was weiter?

Die derzeitige Prozesstechnologie ist komfortabel und gemütlich wie Hausschuhe. Das einzige Problem ist, dass in Veeam immer eine unsichtbare Ahle Sie antreibt: schneller, mehr, mehr, mehr.
In jüngerer Zeit wurden Pilotbüros in Finnland und der Tschechischen Republik errichtet. In diesem Jahr bereiten wir die Eröffnung des Prager Forschungs- und Entwicklungszentrums für mehrere hundert Personen vor.


Die Lobby unseres Prager Büros

Kürzlich wurde in Israel ein Entwicklungsbüro eröffnet, und die Teams in Kanada und Deutschland wachsen. Die Anzahl gemeinsamer Entwicklungsprojekte mit HP, NetApp, Nutanix, EMC nimmt zu.
Die Manufaktur verwandelt sich in einen geografisch verteilten Förderer und gleichzeitig kristallisieren neue Prozesse. Dies ist jedoch ein Thema für einen separaten Artikel.
Bleiben Sie in Verbindung.