Обсуждая agile техники и подходы к разработке и управлению проектами, мы, как правило, смотрим на проблему изнутри команды, говорим о том, как команда должна быть организована и каковы основные ингредиенты успеха. При этом мы зачастую опускаем внешнее окружение или предполагаем, что внешнее окружение легко прогнется под воздействием команды под ее нужды и мировоззрение. А так ли это? Очевидно, что ответ зависит от контекста, в котором работает команда. В условиях совместной с клиентом разработки (co-development) пренебрегать внешним окружением нельзя, и, не понимая его, считаться с ним эффективно не получится. Давайте разбираться на примерах.
Клиентов сервисных компаний софтверного бизнеса можно делить на разные категории. Но, если смотреть на проблему свысока и отбросить наукоемкое производство и государственные заказы, то останутся две большие группы:
- ISV, основной бизнес которых есть производство софтверных продуктов
- Бизнес компании, занимающиеся производством или оказанием услуг в других областях и пользующиеся софтверными продуктами как инструментом
Разница между ISV и корпоративными клиентами намного больше, чем между ISV разного размера и технологической ориентации внутри своей категории. Не попробовав поработать и в той и в другой среде, очень сложно оценить и прочувствовать, насколько же сильна эта разница. Попробовав и сделав пару тройку успешных (и не очень) проектов и там и там, сложно выделить ключевые элементы и разложить по полочкам, в чем же собственно заключены основные отличия. Но я рискну коротко просуммировать свой опыт работы с компаниями обоих типов на американском рынке (непосредственно об устройстве ISV и больших корпораций и об особенностях работы с ними я обязательно напишу отдельно в продолжение начатой темы):
- ISV делают софт “всю жизнь”, этим зарабатывают деньги, и практически на всех ролях в компании работают инженеры. Отсюда - знание и понимание процессов разработки и жизненного цикла, почерпанное не только из книжек. Знание это не обязательно “кошерное”, но зато оно опробовано на собственной шкуре.
- IT отдел в бизнес компании есть всего лишь сервис, который долгое время варится в своем соку и разговаривает с бизнесом через “переводчиков”. Отсюда медлительность и возведение многих аспектов процесса разработки в религию. Энциклопедические знания по теме зачастую превышают ожидания, но, неподкрепленные практическим опытом, превращаются в идейные лозунги.
- ISV нацелены на результат, тогда как IT отделы корпораций больше нацелены на процесс. Отсюда давление и сжатые сроки при работе с ISV, и (на контрасте) очень политизированная и электризованная среда в корпорациях.
- Конкуренция вынуждает ISV рисковать и опробовать новые техники (как в выборе инструментария и платформ, так и в выборе подходов к организации процессов), в то время как IT отделы бизнес клиентов в большей степени озабочены надежностью и предсказуемостью. А когда делают инновации - делают их очень основательно.
Список этот можно продолжать, но для моего сегодняшнего примера приведенных различий достаточно. Хотелось бы добавить только одно забавное наблюдение. Карьера профессионалов редко пересекает границы двух миров: любо карьера в бизнес компаниях, либо карьера в ISV. Похоже, что сформированную ментальность по одному из двух путей развития тем сложнее перетащить в другой, чем больше времени проведено в изначально освоенной. Архитектор с большим опытом работы в корпорации при случае окажется не способен оценить и принять практичную направленность работы своих коллег в ISV, а главное: не сумеет быстро отрабатывать свои предложения. Такой же опытный архитектор из ISV подвергнет свой мозг и характер серьезному испытанию, перейдя в политизированный, медлительный, а главное теоретическо-направленный мир архитектурной профессии своих коллег из корпоративного мира. Хотя оба легко и одинаково хорошо сдадут тесты проф пригодности в области своей компетенции.
А на другой стороне мы - сервисные софтверные компании - зарабатываем деньги, профессионально производя программные продукты и оказывая всевозможные попутные услуги. Отличается ли стиль и содержание нашей работы в зависимости от типа клиента? Абсолютно да! но об этом тоже в другой раз.
А сегодня - о причудливых формах agile, развернутом IT отделом большой корпорации, и о влиянии этих форм на agile команду разработки за океаном. По версии клиента квинтэссенцией agile являются истории, которые надо измерять (ни в коем случае!) не в человеко-часах, а только лишь в поинтах). Истории, которые можно насаживать на дерево функциональных областей (feature tree), но нельзя записывать в бэклоги (и вообще, бэклоги есть рудимент, отмирающий на пути к agile 2.0). Истории должны проходить четкий процесс утверждения на реализацию и каждая иметь за собой индивидуальную ветку в системе контроля версий (GIT). Ветка проходит обязательный peer review и зайдет в основной репозиторий только через гейт кипера (definition of done в частности запрещает To-Do комментарии в коде). А промежуточные демонстрации бизнесу должны проходить гладко, чтоб без сучка без задоринки и по заранее оговоренному сценарию. А сверху положен должен быть MPP для отражения плана и прогресса в наглядной форме, понятной главному руководству. Ну, и конечно, правильная гранулярность WS API и семантика публичных методов сервисов важнее всего.
Многие детали я опустил, но суть вы уже поняли – реализовано много хороших и правильных практик, местами некорректно интерпретированных, частью возведенных в абсолют, разбавленных старыми добрыми традициями водопадных процессов (mainframe софт по-другому не писали) и особенностями взаимоотношений отделов. Бизнес ведь все-таки клиент и музыку заказывает, но сам играть не умеет. Вот мы и будем играть, как считаем нужным, а они нам перечить не станут - не их профессия да и культура не позволяет (про культурные отличия мы тоже обязательно поговорим). Надо бы оговориться, что и ISV клиенты успешно навязывают свое видение мира, особенно в условиях совместной работы, но их мировоззрение, пусть не всегда более близкое к истине, все-таки (как правило) более практично и имеет свои корни не в эрудированности наставляющих, а в синяках на различных частях их тела.
Что в этой ситуации делает исполнитель? Вариантов, конечно, несколько, но одно понятно совершенно точно - от внешнего воздействия не избавиться, и его присутствие необходимо учитывать:
- Вариант 1. Можно пробовать максимально игнорировать нездоровые идеи, выставляя прокси/маску наружу, и инсталлируя внутри команды тот agile, который наиболее подходит для команды и задачи. В теории – работает. A на практике - прозрачность stand up -ов и распределенная разработка по веткам-историям создает слишком много барьеров, прятать которые за маски каждый день просто не получается без серьезных потерь в эффективности
- Вариант 2. Можно принимать правила игры полностью и катиться по проторенной колее. Побочные эффекты: тяжелая адаптация, постоянный внутренний конфликт (особенно ярко наблюдаемый в активных личностях, остро болеющих за эффективность), и часто не лучшие отношения с бизнесом.
Два “крайних” случая одинаково непригодны - серьезная потеря эффективности и постоянный дискомфорт. Так что же делать?? ответ одновременно простой и сложный (за серебряными пулями не ко мне, простите) - адаптироваться. На то и слово есть красивое - agile. Адаптироваться в данной ситуации означает: оптимизировать функцию от эффективности (делать как мы), прозрачности (делать как они), комфорта (наше удовольствие от результата), качества (их удовольствие от результата), и взаимоотношений.
Я обязательно поделюсь опытом адаптации в описанном выше случае, но сначала хотел бы пофилософствовать о методологиях. Не переключайтесь.
Имхо мы имеем характерное непонимание смысла agile - типа agile значит “адаптироваться”, а “адаптироваться” значит “тут добавим водопада, а тут выкинем пару практик, тут поставим Главного, тут маленько поднапишем спецификацию, и вот мы уже подстроились под заказчика!”
В результате получается бодяга, которая через пень колоду работает с этим данным заказчиком. У нее есть несомненное достоинство - она работает. Но эта бодяга не дает прироста производительности, использования коллективного опыта, экономии на накладных расходах - потому что при подстройке в интересах QMS+топменеджеров+еще_кого_то она теряет те принципы, ради которых задумывался agile, и не дает эффекта ради которого вводились принципы.
И вот тут как раз хорошо виден дефект мышления нас контуженных аутсорсингом (и я брут, ага) - “команда должна подстроиться под окружение”. Блин, команда не подстраивается под окружение. Окружение, которое реально готово и способно работать agile, создает agile-команду. Тогда - когда окружение и команда - готово и способно работать по agile - вот тогда и получаются чудеса. Тогда - прирост производительности, радостная команда, супер-системы, польза для бизнеса.
Иначе - окружение “подстраивает” команду под псевдо-agile: c терминами “дэйли скрам” (ежеутренний трах менеджером), бэклогами (набор 10страничных документов), “скрам мастерами” (”ты будешь делать то-то и то-то”), DoDами (”ни одна тупая скотина не комитит в транк пока я не отревьиюл!!!”) Это можно называть аджайлом, но это не будет аджайлом. И очередной заказчик скажет за пивом своему товарищу - “знаешь, попробовали мы этот аджайл - чё-то не заметил я ни прироста качества, ни производительности, по моему та же фигня тока вид сбоку…”