Scott W. AmblerBesprekingen

This book provides solutions for activities that are needed to deliver software and satisfy the needs of all involved stakeholders, in a disciplined and agile way.

(Full book review is published on Dzone, and at Disciplined Agile Delivery)

Disciplined Agile Delivery is a hybrid approach, which includes practices from several agile methods. If you are familiar with RUP or the Unified Process, then you will also recognize a lot of the practices provided in the book. The phases Inception, Construction and Transition are described including agile practices that can be used in these phases.

Much emphasize is given to people aspects of agile development. For instance, by looking at what discipline is, and what means to be disciplined by discussing the rights and responsibilities of professionals doing software development. There’s information in the book on how to build effective teams, which digs into collaboration skills and the conditions needed for professionals to work together like the work environment, tools and organizational arrangements.

the book is pretty trivial it the essential content, some of the patterns seem to be just forced to appear here to fill in the space; if you have ever developed a medium size enterprise application, most of patterns would be obvoius and natural; buried in repetetive examples is just one novel idea (novel at least to me) that a db change can be introduced without removing the old schema element(s) and with trigger synchronization between the new and old schema element; in summary 300 pages could easily be shortened to a 10 page aricle ...

Scott Ambler and Pramod Sadalage wrote Refactoring Databases, they say, "to share their experiences and techniques at evolving database schemas via refactoring". The book, particularly in the thorough list of refactorings detailed in later chapters, reveals them to be experienced users of, and writers about, agile development approaches. Their core premise is that data and databases must evolve in the same way as code does - that is incrementally.

They argue persuasively that a big-bang, up-front approach to database design is unacceptable in a modern environment. There is simply too much change and too much uncertainty in the business world for this to be realistic. The basic techniques for evolutionary database design include refactoring (the topic of the book), evolving the data model, database regression testing and configuration management and developer sandboxes. This more evolutionary approach is going to be a big shock for many data professionals, something the authors note, but I think the need for effective evolution and ongoing development of applications and thus their databases is compelling. "Change time", the period after an application (or database) is first deployed is bar far the majority of the life of an application. Techniques that help you cope with this, like database refactoring, are a good thing. Database refactoring as described in the book, is part of an evolutionary approach and with development teams taking on SCRUM, XP and other agile methods it is more important than ever for database teams to do likewise. Many data professionals will likely have the same knee-jerk reaction I did when first approaching this - Why not just get it right up front? But if you believe that agile model-driven development is here to stay for code then you have to accept the need for the same approach to database design.

Martin Fowler's original book Refactoring: Improving the Design of Existing Code made the point that a refactoring must retain the behavioral semantics of the code and this is just as true in databases. The authors take great pains to explain refactoring in enough detail that it you can apply it constantly to keep the database as clean and easy to modify as possible. They emphasize repeatedly the value of test-driven or test first development - even in database design and deployment. The authors stress the importance of testing, especially regression testing, of all the components that access a database when refactoring it. They advise making refactoring efforts small as well as test-driven. They point out that refactoring should be done as a series of small steps and that database develops must not succumb to the temptation to combine refactorings into larger, more complex efforts. The need to treat database designs, and even data, as artifacts subject to change control comes through loud and clear.

The concept of a potentially very long transition period in which both the old and new schemas are supported is a particularly good one. I worry about the organizational dynamics of having the old schema removed by a new team that does not remember the original refactoring but nothing else seems rational in a typical environment where many applications run against the same database. I also liked the paranoia of the authors, for instance in their suggestion to always run regression tests BEFORE refactoring to make sure the database is actually as you think it is! While the book focused on refactoring, many of the hints and suggestions would be good for implementing real changes in business policy.

The book is a surprisingly easy read for such a potentially dense subject. The book starts by describing the fundamentals of evolutionary database development and the basics of refactoring. A process overview, deployment notes and some best practices follow. These initial chapters, designed to be read in sequence, introduce and explain the topic well and have a nice little "What you have learned section" at the end. There were many worthwhile asides in the book as it covers these topics and after these introductory chapters, the book then goes (somewhat abruptly) into a series of chapters on various kinds of refactoring - structural, data quality, referential integrity, architectural, method and transformations. These chapters take a series of very specific refactorings. The potential motivation, tradeoffs and implementation mechanics are defined for each. The refactorings are self-contained and, while this makes reading them as a set somewhat repetitive, it should make the book a much better reference guide for actual users.

The book did not really touch on how you should consider data and database designs used in analytic models or the potential value of using business rules, but these are minor quibbles. The book is well written, full of great examples and gives lots of good advice.

If you are using the Rational Unified Process, or considering doing so, and worried about applying it to a whole IT department rather than separate projects then this book could well be useful. The book has four parts - From RUP to EUP, Beyond Development, Enterprise Management Disciplines and Putting it all Together. Each section has several chapters and the chapters all start with a nice reader ROI section (showing the payoff for reading that chapter). The writing is clear and there are plenty of diagrams, tables and helpful tips.

The book starts of with some background in the RUP. I particularly liked the description of RUP as serial in the large and iterative in the small. Within the RUP there are also nine disciplines (Business Modeling, Requirements, Analysis and Design, Implementation, Test, Deployment, Configuration and Change Management, Project Management, and Environment). The authors outline 10 best practices they see as core to the EUP (they extend the original 6 in RUP) - Develop iteratively, Manage requirements, Proven architecture, Modeling, Continuously verify quality, Manage change, Collaborative development, Look beyond deployment, Deliver working software regularly and Manage risk. Each is clearly described.

In addition to the change best practices, EUP adds a Production phase and a Retirement phase. They point out that the Production phase is not just maintenance or just operations and support but both and more. I think that any organization building systems should spend as much time and effort thinking about production and running their application in production (which includes maintaining it over time) as they do in building it and I was glad to see this so strongly proposed. They also added an operations and support discipline, mostly but not entirely in the production phase. This discipline includes running the system and making hot fixes. I think the Retirement phase is overkill for most organizations but some will find it useful.

They also added some "Enterprise Management" disciplines for use outside the context of a project and this too is a good idea. The disciplines are Enterprise business modeling, Enterprise Portfolio Management, Enterprise Architecture (I particularly liked the idea that "modifiability" should be considered as part of an enterprise architecture - far too few organizations do this well and fail to differentiate between stable services and much more changeable ones), Strategic Reuse (Again I liked the called-out focus on this - without a real plan no reuse is going to happen), People management , Enterprise Administration and Software Process Improvement (Another good one and a timely reminder to all that you should keep improving your software processes)

Overall I liked the book, though it was a somewhat dry subject (as methodologies often are). There was a lot of good advice, some nice tips and some clearly hard-won experience being shared!

This book is sort of like a software development crash course — there's a few pages on almost everything from use cases to polymorphism. The information is well-supported (through citations and authorial experience), and it rang true for the parts about which I know something. The breadth is odd — I imagine most people, like me, know a lot about some parts of the full development process, and therefore didn't learn anything useful from those chapters. And the chapters that applied to parts of the process in which I've never participated were too brief to grasp any kind of working knowledge.

Ambler's case for an agile modeling process is persuasive, although there's little evidence for or against. The cornerstone of the argument is to use whatever model is useful to you, and model only until you have enough information to go to the next step (modeling or writing code). It's a pragmatic approach, which is probably why it's convincing without being demonstrably successful. Ambler doesn't recommend or explain specific models, but the Appendix has a giant list of models used for business, requirements, analysis, design, architecture and infrastructure modeling.

SUMÁRIO
(.)
PARTE I - INTRODUÇÃO À MODELAGEM ÁGIL:
CAPÍTULO 01 - Introdução:
[023] - Entre no desenvolvimento ágil de software;
[025] - Modelagem Ágil;
[032] - O caso de estudo SWA Online;
[033] - Uma breve visão geral deste livro.
(.)
CAPÍTULO 02 - Valores da Modelagem Ágil:
[035] - Comunicação;
[035] - Simplicidade;
[037] - Retorno;
[038] - Coragem;
[039] - Humildade;
[040] - Qualidade para usar além da infância.
(.)
CAPÍTULO 03 - Princípios básicos:
[042] - O Software é o seu objetivo principal;
[042] - Possibilitar o próximo trabalho é o seu objetivo secundário;
[042] - Diminua a carga de trabalho;
[043] - Adote a simplicidade;
[044] - Encampe a mudança;
[044] - Mude incrementalmente;
[044] - Modele com um propósito;
[045] - Tenha mais de um modelo;
[047] - Trabalho de qualidade;
[048] - Retorno rápido;
[050] - Maximize o retorno que seus clientes obterão;
[050] - Por que princípios básicos?
(.)
CAPÍTULO 04 - Princípios suplementares:
(.)
CAPÍTULO 05 - Práticas básicas:
(.)
CAPÍTULO 06 - Práticas suplementares:
(.)
CAPÍTULO 07 - Ordem a partir do caos: como as práticas da MA se ajustam:
(.)
PARTE II - MODELAGEM ÁGIL NA PRÁTICA:
CAPÍTULO 08 - Comunicação:
(.)
CAPÍTULO 09 - Criando uma cultura ágil:
[096] - Supere os conceitos errôneos que envolvem a modelagem;
[101] - "Pense pequeno";
[101] - Relaxe um pouco;
[102] - Apóie com firmeza os direitos e as responsabilidades dos clentes;
[103] - Repense as apresentações para os clentes.
(.)
CAPÍTULO 10 - Você está usando as ferramentas mais cimples possíveis?
[107] - Modelagem Ágil com ferramentas simples;
[111] - O desenvolvimento de um modelo;
[115] - Modelagem Ágil com ferramentas CASE;
[118] - Uso dos meios;
[119] - O efeito das ferramentas sobre os modelos;
[120] - Uso das ferramentas mais cimples na prática.
(.)
CAPÍTULO 11 - Áreas de trabalho ágil:
[121] - Sala de Modelagem Ágil;
[124] - Áreas de trabalho eficazes;
[124] - Executando este trabalho no mundo rea.
(.)
CAPÍTULO 12 - Equipes de Modelagem Ágil:
[126] - Recrute alguns desenvolvedores bons
[130] - Reconheça que não há "eu"na Modelagem Ágil;
[131] - Peça que todos participem ativamente;
[131] - Modele em equipe;
[133] - Executando este trabalho no mundo real.
(.)
CAPÍTULO 13 - Sessões de Modelagem Ágil:
[135] - Duração de uma sessão de modelagem;
[136] - Tipos de sessões de modelagem;
[138] - Participantes das sessões de modelagem;
[140] - A formalidade das sessões de modelagem;
[141] - Como fazer isto funcionar no mundo real.
(.)
CAPÍTULO 14 - Documentação ágil:
[144] - Por que as pessoas documentam?
[147] - Quando um modelo se torna permanente?
(.)
CAPÍTULO 15 - A UML e além:
[164] - A UML não é suficiente;
[167] - A UML é complexa demais;
[167] - A UML não é uma metodologia nem um processo;
[167] - Esqueça a UML executável (por enquanto);
[169] - Fazendo a UML funcionar na prática.
(.)
PARTE III - MODELAGEM ÁGIL E PROGRAMAÇÃO EXTREMA (XP):
CAPÍTULO 16 - Esclarecendo os fatos:
[174] - A modelagem faz parte da XP;
[174] - A documenta;áo é realizada;
[176] - XP e UML?
[178] - E o veredito é?
(.)
CAPÍTULO 17 - Modelagem Ágil e Programação eXtrema:
(.)
CAPÍTULO 18 - Modelagem ágil ao longo do ciclo de vida XP:
(.)
CAPÍTULO 19 - Modelagem durante a fase Exploração da XP:
(.)
CAPÍTULO 20 - Modelagem durante uma iteração XP: procurando itens:
(.)
CAPÍTULO 21 - Modelagem durante uma iteracão XP: totalizando um pedido:
(.)
PARTE IV - MODELAGEM ÁGIL E O PROCESSO UNIFICADO:
CAPÍTULO 22 - A Modelagem Ágil e o Processo Unificado:
[219] - Como a modelagem funciona no Processo Unificada;
[220] - Até que ponto a adaptação é boa?
[221] - Decida ser ágil.
(.)
CAPÍTULO 23 - A Modelagem Ágil ao longo do ciclo da vida do Processo Unificado:
[225] - As disciplinas de modelagem;
[232] - Disciplinas não-relacionadas à modelagem;
[234] - Como fazer isto funcionar?
(.)
CAPÍTULO 24 - Modelagem Ágil de negócios:
[237] - Um modelo de casos de uso de negócios/essenciais;
[238] - Um modelo simples de objetos de negócio;
[240] - Uma especificação de negócios suplementar ágil;
[242] - Uma visão do negócio;
[242] - Como fazer isto funcionar na prática.
(.)
CAPÍTULO 25 - Requisitos ágeis:
[244] - O modelo de contexto;
[246] - Modelo de casos de uso;
[250] - Story board de casos de uso;
[253] - Especificação suplementar;
[255] - Como fazer isto funcionar na prática.
(.)
CAPÍTULO 26 - Análise e projeto ágeis:
[257] - Repensando modelos de análise e projeto no UP;
[258] - Modelagem de arquitetura;
[263] - Criando realizações de casos de uso;
[264] - Hora de atualizar o caso de uso?
[269] - Hora de usar uma ferramenta CASE?
[269] - Modelagem de projeto de classes;
[272] - Modelagem de dados;
[275] - Encampando a mudança;
[276] - Como isto funciona na prática?
(.)
CAPÍTULO 27 - Gerenciamento ágil de infraestrutura:
[278] - Modelos de infraestrutura;
[279] - Modelagem de infraestrutura;
[281] - Estabelecendo convenções e diretrizes de modelagem;
[282] - Equipes de infraestrutura básica;
[285] - Escalando MA com equipes de arquitetura básica;
[285] - Como fazer isto funcionar no mundo real.
(.)
CAPÍTULO 28 - A adoção da MA em um projeto UP:
[290] - Como isto funciona?
(.)
PARTE V - OLHANDO À FRENTE:
CAPÍTULO 29 - Adotar a Modelagem Ágil ou superar adveersidades:
[294] - Analise a adaptação;
[297] - Mantenha tudo simples;
[297] - Supere desafios organizacionais e culturais;
[301] - Supere desafios relacionados ao projeto;
[304] - Pense em alternativas à adoção integral da MA;
[304] - Como fazer isto funcionar na prática.
(.)
CAPÍTULO 30 - Conclusão: decida ser bem-sucedido:
[305] - Equivocos comuns em relação à Modelagem Ágil;
[306] - Quando é Modelagem Ágil ou não?
[308] - Fontes da Modelagem Ágil;
[308] - Algumas considerações.
(.)
[311] - Apêndice A Técnicas de modelagem.
(.)
[329] - Glossário de definições e abreviaturas.
(.)
[337] - Referências e literatura sugerida.
(.)