Предпосылки возникновения Agile

3.3. Эффективная таблетка от болезней?

Итеративный и Agile методы разработки программных продуктов подходят не всем. Во всех компаниях существует своя специфика, которая определяется множеством разнообразных факторов различной природы, определяемой организационными, административными и специализированными условиями внешней и внутренней среды. В ряде компаний использование водопадной модели обосновано и экономически целесообразно. Можно привести много причин, почему Agile использовать не стоит.

Разработка качественной информационной системы - дело непростое. Каждый, кто сулит реальность "волшебного зелья", гарантирующего выпуск программного продукта, решающего все проблемы и снимающего "боль" компании, - шарлатан, продающий плацебо.

Консультанты, специализирующиеся во внедрении и продвижении Agile, первым делом заявляют, что Agile - не волшебная пуля, магическим образом убирающая все проблемы, но оставшуюся часть времени вам говорят, что это лучшее изобретение человечества.

Agile - это набор устоявшихся методик, основанный на итеративной разработке программного обеспечения.

Конечно, есть литература, книги, эксперты, конференции и т. д., но следует помнить, что это всего лишь устоявшиеся методики, которые базируются на:

• изменениях;
• приспособляемости;
• людях.

Методология Agile, несмотря на обилие существующей литературы, имеет строго практическую направленность. Не получится просто прочесть несколько статей, изучить книгу, пройти курс и внезапно стать гибким. Важно параллельно с освоением теоретических азов постигать практические приемы работы. Agile дает многочисленные преимущества рабочим группам и небольшим проектам. Это является основой для обсуждения преимуществ, которые они могут предоставлять для разработки крупных модульных систем.

3.4. Для кого подходит, а для кого нет?

В сообществе ИТ-менеджмента Agile - одна из самых популярных тем уже на протяжении долгого периода времени. Происходит это из-за волнообразного спроса на повышение эффективности процессов разработки в различных сегментах деятельности. Мнения по этому поводу самые разные.

При обсуждении необходимо учитывать предпосылки, которые демонстрируют преимущества и недостатки, основываясь не столько на отдельных оценках уважаемых экспертов, а на фактах, возникающих в процессе эксплуатации Agile различными участниками процессов. Именно взвешенные мнения участников процесса позволят установить истину, рожденную в дебатах.

Agile, несмотря на демократичность, подразумевает наличие жесткой дисциплины. Это может способствовать более эффективной организации труда и, как следствие, максимизации получаемого результата. Но это кое-чего стоит.

Для распространения необходимой информации по процессу в Agile предписывается для выполнения ряд необходимых мероприятий. В них на постоянной основе должны участвовать не только специалисты, занятые разработкой программного обеспечения, но и менеджеры, активное участие которых необходимо и во многом предопределяет дальнейший успех создаваемого продукта.

Если менеджер не сможет участвовать в предписываемых гибкой методологией встречах, то необходимо задуматься о делегировании соответствующих полномочий в развитии разрабатываемой системы коллеге или подчиненному, который сможет вдумчиво, настойчиво, ясно и с полным осознанием сути задачи донести ее до команды и впоследствии принять созданный результат. В противном случае суть Agile будет выхолощена и принцип "первого руководителя", по мнению многих, самый действенный при внедрении и применении различных процессов, будет нивелирован. Как следствие, Agile не достигнет постулируемой эффективности, и программный продукт будет создаваться разработчиками для разработчиков.

Код создаваемой системы должен быть простым и читаемым, чтобы его можно было легко менять, причем в любой момент и разным специалистам. Для этого требуется постоянно критически его пересматривать и заниматься рефакторингом разработанной, но устаревшей функциональности. Важно иметь человека, который сможет критически подойти к актуальной ситуации и при необходимости обозначить нужные доработки в целях облегчения дальнейшей сопровождаемости и развития информационной системы

Для того чтобы держать планку заданного качества, требуется создавать юнит-тесты. Это приводит к тому, что на разработчика вешается вдвое больше работы. Но если этого не делать, то повышается вероятность выпуска низкокачественного продукта, который будет не соответствовать ожиданиям пользователей.

Для того чтобы разрабатываемый продукт был целостным с точки зрения концепции его развития, необходимо постоянно обсуждать вопросы анализа, проектирования, выполнять контроль деятельности менее опытных разработчиков, отыскивать ошибки. Одна из техник, которая может позволить выполнить намеченные задачи, называется парным программированием. Его суть состоит в парной, поочередной разработке кода двух разработчиков в единицу времени за одним рабочим местом. Это очень тяжелое испытание для тех, чей уровень коммуникационных способностей находится на достаточно низком уровне. Представьте себе, что кто-то сидит рядом с вами и постоянно указывает на то, как, по его мнению, правильно реализовать тот или иной участок создаваемой информационной системы. Более того, иногда (а вернее, очень даже часто) будет требоваться напрямую общаться с заказчиками функционала. Agile позволит создавать работающий продукт с высоким качеством в прогнозируемые сроки. Единственное важное условие - заказчик должен быть заинтересован в создании работающего продукта с высоким качеством в прогнозируемые сроки.

Большинству разработчиков интересно реализовывать сложный, "заковыристый" модуль, но неинтересно писать простой, но надежно работающий продукт. Разработчики более заинтересованы в увлекательном исследовательском процессе, а что будет происходить с заказчиком в момент использования разработанной функциональности клиентом - их, как правило, не интересует.

Специалисты ценят свой комфорт за компьютером. Рабочее место - родной дом и непререкаемая зона комфорта. Менеджер, ответственный за процесс, должен изменить ситуацию, когда собственный комфорт важнее, чем работающий софт, успех компании и т. д. Требуется постоянно доносить до ответственных специалистов необходимость и нужность их работы, ее влияние на процессы компании.

Agile предписывает изменения в подходах не только к работе, но и к устоявшимся привычкам, если они противоречат общим целям. Такой процесс не только постулирует желание и готовность к постоянным переменам и "ломкам" характера и профессиональных устоев. Он привносит мотивацию, которой вряд ли можно ожидать в компаниях, проповедующих классические подходы к процессам разработки программного обеспечения, как, например, техника парного программирования, о которой мы поговорим позже.

Итогом становится то, что для эффективного внедрения Agile необходим ряд факторов, которые смогут обеспечить его оптимальное применение в компании:

• заинтересованность руководства в достижении поставленных результатов;
• желание и способность участвовать в развитии продукта;
• наличие квалифицированной команды разработчиков, способной создавать качественный продукт и анализировать результаты и существующий процесс в целях его оптимизации;
• готовность к открытому диалогу и конструктивной критике всех членов команды;
• желание изменений и перемен.

В последующих главах курса мы дополним, раскроем и детализируем приведенный список факторов.

3.5. Краткие выводы

Ситуацию, благодаря которой Agile получила право на существование, трудно назвать идеальной. Состояние области разработки и внедрения программного обеспечения сложно назвать стабильной и отвечающей ожиданиям заинтересованных в ее использовании. Agile возникла не как академическая дисциплина, а как ответ на несостоятельность рыночным реалиям ее конкурентов. Не просто возник, а явился результатом вдумчивого процесса размышления признанной группы консультантов и экспертов над проблемами в области управления разработкой программного обеспечения и уже на протяжении долгого периода показывает свою состоятельность и результативность.

Все это говорит о том, что Agile завоевала свою аудиторию и стала популярной. В то же время по-прежнему еще слабо представляется, как правильно работать по Agile. Приведем слова Майкла Кона: "Мне хочется, чтобы все Agile-бренды в конечном счете исчезли, и осталось просто то, как мы разрабатываем программное обеспечение".

Можно и нужно сравнивать различные направления Agile, такие как Scrum или Kanban, сосредоточиваясь на техническом совершенстве каждого из них, или же, напротив, развивать коммуникации и командную работу. Все это в конечном итоге приведет к совершенствованию и развитию Agile, повышению эффективности в зависимости от условий, в которых ее используют.