REF 195.0.1. Переход к agile - тяжелая работа

Фрагмент :

Я выделяю три причины, по которым “гибкие” инициативы затормаживаются:

1. Движение в сторону “гибкости” часто начинается с самого низкого уровня и поэтому рассматривается как “блажь кодеров”. Как следствие, менеджеры и заказчики зачастую не участвуют в преобразованиях. Это тормозит инициативу, потому что настоящая “гибкость” требует смены парадигмы как менеджеров, так и заказчиков.
2. Часто в самом процессе преобразований допускаются ошибки, например, база кода “загнивает” или в умах команд или заказчиков формируются завышенные и нереальные ожидания от “гибкого” процесса. Иногда реализация “гибкости” следует рецепту, который не подходит для данной организации в целом или ряда групп внутри организации.
3. Иногда “гибкость” рассматривают как серебряную пулю, которая быстро решит все проблемы. В этом случае команды оказываются не готовы к большому объему работы, которую нужно проделать для изменения процесса, и энтузиазм постепенно угасает.

Инициация и поддержание эффективной программы внедрения “гибкости” - это тернистый путь. Во-первых, в реализацию должны быть вовлечены не только команды разработчиков, более того, всем участникам потребуется изменить свое мышление и подход к управлению. Во-вторых, технические практики - короткие итерации, разработка через тестирование, непрерывная интеграция - не опциональны. Ну и напоследок, ничто, даже “гибкая разработка”, не устранит сложность ПО или ее нелинейное возрастание с увеличением размера ПО.

Текст оригинала :

I observe three reasons why agile initiatives seem to plateau:

• First, agile development is frequently initiated as a grassroots movement to develop better software—it is seen as a “developer thing.” Consequently, development managers and customer organizations are often not on board. This is a mistake, because dramatic improvements from agile development require a different mindset on the part of both development managers and the organizations for which the software is being developed.
• Second, some companies have made serious missteps in applying agile — perhaps by developing an unmaintainable code base or creating an unsupportable set of expectations in the minds of development teams or customers. Sometimes an agile implementation follows a simple recipe that is a bad fit to the company needs; sometimes the implementation is perfect for some people in the company (developers, for instance), but it doesn’t take into account the needs of others (testers, for example).
• Finally, agile development might be considered a silver bullet—a quick and easy fix to problems that plague software development. In this case, the hard work required to make agile successful is ignored, and when companies come to the realization that agile is not going to be as easy as they anticipated, all too often commitment dissipates.

Initiating and sustaining an effective agile development program is a challenging journey. First, implementation should involve far more than the development team. A broad array of cross-functional impacts should be considered, not to mention the fact that agile might well require a different management approach. Second, the technical practices that agile brings to the table—short iterations, test-first development, contin uous integration—are not optional. Ignore them or leave them until later at your own risk. Finally, nothing, not even agile development, will remove the inherent complexity of software development or its nonlinear escalation with size.

Источник: REF 195. Becoming Agile. Smith, Greg. 2009, foreword, p.xvii-xviii