https://www.insidesql.org/blogs/frankkalis/?disp=comments de-DE http://backend.userland.com/rss 60 Thu, 31 May 2012 13:24:24 +0000 admin c2063@https://www.insidesql.org/blogs/ Da muss man teilweise hartnäckig sein und sich nicht mit einem "Habe jetzt keine Zeit" abspeisen lassen. Natürlich hilft es aber ungemein, wenn man aber auch als Entwickler eine gewisse Affinität zu dem Business hat, für das man arbeitet. Wenn man sich nicht für die Arbeit der Händler interessiert, ist es schwer, nachzuvollziehen, warum und wieso manche Sachen so gemacht werden, wie sie gemacht werden. Dann kann man schlecht argumentieren und auch schlecht "bessere" Ansätze vorschlagen. Bzgl. der Ausfallzeiten brauche ich mir bisher kaum Gedanken zu machen. Ohne den weiteren Artikeln vorwegzugreifen: Die meisten Changes machen wir über Mittag. Sollten dann doch mal längere Releases notwendig werden, können die nach dem Tagesabschluss oder am Wochenende gemacht werden. Dazu aber in einem Folgeartikel mehr.... https://www.insidesql.org/blogs/frankkalis/2012/05/31/agile-datenbankentwicklung-teil-1#c2063 Thu, 31 May 2012 12:37:21 +0000 cmu c2062@https://www.insidesql.org/blogs/ Sehr interessant finde ich auch die fachlichen Anforderungen an die Entwickler, um die eher "unscharfen" Fachkonzepte der Fachabteilung in der Kürze der Zeit zu verstehen. Man darf auch nicht ausser Acht lassen, dass eine Auslieferung im Datenbankumfeld deutlich länger dauern kann und bei großen Datenbanken mit Auszeiten von mehreren Stunden verbunden sein kann, wohingegen Codestücke in Sekunden ausgeliefert sind. Wer möchte aber bei 14 tägigen Release-Zyklen auch immer lange Ausfallszeiten in Kauf nehmen? Ich bin gespannt, wie ihr den Spagat meistert. https://www.insidesql.org/blogs/frankkalis/2012/05/31/agile-datenbankentwicklung-teil-1#c2062