Beschreibung des Unternehmen

Ursprünglich war Ikano ein Teil des 1943 von Ingvar Kamprad gegründeten Einrichtungshauses IKEA.
In den 1970er Jahren war Ikano im Bereich Immobilien und Vermögensverwaltung, Versicherungen und
Finanzdienstleistungen für IKEA tätig.

1988 wurde Ikano zu einem unabhängigen Konzern von Unternehmen im Besitz der Kamprad Familie.

Die Ikano Group bietet heute Services und Lösungen in den Bereichen Finanzdienstleistungen,
Immobilien, Versicherungen, Vermögensverwaltung und Einzelhandel für Privat- und Firmenkunden an.
In einigen Ländern zählen auch Angebote für Leasing, Baufinanzierung und Einlagengeschäft zum
Portfolio.

!Die Stärke von Ikano drückt sich aus in der Zusammenarbeit Langzeitlösungen basierend auf fairen
Grundsätzen zu entwickeln, um unseren Kunden, Partnern und uns selbst Nutzen zu bringen.!


Die Ikano Group ist in Schweden, Dänemark, Norwegen, Finnland, Großbritannien, Deutschland,
Österreich, Russland und Polen tätig.

Die deutsche Tochtergesellschaft Ikano Bank GmbH hat ihren Sitz in Wiesbaden Nordenstadt.

Ein populäres Produkt in Deutschland ist der Kash Borgen Ratenkredit mit über 1 Millionen Kunden.




Scrum

Allgemein

Scrum ist einer von mehreren existierenden sogenannten agilen Prozessen für Softwareentwicklung
und Projektmanagement - andere sind z.B. Crystal, Extreme Programming (XP), Feature Driven
Development (FDD).

Bereits Mitte der 1980er Jahre gab es erste Tendenzen, die bekannten Projektmanagement-Methodiken
in Frage zu stellen und nach agileren Ansätzen zu suchen. Seit den 1990er Jahren werden
Scrum-Projekte durchgeführt. Etwa seit der Jahrtausendwende war der Erfolg von Scrum mit der
explosionsartig wachsenden Zahl erfolgreicher Projekte nicht mehr aufzuhalten.

Scrum kennt drei Rollen für direkt am Prozeß Beteiligte: Product Owner (stellt fachliche
Anforderungen und priorisiert sie), ScrumMaster (managt den Prozeß und beseitigt Hindernisse)
und Team (entwickelt das Produkt). Daneben gibt es als Beobachter und Ratgeber noch die
Stakeholders.
Die Anforderungen (Requirements) werden in einer Liste (Product Backlog) gepflegt, erweitert
und priorisiert. Das Product Backlog ist ständig im Fluß. Um ein sinnvolles Arbeiten zu
ermöglichen, wird monatlich vom Team in Kooperation mit dem Product Owner ein definiertes
Arbeitspaket dem oberen, höher priorisierten Ende des Product Backlogs entnommen und komplett in
Funktionalität umgesetzt (inkl. Test und notwendiger Dokumentation). Dieses Arbeitspaket, das
Increment, wird während der laufenden Iteration, des sog. Sprints, nicht durch Zusatzanforderungen
modifiziert, um seine Fertigstellung nicht zu gefährden. Alle anderen Teile des Product Backlogs
können vom Product Owner in Vorbereitung für den nachfolgenden Sprint verändert bzw. neu
priorisiert werden.
Das Arbeitspaket wird in kleinere Arbeitspakete (Tasks) heruntergebrochen und mit jeweils
zuständigem Bearbeiter und täglich aktualisiertem Restaufwand in einer weiteren Liste, dem Sprint
Backlog, festgehalten.  Während des Sprints arbeitet das Team konzentriert und ohne Störungen von
außen daran, die Tasks aus dem Sprint Backlog in ein Increment of Potentially Shippable
Functionality, also einen vollständig fertigen und potentiell produktiv einsetzbaren Anwendungsteil,
umzusetzen. Das Team gleicht sich in einem täglichen, streng auf 15 Minuten begrenzten
Informations-Meeting, dem Daily Scrum Meeting, ab, damit jeder weiß, woran der andere zuletzt
gearbeitet hat, was er als nächstes vor hat und welche Probleme es evtl. gibt.
Am Ende des Sprints präsentiert das Team dem Product Owner, den Stakeholders u.a. interessierten
Teilnehmern in einem sog. Sprint Review Meeting live am System die implementierte Funktionalität.
Halbfertiges oder gar Powerpoint-Folien sind während des Reviews verboten. Das Feedback der Zuseher
und die neuen Anforderungen des Product Owners für den kommenden Sprint fließen dann wieder in das
nächste Sprint Planning Meeting ein, und der Prozeß beginnt von neuem.

Worin sich Scrum von diversen anderen Vorgehensmodellen unterscheidet, ist die Tatsache, daß nicht
nur Meilensteine in der Entwicklung gesetzt werden, sondern daß die Qualität eines Meilensteins
(Increment) jeweils so definiert ist, daß vom Auftraggeber (Product Owner) immer erwartet werden
darf, daß das in der abgeschlossenen Iteration (Sprint) fertiggestellte Stück Funktionalität in
sich abgeschlossen und produktiv einsetzbar ist. Dazu gehören auch Dokumentation in notwendigem
Umfang und Tests. Der bekannte Begriff in Scrum hierfür lautet Increment of Potentially Shippable
Functionality.



______
unser scrum cycle
Scrum Cycle

Cycle

The two Java teams follow a Sprint cycle lenght of two weeks. A major release happens every three sprints. The first and the second sprint are used for development, the third one for consolidation and integration testing.
Planning Poker

When: before the Sprint starts.

The product owner describes the user stories of the backlog that should be implemented in one of the next sprints. The team estimates the effort that is necessary to complete the user story according to the "Definition of Done":

    Specified
    Requirements must not have any gaps. If necessary, the product owner is prompted to update the documentation (e.g. mock-ups).

    Analyzed
    Technical feasibility has been checked and the developer has made up his mind of how the task can be accomplished best.

    Committed
    The developer has commited the code he has developed.

    Documented (developer documentation and archtitectural documentation)
    The APT pages and if necessary the EAP file for the architecture documentation have been updated in order to consider the implemented change.

    Selenium tests remain "green" (appropriate new tests have been created)
    Front-end changes / corrections should be covered by Selenium tests. Therefore existing tests need to be adjusted and new tests need to be written in order to keep the tests up-to-date.

    JUnit tests remain "green" (appropriate new tests have been created)
    Back-end changes / corrections should be covered by JUnit tests. Therefore existing tests need to be adjusted and new tests need to be written in order to keep the tests up-to-date.

    Review on FTEST1 (development DB)
    The implemented code is reviewed in the development environment by another team member. The review result should be documented in the underlying SBM ticket.

    Deployment to TCS (integration DB)
    After review remarks have been worked into the implementation the resulting code is to be brought onto the integration environment. The business/product owner is asked for approval of the user story.

    Approval of ticket by business/product owner
    The business expert/product owner checks that the implemented change corresponds to what has been required in the SBM ticket. The approval must be documented in the underlying SBM ticket.

The scrum master ensures that technical challenges are considered for the estimation. The planning poker is time boxed to 60 minutes.
Sprint Planning I

When: at the first day of the sprint.
With the Project Owner we agree what we want to achieve in the next two weeks. The number of available person days plus our velocity is our guide. When we select the backlog, we need to verify that we will not block ourselves when implementing this, and that we have the right skills available during that time. It shouldn't take more than 30 minutes, assuming the backlog has already been estimated in a planning poker.
Sprint Planning II
When: at the first day of the sprint.

We break down the different stories to tasks. This shouldn't take more than 45 minutes. We need to make sure that we start the big things that might need some communication first in order to be able to have them tested and approved at the end of the sprint. After this meeting one member should make sure that all stories and tasks have a ticket number.

Daily Stand-up
When: every day in the morning.

All team members gather for a short status on what they have done the day before. They talk about impediments and ask for help if necessary. The meeting is time boxed to 15 minutes.
Sprint Review
When: at the last day of the sprint.

It takes about 30 minutes to review the things completed in the last sprint. After that we write a short summary. Also the changes.xml file in each project need to be updated with the completed tasks.

To: storeportal-entwickler; Frank Richter;
CC: Holger Ammelung
Subject: Completed tasks of last sprint (calendar week AA/BB)
Hello,
in the last sprint we completed the following tasks:
   * xxxxx – ...
We completed XX points in XX days (velocity X,X). The velocity is higher/lower due to ...
...

Sprint Retrospective

When: at the last day of the sprint.

The team members talk about what they have done during the last two weeks. The state how they have experienced their
work. Especially, the Scrum Master asks the members about impediments (obstacles) and about the things that have
been good in the sprint.


Definition of Done hier:
spezifiziert
analysiert
commited
dokumentiert (Entwicklersicht / Architektursicht)
JUnitTests fürs Backend bzw. SeleniumTests fürs Frontend auf 'grün'
reviewed auf der FTEST1
deployed auf die TCS
Ticket vom business/product owner abgenommen




Bewerbungsablauf für das Praktikum

Beworben Nachgebessert Monat gewartet Bewerbungsgespräch 1 Woche später angefangen.

Vorstellung der Abteilung des Praktikums vom Unternehmen
Aufgaben und Ziele im Praktikums
Fazit und Rückblick auf das Praktikum

ikano bank geschichte location sinnzweck daten ~1 seite

baf it geschichte aufbau sinnzweck daten 1 seiten

surroundings 1 seite

scrum allgemein ausprägung hier 3 seiten

technologien jsf rich seam spring jpub oracle 3 seiten

tag 2 seiten

verlauf 6 seiten