Diese Präsentation beschreibt, welche Faktoren für ein IT Start Up wichtig sind und zeigt Beispiele.

1. 1
Agenda
● Was macht ein Start Up erfolgreich?
● Das Team
● Business und IT Alignment
● Technologie
● Entwicklungsprozesse
● Deployment
● Sicherheit
● Monitoring
● Dokumentation

2. 2

3. 3
Start Up Erfolg
● Pro
● Schnelles lernen
● Günstiges lernen
● Gutes Team
● Exzellente Ausführung
● Contra
● Zu früh skalieren
● Schlechte Anforderungen
● „Verzetteln“ → Fokussierung auf unwichtige Dinge
Quelle: Startup Genome Report 01 https://www.startupcompass.co/

4. 4
Start Up Stages
Discovery Validation Efficiency Scale
Profit
Maximation
Renewal

5. 5

6. 6
Zyklisches Controlling
● Alles messen
● Smart/e Ziele
● spezifisch
● messbar
● akzeptiert
● realistisch
● terminiert
● Regelmäßig messen
● fester Tag im Monat an dem Ziele kontrolliert
werden, bei neuen Zielen wöchentlich bis täglich

7. 7
Kommunikation
● Eine auffällige Gemeinsamkeit erfolgreicher
Unternehmen ist effiziente und effektive
Kommunikation
● Wann wird effektiv kommuniziert?
● Entscheidungen werden im Zeitplan getroffen und
werden von allen respektiert und akzeptiert
● Es herrscht ein Vertrauensverhältnis zwischen allen
Mitarbeitern
● Es gibt nur Meetings, wenn Entscheidungen zu
treffen sind

8. 8
Das Team

9. 9

10. 10
Personal
● Personal
● Teuerste Komponente im Unternehmen
● Schwer zu beschaffen
● IQ guter Indikator, ob passend für Stelle
● Fähigkeiten messen
● Effizientes Arbeiten
● Programmierer Produktivität schwankt um den
Faktor 10
● Persönliche Ziele
● Klare Anforderungen
http://www.johndcook.com/blog/2011/01/10/some-programmers-really-are-10x-more-productive/

11. 12

12. 13
Identität für Team anbieten

13. 14
Recruitment
● Am effektivsten über persönliches Netzwerk
● Frühzeitig Personen an sich binden
● Personen, die für Geld kommen, werden auch
wieder für Geld gehen
"In looking for people to hire, you look for three qualities:
integrity, intelligence, and energy. And if they don't have the
first, the other two will kill you."
Warren Buffet
CEO, Berkshire Hathaway

14. 15
Business und IT Alignment

15. 16
Prozesse
● Die Kernprozesse sollten aufgeschrieben sein
z.B. Porter Wertkette
● Wann ist etwas ein Kernprozess?
– Er trägt mehr als 10% zu den Unternehmenseinnahmen
bei
– Er trägt mehr als 10% zu den Unternehmensausgaben
bei
● Prozesse erst nach Etablierung dokumentieren
● IT Systeme zur Unterstützung dieser Prozesse
sollten zugeordnet sein

16. 17
Beispielkernprozesse
Entwicklung Betrieb Support
Qualitäts-
sicherung
Entwicklung und BetriebEntwicklung und Betrieb
Vertrieb und Marketing / B2B
Lead
Generierung
Vertrags-
abschluss
Bereit-
stellung
Lead-
qualifizierung
und -pflege
... bis zu 70% der IT Kosten
bis zu 50% der Gesamtkosten bei SaaS

17. 18
IT kann Prozesse beeinflussen
● Neue IT Systeme bilden meist nicht die
Prozesse so ab, wie sie vorher im
Unternehmen waren
● Sinnvoll die Best Practises von Software zu
übernehmen anstatt für viel Geld anpassen zu
lassen
● Auswahl der Lösungen die möglichst gut die
momentanen Prozesse beschreiben

18. 19
Wann brauche ich ein IT System
● Viele Prozesse werden implizit durch IT
unterstützt
● Standardprogramme: Email, Office,
Tabellenkalkulation, Kalender
● IT Systeme sind primär zum Sammeln von
Daten, Auswerten und Präsentation an mehrere
Personen
● IT Systeme werden oft gebraucht, wenn ein Prozess
mit mehreren Personen statt findet und die Daten an
dem Prozess anstatt in den Mailboxen der
beteiligten Personen landen sollen

19. 20
Start Up Kosten von Entwicklung
dominiert
● Sinnvolle Strategie schnell zu entwickeln und
auf Funktionen und möglicherweise Qualität zu
verzichten um Geschäftsmodell zu validieren
● Startups need 2-3 times longer to validate
their market than most founders expect.
(Startup Genome Report)
● Performanzprobleme sind Luxusprobleme
● Wenn erfolgreiches Businessmodell, dann ist
Geld vorhanden um gute IT zu bauen

20. 21
Technologie

21. 22
Welche Technologie wählen?
● Technologie egal, die Probleme liegen
woanders:
● Die festgestellten Haupterfolgsfaktoren sind:
– Einbindung der Endbenutzer
– Unterstützung durch das obere Management
– Klare Anforderungen
● Die Hauptpunkte, die zum Scheitern der Projekte
führen sind:
– fehlende Zuarbeit durch Benutzer
– unvollständige/unklare Anforderungen
– häufige Anforderungsänderungen
Quelle http://de.wikipedia.org/wiki/Chaos-Studie CHAOS-Studie der Standish Group

22. 23
https://www.plat-forms.org/results-2011
Produktivität von Webplatformen

23. 24
Produktivität abhängig von
● Daumenregel
● Person (50%)
● Anforderungen (30%)
● Technologie (20%)

24. 27
Performance Tests
● ab -
http://httpd.apache.org/docs/2.2/programs/ab.h
tml
● JMeter - http://jmeter.apache.org/

25. 28
Entwicklungsprozesse

26. 29
Teamgröße
● Optimales Entwicklungsteam zwischen 4-9
Leute
● Experten sollten sich viel mit Planung,
Dokumentation und den Kollegen helfen
beschäftigen, nicht alles selbst coden
● Um eine Anforderung zu erfüllen sollten immer
zuerst bereits bestehende Lösungen evaluiert
werden
● 20% der Personen machen ausschließlich
Managementarbeit

27. 30
Vorgehensmodelle
● Vorgehensmodelle sollten nur so benannt
werden, wenn der Verantwortliche mindestens
200 Seiten zu dem Modell gelesen hat
● Wasserfall
– V Modell XT
– PRINCE2 (project management)
● Iterative (agile)
– Rational Unified Process
– Xtreme Programming
– Scrum (momentan trendy)
– Kanban (noch cooler als Scrum)

28. 31
http://www.joelonsoftware.com/articles/fog0000000043.html
Joels Rules for productivity
● Do you use source
control?
● Can you make a build in
one step?
● Do you make daily builds?
● Do you have a bug
database?
● Do you fix bugs before
writing new code?
● Do you have an up-to-date
schedule?
● Do you have a spec?
● Do programmers have
quiet working conditions?
● Do you use the best tools
money can buy?
● Do you have testers?
● Do new candidates write
code during their
interview?
● Do you do hallway usability
testing?

29. 32
Application Lifecycle Management
SCM e.g. git, svn
Issue Management e.g.
JIRA, Redmine
Continious Integration
Server e.g. Hudson,
Bamboo
Server Runtime e.g.
Tomcat, Apache

30. 33
Ticketing System
● Arbeitsanweisungen werden nur über Tickets
kommuniziert
● Messbarer Fortschritt
● Klarer Lebenszyklus (Erstellt, In Arbeit, Fertig)
● Quellcode und Deployment integrierbar

31. 34
Continious Integration
● Eine Funktion muss innerhalb von 8 Stunden
so implementiert sein, dass das System
kompilierbar ist
● System wird täglich kompiliert
● System wird täglich getestet
● System ist ständig auslieferbar
● Automatisiertes Kompilieren, Testen und
optionale Auslieferung

32. 35
Integration und Traceability
● SCM, Ticketing und CI sollten integriert sein
● Typische Fragen
● Warum wurde folgender Code geschrieben?
● Welche Features sind in dem momentanen Build,
die nicht in dem vorherigen waren?
● Gibt es für alle Tickets Test Cases
● Wer hat wie viele Zeilen Code geschrieben für den
momentanen Build

33. 36
Vorgehensmodelle
● Vorgehensmodelle sollten nur so benannt
werden, wenn der Verantwortliche mindestens
200 Seiten zum dem Modell gelesen hat
● Wasserfall
– V Modell XT
– PRINCE2 (project management)
● Iterative (agile)
– Rational Unified Process
– Xtreme Programming
– Scrum (momentan trendy)
– Kanban (noch cooler als Scrum)

34. 37
Anforderungen a.k.a User Stories
aber wie?
● Anforderung z.B. wie folgt definieren:
● Welches Problem löst die Anforderung
● Bewertung des Geschäftswert
● Textuelle Beschreibung
● Prozess Diagramm machen
● Wireframes machen
● Optional: PSDs für Designs machen
● Entity-Relationship Diagramme machen
● Schätzung der Kosten
● Akzeptieren der Entwicklung

35. 38
Einflußfaktoren und Gewichtung für
Produktqualität

36. 39
Vorstellung von Scrum
Quelle: 2006 Softwaretechnik II Vorlesung bei Dr. Eckhardt Holz

37. 40
http://scrumcrazy.wordpress.com/2012/06/26/a-diagram-of-the-user-story-life-cycle/

38. 41
Problem
● Welche Dinge mag ein Kunde?

39. 42
Beschreibung
For the following items, it is advisable to capture explicit feedback:
• Fashion dresses
• DVDs, especially movies
• Books
• Recipes
The explicit feedback will also be associated with the user. Afterwards, it
may be used to make better recommendations. Additionally, it could possibly
be the case that the cross domain knowledge improves the cold start
problem when adding a new domain. This functionality should be integrated
in social networks like studiVZ. A mobile app should be made available.
A survey is a special case of explicit feedback. It collects multiple,
enumerable attributes by requesting the user to answer multiple questions
on their review concerning a specific item.

40. 43
Prozessmodel
User fills
out survey
missing fields

41. 44
Wireframe

42. 45
Entity Model

43. 46
Anfoderung ready to implement
● Nun ist die Anforderung fertig zum
implementieren

44. 47

45. 48
Deployment

46. 49
Installation von Software
● Automatisiertes Bereitstellen
● Welche Funktion ist neu?
● Ausfallzeiten begrenzen
● Checklisten durchgehen nach Bereitstellung

47. 50
CI Servers
production system
test system
SCM
Entwickler
1. coden
2. commiten
3. bauen
4. automatisch
testen
5. manuell
testen
6. deployen

48. 51
Sicherheit

49. 52
Sicherheit
● Checkliste:
● https://www.owasp.org/index.php/Top_10_2010-Mai
n
● Prozesse
● PCI compliance (Kreditkarten)
● ISO/IEC 10181 Security frameworks
● Penetration testing
● http://www.backtrack-linux.org/
● nmap
● Nessus (http://www.tenable.com/)

50. 53
Intrusion Detection/Prevention
● Hardening PHP (Suhosin) – outdated
● Snort - http://www.snort.org/
● „Web Application Firewall“
● http://www.modsecurity.org/ - Apache

51. 54
Monitoring

52. 55
Monitoring
● Sicherstellung, dass angebotene Systeme
laufen
● Benachrichtigung bei Ausfall von Services
● Verschiedenste Systeme
● New Relic
● Icinga → empfohlen
● Derdack Enterprise Alert
● Zabbix

53. 56