Jetzt anfragen: http://jira.seibert-media.net - Effektives, zentrales Aufgaben- und Projektmanagement für Unternehmen. Informationen vom deutschen Atlassian-Vertriebspartner //SEIBERT/MEDIA.
The document discusses various product management artifacts used in Agile development such as user stories, product vision, product roadmap, product backlog, and sprint backlog. It describes how the product roadmap informs the prioritized product backlog, which contains short user stories that guide development work tracked in sprint backlogs on a sprint-by-sprint basis. Effective use of these artifacts helps ensure alignment between product strategy and development activities.
This document discusses epics and user stories in agile software development. It defines epics as large features or requirements too big to complete in a single sprint that need to be broken down into smaller user stories. User stories are simple descriptions of features written from the perspective of the end user that follow a who, what, why template. The document provides examples of epics and user stories and guidelines for when and how to split large stories or epics into smaller independent stories that can be estimated and implemented within a sprint.
The document provides an overview of Agile and Scrum frameworks and processes. It discusses key Scrum roles like Product Owner and Scrum Master. It also covers Scrum artifacts like user stories, product and sprint backlogs. The document emphasizes that user stories should be short, independent, negotiable, valuable, estimable, small, and testable (INVEST criteria). It provides examples of proper user story structure and components.
The document discusses user stories for software requirements. It provides tips for writing good user stories, such as starting with user goals, writing smaller stories for soon-to-be-implemented functionality, keeping the user interface out of stories initially, and having the customer rather than developer write stories. It also identifies "smelly" user stories, such as those that are too small, interdependent, include too many details, or are written too far in advance.
Case Study, Guideline und Tools zum Thema Git, Jenkins und lokale Entwicklungsumgebung. Ich gebe eine Einführung wie die Firma die Medienagenten oHG einen Deploymentprozess eingeführt haben inklusive aller Stolpersteine
Jetzt anfragen: http://jira.seibert-media.net - Effektives, zentrales Aufgaben- und Projektmanagement für Unternehmen. Informationen vom deutschen Atlassian-Vertriebspartner //SEIBERT/MEDIA.
The document discusses various product management artifacts used in Agile development such as user stories, product vision, product roadmap, product backlog, and sprint backlog. It describes how the product roadmap informs the prioritized product backlog, which contains short user stories that guide development work tracked in sprint backlogs on a sprint-by-sprint basis. Effective use of these artifacts helps ensure alignment between product strategy and development activities.
This document discusses epics and user stories in agile software development. It defines epics as large features or requirements too big to complete in a single sprint that need to be broken down into smaller user stories. User stories are simple descriptions of features written from the perspective of the end user that follow a who, what, why template. The document provides examples of epics and user stories and guidelines for when and how to split large stories or epics into smaller independent stories that can be estimated and implemented within a sprint.
The document provides an overview of Agile and Scrum frameworks and processes. It discusses key Scrum roles like Product Owner and Scrum Master. It also covers Scrum artifacts like user stories, product and sprint backlogs. The document emphasizes that user stories should be short, independent, negotiable, valuable, estimable, small, and testable (INVEST criteria). It provides examples of proper user story structure and components.
The document discusses user stories for software requirements. It provides tips for writing good user stories, such as starting with user goals, writing smaller stories for soon-to-be-implemented functionality, keeping the user interface out of stories initially, and having the customer rather than developer write stories. It also identifies "smelly" user stories, such as those that are too small, interdependent, include too many details, or are written too far in advance.
Case Study, Guideline und Tools zum Thema Git, Jenkins und lokale Entwicklungsumgebung. Ich gebe eine Einführung wie die Firma die Medienagenten oHG einen Deploymentprozess eingeführt haben inklusive aller Stolpersteine
Dank vieler praktischer Funktionen können Entwickler unter ColdFusion relativ schnell und einfach Applikationen entwickeln und produktiv einsetzen.
Doch wie sieht es aus wenn diese Applikationen dann intensiv genutzt werden? Von hunderttausenden Usern in unzähligen Ländern, Sprachen und Zeitzonen? Wenn Inhalte laufend generiert und abgefragt werden?
Dieser Talk zeigt, wie ColdFusion in einem Enterprise Projekt eingesetzt werden kann. Welche Architektur für einen sicheren Betrieb rund um die Uhr und die Welt benötigt wird. Welche ColdFusion Enterprise-Funktionen gebraucht werden und welche nicht, welche überhaupt funktionieren, welche Lektionen wir im praktischen Einsatz gelernt haben und warum Optimierungen im Milisekunden-Bereich tatsächlich Tage sparen können.
Jeder Service für sich kann unabhängig deployed und skaliert werden.
Gerade Cloud Computing erleichtert in vielen Unternehmen die Verwaltung der IT-Infrastruktur. Weil die für die Software benötigte Plattformen so einfach anzumieten sind, werden Developer deshalb immer mehr in die Rolle des DevOps gedrängt -- die Software, die sie entwickeln, soll auch selbst betrieben werden -- You build it, you run it.
Doch diese Strukturierung ist nicht ganz kostenlos - Developer müssen dadurch immer mehr Verantwortung übernehmen. Um dieser Verantwortung gerecht zu werden, muss eine Schwachstelle ausgeschaltet werden: der Mensch. Im Talk gehe ich auf Prozesse der klassischen Softwareentwicklung ein und lege dar, wie diese in dem “You build it, you run it”-Modell verbessert werden.
Immer mehr Open-Source-Projekte benutzen Git. Der Vorteil ist klar: Viele Entwickler arbeiten weltweit verteilt, zeitlich versetzt und nur lose gesteuert an einem Projekt. Das passt hervorragend zum dezentralen Ansatz von Git. Git untersützt die benötigten Workflows für eine solche Projektorganisation hervorragend - denn dafür wurde es entwickelt.
Der Vortrag diskutiert die Fragen, die sich bei der Einführung von Git im eigenen Unternehmen stellen:
- Welche Vorteile bringt Git für In-House-Projekte und Produktentwicklungen?
- Wie geht man vor, wenn man Git einführen möchte?
- Mit welchen Problemen ist beim Umstieg zu rechnen?
- Sind die gleichen Workflows, die in der Open-Source-Welt funktionieren auch für die Unternehmenswelt sinnvoll?
Am Beginn des Vortrages gibt es einem kurzen Einstieg in Git, so dass auch Git-Unerfahrene eine Idee von den Fähigkeiten einer dezentralen Versionsverwaltung erhalten.
Abendvortrag oose Innovative Informatik GmbH, Tower Falkenried-Piazza, Straßenbahnring 7, 20251 Hamburg
DWX 2017 - GIT im Leben eines VS EntwicklersMarc Müller
GIT gilt als die beliebteste und erfolgreichste verteilte Quellcode-Verwaltung überhaupt und ergänzt seit nun fast drei Jahren das Portfolio der ALM Plattform Team Foundation Server. Für eingefleischte TFVC Benutzer stellt Git oftmals noch Neuland dar und es gilt einigen Stolperfallen geschickt aus dem Weg zu gehen. Im Vortrag zeigen wir mit viel Hintergrundinformationen und Beispielen, welche Konzeptänderungen auf einen warten. Nebst Visual Studio zeigen wir auch Shell Extensions und die Kommandozeilen-Tools als Ergänzung zum gewohnten Tool-Sets. Themen wie Git-Flow oder Large File Support (LFS) dürfen natürlich ebenfalls nicht fehlen.
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen ProjektenCreasoft AG
Software-Projekte sind mit vielen Risiken behaftet. Die Ursachen für Fehlschläge sind oft Fehler im Management der Anforderungen und mangelhafter Einbezug der Benutzer.
Agile Vorgehensmodelle wollen genau dieses Problem lösen. Allerdings wird die Thematik in den ursprünglichen Konzepten zu stark vereinfacht und dadurch oft missverstanden.
Fedora ist nicht einfach nur ein Projekt oder eine Linux-Distribution, sondern eine Entwicklungsplattform. Kaum eine andere Distribution bringt so viele neue Entwicklungen hervor und integriert sie so schnell in eine stabile Version. Neue Technologien werden oft zuerst in Fedora gezeigt, bevor sie ihren Weg in andere Distributionen finden.
(Vortrag auf dem LinuxTag Berlin am 14.05.2011)
Veranstaltung "Confluence & JIRA Community Day 2013" in Frankfurt/M. am 21. November 2013.
Eine Präsentation zum Thema "JIRA goes i18n" von Jan Schulz, Head of Project bei der catWorkX GmbH.
Dank vieler praktischer Funktionen können Entwickler unter ColdFusion relativ schnell und einfach Applikationen entwickeln und produktiv einsetzen.
Doch wie sieht es aus wenn diese Applikationen dann intensiv genutzt werden? Von hunderttausenden Usern in unzähligen Ländern, Sprachen und Zeitzonen? Wenn Inhalte laufend generiert und abgefragt werden?
Dieser Talk zeigt, wie ColdFusion in einem Enterprise Projekt eingesetzt werden kann. Welche Architektur für einen sicheren Betrieb rund um die Uhr und die Welt benötigt wird. Welche ColdFusion Enterprise-Funktionen gebraucht werden und welche nicht, welche überhaupt funktionieren, welche Lektionen wir im praktischen Einsatz gelernt haben und warum Optimierungen im Milisekunden-Bereich tatsächlich Tage sparen können.
Jeder Service für sich kann unabhängig deployed und skaliert werden.
Gerade Cloud Computing erleichtert in vielen Unternehmen die Verwaltung der IT-Infrastruktur. Weil die für die Software benötigte Plattformen so einfach anzumieten sind, werden Developer deshalb immer mehr in die Rolle des DevOps gedrängt -- die Software, die sie entwickeln, soll auch selbst betrieben werden -- You build it, you run it.
Doch diese Strukturierung ist nicht ganz kostenlos - Developer müssen dadurch immer mehr Verantwortung übernehmen. Um dieser Verantwortung gerecht zu werden, muss eine Schwachstelle ausgeschaltet werden: der Mensch. Im Talk gehe ich auf Prozesse der klassischen Softwareentwicklung ein und lege dar, wie diese in dem “You build it, you run it”-Modell verbessert werden.
Immer mehr Open-Source-Projekte benutzen Git. Der Vorteil ist klar: Viele Entwickler arbeiten weltweit verteilt, zeitlich versetzt und nur lose gesteuert an einem Projekt. Das passt hervorragend zum dezentralen Ansatz von Git. Git untersützt die benötigten Workflows für eine solche Projektorganisation hervorragend - denn dafür wurde es entwickelt.
Der Vortrag diskutiert die Fragen, die sich bei der Einführung von Git im eigenen Unternehmen stellen:
- Welche Vorteile bringt Git für In-House-Projekte und Produktentwicklungen?
- Wie geht man vor, wenn man Git einführen möchte?
- Mit welchen Problemen ist beim Umstieg zu rechnen?
- Sind die gleichen Workflows, die in der Open-Source-Welt funktionieren auch für die Unternehmenswelt sinnvoll?
Am Beginn des Vortrages gibt es einem kurzen Einstieg in Git, so dass auch Git-Unerfahrene eine Idee von den Fähigkeiten einer dezentralen Versionsverwaltung erhalten.
Abendvortrag oose Innovative Informatik GmbH, Tower Falkenried-Piazza, Straßenbahnring 7, 20251 Hamburg
DWX 2017 - GIT im Leben eines VS EntwicklersMarc Müller
GIT gilt als die beliebteste und erfolgreichste verteilte Quellcode-Verwaltung überhaupt und ergänzt seit nun fast drei Jahren das Portfolio der ALM Plattform Team Foundation Server. Für eingefleischte TFVC Benutzer stellt Git oftmals noch Neuland dar und es gilt einigen Stolperfallen geschickt aus dem Weg zu gehen. Im Vortrag zeigen wir mit viel Hintergrundinformationen und Beispielen, welche Konzeptänderungen auf einen warten. Nebst Visual Studio zeigen wir auch Shell Extensions und die Kommandozeilen-Tools als Ergänzung zum gewohnten Tool-Sets. Themen wie Git-Flow oder Large File Support (LFS) dürfen natürlich ebenfalls nicht fehlen.
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen ProjektenCreasoft AG
Software-Projekte sind mit vielen Risiken behaftet. Die Ursachen für Fehlschläge sind oft Fehler im Management der Anforderungen und mangelhafter Einbezug der Benutzer.
Agile Vorgehensmodelle wollen genau dieses Problem lösen. Allerdings wird die Thematik in den ursprünglichen Konzepten zu stark vereinfacht und dadurch oft missverstanden.
Fedora ist nicht einfach nur ein Projekt oder eine Linux-Distribution, sondern eine Entwicklungsplattform. Kaum eine andere Distribution bringt so viele neue Entwicklungen hervor und integriert sie so schnell in eine stabile Version. Neue Technologien werden oft zuerst in Fedora gezeigt, bevor sie ihren Weg in andere Distributionen finden.
(Vortrag auf dem LinuxTag Berlin am 14.05.2011)
Veranstaltung "Confluence & JIRA Community Day 2013" in Frankfurt/M. am 21. November 2013.
Eine Präsentation zum Thema "JIRA goes i18n" von Jan Schulz, Head of Project bei der catWorkX GmbH.
2. Über uns
Die aktuellen Rekord-Kennzahlen im Überblick*
Über 5 Millionen Besucher**
Über 1,7 Milliarden Seitenaufrufe
Über 210 Millionen abgerufene Exposés
Über 1,2 Millionen Angebote
Rund 110.000 Immobilienanbieter
*jeweils pro Monat
**laut Nielsen//NetRatings
• >500 Mitarbeiter
• 160 In der IT
• 19 Entwicklungsteams, 6 davon externe
3. Wer bin ich?
• ‚Head of Quality Assurance‘ bei Immobilien Scout
• 6 Jahre Erfahrung mit Jira
• Jira admin bei der letzten Firma
4. Ausgangssituation
Bugzilla für Bug Tracking Dokumentation überall
Time Tracking mit Time4U
No traceability für Epics und
Stories (Heavy-weight RM Story Backlogs in Excel
Prozess)
5. …and then one day…
• 5 Leute mit Jira Erfahrung wollten raus aus dem Chaos
• PM/PO, Scrummaster wollten bessere Produkt Backlogs
• QA + Entwickler wollten alle Information an einem Ort
• Release Management wollte wissen was integriert wurde
• Alle wollten besser informiert werden
• 5 Köpfe haben ein Rollout Plan entwickelt, und schon 4
Monate nach dem ersten Gespräch war Jira am Leben
7. Projekt Struktur
• Ziel war < 10 Projekte
• Aktuelle Situation = fast 30
• Unter Projekte, liegen Komponenten
• Jede Komponente beinhaltet Epics
• Jeder Epic hat Stories
• Aus der Story bestehen Tasks
• nicht immer in Jira gepflegt
8. Workflows
• Jeder Vorgangstyp hat ein eigenen
Workflow
• Erlaubt einfachere Anpassung
• Entspricht der Arbeitsweise
• Einen Workflowschema für IS24 Projekten
• Ein Team implementiert gerade besondere
Workflows für deren Sonderfälle
9. Migration Bugzilla -> Jira
• Bugzilla:
• 30,000 Bugs und ToDos
• Stark angepasst (programatisch)
• Externe System Import-beta benutzt -> Schlug fehl
Users konnten nicht während des Imports erzeugt
werden
Custom Felder waren nicht richtig interpretiert
„null“ Datum konnten nicht richtig behandelt werden
(Support von Atlassian war super)
• Lösung war nur offene Bugs und ToDos zu importieren
Erster Versuch: mBean SQL angepasst
Zweiter Versuch: Bugzilla Datenbank geschrumpft
10. Migration Bugzilla -> Jira
• Viele Projekte wurden erzeugt
mussten nachträglich aufgeräumt werden
• Jira Login ist mit LDAP verknüpft, leider keine volle Integration
Users importiert aus LDAP (Active Directory)
Usernamen Format unterschiedlich Jira <-> Bugzilla
Users gemapped in Import config Datei
Generic User für alte Bugzilla Users
• 6 Wochen lang fast täglich Proben und Übungen
5 Stunden Migration an einem Freitag Abend
keine schmerzen
11. Import Projekt Backlog
• Jeder Projekt Backlog war früher in Excel
• External System Importer (nicht beta) für csv
• Backlog wurde direkt in das entsprechende
Projekt importiert
• Läuft schmerzfrei, solange das Backlog in
einem Standard Format ist
13. Plugins
• Subversion Plugin
• SVN Pre-commit Hook steht an
• Workflow Visualisation Plugin
• Visual Workflow Editor
• Time Tracking and Reporting
• Worklog Assistant
• Time Tracking and Billing Reporting
14. Aktuelle Probleme
• (Noch) Keine Möglichkeit mit Greenhopper,
Projektübergreifende Backlogs zu pflegen
• Keine Möglichkeit Projektübergreifende Release Versionen
anzulegen
• Muss für jedes Projekt per Hand angelegt werden
• Projekt Struktur (Applikationschnitt) eine Herausforderung:
• 1 Projekt pro Team? (Welches Team ist für Issues zuständig?)
• 1 Projekt pro Produkt? (Wo sind die Grenzen?)
• Servicelines? (Präferierte Lösung, aber auch nicht optimal)
15. Aktuelle Problemen
• Evaluation System wurde als produktives System benutzt
• Projekt Migration ist nicht leicht
• Jira Systemen müssen 1-1 passen, inklusiv Jira Buildnummer
• War leider nicht so in unserem Fall
• Jira wurde zuerst auf Deutsch installiert, dann auf Englisch
geändert. Einige deutsche Begriffe bleiben.
• Unklarheiten wann „Status“ benutzt wird, und wann „Assignee“
16. Administratoren und Workgroup
• Um die Meinung von jeder Abteilung, die mit Jira arbeitet,
zu vertreten, wurde einen Workgroup gebildet
• Besteht aus 8 Leuten (DEV, SYS, QA, SM, PMI, RM, BU)
• Ursprüngliche Jira-Verfechter sind auch noch dabei
• Entscheiden gemeinsam über Änderungen
• Teilen der Administrativen- und Wartungsaufgaben
• Machen Telefon- als auch Email-Support
• Schaffen Transparenz