Den Geist auf eine bewegliche Frequenz einstellen

    Seit langem und erfolgreich unterstützen wir eine Vielzahl von Spezialisten dabei, ihr eigenes Wissen in allen möglichen Bereichen zu teilen - Management und Management, das im Laufe der Zeit immer relevanter wird. Gleiches gilt für Entwicklung, Design und Architektur.

    Allmählich sammelten wir wichtige Designtechniken aus grundlegenden Methoden und architektonischen Standards und übersetzten sie in die menschliche Sprache. Wir haben unsere eigenen Erfahrungen und Arbeitslösungen unserer vielen Kunden zusammengeführt und infolgedessen eine Reihe von Schulungen erhalten. Gleichzeitig ist ihr Format praktisch, daher werden die Teilnehmer die meisten Entscheidungen selbst treffen, was eine enorme Umsetzung der Fähigkeiten in die Anwendung in der Produktion ermöglicht.

    Für wen :
    • Ingenieure: Architekten.
    • Technische Manager: Teamleiter und technische Leiter.
    • Manager: Projektmanager und Produktmanager
    Erfahrung am Start :
    • Bevorzugte Erfahrung in der industriellen Entwicklung von 2 Jahren.
    • Designkenntnisse sind im Rahmen des Kurses Agile Mindset in System Design erforderlich, insbesondere für die Teilnahme an der Fortbildung: Agile Mindset in Solution Design.

    Das Bild teilt alle verfügbaren Erfahrungen in zwei große Komponenten eines Ganzen auf


    Agile Denkweise im Systemdesign . Anforderungen, Architektur, Prozess

    Denken Sie daran, wann Sie das letzte Mal mit aller Kraft die Stärken einer architektonischen Lösung unter Beweis stellen mussten, aber nie erfolgreich waren. Oder, wenn Sie auf den ersten Blick triumphierend eine absolut richtige Lösung vorgestellt haben, die später völlig versagt. Solche Momente werfen eine Reihe von fairen Fragen auf: „Was habe ich falsch gemacht? Wie können Sie Ihre Sichtweise richtig und logisch darstellen? Was ist der Unterschied und wo liegt die Grenze zwischen bewussten und informierten architektonischen Lösungen und einem amateurhaften Ansatz? “

    In dieser Schulung geht es um gesunden Menschenverstand - um die Gültigkeit technischer Lösungen angesichts von Unsicherheit. Wir analysieren, wovon technische Entscheidungen abhängen, und lernen, diese klar zu belegen. Überlegen wir uns, was die Erwartungen an die Architektur sein sollen und ob Sie sie überhaupt in Ihrem Projekt haben. Wir werden lernen, technische Konflikte objektiv zu lösen, und Sie werden das Wort "holivar" für immer vergessen. Sehen Sie sich Designmuster ganz anders an und holen Sie das Beste aus ihnen heraus. Wir werden verstehen, wie Dokumentation für das System effizient erstellt werden kann, damit es wirklich funktioniert, anstatt nur schreibgeschützt zu sein. Wir werden lernen, wie wir uns bei unseren Entscheidungen konzentrieren und schließlich herausfinden, wo wir anfangen sollen - mit dem Datenbankschema oder dem „Concurrency Design“. Und eines der wichtigsten Dinge im Training ist das Erlernen, nicht zu viel zu arbeiten.

    Agile Mindset Systems Engineering-Schulungsprogramm
    • Problemstellung
    • Vorstellung und Sammlung der Anliegen der Teilnehmer
    • Trainingsrückblick
    • Teamzusammenbruch
    • Warum Architektur gebraucht wird - wie man ein Projekt nicht ruiniert
    • Was ist Architektur?
    • Wo liegt die Grenze zwischen Mikrodesign und Architektur?
    • Wer konsumiert architektonische Artefakte?
    • Auf welche Antworten sollte die ausgewählte Architektur reagieren?
    • Architektur als Risikoplan - kompensieren Sie die Unsicherheit der Zukunft
    • Welche Quellen für Projektrisiken können wir herausgreifen?
    • Wie können Sie frühzeitig auf externe Risiken in Ihrer Architektur eingehen?
    • Wie können die internen Risiken in Ihrer Architektur frühzeitig angegangen werden?
    • Die Grenzen des Systems und wie man sie behebt
    • Architektur als Projektplan - zur Steigerung der Produktionseffizienz
    • Was sind die Anforderungen an die PM / RP-Architektur?
    • Wie kann ich einen Projektplan für Architektur erstellen?
    • Ist der kritische Pfad sichtbar?
    • Wie wird die Arbeit parallelisiert?
    • Architektur als Komponentenanforderungen - bieten Flexibilität und senken die Supportkosten
    • Auf welche Annahmen stützen wir uns beim Entwurf von Standardkomponenten oder externen Systemen?
    • Wie können wir unsere Erwartungen an externe Komponenten formulieren?
    • Wie begegnen wir den Risiken einer Nichteinhaltung unserer Erwartungen?
    • Anforderungen an die Architektur: der Anfang der Checkliste - was nicht zu vergessen und nicht zu verpassen
    • Architekturmethodik - wie man technische Entscheidungen zugunsten der Geschäftsanforderungen trifft und Entscheidungen für das Geschäft transparent macht
    • Was entscheidet über Design und Architektur? Wo finde ich Antworten, um sie zu rechtfertigen?
    • Wie kann die Unsicherheit der Anforderungen ausgeglichen werden?
    • Wie kann man methodische Entscheidungen rechtfertigen?
    • Architektur als Funktion der Anforderungen - wie Sie das tun, was Sie brauchen, Nacharbeiten reduzieren und die Kundenzufriedenheit steigern
    • Welche Arten von Anforderungen können unterschieden werden?
    • Wie können „kritische Pfade“ in Anforderungen definiert werden?
    • Wie definieren Anforderungen Systemgrenzen?
    • Was kennen Sie vom typischen Anforderungsprofil → typischen Architekturübergängen?
    • Getrennt von der Skalierbarkeit
    • „Kompromiss“ und „Spezialisierung“ - wie man Entscheidungen im Falle eines konstruktiven Erwartungskonflikts trifft
    • Was sind die Anforderungen?
    • Wie können technische Lösungen diese Beziehungen zwischen Anforderungen angehen?
    • Wie man sich auf Designmuster bezieht - ihren Wert und ihre Probleme
    • Architekturperspektiven und Architekturdokumentation - wie Sie Ressourcen gezielt einsetzen und Risiken frühzeitig angehen
    • In welcher Form können architektonische Entscheidungen dokumentiert werden? Welche Artefakte können ausgestellt werden?
    • Was ist wichtiger - DB-Schema oder Concurrency-Design?
    • Wann und was ist zu dokumentieren?
    • Architekturanforderungen: Fortsetzung Checkliste
    • Architekturmethodik - Entwurf unter Bedingungen äußerer Unsicherheit
    • Was machen Sie, wenn Sie zukünftige Änderungen nicht kennen?
    • Achse der Variabilitätsanforderungen
    • BDUF gegen YAGNI
    • Einkapselung der Variabilität
    • Architekturmethodik - Entwurf unter Bedingungen interner Unsicherheit
    • Die Erwartungen der wichtigsten Komponenten basieren auf den Anforderungen
    • Frühzeitige Überprüfung wichtiger Verträge
    • Externe und interne Expertise, Wireframe-Prototypen
    • Tests als frühe Vertragsüberprüfung
    • Architekturanforderungen: Prüflistenabschluss
    • Letzte Retrospektive: Was morgen in der Produktion verwendet werden soll




    Agile Denkweise beim Entwerfen von Lösungen . Prozess, Team, Kultur, Geschäft

    Sehen Sie sich das Bereitstellungssystem und die Lösungsarchitektur Ihrer Produktionssoftware an. Können Sie die Wahl der prozessualen und architektonischen Ansätze anhand von Geschäftsmetriken und Unternehmensstrategien eindeutig belegen? Wie Teams strukturiert sind, wie die Kommunikation aufgebaut ist und wie der Architekturprozess organisiert ist - liefert dies die für das Geschäft erforderlichen Metriken?

    In diesem Training geht es um branchenerprobte Architektur-, Prozess- und Organisationsstrukturen und deren sinnvolle Auswahl. Das heißt, wie man den architektonischen Prozess und die Struktur der Produktion aufbaut, um den Bedürfnissen des Unternehmens gerecht zu werden.

    Wir werden verstehen, warum eine zu frühe oder zu späte Lösungsarchitektur Schmerzen bereitet und wie man sie misst und ihre Risiken verfolgt. Lassen Sie uns sehen, wie Sie die Qualität des Produkts in einem frühen Stadium sicherstellen können. Wir werden lernen, wie Prozesse aufgebaut werden können, um die Lieferzeit zu verkürzen, ohne das Personal zu erhöhen, und wie die Architektur einen solchen Prozess unterstützen sollte. Wir ermitteln die optimale Teamstruktur, um die Liefergeschwindigkeit und die Produktqualität zu erhöhen. Wir lernen, welche Faktoren für die Architektur wichtig sind, aber wir ignorieren sie hartnäckig und sammeln einen Rechen.

    Wir werden verstehen, wie das Geschäftsmodell unseres Unternehmens zur Schaffung und Pflege von Architektur beiträgt.

    Agile Mindset Solution Design-Schulungsprogramm
    • Problemstellung
    • Vorstellung und Sammlung der Anliegen der Teilnehmer
    • Trainingsrückblick
    • Teamzusammenbruch
    • Entstehungs- und Entwicklungsmuster der Architektur - wenn Sie Entscheidungen treffen müssen und nicht müssen
    • Metriken für Architektur und Design - wie man die Dynamik von Änderungen und die "heißen" Bereiche des Systems misst
    • Metriken
    • Die Vorteile von Metriken
    • Sonar-Demo
    • Überprüfung und Validierung der Architektur - wie Sie ein Qualitätsprodukt liefern und Fehler so früh wie möglich erkennen
    • Architektur als Funktion des Prozesses - wie man erfolgreiche Projekte macht
    • Was ist ein Prozess / eine Methodik?
    • Welche Arten von Entscheidungen werden auf dieser Ebene getroffen?
    • Wie kann man mit der Unsicherheit der Anforderungen umgehen?
    • Wie kann man die Zykluszeit verkürzen?
    • Wie können Entscheidungen auf ausübende Künstler übertragen werden?
    • Wie können Sie gemeinsam mit einer Codebasis arbeiten?
    • Moderne Prozessvorlagen - Inkrementelle Architektur
    • Moderne Projektmanagement-Vorlagen: Matstat, Theorie der realen Optionen, Theorie der Einschränkungen, reduzierter WIP
    • Interaktion der Rollen im Projekt
    • Die fraktale Natur von Projekten - warum wir Fehler bei der Bewertung machen
    • Mehrere Skript-Trails
    • Architektur als Funktion der Unternehmensstruktur - wie man ein Produktionssystem für eine schnelle und qualitativ hochwertige Lieferung aufbaut
    • Matrix gegen Feature-Teams
    • Architektur als Funktion des Team-Management-Modells - Aufbau von Kommunikation für eine schnelle und qualitativ hochwertige Bereitstellung
    • Kollektives Eigentum am System: Vorlagen, inkl. DDD
    • Architekturanforderungen: Fortsetzung Checkliste
    • Architekten als Funktion von Altsystemen - Lösungsarchitektur
    • Wiederverwenden
    • Spezialisierung gegen Generalisierung
    • Die Rolle von Dokumentation und Tests
    • Flexibilität bei Architekturentscheidungen - die wir bei der Projektabwicklung nicht berücksichtigen
    • Welche Faktoren hängen von fundierten technischen Lösungen ab?
    • Architektur als Funktion des Vertrauens des Teammanagements
    • Architektur als Funktion des Vertrauens des Teams in das Management
    • Architektur als Funktion der Unternehmensstruktur
    • Architektur als Funktion von Partnern
    • Architektur als Funktion der Unternehmenspolitik
    • Architekturanforderungen: Fortsetzung Checkliste
    • Architektur als Funktion des Geschäftsmodells des Unternehmens - wie Architektur Unternehmen zu Ergebnissen verhilft
    • Welche Geschäftsmetriken gibt es?
    • Welche Geschäftsmodelle gibt es?
    • Architekturanforderungen: Prüflistenabschluss
    • Letzte Retrospektive: Was morgen in der Produktion verwendet werden soll

    Ergebnisse und gewonnene Erfahrungen / Fachkenntnisse zu den Ergebnissen des Trainings



    Nach dem Training können die Teilnehmer:
    • Treffen Sie rechtzeitig architektonische Entscheidungen - nicht früher oder später - und optimieren Sie so die Kosten und Risiken des Projekts
    • „Diagnose durch Foto“ - Verstehen Sie den Projektstatus und die architektonischen Risiken anhand architektonischer Metriken
    • Es ist sinnvoll, Tools zur Architekturüberprüfung zu wählen, um die Produktqualität so früh wie möglich und ohne zusätzliche Kosten sicherzustellen
    • Passen Sie den Prozess mit minimalen Lieferzeiten an
    • Passen Sie die Teamstruktur und -kommunikation an und verbessern Sie so die Geschwindigkeit und Qualität technischer Entscheidungen erheblich
    • Reduzieren Sie die Kosten für neue Lösungen, indem Sie vorhandene Systeme effizient wiederverwenden
    • Besseres Verständnis der Top-Management-Geschäftslösungen und Unterstützung der Geschäftsstrategie in der Systemarchitektur
    • Prüfen Sie die vorhandene Architektur auf Übereinstimmung mit den Geschäftszielen und -strategien - wählen Sie die wichtigsten Punkte für ein schnelles Refactoring aus
    • Es ist vernünftig, architektonische Entscheidungen zu treffen und sie mit Vernunft zu verteidigen
    • Bieten Sie die notwendige architektonische Flexibilität
    • Reduzieren Sie die laufenden Kosten, indem Sie sich klar auf wirklich wichtige Themen konzentrieren
    • Reduzieren Sie Kosten und Risiken zukünftiger Unterstützung
    • Lösen Sie Konstruktionskonflikte einfach und effizient - ohne Fluchen, Beleidigungen und Dramen
    • Es ist vernünftig, technische Entscheidungen angesichts von Unsicherheiten zu treffen - wenn nicht klar ist, was und wie zu tun ist
    • Beschleunigen Sie die Zustellung durch sinnvolle Parallelität
    • Verstehen Sie die Bedürfnisse und Denkweisen eines Unternehmens - geben Sie dem Unternehmen die Informationen, die es wirklich benötigt, über den Status des Projekts
    • Erstellen Sie den Herstellungsprozess mit minimalem Aufwand neu, um die Lieferzeit zu verkürzen und die Qualität zu verbessern


    Trainer: Evgeny Krivosheev
    Verfügt über sieben Jahre Erfahrung in der Entwicklung und Vermittlung von Technologien auf den Plattformen J2SE, J2EE, BEA Systems, IBM sowie in der parallelen Entwicklung. Seine Erfahrung ermöglicht es ihm, als Architekt bei der Entwicklung großer kommerzieller Systeme zu fungieren und einem breiten Spektrum von Menschen komplexes technologisches Wissen zu vermitteln.

    Ein paar einfache Fragen bezüglich des Potenzials und des Anreizes zur Teilnahme an der Schulung an Jewgeni Kriwoschew:

    - Eugene, wer ist die Zielgruppe der Agile Mindset-Ingenieurschulung im Allgemeinen? Welche Experten werden das Beste daraus machen?
    Unsere Schulungen richten sich an durchschnittliche (reguläre) Entwickler und mehr Fachkräfte.

    Nachwuchsentwickler sind vielleicht auch an Schulungen interessiert, aber nachdem sie sich mit den Grundlagen von Agile vertraut gemacht haben. Die zweite Schulung, die sich nicht mehr auf Architekturen, sondern auf bestimmte Prozesse und Geschäftsmodelle konzentriert, dürfte für Junioren schwierig sein, da sie nicht nur für Senior-Entwickler, sondern auch für Architekten und PMs mit Entwicklungserfahrung gedacht ist.

    Auf die eine oder andere Weise besteht die Essenz der beiden Schulungen genau darin, „End-to-End“ -Regeln für Entwickler, Architekten, Projektmanager, Ressourcenmanager, Produktmanager und vielleicht sogar Eigentümer festzulegen. Dies geschieht, um ein einziges Entscheidungsmodell zu erhalten.

    Das Ziel ist auch, dass das Engineering dem Geschäft hilft und nicht einmischt. Es hat geholfen, das System zu entwickeln, mehr Geld zu verdienen und andere Probleme zu lösen: Verkürzung der Lieferzeit (Time-to-Market), Erhöhung der Vorhersehbarkeit und Verbesserung der Systemqualität.
    Zu diesem Zweck ist es wichtig , dass die Ingenieure von Unternehmen gehört haben, und das Geschäft leicht Fragen von Ingenieuren beantwortet

    Wie genau Engineering Entscheidungen zu treffen? Wie baue ich Architektur? Wie kommuniziere ich? Beide Trainings sollen diese Fragen beantworten und helfen, eine Lösung zu finden.

    - Welche praktischen Fähigkeiten oder Techniken können während des Trainings erlernt werden?
    Das Wichtigste ist Kommunikationsfähigkeit. Während des Trainings lernen wir, in einer einzigen Sprache zu kommunizieren und zu verstehen, was andere Rollen im Prozess der architektonischen Gestaltung bestimmt. Die meisten Probleme des Software-Engineerings beruhen unserer Meinung nach in erster Linie auf der Kommunikation: Sie hören die Rollen des anderen nicht, arbeiten nach unterschiedlichen Konzepten und gehen nicht über die „operativen Mauern“ hinaus.

    Die zweite Fähigkeit ist ein spezifischer Satz von Techniken und Mustern des Systemdesigns. Diese Fähigkeiten können verfahrenstechnisch und technisch sein.

    Wie lassen sich Arbeit und Architektur in einem sich ständig ändernden Anforderungsfluss aufbauen? Dazu benötigen wir methodische Unterstützung (was?) Und spezifische technische Lösungen (wie?).

    - Warum ist Agile Mindset eine „Denkweise“ und wie hilft diese Denkweise beim Entwerfen großer Architekturen?
    Dieser ganze Teil der realen Welt ist in zwei ziemlich große Teile unterteilt: die Welt der formalen oder sequentiellen Methoden und Prozesse und die Welt der flexiblen Methoden und Prozesse (weniger formale Anfangseinstellungen, mehr Reaktion auf das, was in Echtzeit geschieht).

    Der Nutzen für die Teilnehmer drückt sich in folgender Metapher aus: „Endlich sind die Aufgaben erledigt!“. Formale und konsistente Ansätze erfordern eine lange Rückkopplungsschleife - viel Zeit vergeht zwischen der Idee und der Umsetzung, viel Aufwand für die Kommunikation und die Überwindung verschiedener Hindernisse: bürokratisch, kommunikativ und möglicherweise organisatorisch.
    Was ist in der Welt der agilen Methoden wichtig? Eine relativ kleine Entwickler-Feedback-Schleife. Der Mitarbeiter sieht, dass das Ergebnis seiner Arbeit schnell umgesetzt wird und trägt zur positiven Motivation des gesamten Teams bei.

    Kommen Sie und implementieren Sie gesunden Menschenverstand in Ihrem Unternehmen!

    Jetzt auch beliebt: