https://www.insidesql.org/blogs/frankkalis/?disp=comments de-DE http://backend.userland.com/rss 60 Wed, 04 Jul 2012 20:37:03 +0000 tosc c2100@https://www.insidesql.org/blogs/ Mir auch! ... die Konsistenz bzw. technical tasks (Christophs Beispiel 2Dev ...) sollte doch im Sprint Backlog gelistet sein - wenn ich es richtig verstanden habe: Sprint Backlog List of technical tasks per Product Backlog Item Owned by T, status & estimates updated daily Only T modifies it (PO must not change scope!) ... eine wirklich interessante "Kost"! https://www.insidesql.org/blogs/frankkalis/2012/07/03/agile-datenbankentwicklung-teil-2-sprint#c2100 Wed, 04 Jul 2012 09:09:42 +0000 admin c2099@https://www.insidesql.org/blogs/ Du kannst Gedanken lesen? :-) Allerdings kommt es bei 2 DB Entwicklern bei uns sehr selten vor, dass beide zur gleichen Zeit am selben Objekt arbeiten. Da kann man sich schnell absprechen, wer welche Änderungen wann macht. Aber genau das ist eines der Themen für den nächsten Artikel. Zusammen mit, wie gehen wir mit "breaking changes" um und wie entkoppeln wir Datenbank-Releases von den korrespondierenden Client-Releases... https://www.insidesql.org/blogs/frankkalis/2012/07/03/agile-datenbankentwicklung-teil-2-sprint#c2099 Wed, 04 Jul 2012 08:35:48 +0000 cmu c2098@https://www.insidesql.org/blogs/ Gefällt mir gut! In einer Folgeversion wünsche ich mir die Antwort auf die Frage: Wie schaffen es denn die Entwickler, die an unterschiedlichen Tasks arbeiten ihre Versionen konsistent zu halten, falls die Tasks Überlappungen im Datenbankbereich haben? Also zwei Entwickler müssen unterschiedliche Änderungen an einem Datenbank-Objekt machen. Die Skripte müssen dann ja auch konsolidiert werden, oder es wird sichergestellt, dass die Tasks keine Überschneidungen haben, sondern seriell abgearbeitet werden ... https://www.insidesql.org/blogs/frankkalis/2012/07/03/agile-datenbankentwicklung-teil-2-sprint#c2098