Data professionals, whether they go by the title of database administrators, database engineers, or something else, can be among the most resistant to adopting Scrum. Much of what the preceding section said about programmers will also be true about database administrators. Additionally, data professionals will be faced with learning how to do incrementally what has traditionally been viewed as a part of a project's up-front work.
Standard advice in database design has been to do a complete analysis of the system's needs, create a logical or conceptual database design, and then map the concepts to the constraints of a real-world database during physical database design. Success at this series of steps is predicated on a full and accurate analysis up front. The traditional data professional's view was best summed up to me by a fellow traveler on a plane from Chicago to Sacramento. He was a vice president of database development for a relatively large healthcare company. His view on the world was "applications change; data is forever."
This type of thinking leads to an intense focus on doing a complete analysis up front. This is nice in theory, but while we're taking the time to do that complete analysis, the world is continuing to evolve. Users' needs are changing. Competitors are releasing their products. Databases need to evolve to support the evolving applications built on them.
Much of a DBAs day-to-day work will not change significantly, but how the DBA approaches and schedules that work will change dramatically.
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
Standard advice in database design has been to do a complete analysis of the system's needs, create a logical or conceptual database design, and then map the concepts to the constraints of a real-world database during physical database design. Success at this series of steps is predicated on a full and accurate analysis up front. The traditional data professional's view was best summed up to me by a fellow traveler on a plane from Chicago to Sacramento. He was a vice president of database development for a relatively large healthcare company. His view on the world was "applications change; data is forever."
This type of thinking leads to an intense focus on doing a complete analysis up front. This is nice in theory, but while we're taking the time to do that complete analysis, the world is continuing to evolve. Users' needs are changing. Competitors are releasing their products. Databases need to evolve to support the evolving applications built on them.
Much of a DBAs day-to-day work will not change significantly, but how the DBA approaches and schedules that work will change dramatically.
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
|
|
0 comments
Post a Comment