Anyway wouldn't a database be just a by-product of an agile process ? Unless special attention needs to be paid to roles and support required from the DB guys in an agile process ?
Well, depends on what you mean by a "database". Most projects end up using an abstract database of some sort, be it a cluster of Oracle servers or a plain old file system. Few projects produce a relational database software as a by-product, however
Anyway wouldn't a database be just a by-product of an agile process ?
Ideally, the "DB guys" are part of the agile team, not in a support role. In that way, yes, special attention should be given.
Unless special attention needs to be paid to roles and support required from the DB guys in an agile process ?
Scott would surely give you a more accurate description, but here's how I would classify agile database design:
Originally posted by Pradeep Bhat:
What does [agile database design] mean?
The database schema is designed in small steps using an evolutionary approach, based on emerging needs during the whole software development life-cycle.
(Am I close?)
I guess we could call it evolutionary database design just as well. However, agile does have more punch in it to stress that the evolution needs to happen fast when a need arises, i.e. the iterations should not be in the months.
Originally posted by Pradeep Bhat:
Why do we call it agile when it is done in small evolutionary steps ?
1. We need to distinguish between the Agile Data (AD) method and agile database techniques (ADT) which support the methdod. The method, http://www.agiledata.org/essays/vision.html, defines 6 philosophies for effective data-oriented activities on agile projects. The techniques, described at www.agiledata.org as well, support the method. It would be irresponsible of me to define a method without supporting techniques. Fundamentally this is a process+ discussion.
2. The fundamental message to data professionals is that modern development is evolutionary (iterative and incremental) in nature and therefore you need to work in that manner as well (and by the way, here are the techniques that enable you to do so).
3. The fundamental message to developers (object professionals, call it like it is) is that data is important and you need to improve your skillset. Naturally I also cover the basic skills you need, such as data modeling and data normalization, so you have an understanding of the fundamentals. But I also get into implementation issues, such as how to implement concurrency control in your Java code. This chapter covers the basics of CC and describes several strategies for implementing it, discussing the trade-offs. Most books only focus on one strategy, such as doing an incremental counter to support optimistic locking, but my philosophy is that effective developers know several ways to do things and will pick the right approach for the situation. You don't want to be a one trick pony, do you?
4. Data folks should be part of the team. As I've discussed in other postings, they should be generalizing specialists. Over time, if they do this, they'll likely rethink the concept of being just a data professional and think of themselves.
5. Database design can and should proceed in an evolutionary manner, just like object design. And, when you actually try it, it seems to work much better this way. Many experienced data folks might not see it this way, but then again they very likely haven't tried the new ways either.