Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

Антипаттерны перехода на гибкие методологии

В последнее время мне всё чаще и чаще приходится выслушивать негативные впечатления от моих друзей, знакомых и экс-коллег, связанные с переходом ИТ-компаний на гибкие (agile) метологии. В частности, наибольшую популярность (и как следствие, народное недовольство) снискал переход на Scrum.

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

Итак, основные антипаттерны перехода на гибкие метологии:

1. Непонимание роли руководства при внедрении методологии. Переход на многие гибкие методологии (Scrum, XP) подразумевает координальную смену задач и методов работы руководителей. В двух словах этот переход можно сформулировать как переход от управления к направлению, переход от приказов и указаний к рекоммендациям. Первая ошибка, которая допускается при таком переходе - подсознательное стремление сохранить за собой власть, ведущее ко всё тому же управлению, но замаскированному идеями agile. Вторая, не менее серьёзная ошибка прямо противоположна - неправильное понимание этого перехода может привести к устранению менеджеров от руководящих функций, когда руководитель перестаёт давать указания, но так и не начинает давать рекомендации. Роль руководителя при этом сводится к чисто формальным, секретарским функциям. Причиной этого может быть и неготовность руководителей давать аргументацию своему мнению (в старой модели им этого зачастую делать не приходилось) или боязнь невыполнения высказанных рекоммендаций.

2. Построение «системы», не обладающей необходимой гибкостью. Отсутствие опыта работы по новой методологии ведёт к тому, что новый процесс внедряется по инструкциям, буква к букве, что ведёт к негибкости и бюрократизации.

3. Начало внедрения не с «основ». При переходе на новые методологии руководство преследует конкретные выгоды, которые должна обеспечить методология: высокая производительность, качество и т.п. При этом некоторые практики нового процесса более очевидно ведут к этим выгодам, а некоторые - совсем не очевидно. В связи с этим возникает соблазн внедрить сначала более "выгодные" практики, а потом уже остальные. При этом не учитывается, что некоторые практики являются базовыми по отношению к другим, и внедрение вторых без первых невозможно. Пример: внедрение таких практик XP как рефакторинг или коллективное владение кодом без отработанной практики юнит-тестирования гарантированно приведёт к резкому ухудшению качества.

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

5. Все измерять (собирать данные), но ни на что не реагировать. Бесконечный анализ ситуации, вместо непрерывных улучшений («Паралитический анализ»). Большинство гибких методологий подразумевают сбор метрик и обязательную рефлексию - обсуждение ощибок, совершённых на предыдущем этапе, перед началом следующего. Распространённые ошибки в этой сфере - сбор метрик без их последующего анализа или неверная, слишком поверхностная интерпретация метрик; рефлексия без внесения изменений в процесс (или внесение симптотических, экстенсивных изменений).

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


Categories: Agile | Management
Posted by Vitalii Tsybulnyk on Monday, April 26, 2010 9:31 AM
Permalink | Comments (6) | Post RSSRSS comment feed

Comments (6) -

Аленка United States

Monday, September 13, 2010 2:42 AM

Виталик, прокоментируй плиз "коллективную ответственность" в гибких методологиях и отказ от QA?
хотела бы услышать твое мнение о возможности построения успешной команды в таких условиях?

Vitalii Tsybulnyk United States

Monday, September 13, 2010 10:28 AM

Алёнка, хотелось бы чуть больше деталей в твоём вопросе.

Практика "коллективной ответственности" во многих гибких методологиях подразумевает совместную ответственность всей команды за успехи и ошибки проекта. Такая формулировка является прямым следствием присутствия в команде специалистов всех профилей, необходимых для успеха команды - например Scrum команда обычно включает в себя специалиста по планированию, анализу требований и работе с заказчиками (Program Manager), специалистов по дизайну функциональности и разработке кода (Developer) и специалистов по контролю качества продукта (QA). Однако команда может привлекать для работы над конкретным спринтом/релизом специалистов и других профилей, если они необходимы (эксперты usability, security и т.п.) Именно наличие в команде разноплановых специалистов и возможность привлекать необходимые ресурсы и есть залог практики "коллективной отвественности" за результат работы.
Лично мне эта практика очень по душе как противовес практики противостояния, существующей в классических методологиях. Классические примеры противостояния:
* Program Manager - Developer: ПМ старается впихнуть девелопером как можно больше требований и как можно более жёсткие сроки, а релистичность их уже как говорится "не моя проблема", за провал реализации если что отвечать девелоперам.
* Developer - QA: Девелоперы в свою очередь стараются "впарить" свою работу QA, а те в свою очередь изо всех сил стараются "подловить" девелоперов на багах, т.к. в конечном итоге за пропущеные баги "крайний" как раз тестер.
Такие практики совершенно не способствуют общему успеху проекта, поэтому вводится "коллективная ответственность" как залог взаимопомощи специалистов разных профилей друг другу: девелоперы помогают ПМ постоить реальные планы и реалистично оценить трудоёмкость требований, тесты помогают девам найти грубые ошибки на ранних стадиях и сделать весь код более устойчивым, а девы в свою очередь делают свой код как можно более "тестабильным" (testablility) чтобы помочь тестам. Однако у такой практики есть и обратная сторона - все роли должны хорошо понимать задачи и проблемы других ролей, так девы должны понимать основы QA, тесты должны понимать основы кода (вплоть до способности делать ревью или дебажить проблему), а тесты и девы должны знать и понимать план своих работ. Таким образом границы ролей как бы стираются на фоне общих задач и целей.

Об "отказе от QA" я слышал только от команд, практикующих XP. В Scrum, насколько мне известно, эта практика не применяется, а даже наоборот, в состав скрам-команды обязательно должны входить специалисты QA в количетве приблизительно равном количеству девелоперов. Что касается "отказа от QA" в XP - то это очень хороший пример "неверных интерпретаций", о которых я говорил в статье. Под "отказом от QA" в XP подразумевается то, что в состав XP-пар входят активные девелоперы, которые по очереди пишут код, а QA обеспечивается тем же кодом юнит-тестов и/или автоматических тестов, написанных этими же девелоперами. Т.о. якобы заявляется "отсутствие QA", а на самом деле подразумевается, что необходимы "мастера на все руки" Smile  К сожалению количество "мастеров на все руки" на этой планете весьма ограничено, да и эффективность такого подхода для крупномасштабных проектов не так высока, поэтому большинство гибких методологих всё-таки не устраняет роль QA и не объединяет её с другими ролями.

Аленка United States

Monday, September 13, 2010 7:40 PM

я умышленно не дала больше деталей, чтобы услышать "чистое" твое мнение, не базированное на моем Smile
Все, что ты говоришь, звучит очень хорошо. Но, увы, встречается только в теории. По крайней мере тут, у нас, у простых смертных Smile
Коллективная ответственность сводится к тому, что никто ни за что не отвечает. т.е ответственности как таковой и нет.
т.е если ПМ допустил грубую ошибку - он всегда может сьехать "а что ж вы мне не подсказали, не помогли, не предупредили?"
в случае с отказом от QA все обстоит еще веселее. Как и многие другие "прелести" гибких методологий, ПМы\директора слышат только то, что хотят слышать.
а-ля "можно жить без спецификаций" и упорно игнорируют всякую документацию. Пунктик о том, что в это время спецификация заменяется на подробные юзер-стори или еще что, просто игнорируется. Так же с QA- без них можно жить, но всякие "но при этом надо" - упускаются.
Вот и интересно, существуют ли команды, где это действительно работает, где Скрам-проекты успешны? где живя по ХР заканчивают проекты в срок и полном объеме?

Vitalii Tsybulnyk United States

Tuesday, September 14, 2010 6:50 AM

Именно такие истории мне приходится слышать постоянно и именно ответом на них и был мой пост.
Да, конечно, гибкие методологии работают и очень хорошо, и множество серьёзных проектов заканчиваются успешно и в срок (иначе "миф" об их эффективности быстро бы развеялся)! Только вот почему-то когда люди учатся плавать - они понимают что им нужен инструктор, иначе они либо утонут сразу, либо максимум научатся плавать "по-собачьи". Когда люди учатся играть на музыкальном инструменте - они понимают, что им нужен учитель, ведь можно потратить годы извлекая какофонию из инструмента, и так и не изобрести сколько-нибудь внятную технику игры. А вот когда доходит до вещей типа гибких методологий - большинство мнит себя рождёнными в рубахе и способными осилить эту науку в лучшем случае по онлайн-тренингам, а в большинстве по обрывкам прочитанных статей.
Мне кажется "ноги" такого поведения "растут" из того, что большинство наших ИТ-шных управленцев - самоучки и привыкли всё осиливать сами. При том как правило они самоучки как в ИТ, так и в управлении. И если в техно-вопросах самоучка в большинстве случаев совершенно не уступает обученному человеку (ведь там более-менее всё линейно: написал код - получил работу программы), и то постоянно случаются казусы когда самоучка использует технологию неким извращённым, неэффективным а то и ошибочным способом. В управлении же иногда нужны годы, чтобы понять допущенную вначале ошибку, а потом ещё годы чтобы её исправить. Поэтому в управлении, частью которого является внедрение, адаптация и соблюдение методологий, как нигде важна помощь эксперта в методологии, который хотябы знает как выглядит в работе конечный результат перехода, который мог бы вовремя исправить все недопонимания, опасные "усовершенствования" и неверные интерпретации. И помощь такого экстперта нужна не только при переходе, а и постоянно, пока методология не укоренилась и не дала первые положительные результаты.
Это и есть ответ на твой вопрос - прибегала ли компания/команда к помощи экспертов при переходе на гибкую методологию? Если нет - то то, на что они перешли с большой вероятностью не является заявленной методологией. Прямо как в анекдоте:
- Этот ваш Паваротти так отвратительно поёт, кому это вобще может нравится? Мало того что ни слуха ни голоса, так ещё и картавит!
- А ты слышал?
- Не, мне сосед по телефону напел.
Smile

Аленка Ukraine

Tuesday, November 2, 2010 9:19 PM

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

Vitalii Tsybulnyk United States

Monday, November 22, 2010 10:59 AM

Кстати, Аленка, ты сетуешь на отсутствие документации, так я вспомнил, что у меня был пост по поводу особенностей документирования при гибких процессках: blog.tsybulnyk.com/.../...re-Development-Team.aspx Там же и о границах применения такого подхода есть.
Больше о границах применения agile вобще в новом посте blog.tsybulnyk.com/post/Team-vs-Methodology.aspx

Add comment




  Country flag

b i u quote
Loading