Lesenswert KW50

Hinterlasse einen Kommentar
Lesenswert

Lesenswert KW35

Hinterlasse einen Kommentar
Lesenswert

Wie funktioniert Preisfindung im B2B-Sales? | The Art of Sales #7

Scaling, automatically and manually – The Isoblog.

Is an ‚oligopoly‘ of cloud vendors a risk to innovation? | Cloud Pro

The Actually Distributed Web | Linux Journal

deeplearning.ai

Karriere dank Blockchain: So könnte die Technologie Bewerbungen und Bildung aufmischen | ❤ t3n

When Government Rules by Software, Citizens Are Left in the Dark | WIRED

AI Programs Are Learning to Exclude Some African-American Voices – MIT Technology Review

Google DeepDream art: If an AI creates a work of art, who owns the rights to it? — Quartz

BT Exploring Open Data Center Switch Tech to Transform Its Network | Data Center Knowledge

Ambitious One-Gigawatt Data Center Planned in Norway | Data Center Knowledge

In nahezu Echtzeit nutzbar: Microsoft stellt neue KI-Plattform vor

Traditional Asset Tokenization – Hacker Noon

The Beginning of Uber – Garrett Camp – Medium

Inside Waymo’s Secret World for Training Self-Driving Cars – The Atlantic

Growing Up with Alexa – MIT Technology Review

Serverless Computing: Keine Server, einfach nur Code | ❤ t3n

Planung und Aufwandsschätzung in Projekten

comments 2
Projektmanagement

Als „klassischer“ Projektleiter ist man heutzutage gefühlt von der alten Schule. Uncool, nicht „agile“, nicht state-of-the-art. Die wenigsten haben halbwegs Ahnung über agile Methoden, aber lassen wir das an der Stelle…

Eine klassische Disziplin die man von Projektleitern erwartet, ist die Planung. Planung von Aktivitäten, Arbeitspaketen, Aufgaben und was es sonst noch so alles gibt. Selten wird der Planungsvorgang als klassische „handwerkliche“ Tätigkeit gesehen, meistens ist die Erwartung das der Projektmanager durch Magie oder Zauberkunst einen Plan erstellt. Einen Plan, der passen muss. Die sachliche Betrachtung ist ein Stück weit einfacher. Projektpläne entstehen in der Regel nicht durch Eingebung sondern durch sachliche Analyse. Analyse des Projektendproduktes, Zerlegung dieses in seine Einzelteile und dann Abschätzung der Aktivitäten und deren zeitlichen Aufwände.

Kurzum, 99% Arbeit und maximal 1% „Kreativität“.

Nachdem man die diversen Aktivitäten ermittelt hat, in der Prince2 Welt wird das oftmals über die Zerlegung des Ergebnisprodukts in Teilprodukte (Produktbasierte Planungstechnik), gilt es deren Aufwände abzuschätzen. Hier haben sich diverse Methoden (“Best Practice“) zur Schätzung ergeben, die teilweise auch im Prince2 Workbook so aufgeführt werden:

  1. Top-Down-Schätzung: Man nähert sich von oben an den Planwert. Typischerweise hilft diese Methode in einer frühen Phase oder bei einer sehr allgemeinen Aussage. Als Beispiel kann die Verteiler der Ressourcen dienen, es werden 30% Engineering und 30% Testing basierend auf Erfahrungen benötigt. Geht schnell, ist aber unpräzise.
  2. Bottom-Up Schätzung: Jede einzelne Aktivität wird für sich geschätzt. Das kann durch ausführliche Diskussion mit Fachexperten, vorausgegangenen Projekten oder Erfahrungswerten stattfinden.
  3. Vergleichsbasiertes Schätzen: Für mich ein zu häufig vernachlässigter Ansatz, dabei wird systematisch auf bestehende Daten zurückgegriffen. Im Laufe der Zeit sollten Organisationen mit Projekterfahrung einen entsprechenden Fundus an Daten besitzen. Leider wird aber oftmals beim Projektabschluss auf eine entsprechende Dokumentation verzichtet. Oder die Daten sind zu unstrukturiert.1 Im Idealfall besitzt man für bestimmte Aktivitäten aber Vergleichs- oder Referenzwerte, die der Projektleiter auf diese neue Planung anwenden kann.
  4. Parametrische Schätzung: Die offizielle Beschreibung lautet Ermittlung von Schätzwerten, wo immer möglich anhand von Messdaten/empirischen Daten und Korrelationsanalysen(…)“. Kollegen von mir haben eine Metrik, an der sie die Aufwände einer Infrastruktur basierend auf der Anzahl und Typ der eingesetzten Infrastrukturkomponenten hochrechnen können. Beispielsweise, x Loadbalancer mit y Regeln bedeuten ein Engineering Aufwand von z.
  5. Ein-Punkt-Schätzung: Nutzung/Berechnung eines einzelnen Wertes als beste Schätzung.
  6. Delphi-Methode: Sehr aufwendige Methode, da mittels Fragebögen und unabhängiger Befragung von diversen Gruppen (Experten, Fachfremde, etc.) Fragerunden geführt werden, die mittels Rückkopplung verfeinert werden.
  7. Drei-Punkt-Schätzung: Mittels der Drei-Punkt-Schätzung oder PERT-Schätzung habe ich bislang die besten Erfahrungen gemacht. Dabei werden Fachexperten gebeten den besten Fall, den wahrscheinlichsten Fall und den schlechtesten Fall einer Aktivität zu schätzen. Damit wird dann der gewichtete Durchschnitt errechnet.2 Als Formel dient (BestCase + 4 x LikelyCase + Worstcase) / 6

Im Rahmen einer seriösen „klassischen“ Planung gilt es zudem noch ein paar Regeln zu beachten:

  • Ressourcen sollten niemals zu 100% verplant werden, aus den bekannten Gründen (Krankheit, Overhead, etc.) – maximal 80%!
  • Ressourcen, die an mehreren Projekte parallel arbeiten können noch weniger geplant werden, da der Overhead steigt und die „Umschaltzeiten“ merklich ansteigen.
  • Je nach Situation werden oftmals „Wunschwerte“ geplant. Wenn beispielsweise der Geschäftsführer am Planungsworkshop teilnimmt und dieser ein bestimmtes Interesse hat, werden die Teilnehmer oft opportunistisch schätzen. 3
  • Im Idealfall sollte ein übergreifendes Team bei der Schätzung teilnehmen, der jeweilig für die Erarbeitung des Produktes verantwortliche das letzte Wort bei der Schätzung haben.
  • Und der no-brainer zum Schluss, es sollten immer hinreichend Puffer, besser noch „Zeitreserven“ für sonstige Abstimmungen und unerwartete Ereignisse („Probleme im Projekt“) eingeplant werden.
  1. Hier bin ich seit längerem der Meinung, dass Spracherkennung und Maschinelles Lernen eine Lösung bieten können
  2. Ich habe hierzu ein nettes MS Project Template mit eingebauter PERT Funktion erstellt. Bei Interesse hinterlasse bitte einen Kommentar und ich sende es Dir zu.
  3. Schnell besteht hierbei die HiPPO (highest paid person’s opinion, highest paid person in the office) Gefahr

Lesenswert KW32

Hinterlasse einen Kommentar
Lesenswert

How will Brexit affect your cloud strategy? | Cloud Pro

Google Spent 2 Years Studying 180 Teams. The Most Successful Ones Shared These 5 Traits | Inc.com

Aussie brothers raise $9m for training startup A Cloud Guru after less than two years | afr.com

VW CEO pushes for electric cars but faces internal backlash from leadership | Electrek

Mazda exec presents bold ‘let’s pretend the EV future will never come’ strategy | Electrek

How to get ready for your cloud transformation | Cloud Pro

National Theatre moves to the cloud to prepare for GDPR | Cloud Pro

BP starts to move workloads into Microsoft Azure | Cloud Pro

Alphabet Wants To Fix Clean Energy’s Storage Problem — With Salt

Capitalism the Apple Way vs. Capitalism the Google Way – The Atlantic

Scientists Need to Move Fast and Break Things – Scientific American Blog Network

Chinese chatbots apparently re-educated after political faux pas

Managing Deep Learning Development Complexity

The same old historicism, now on AI | Terra Incognita

How Machine Learning Is Helping Morgan Stanley Better Understand Client Needs

Microsoft 2017 annual report lists AI as top priority

Chaos Engineering – das Impfen unter den Operations Modellen

Hinterlasse einen Kommentar
Service Management

Vor ein paar Wochen stellte ich fest, dass mein Impfschutz gegen Tetanus vor 21 Jahren abgelaufen war. Das war dann in der Tat notwendig. Wikipedia definiert den Begriff einer Impfung wie folgt:

Eine Impfung, auch Schutzimpfung oder Vakzination (ursprünglich die Infektion mit Kuhpockenmaterial; von lateinisch vacca, ‚Kuh‘) genannt, ist die Gabe eines Impfstoffes mit dem Ziel, vor einer (übertragbaren) Krankheit zu schützen. Sie dient der Aktivierung des Immunsystems gegen spezifische Stoffe. Impfungen wurden als vorbeugende Maßnahme gegen Infektionskrankheiten entwickelt.

Das past zu einer Analogie, die ich im Cloudcast #299 gehört hatte. Dort ging es um die Disziplin des Chaos Engineerings, einem Betriebsmodell bei dem es darum geht, dass (verteilte) IT-Systeme niemals perfekt sind. Vielmehr ist die These sogar, dass sie verwundbar sind und eher die Frage berechtigt ist, wem diese Verwundbarkeit zuerst auffällt. Dem dafür verantwortlichen Betreiber oder jemand externem.1

Der Begriff Chaos Engineering leitet sich am ehesten von einem Modell, dass bei Netflix angewandt wird ab. Dort wurde vor Jahren ein Tool namens Chaos Monkey genutzt (und für Jedermann veröffentlicht), welches zufällig bestimmte Komponenten eines Systems bewusst im laufenden Betrieb zum Absturz bringt. Damit kann dann validiert werden, on das System als Ganzes wirklich hinreichend ausfallsicher ausgelegt ist.

Die Denke ist, Fehler werden passieren, die Frage ist nur wann. Und wie sehr kann ich den „Impact“ durch diesen Fehler im Falle minimieren.

Hier kommt die Analogie zur Impfung ins Spiel. Damit mein Immunsystem zur Abwehr gegen bestimmte Stoffe aktiviert wird, muss ich es zunächst einer kleinen Menge eben dieses Stoffes aussetzen.

Was sind die Prinzipien des Chaos Engineerings?

Hierzu bietet die eigens von Afficionados angelegte Seite PRINCIPLES OF CHAOS ENGINEERING eine gute Definition:

Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.

Selbst wenn alle einzelnen Systeme einer verteilten Umgebung voll funktionstüchtig sind, kann es dennoch zu einer Nutzerbetreffenden Einschränkung kommen. Eben diese impliziten Abhängigkeiten sind in großen Systeme oftmals nur nach einer Störung herauszufinden (dran Denken, Lessons Learned nach einem Incident). Will man hier etwas „proaktiver“ Vorgehen, ist das Modell des Chaos Engineerings prädestiniert:

  1. Definiere den ‚steady state’, am besten in einer messbaren Form, aus dem das zu erwartende normale Verhalten Deines Systems hervorgeht. Wichtig ist hier meines Erachtens der Aspekt des messbaren. Das kann bei einer Webseite die Antwortzeit auf bestimmte Anfragen sein, am besten auf Anfragen, die eine Vielzahl von Backend-Services mit einbezieht.
  2. Stelle die Hypothese auf, dass sowohl die Kontrollgruppe, als auch die experimentelle Gruppe sich gleich verhalten werden.
  3. Definiere Variablen, die ein echtes Verhalten darstellen, wie denkbare Anzahl von abgestürzten Servern, reduzierter oder limitierter Netzwerkbandbreite, usw.
  4. Vergleiche die Experimentier und die Kontrollgruppe kontinuierlich. D.h. starte durchgängig Experimente, die durch die Veränderung der definierten Variablen geprägt sind.

Die Fortgeschrittenen führen die Experimente direkt in der Produktion aus. Naheliegend fängt man mit einem reduziertem Radius an und vergrößert diesen immer weiter. Im Idealfall ist das gesamte System eingebunden. Mir ist zudem immer wichtig, dass man die dennoch auftretenden Incidents und im wiederholten Falle Problems (nach ITIL Sprache) als Input für die Testfälle/Variablen hernimmt.

  1. Extern muss nicht limitiert sein auf einen externen „Angreifer“ im Security Sinne. Es kann sich dabei einfach um einen operationsfremden und zu spät erkannten Incident handeln.

Lesenswert KW31

Hinterlasse einen Kommentar
Lesenswert

7 Interesting Parallels Between the Invention of Tiny Satellites and Cloud Computing  – High Scalability –

ImageNet: the data that spawned the current AI boom — Quartz

Corporations in the Age of Inequality

How We Built a Virtual Scheduling Assistant at Microsoft

When Moore’s Law Met AI – Artificial Intelligence and the Future of Computing – Medium

Japan battles population decline with robots – CBS News

Facebook builds natural language processing into Messenger | VentureBeat | Bots | by Khari Johnson

Google launches its own AI Studio to foster machine intelligence startups | TechCrunch

A practical explanation of a Naive Bayes classifier | MonkeyLearn Blog

Hackers break into voting machines in minutes at hacking competition | TheHill

Unlock | The Daily | L2

Die Verfügbarkeits Pyramide – oder wie man zu hoch verfügbaren Services kommt – Teil 2

Hinterlasse einen Kommentar
Service Management

Im vorhergehenden Post zum Thema Verfügbarkeits Pyramide beschrieb ich die ersten drei Ebenen. Nun zu den weiteren.

Ebene vier, wenn man die ersten Drei „im Griff“ hat, ist ein ordentliches Testkonzept und gesetzte Release Verfahren. Ein gutes Zitat zur Frage wie weit man Testaufwände treiben sollte, geht wie folgt:

„If you haven’t tried it, assume it’s broken.“

(Autor unbekannt)

Dem folgend gilt also alles als kaputt, solange nicht das Gegenteil nachweisbar ist. Das ist eine vielerorts untypische Vorgehensweise. Ist es doch traditionell so, dass man in ein System eindringt, oder ein Fehlverhalten auftrat. Folgt man der oben angeführten Haltung, geht man davon aus, dass bis zum Bestehen eines negativen Tests ein System als unbekannt gilt.

In der Softwareentwicklung gebt es dazu den Ansatz der Testgetriebenen Entwicklung. Dabei werden die Testfälle vor der Entwicklung der eigentlichen funktionalen Komponenten geschrieben. Nach dem Paradigma des Site Reliability Engineerings https://landing.google.com/sre/book/chapters/testing-reliability.html wird davon ausgegangen, dass man durch fundiertes und professionelles Testing die MTTR (Mean-Time-To-Repair) reduzieren und damit die MTBF (Mean-Time-Between-Failures) steigern kann:

It’s possible for a testing system to identify a bug with zero MTTR. Zero MTTR occurs when a system-level test is applied to a subsystem, and that test detects the exact same problem that monitoring would detect. Such a test enables the push to be blocked so the bug never reaches production (though it still needs to be repaired in the source code). Repairing zero MTTR bugs by blocking a push is both quick and convenient. The more bugs you can find with zero MTTR, the higher the Mean Time Between Failures (MTBF) experienced by your users.

Klassisch gibt es drei Testtypen:

  • Unit Tests, zum Testing einzelner Komponenten
  • Integrationstests, zum Testen der Komponenten im Verbund
  • Systemtests, zum Testen ganzer Umgebungen unter Simulation bestimmter Thesen (wie z.B. „Kann 10.000 User Sessions standhalten“)

Als nächster Aspekt der Pyramide wird das Capacity Planning angesehen. Also der kontrollierte Umgang mit der vorhandenen und basierend auf Trends oder Annahmen benötigten Kapazität. Bei eigenen Installationen („On-Premise“) sind hier in der Regel auch Investitionsplanungen und Entscheidungen abhängig. Aber auch beim Einsatz von Cloud Service Providern gilt es diese Disziplin sachgerecht durchzuführen. Denn man möchte/muss die etwaigen Ressourcen bei Zeiten verfügbar haben (Spin-up, Konfiguration laden, Applikation ausrollen, etc.).

Die letzten beiden Punkte der Pyramide würde ich tendenziell zusammenfassen: Development und Product.

Es ist essentiell, dass die Produktentwicklung von vornherein Skalierung vorsieht. Dazu benötigt es die richtigen Komponenten, wie Analyse Tools. Aber auch einen passenden Produktstart, wie zum Beispiel eine Einführung in Phasen („Beta“, Closed User Group, usw.). Bei Google haben sie auch dafür eine eigene Rolle, die des Launch Coordination Engineers. Diese kümmern sich um die korrekte Bearbeitung der Lauch Coordination Checklist.

Lesenswert KW 30

Hinterlasse einen Kommentar
Lesenswert

Amazon’s New Customer – Stratechery by Ben Thompson

ipSpace.net: Automation or Orchestration?

ipSpace.net: Swimlanes, Read-Write Transactions and Session State

ipSpace.net: Sample Network Automation Ansible Playbooks

Get eyes in the sky with your Raspberry Pi

Learn Kubernetes behind a corporate proxy

Build a budget IoT Grow-box with your Raspberry Pi

HBR: The Business of Artificial Intelligence

NYT: Beijing Wants A.I. to Be Made in China by 2030

Is Anyone Home? A Way to Find Out If AI Has Become Self-Aware

Techcrunch: Why the future of deep learning depends on finding good data

Lesenswert KW29

Hinterlasse einen Kommentar
Lesenswert

Der erste Eintrag ist eher hörenswert. Vom Digital Kompakt Podcast, 40 min über B2B Sales. Was sollte ein Vertriebler machen und was nicht.

Die fünf goldenen Regeln des B2B-Sales | The Art of Sales #6

‘Chinafrica’ is a macro megatrend set to impact everything from Silicon Valley to Wall Street | TechCrunch

Crypto-tulips

You’ll Never Expect Which Generation Has the Most Freelancers Today

Sesame Workshop and IBM team up to test a new A.I.-powered teaching method | TechCrunch

How AWS Cloud is demolishing the cult of youth – James Governor’s Monkchips

An introduction to model ensembling – weights and biases – Medium

Google wants to make sure AI advances don’t leave anyone behind – The Verge

Lesenswert KW28

Hinterlasse einen Kommentar
Lesenswert

Why Artificial Intelligence is Different from Previous Technology Waves

Facebook, for the first time, acknowledges election manipulation – CBS News

Without saying the words „Russia,“ „Hillary Clinton,“ or „Donald Trump,“ Facebook acknowledged Thursday for the first time what others have been saying for months.

AI Progress Measurement | Electronic Frontier Foundation

When the automatons explode – MIT Sloan School of Management

How AI detectives are cracking open the black box of deep learning | Science | AAAS

Where Machine Learning meets rule-based verification – The Foretellix Blog

Mesosphere-Chef Florian Leibert: Der Bill Gates des Cloud-Computings | ❤ t3n