Аджайл что это: Что такое Agile, зачем и где используется, разница Scrum и Kanban

Agile coach здорового человека / Хабр

Вступительное слово

Для удобства я буду писать различные английские слова, такие как “Agile”, “coach”, “Scrum” и т.д. русскими буквами. Аджайл, коуч, скрам и т.д. Кто легко оскорбляется наличием транслитерации в тексте — прошу меня понять и простить.

Аджайл сегодня, как мгла из одноимённого романа Кинга, распространяется по планете Земля, проникая во всё большее количество сфер человеческой деятельности и в умы непосредственных деятелей.

К нашему всеобщему счастью в Аджайле обитают не только чудовища. Одно из порождений Аджайла, о котором сегодня пойдёт речь — аджайл коуч.

А стоит об этом поговорить, потому как всё чаще можно встретить людей, всерьёз рассуждающих, что лучше канбан, или скрам; увидеть компании, ищущие аджайл коучей/скрам-мастеров (именно в таком виде), и наткнуться на литературу, рассказывающую, что в начале было слово, и это слово было “Аджайл”.

И это опасная тенденция.

Попробумем разобраься, что такое аджайл, кто такой аджайл коуч, каким аджайл коуча хочет видеть бизнес, что аджайл коуч должен знать и уметь, и где этому можно научиться.

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

Приятного чтения.

Кто такой Аджайл коуч?

Чтобы однозначно ответить на вопрос, кто такой “специалист в области Х” нужно подробно рассмотреть эту область деятельности. Определить её суть, практический смысл и понять пул фундаментальных знаний, к ней относящийся.

Аджайл

Современное понимание этого слова в контексте рабочего процесса основывается на “Манифесте гибкой разработки программного обеспечения”, где и отражена общая логика и специфика идей, концепций и практик.

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

Кратко Аджайл — это парадигма разработки ПО (исходя из определения понятия “парадигма”). Это набор определённых концепций, идей и практик, объединенных общей логикой и спецификой.

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

Поскольку именно от условий зависит то, какими свойствами должна обладать система, создаваемая для работы этих условиях, имея описание свойств системы, мы можем вывести и сами условия.

Я буду опираться на ценности и принципы и описывать условия, когда следование этим ценностям и принципам приносило бы ощутимую пользу.

• Когда в модели итогового продукта есть неизвестные элементы, или требования к определенным элементам неоднозначны/не определены и невозможно построить математически точную модель.
• Когда нет возможности учесть влияние всех факторов внешней среды, и внезапно может возникнуть фактор, который сделает следование изначальному плану нецелесообразным.
• Когда процессы не определены однозначно от начала и до конца (и не обкатаны на практике и не стандартизированы) и могут внезапно открыться новые необходимые шаги, или обнаружится нецелесообразные. Неполноценность инструментария идёт, как неизбежное следствие, поскольку инструменты подбираются в соответствии с содержанием того, что придётся делать, т.е. с процессами. Как еще одно следствие — возможность оперативно вносить изменения в процессы. Т.е. к процессам не должно предъявляться никаких жестких требований.
• Когда требования к итоговому продукту не строгие и последствия наличия ошибок несущественны.
• Когда есть возможность получения прямой обратной связи от конечного пользователя продукта и изменения его свойств на основе полученной информации. Т.е. продукт должен использоваться непосредственно и главным критерием готовности (приемлемости) должна являться удовлетворённость пользователя.
• Когда есть возможность изменять любые свойства продукта на любой стадии разработки. Т.е. специфика продукта должна это позволять.
• Когда есть возможность выпускать продукт итеративно. Т.е. специфика продукта должна это позволять. Продукт должен быть полноценен с минимальным набором функциональности и сложность его доработки должна быть достаточно низкой, чтобы итерации не затягивались.
• Когда есть возможность корректировать свойства продукта в соответствии с целями бизнеса (прибыль). Т.е. специфика продукта должна позволять вносить изменения в его свойства, исходя из соображений прибыльности. Значит, к итоговым свойствам и используемым технологиям не должно предъявляться строгих требований. (Сертификации, стандарты качества и т.д.)
• Когда есть возможность оценивать прогресс по состоянию продукта. Т.е. к самому процессу разработки не должно предъявляться строгих требований, он не должен быть жестко регламентирован, и не должен страдать от произвольной организации.
• Возможность непосредственно вносить изменения в производственный процесс. Т.е. он должен быть достаточно простым, чтобы изменения, во-первых, были реализуемы без длительных подготовительных процедур, во-вторых, не спровоцировали неочевидных нежелательных последствий в долгосрочной перспективе на различных этапах.

Итак, мы получили описание условий для работы в которых адаптирована рабочая среда, созданная в соответствии с ценностями и принципами манифеста.

Первое, что лично мне бросилось в глаза — в описанных условиях физически возможно создавать только крайне специфические продукты. Что делает гибкую парадигму весьма узкоспециализированной и неприменимой за описанными рамками. Например, производство лекарств подобным образом в принципе невозможно. Поскольку, как ни крути, а соблюсти большую часть ценностей и принципов не получится (И как следствие большинство методик и инструментов не подойдут). И, разумеется, это касается не только лекарств. Чем дальше специфика продукта и условия от описанных, тем менее адекватными будут инструменты и практики аджайла. (По идее, сравнив свой продукт и условия, в которых придётся работать, с вышеизложенными, заинтересованное лицо от бизнеса может прикинуть, насколько в принципе компании подойдёт аджайл)

Но рост популярности гибкой парадигмы — факт. Что же происходит?

Если еще раз внимательно посмотреть на 12 принципов, можно выделить следующие:

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

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

Подходы к организации командной работы и используемые для её обеспечения инструменты выкристаллизовались из имперического опыта сотен тысяч команд. Они реально хороши. Их можно и нужно перенимать. А всё остальное — только после вдумчивого критического переосмысления, потому как слепо скопированный рабочий процесс в других условиях будет попросту неадекватен и погрузит компанию в процессный ад.

Суммируя.

Аджайл — это парадигма разработки ПО. Рабочая среда, выстроенная в соответствии с этой парадигмой — это среда, где на практике реализованы (т.е. отражены в бизнес-процессах и культуре) ценности и принципы манифеста. Существующие в рамках парадигмы подходы, практики, инструменты и т.д. строго “заточены” на производство весьма специфического продукта в конкретных условиях (которые мы и описали). Применять их без адаптации безопасно только если специфика продукта и условия компании соответствуют “классическим”.

Кого хочет видеть бизнес в роли аджайл коуча?

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

Первый — АК в роли трансформационного менеджера и советника.

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

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

Основной акцент делается на функционал скрам-мастера. От коуча остаётся необходимость продвижения ценностей аджайла среди сотрудников компании.

Аджайл коуч в роли скрам-мастера практического смысла не имеет, поскольку скрам-мастер роль вполне конкретная. И если компании нужен именно скрам-мастер, значит в компании уже внедрен (внедряется) скрам. В то время, как аджайл коуч в рамках разработки пакета предполагаемых изменений, должен еще решить, а будет ли использоваться скрам. Сам факт существования подобной формулировки должности можно объяснить отсутствием у тех, кто готовит описание подобных вакансий, понимания кто есть кто и кто что делает.

Таким образом, можно сделать вывод, что бизнес (в целом) в виде аджайл коуча хочет получить некоего консультанта, специалиста в построении рабочего процесса. Который расскажет что и как делать, чтобы стало лучше и проследит, чтобы всё прошло, как надо.

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

Первая грань есть. Аджайл коуч — это архитектор рабочего процесса.

Проанализируем вторую грань — коуч.

Что такое коучинг и кто такой коуч?

Коучинг — это частный случай психологического консультирования, вокруг которого выстроилась огромная индустрия по изъятию денег из людей. Поэтому многие воспринимают коучинг, как самостоятельную сферу.

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

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

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

Ровно это мы и видим в описании вакансий. Бизнес хочет, чтобы аджайл коуч не только реализовал ряд изменений рабочего процесса, но и организовал плавный и безболезненный переход в новые условия сотрудников компании. Ну, еще до кучи объяснил руководству вот зе фак из аджайл. Потому как требование пропагандировать ценности данной парадигмы есть почти в каждой вакансии. (Интересно, а инженеров сейчас просят пропагандировать ценности электродинамики в рамках рабочих обязанностей?)

Объединяем обе грани и получаем смысл деятельности аджайл коуча — его основная задача перестроить рабочую среду компании (или выстроить с нуля) так, чтобы она гармонично сочетала в себе все лучшие практики и инструменты гибкой парадигмы и других, но при этом соответствовала специфике продукта, который производит компания и условиям, в которых компания работает, и реализовать процесс адаптации персонала к обновлённым (или новым) условиям.

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

“гармонично сочетала в себе все лучшие практики и инструменты гибкой парадигмы и других”

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

Аджайл коуч не работает с абстрактной моделью рабочего процесса, он всегда работает с реальной компанией. Современные компании теорией управления понимаются, как системы. Из определения системы

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

мы можем выделить общее, присущее всем компаниям. Любая компания — это организационная система. Далее из определения понятия “управление”

“Управление — это воздействие на управляемую систему с целью обеспечения требуемого ее поведения”

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

Аджайл коуч — это по сути специалист по управлению системами в широком смысле. На практике его деятельность сводится к изменению свойств системы и курированию процесса изменений.

В результате мы неизбежно приходим к утрате смысла приставки “аджайл”, когда речь идёт в общем об управлении системами. Бизнес не хочет видеть на роли консультанта по “перестройке” компании узкоспециализированного специалиста, способного работать только в очень специфических условиях. Он хочет видеть специалиста, способного работать в любых условиях в целом, и в частности в условиях конкретной компании, куда его приглашают. (Я делаю это смелое допущение о желании бизнеса, основываясь на том, что узкий специалист в незнакомых условиях будет действовать фактически вслепую. Что для компании выльется в риски потерять неограниченную сумму денег. А никакой бизнес, да и вообще никто в здравом уме, не хочет на пустом месте терять деньги. Возможно, я не прав, и представители бизнеса меня поправят).

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

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

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

Во избежании неоднозначности, уточню. Аджайл коучем курильщика я называют либо специалиста, который умеет работать только в рамках гибкой парадигмы, но лезет в другие области, и там бездумно пытается натягивать гибкие подходы на имеющуюся структуру, либо человека, который нахватался информации по верхам, и в принципе не способен нормально работать нигде. Аджайл коуч просто — это узкоспециализированный специалист. А аджайл коуч здорового человека — это специалист по управлению системами в широком смысле, который может работать в любом контексте, включая специфический “гибкий”. (Это субъективная классификация, отражающая лично моё отношение, если что)

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

Один из способов вывести содержание деятельности — из результата.

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

Давайте смоделируем действия аджайл коуча на примере некой абстрактной компании. Вот есть компания “А”, руководство которой, посовещавшись, пришло к выводу: “пора и нам внедрять Скрам”. С помощью кнопки “монтаж” пропустим все этапы согласования и перенесёмся сразу к этапу начала работы приглашенного специалиста.

С чего может начинаться работа высококвалифицированного специалиста по управлению системами, когда его приглашают провести в существующей системе определённые изменения? Как ни странно, с оценки — а действительно ли данной системе будет полезно получить новые свойства. Потому как изменения могут принести вред. А владельцу бизнеса не обязательно самому быть в состоянии провести подобную оценку. Ему подверженность веянию моды вполне можно простить. Он ведь нанимает специалиста, а не последователя культа. (По крайней мере надеется на это) Соответственно, неизбежный первый этап — это построение максимально полной модели существующей системы. Анализ её свойств и формирование прогноза последствий предполагаемых изменений.

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

Как только оба плана сформированы и согласованы, все подготовительные процедуры проведены, специалист приступает к их выполнению.

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

По достижении системой желательного состояния, специалист либо переходит к сопровождению, либо готовит того/тех, кто будет это делать после его ухода.

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

Аджайл коуч здорового человека должен:

• разбираться в моделировании, чтобы быть в состоянии построить удобную, понятную и наглядную модель (должен знать нотации, уметь пользоваться необходимыми инструментами),
• разбираться в устройстве сложных систем, владеть методами и инструментами анализа, чтобы быть в состоянии построить адекватную модель и с её помощью проанализировать и оценить свойства системы,
• знать специфику области, в которой работает компания, чтобы правильно учесть все нюансы, или же иметь доступ к профильным специалистам (как правило, сотрудникам компании), чтобы использовать их экспертизу, как ресурс,
• безукоризненно разбираться в “гибких” системах, чтобы понять, что можно взять и оценить, станет ли компания работать лучше в существующих условиях,
• разбираться в экономике, чтобы оценить последствия предполагаемых изменений в долгосрочной перспективе (в противном случае данные анализа будут вырваны из контекста, поскольку компания существует и продолжит существовать в контексте экономической ситуации),
• знать методы прогнозирования и уметь их применять, чтобы давать прогнозы с адекватным уровнем достоверности,
• иметь достаточные ресурсы для сбора и анализа необходимого объёма информации (иначе любой прогноз будет нерелевантным),
• уметь работать с изменениями в сложных системах, чтобы построить адекватный план внедрения изменений,
• уметь полноценно управлять проектами, чтобы адекватно подготовить и реализовать проект по реализации запланированных изменений (включая сбор и подготовку проектной команды),
• быть специалистом по обучению, адаптации и мотивации персонала, чтобы разработать процедуру адаптации ВСЕХ сотрудников компании в процессе изменения рабочей среды,
• быть квалифицированным фасилитатором, коучем, тренером и психологом, чтобы реализовать все необходимые мероприятия в рамках процесса адаптации,
• знать методы сбора и анализа статистических данных, уметь пользоваться необходимым математическим аппаратом для построения промежуточных моделей и оценки всё ли идёт, как запланировано, и внесения требуемых изменений.

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

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

Где же всему “этому” учиться?

Начнём с того, что я нигде не встречал восприятия аджайл коуча, как специалиста по управлению системами.

Зато я видел вот это.

Интересно, что тут не так?

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

По-моему, выглядит очень неплохо. Пойду запишусь в институт Герметичного Управления и по окончании буду сертифицированным практиком Герметичности.

Так называемый Гибкий Образ Мышления — искусственно созданная, абсолютно бесполезная конструкция. Как и Герметичный Образ Мышления. Есть ряд фундаментальных наук, изучая которые человек узнаёт, как устроен окружающий мир, что такое вакуум, что такое космический корабль и каким он должен быть, чтобы нормально работать в условиях вакуума. Такой человек называется инженером. И у него Science Mindset. Точно также есть список фундаментальных наук, изучая которые человек понимает, что такое компания, как система, по каким законам она работает, что такое условия высокой непоределённости и какой должна быть компания, чтобы нормально работать в условиях высокой неопределённости. И у него тоже должен быть Science Mindset. (Science. Bitch!)

Вот как могла бы выглядеть картинка, описывающая суть гибкой парадигмы:

Есть объективная реальность.

Есть науки, занимающиеся исследованием и описанием объективной реальности и структурированием полученных знаний.

В объективной реальности существуют различные системы.

На базе фундаментальных наук, сформирована наука(и), занимающаяся углублённым изучением систем.

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

Этот специалист будет способен смоделировать и создать систему, способную работать в частности в условиях высокой неопределённости.

Но реальная схема так не выглядит. И, на мой взгляд, это проблема.

Почему?

Ответ кроется на следующей же странице Agile Practice Guide, откуда была взята великолепная схема.

Гибкий Альянс даже при помощи Института Управления Проектами не смогли однозначно ответить на вопрос what the f is Agile?

Я предполагаю, что странная необходимость пропагандировать ценности аджайла, как одна из рабочих задач, присутствующая в 95% вакансий, как-то связана с неспособностью основателей “подхода” сформулировать внятное и однозначное определение их “подхода”. Т.е. они сами еще не до конца разобрались, что же у них получилось. (Вернее, им просто не хочется говорить всю правду, ведь это значительно снизит приток денег). Но с удовольствием обучат вас “подходу” за деньги.

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

Вот, например, визуализация карты развития полноценного “гибкого гуру” по версии ICAgile. Каждая медалька — это 2-3 дневный тренинг.

Чтобы понять, в чём некоторая неоднозначность такого подхода к образованию, нужно, опять же, переложить его на любую другую область человеческой деятельности. Насколько квалифицированного врача можно подготовить за 25-35 учебных дней? А инженера? А преподавателя? А программиста? А хоть кого-то можно?

Можно. Можно подготовить аджайл коуча курильщика. Который, попав в незнакомый контекст, немедленно приступит к противоестественной деформации сов. Потому как ничего другого не знает и не умеет.

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

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

Стремительно растущий ажиотаж вокруг слова “Аджайл” неизбежно приводит к росту числа желающих овладеть “тайными” знаниями. А как известно, спрос порождает предложение. Бесконтрольное предложение приводит к стремительному падению качества выпускаемой продукции (в данном случае учебных материалов). Инфополе наполняется мусором, как грибы множатся компании-обучалки, и процесс становится рекурсивным. Скоро (если не уже) ситуация станет, как с обучением программистов. Без понимания, как работает железо, без понимания устройства и логики работы операционных систем, без понимания алгоритмов, без умения работать с документацией, без понимания современных технологий, в рамках которых происходит взаимодействие продуктов, с одним лишь фрагментарным знанием синтаксиса одного языка, и опытом сборки одного корявого приложения по шаблону, я — Программист.

Глобальная проблема, идущая неизбежным следствием за поверхностным и фрагментарным обучением — мистификация подхода. Т.е. наделение его чуть ли не волшебными свойствами. Дальнейшая фрагментация знаний, догматизация и деградация до набора узкоспециализированных практик, идущих вперемешку с суевериями. То есть появление того самого культа, последователи которого верят, что в начале было слово, и это слово было “Аджайл”.

Всё, что работает хорошо и эффективно — это аджайл. Всё, что нет — не аджайл.

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

Что делать?

Для начала — не быть аджайл коучем курильщика. (Совушек нужно беречь. Они милые).

Еще можно делать качественные, структурированные знания общедоступными и бесплатными.

Можно присоединиться к Легиону и на серьёзных щах рассуждать что лучше — Канбан или Скрам.

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

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

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

Наука, изучающая системы и управление ими, называется кибернетика.

В работе под названием “Кибернетика. Навигатор. История кибернетики, современное состояние, перспективы развития” за авторством Новикова Дмитрия Александровича, я нашел следующую информацию.

Кибернетика 2.0 — это наука об (общих закономерностях) организации систем и управления ими.

На концептуальном уровне Кибернетику 2.0 составляют:

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

Базовыми науками для кибернетики 2.0 являются:

• теория управления,
• общая теория систем и системный анализ,
• системная инженерия.

Комплементарными науками для кибернетики 2.0 являются:

• информатика,
• оптимизация,
• исследование операций,
• искусственный интеллект.

Также в работе дан огромный (без преувеличения) список литературы.

Хм…

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

Благодарю за внимание. У меня пока всё.

P.s.

Я, разумеется, не претендую на объективность ни в коей мере. Всё вышеизложенное — мой субъективный анализ текущей ситуации. Если у вас возникнут замечания/предложения/мысли по существу, пишите, буду рад обсудить.

И да, Скрам методикой, а не фреймворком я называл осознанно.

Лучшие приемы и практики Agile для технических и нетехнических команд

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

Знаменитая методология была создана для разработки ПО. Поэтому практически все практики Agile применяются именно там. Однако это не мешает применять Agile и многим нетехническим командам.

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

С 2001 года Agile-принципы оформили в знаменитый манифест Agile, а сама методология стала стандартным процессом разработки ПО.

Каковы ключевые практики Agile сделали методологию столь известной и востребованной?

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

Список лучших практик Agile

Очередь задач

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

Обычно в бэклог продукта входят следующие элементы: продуктовые фичи, возможные баги, приоритетные знания по продукту, некоторые технические работы, и др.

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

В управлении бэклогом определяющую роль играет собрание backlog grooming, во время которого представители Agile команды обсуждают детали бэклога продукта и готовят очередное планирование спринта.

Итерации

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

Клиентоориентированность

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

User stories

В Agile описывается функциональность по общению с клиентами, а затем с позиции продукта определенным образом (помните формулу “Я как , хочу , потому что ”?). История пользователей в Agile project management означает единицу работы, которая должна быть завершена в одном спринте.

User stories включают описание, критерии приемки и оценку времени. Когда они слишком сложны, менеджеры продуктов разделяют их на более мелкие.

Agile-роли

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

• Team Lead, Project Lead и Скрам мастера
• Членов команды
• Собственника продукта для Scrum и On-site customer для XP
• Заинтересованные стороны (stakeholders)

Команды Agile могут также состоять из дополнительно привлекаемых технических специалистов.

Value stream analysis

Анализ потока ценностей — это метод управления для анализа текущего состояния и разработки будущего состояния продукта. Цель анализа в том, чтобы идентифицировать и удалять «отходы» в потоках создания ценности, тем самым повышая эффективность потока данных.

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

Timeboxing

Timeboxing используется в качестве метода планирования проекта. Расписание делится на несколько отдельных периодов времени (таймбоксы), каждый из которых имеет свои конечные результаты, срок и бюджет.

Спринты продолжаются в соответствии с указанными таймфреймами. Обычно от двух недель до одного месяца. Scrum-митинги обычно продолжаются около 15 минут.

Ежедневные собрания

Например, Scrum meeting — это ежедневное мероприятие, короткая утренняя или дневная встреча, обычно организованная менеджером продукта или владельцем продукта. Длится 10-15 минут и требует присутствия Скрам-мастера и всей команды. Такая встреча организуется, чтобы:

• вспомнить, что было сделано вчера
• определить, что будет сделано сегодня
• выявить любые препятствия, если такие есть

Sprint demo meeting

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

Retrospective meeting

Речь идет о ретроспективе по окончательному итеративному развитию. Retrospective meeting рекомендуется посещать всем членам команды. Клиенты также могут участвовать.
Здесь обсуждаются возможности улучшения процессов, качества работы, используемых инструментов и т. д.

Тестирование

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

Burndown chart

Этот график демонстрирует, действительно ли все идет в соответствии с календарем программирования и общим планом. Он отражает сроки и расписания. В диаграммах Burndown также отображается количество пользовательских историй за единицу времени.

Приоритизация требований

Приоритезация требований используется в Agile для определения того, какие конкретные требования к продукту должны быть включены в определенный релиз.

Менеджеры продуктов также приоритезирует требования для минимизации рисков во время разработки — сначала выполняются наиболее важные. В этом случае опытные менеджеры по продуктам и проектам используют хорошо известные методы и техники приоритизации.

Планирование релиза

Релиз продукта представляет собой набор новых функций или финальный запуск продукта. Грамотное планирование релиза помогает командам выпускать качественные продукты.

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

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

Этот список можно продолжать и дополнять другими интересными практиками. Однако какие же практики могут быть использованы нетехникеской командой?

Яркий пример — использование бэклога и приоритизация задач командой авиатранспортной компании Air Methods, которая специализируется на оказании скорой помощи.

В компании из более чем 6000 сотрудников активно работает команда по созданию и управлению стратегией обучения и развития. В самом начале деятельности эта команда столкнулась с тем, что заинтересованные стороны не понимали, сколько времени и сил понадобится для создания тренингов и обучающих проектов.

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

На доске собираются запросы заинтересованных сторон, команда присваивают каждому зеленый или красный лейбл. “Зеленые” проекты можно выполнять сейчас, “красные” попадают в очередь.

Ежемесячно команда и заинтересованные собираются для определения новых приоритетов, голосуют и дискуссируют.

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

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

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

Где Agile ужасен, особенно Scrum / Хабр

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

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

Программисты обычно не очень хорошо работают с клиентами. Мы слишком буквальные люди. Нам нравятся системы с чётко определённым поведением. Это усложняет нам взаимодействие с гуманитариями, потому что мы склонны воспринимать каждый запрос буквально, а не выяснять, что они хотят на самом деле. На корпоративном уровне гибкие методы (вне консалтинговой среды) идут дальше и предполагают, что инженеры недостаточно умны, чтобы понять, чего хотят их внутренние «клиенты». Это означает, что работа распыляется на «пользовательские истории» и «итерации», которые часто лишают нас удовлетворения от выполненной работы, а также любой надежды на долгосрочное видение, куда идут дела.

В целом обычно создаётся два типа работ, будь то внутри компании или для подрядчика. На высоком уровне нанимаются со стороны высококвалифицированные специалисты. На нижнем — сбрасывается на сторону вся работа, которую не хотят делать. Очевидно, что один класс консультантов получает уважение, а другой нет. Плохо управляемые консалтинговые фирмы в конечном итоге часто становятся «мусоропроводами» для низкоквалифицированной работы. Scrum будто создан для таких организаций, где отношения с клиентами настолько плохи, что за инженерами нужно наблюдать на ежедневной основе, потому что они стали отстойником для низкопробной работы, бесполезной для карьеры, которую никто не хочет делать (и вероятно, это не очень важная работа, отсюда низкие тарифы и уважение).

На рабочем месте в IT есть много трендов, которые делают карьеру программирования чрезвычайно непривлекательной, особенно для творческих, умных людей.

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

Хорошо известно, что творческие люди теряют креативность, если их просят объясниться во время работы. То же и с программным обеспечением. Программистам часто приходится работать в условиях односторонней прозрачности. Эти системы Agile часто неправильно применяются и требуют унизительной прозрачности работы, несмотря на отсутствие взаимности. Вместо того, чтобы работать над фактическими долгосрочными проектами, которыми человек мог бы увлечься, они низведены до работы над атомизированными, функциональными «пользовательскими историями» и часто запрещают работать над улучшениями, которые не связаны с краткосрочными, непосредственными потребностями бизнеса (часто спускаемыми сверху). Этот неправильный, но распространённый вариант Agile исключает понятие собственности и расценивает программистов как взаимозаменяемые, одинаковые компоненты.

Scrum — худший вариант, с глупостью двухнедельных «итераций». Это вызывает ненужное беспокойство о микрофлуктуациях производительности человека. Нет абсолютно никаких доказательств, что такой подход действительно ускоряет или улучшает разработку в долгосрочной перспективе. Он просто заставляет людей нервничать. Многие в бизнесе думают, что это хороший подход, потому что работа «идёт быстрее». Я в IT-индустрии уже десять лет, как менеджер и как рабочая пчела. Это неправда.

1. Бизнес-ориентированная разработка.

Agile часто подают в сравнении с «водопадом». Что такое водопад?

Подход Waterfall действительно ужасен. В нём «работа катится вниз», где каждый уровень организационной иерархии выбирает то, что он считает «интересным материалом», и передаёт дальше. Проекты определяются руководителями, архитектура проектируется архитекторами, личные сроки устанавливаются менеджерами среднего звена, реализация выполняется рабочими лошадками верхнего уровня (программистами), а затем операции и тестирование передаются лошадкам нижнего уровня. Это крайне нефункциональная схема. Когда люди чувствуют, что все важные решения уже приняты, у них нет мотивации работать как можно лучше.

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

У меня смешанные мнения о названиях должностей вроде «старший» и «директор», и тому подобное. Они имеют значение, и я сам, вероятно, не приму должность ниже уровня директора, но я ненавижу их значение. Если вы посмотрите на Scrum, он специально лишает прав старших, самых способных инженеров, потому что здесь они обязаны придерживаться установленных процессов (работа только над созданными задачами, 5-10 часов в неделю на планёрках). Эти процессы спроектированы для людей, которые начали программировать месяц назад.

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

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

Кремниевая долина сделала много ошибок, особенно в последние пять лет, но кое-что сделала правильно. В том числе ввела концепцию «инженерной» компании. Для инженеров не всегда лучше управлять всей компанией целиком, но когда инженеры управляют разработкой и устанавливают приоритеты, то выигрывают все: инженеры счастливы работой, которую им назначают (или, ещё лучше, сами себе назначают), а бизнес получает гораздо более высокое качество разработки.

Но у вас «бизнес-компания», это нормально. Тогда не нанимайте инженеров в штат, если вам нужен талант. Вы можете получить лучших людей в качестве консультантов (начиная с $200 в час и резко поднимаясь с этого уровня), но не в качестве штатных сотрудников «бизнес-компании». Хорошие инженеры хотят работать в фирмах, управляемых инженерами, где они будут участвовать в планировании работы без необходимости оправдываться перед «скрам-мастерами», «владельцами продукта» и несколькими уровнями менеджеров-гуманитариев.

В конечном счёте, Agile (как практикуется) и Waterfall — формы бизнес-ориентированной разработки, и поэтому ни одна из них не подходит для разработки качественного ПО или мотивации сотрудников.

2. Подчинённое положение молодых.

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

Проблема с двухнедельными итерациями Agile (или «спринтами») и пользовательскими историями заключается в том, что нет стратегии выхода. Там нет варианта «Нам не придётся больше это делать, когда мы достигнем [X]». Предполагается, что эта система навсегда: ориентированные на бизнес митинги никогда не исчезнут. Архитектура, НИОКР и развитие продуктов уходят из работы программиста, потому что не вписываются в атомизированные «истории пользователей» и двухнедельные спринты.

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

Однажды я работал в компании, где менеджер по продуктам сказал, что разница между старшим инженером и младшим инженером — в способности давать более точные оценки по срокам. Ну, вообще-то нет. И это даже оскорбительно. Я ненавижу оценки, потому что они генерируют политики и на самом деле не делают работу быстрее или лучше (на самом деле, обычно наоборот).

Самое худшее в оценках — что они стимулируют выполнение работы, которую можно оценить. Это заставляет программистов отдавать предпочтение простым вещам низкого уровня, которые на самом деле не нужны бизнесу (даже если неуклюжие менеджеры среднего звена думают иначе), но это «безопасно». Всё, что на самом деле стóит делать, имеет ненулевой шанс неудачи и слишком много неизвестных параметров для разумной оценки сроков. Концентрация Agile на краткосрочной ценности для бизнеса в конечном итоге отталкивает людей от работы, которая действительно нужна компании, ради управления репутацией каждого программиста в режиме реального времени.

Такая культура наталкивает на мысль, что программирование — это ребячество, от которого нужно избавиться к 35 годам. Я не согласен с таким мнением. На самом деле, я думаю, что это вредная мысль. Мне 30 с небольшим, и я чувствую, что только начинаю хорошо программировать. Преследование старших программистов только потому что они достаточно опытны, чтобы знать, что этот гибкий/scrum-процесс не имеет ничего общего с информатикой и что он не добавляет ценности — это ужасная идея.

3. Слишком краткосрочный подход, что глупо и опасно.

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

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

В рамках Agile технический долг накапливается и не решается, потому что бизнес-люди, назначающие задания, не увидят проблемы, пока не станет слишком поздно или, по крайней мере, слишком дорого её исправить. Более того, отдельные инженеры вознаграждаются или наказываются исключительно на основе текущих двухнедельных «спринтов», то есть никто не смотрит на пять «спринтов» вперёд. Agile — всего лишь один бессмысленный, близорукий «спринт» за другим: никакого прогресса, никаких улучшений, просто тикет за тикетом, за тикетом.

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

4. Он не имеет никакого отношения к построению карьеры.

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

В чрезвычайной ситуации, будь то консультация, стремящаяся успокоить важного клиента или корпоративная «военная комната», мысли о резюме могут подождать. Мало кто откажется от пары недель неприятной или иной работы, не имеющей отношения к развитию карьеры, если это действительно важно для компании. Важность работы здесь приоритет. Если вы можете сказать «Я сидел в штабе и по 20 минут в день общался с гендиректором», это оправдывает выполнение тупой работы.

Но если нет чрезвычайной ситуации, программисты ожидают, что их карьерный рост будет воспринят серьёзно. Иначе они уйдут. «Я был в команде Scrum» означает, что вы груша для битья. Одно дело сделать тупую работу, потому что гендиректор признал, что неприятная задача добавит миллионы долларов стоимости (и он вознаградит её соответствующим образом). Но если вам просто назначили «пользовательские истории» и тикеты Jira — значит, вас рассматривают как лузера.

5. Цель определить низкие показатели, но при этом неприемлемо высок уровень ложноположительных результатов.

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

В дебатах о гражданских свободах часто упоминается распространённая ошибка: аргумент «нечего скрывать». Некоторые любят утверждать, что вторжение в частную жизнь, скажем, правоохранительными органами, не является проблемой, потому что они сами не преступники. Эти люди упускают несколько ключевых вещей. Например, что законы меняются. Спросите любого, кто был евреем в Центральной Европе в 1930-х годах. Даже для респектабельных людей состояние слежки — это состояние тревоги.

Факт наблюдения меняет то, как люди работают. В творческих областях это вредит. Практически невозможно работать творчески, если нужно отчитываться о работе каждый день.

Здесь приходит на ум ещё одна тема: чувствительность к статусу. Программисты любят притворяться, что они преодолели несколько миллионов лет эволюции приматов, связанных с социальным статусом, но факт в том, что социальный статус имеет значение, и не стыдно признать этот факт. Пожилые люди, женщины, расовые меньшинства и люди с ограниченными возможностями, как правило, чувствительны к статусу на рабочем месте, потому что для них это вопрос выживания. Постоянное наблюдение за работой указывает на отсутствие доверия и низкий социальный статус, а самые чувствительные к статусу люди (даже если они лучшие работники) первыми страдают от усиления наблюдения. Если они чувствуют, что им не доверяют (и что ещё передаётся культурой, где каждый элемент работы должен быть одобрен?), то быстро теряют мотивацию.

Agile и особенно Scrum уязвимы для ошибки «нечего скрывать». Если ты не «плохой работник», ты ведь не против ежедневных планёрок, верно? Единственные люди, кто будет возражать против ежедневных отчётов о своей работе с точки зрения краткосрочной стоимости бизнеса — это «бездельники», которые хотят украсть деньги у компании, верно? Ну, нет. Очевидно, нет.

Культура насильственной прозрачности предназначена для самых нечувствительных к статусу людей: молодых, обычно белых или азиатов, привилегированных мужчин, которых ещё никогда не прессовали на работе. Для тех, кто думает, что HR и управление — пустая трата времени, а работник должен просто проглатывать унижения и оскорбления.

Часто от внедрения Agile/Scrum страдают лучшие сотрудники, потому что R&D эффективно устраняется. Одержимость краткосрочными «итерациями» или спринтами означает невозможность опробовать нечто новое, рискованное.

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

6. Пьяный эффект.

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

С точки зрения менеджера, который не знает, как работает программное обеспечение, это может показаться приемлемым компромиссом: несколько «примадонн» уровня 7+ покинут корабль под парусом Дивного Нового Scrum, зато 3-ки и 4-ки станут вполне приемлемыми 5-ками. Проблема в том, что разница между программистами 7 и 5 существенно больше, чем между 5 и 3. Если вы потеряете своих лучших людей и своих лидеров (которые необязательно находятся на руководящих ролях), то небольшое повышение уровня некомпетентных, для которых предназначен Scrum, не приносит пользы.

Scrum и Agile играют в то, что я называю предвзятостью к смене статуса. По сути, многие люди судят о своих успехах или неудачах не объективно, а исходя из субъективных изменений в статусе. Убедить программиста уровня 5 согласиться на зарплату программиста уровня 3 в стартапе (в обмен на долю в стартапе) психологически расценивается не как потеря денег, а как серьёзная прибавка в статусе.

Agile/Scrum и культура дискриминации по возрасту в целом касаются получения наиболее впечатляющей статусной прибыли, а не фактической экономической прибыли. Её можно достичь, как правило, путём найма людей, которые принесут наибольшую ценность (даже если вы предлагаете на 50% выше рыночной ставки, потому что лучшие программисты стоят в 10-30 раз больше их рыночной ставки).

Люди, которые меньше всего осведомлены о том, какой социальный статус они «должны» иметь — это молодёжь. Вы найдете 22-летнего программиста уровня 6, который думает, что у него уровень 3 и который согласится на Scrum, но 50-летний уровень 9, вероятно, знает, что у него 9 и может неохотно принять условия уровня 8,5, но точно не опустится до 3 или даже 6. Поиск статусной прибыли, конечно, бесполезен. Эти пункты ничего не значат. Вы выигрываете в бизнесе на разнице в доходах и расходах, а не на разнице в бессмысленных пунктах статуса. Может быть, существует целая индустрия в привлечении инженеров 5-го уровня, расценивая (и оплачивая) их как 4, но в нынешних рыночных условиях гораздо выгоднее нанять 8 и относиться к нему как к 8.

7. Нечестная реклама.

Здесь я сосредоточусь на Scrum. Некоторые утверждают, что Scrum является «экстремистским вариантом Agile», а другие — что это самый далёкий вариант от истинного Agile. (Возможно, здесь проявляется одна из проблем: мы не можем договориться о том, что является и не является Agile).

Решениям вроде Scrum есть своё место: очень ограниченное, временное. Нечестно говорить, что оно работает везде и на постоянной основе.

До того, как причуда Agile сделала его постоянным процессом, Scrum означало нечто вроде «красного кода» или «чрезвычайной ситуации». Если бы возникла неожиданная, быстро развивающаяся проблема, вы бы собрали своих лучших людей и сформировали экстренную команду.

У этой команды не будет чёткого менеджера, поэтому вы выберете лидера (например, “Scrum Master”) и дадите ему полномочия. Вы не хотите, чтобы он был официальным «менеджером людей» (так как он должен быть максимально беспристрастным). Поскольку кризис носит краткосрочный характер, карьерные цели отдельных лиц могут быть приостановлены. Это считается «спринтом», потому что люди должны работать так быстро, как могут, чтобы решить проблему, и потому, что им будет разрешено вернуться к своей обычной работе, как только спринт закончится. Кроме того, в такой чрезвычайной ситуации вам нужно дать понять, что никто не оценивается индивидуально. Основное внимание уделяется миссии и только миссии.

Когда вы навязываете процесс и требуете односторонней прозрачности всех работников, люди чувствуют, что за ними наблюдают. Они понимают, что их пометят как «слабых исполнителей», если неделя за неделей отдельные показатели пойдут не так. Такое обижает людей. Это дисфункционально. С другой стороны, если вы собираете группу проверенных специалистов, чтобы справиться с конкретным и ограниченным по времени кризисом, они не возражают против частых отчётов, если понимают, что это острота ситуации, а не их собственный низкий социальный статус, стал причиной этого.

Существует два сценария, которые должны прийти на ум. Первый — это корпоративная «военная комната». Но если конкретные лица (за исключением руководителей высшего звена) проводят в таком режиме более 4 недель в год, то с компанией что-то не так, потому что чрезвычайные ситуации должны быть редкими. Во-вторых, консультанты, которые пытаются зарекомендовать себя или плохо справляются с обслуживанием клиентов и установлением независимой репутации, и поэтому должны работать в условиях постоянного чрезвычайного положения.

Таким образом, Scrum признаёт идею, что иногда власть нужно делегировать «экстренным» руководителям: они будут делать всё, что считают необходимым, чтобы выполнить работу, оставив споры на потом. Всё нормально. Иногда всё должно быть именно так.

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

Честолюбивому демагогу (скрам-мастер?) легче проявить себя в схватке с драконами, чем избежать их появления. Проблема с агрессивным настаиванием Scrum на бизнес-ориентированной инженерии заключается в том, что она делает ценностями («сотрудничество с клиентами») привлечение и убийство драконов (известных как «требования»), когда может быть более разумным не выманивать тех из своих пещер.

Agile и Scrum прославляют чрезвычайные ситуации. Это их главная проблема. Некая версия того, что индустрия видеоигр называет «шоу-тайм». Это не позволяет устойчиво работать. Агрессивный акцент на индивидуальной производительности, отсутствие заботы о карьерных целях людей при распределении работы и мандат, в соответствии с которым люди работают только на заявленный высший приоритет — всё это даёт большую пользу в краткосрочной чрезвычайной ситуации, но становится токсичным и деморализующим в долгосрочной перспективе. Люди стерпят краткосрочную потерю автономии, но только если впереди будет чёткая точка, когда они её вернут.

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

Если избавиться от проблем Agile и Scrum, то у меня не будет такой сильной проблемы с концепциями. Если у компании есть команда только младших разработчиков и ей нужно быстро выпускать функции, она должна рассмотреть возможность использования этих методов в течение короткого времени, с планом отхода от них по мере того, как люди растут, а временные рамки становятся менее жёсткими. Но если подавать Scrum за то, что он есть — набор чрезвычайных мер, которые нельзя использовать для постоянного повышения производительности, — то будет гораздо меньше «покупателей» для него, и консалтинговая индустрия Agile перестанет существовать. Только через нечестную рекламу этих методов (прославленное «шоу-тайм», упакованное как постоянные исправления) они становятся доступными для продажи корпоративному миру в больших масштабах.

Этой культуре подчинённого положения молодых, низкой автономности и агрессивного управления пришло время уйти. Это не просто плохие идеи. Здесь более серьёзная опасность, потому что выросло поколение инженеров-программистов, которые поглощают их, не зная ничего лучшего. Есть слишком много молодых программистов, обречённых на посредственность из-за уверенности в том, что бизнес-ориентированная разработка и «пользовательские истории» — так всегда всё работало. Такое следует предотвратить: от этого зависит будущее нашей индустрии. Agile, по крайней мере, а такой извращённой реализации, как всё, что я видел, — полная ерунда, которая не имеет никакого отношения к программированию и, конечно же, не имеет никакого отношения к информатике. Бизнес-ориентированная разработка в целом — тупик. Её следует бросить обратно в грязь, из которой она вышла.

Agile умер, да здравствует… Agile / Хабр

За последние несколько лет гибкие методологии почти вытеснили традиционные способы разработки – полностью по принципам Agile сейчас работают две трети IT-компаний. Оправдались ли ожидания, какие возникают проблемы и куда всё движется? Предлагаем анализ существующего российского и зарубежного опыта работы по Agile и ответы на эти вопросы.

Несмотря на то, что Agile появился около 20 лет назад, более-менее активно применять его начали только в течение последних восьми лет. Гибкие принципы возникли как альтернатива традиционным методам разработки с целью уменьшения затрат на производство ПО, готового для отправки заказчику (potentially shippable software), за счёт повышения эффективности совместной работы и клиентоориентированности. То есть набор принципов формировался под решение задач бизнеса – для ускорения процесса разработки и достижения максимального результата от команды без увеличения затрат на производство.
Да, гибкая методология позволяет выжать из команды максимальный КПД, но есть два нюанса, которые при сложившихся обстоятельствах снижают Agile-эффект. Во-первых, принципы действительно работают только в небольших командах. Кроме того, если в команде все специалисты очень сильные, то совершенно не факт, что получится существенно увеличить их производительность.

Как это работает?

Сегодняшний процесс разработки можно разделить на три этапа: написание кода, подготовка его к запуску и продакшен.

Традиционно целью Agile был первый этап разработки – написание кода. В конце далёких 90-х именно этот этап рассматривался как требующий улучшения и серьёзных изменений. Тогда же получила известность одна из наиболее распространённых имплементаций Agile — Scrum. Справедливости ради стоит отметить, что Scrum вышел в свет в 1986 году, за 15 лет до того, как был адаптирован для Agile в 2001 году.

Scrum приносит выборку того, что нужно писать, позволяет отследить процесс разработки, выявить недостачи и противоречия на начальных этапах. Без технического задания программист не знает, какой именно продукт должен получиться в результате. Например, если речь идет о Google или Facebook, то у разработчиков того или иного сервиса вопросов не возникает. Они делают продукт для себя — сами являются его заядлыми пользователями и понимают, что и как должно выглядеть и что нужно сделать, чтобы новый функционал был удобным. Другое дело, например, система биллингa. Программист не знает того огромного количества нюансов, которые необходимо учесть для корректной работы сервиса как регуляционных, так и маркетинговых, как, например, различные модели расчётных операций.

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

С целью подготовки написанного кода для потенциального выпуска появился Continuous Delivery. Стоит обратить внимание, что выпуск не обязательно происходит сразу, а может быть задержан, например, для привязки к определённой дате в соответствии с бизнес-задачами. Такой подход позволяет добиться слаженной работы команды, автоматизировать все процессы и повысить скорость потенциальной отправки кода в продакшен. Однако качество продукта гарантируется только за счет автоматических тестов, так как приемочные проверки не справляются со скоростью поставки кода и зачастую используются как формальный этап. Конечно, сегодня такие автоматические тесты отдельных компонент, написанные зачастую самими разработчиками, обеспечивают правильное исполнение кода. Но ни сама методология, ни какие-либо существующие сегодня инструменты не обеспечивают корректную работу кода в более сложной среде – продакшене. Кроме того, не факт, что код будет выполнять необходимые заказчику функции и решать поставленные задачи.

Например, в июле 2015 после очередного обновления ПО были остановлены торги на Нью-Йоркской фондовой бирже. Этот сбой сотряс мировую экономику, в частности, снизил на 1% фондовый индекс США на весь день, а также затормозил переговоры Греции с ее кредиторами на целую неделю! Ещё один яркий пример – обновление системы продажи авиабилетов в компании «Дельта». После выпуска нового ПО в продакшен информация вообще перестала поступать в диспетчерскую службу. В результате авиакомпания отменила все рейсы и понесла существенные финансовые и репутационные потери. Несомненно, в обоих случаях многие проверки перед запуском были пройдены и, тем не менее, ещё многие были бы сделаны, если бы занимали меньше ресурсов и времени.

Пробел с обеспечением качества кода сегодня очень актуален и он будет постепенно заполняться. По оценкам Gartner, в ближайшие три года по крайней мере 75% IT–корпораций будут вынуждены развить автоматическое тестирование, интегрирующее бизнес-процессы. Определенные надежды на решение проблемы качества возлагаются на такие технологии и методологии, как контейнеры и BDD (behavior driven development) – Docker, Cucumber и прочие.

У кого это работает?

На сегодняшний момент принципы Agile имплементированы в большинстве компаний, где это было возможно сделать без особых рисков для бизнеса. И все, кто смог выстроить новые процессы, в целом довольны результатами, например: Google, Zara, Ikea. Однако стоит обратить внимание, что эти компании действуют по принципу «разделяй и властвуй» — то есть работа разделена на проекты, которыми занимаются относительно небольшие самостоятельные команды. Кроме того, по Agile в этих компаниях работает в первую очередь бизнес-подразделение (особенно это касается Zara и Ikea), а не только отдел разработки. Они изменили не только организацию процесса, но и бизнес, поэтому естественным образом соответствуют Agile-модели.

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

То есть в тех областях, где цена ошибки очень высока, компании пока опасаются что-то менять. Да, они понимают, что Waterfall себя изжил и, работая по-старому, можно в какой-то момент остаться далеко позади от конкурентов и всё потерять. Они бы и рады перейти на новые методы работы, но пока риски гораздо выше, чем потенциальная выгода от нововведений. Кроме того, зачастую необходимы большие вложения, чтобы перевести бизнес на гибкие методологии и далеко не факт, что всё сразу заработает хорошо. Это касается в первую очередь тех компаний, где большинство бизнес-процессов построено на ПО, написанном десятки лет назад на языках программирования, не столь модулярных, как Java, Scala, GO и пр.

Но те компании, которые пытались внедрить Agile и не получили ожидаемых результатов, всё больше и больше проявляют недовольство. Им обещали, что после имплементации гибкой методологии КПД увеличится, а time-to-market и вместе с ним затраты на производство сократятся. Однако ожидаемого эффекта не возникает, так как код выходит быстрее и всё больше и больше проблем появляется на продвинутых этапах разработки. КПД в некоторых случаях повышается, однако заметного сокращения затрат не происходит. Но чаще всего случаются откаты из продакшена, которые бьют по времени достижения целей, бьют по time-to-market и стоят очень дорого, так как исправление багов в продакшене требует гораздо больших затрат ресурсов разработчиков. Цена ошибки возрастает не только из-за позднего обнаружения, но и из-за высокой скорости разработки. Этот эффект можно сравнить с турбулентностью в потоках, когда скорость потока превышает максимально допустимую для данной среды.

Всё это привело к тому, что в последнее время появился большой спрос на инструменты, позволяющие решить эти проблемы и всё-таки добиться Agile-эффекта.

Как повысить эффективность?

Облака очень активно развивались в последнее десятилетие и частично открыли шлюзы для проведения тестирования в больших масштабах. Однако проблема полностью не была решена – несмотря на все преимущества, облачные технологии относительно дороги. Кроме того, не всегда просто построить необходимые среды проверок в cloud. Сегодня, в среднем, каждому разработчику необходимо 10 сред — таким образом цена среды может сравниться с бюджетом оплаты труда самого разработчика.

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

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

На чем стоит и куда движется Agile

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

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

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

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

1. Появление возможности для запуска бизнес-тестов без особых затрат,

2. сдвиг интегрального и бизнес-тестирования как можно ближе к источнику изменений.

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

Когда наступит «золотой век» Agile?

С начала своего существования Agile перевоплотился из набора принципов в ассортимент методологий, процессов и даже стандартов. Сегодня поле деятельности этих методологий не ограничено командами разработчиков. Гибкие процессы успешно внедряются практически во все отделы IT и даже бизнес руководствуется стандартами Agile. Среди наиболее известных можно отметить Scrum, Scrumban, SAFe, ScaleAgile@Spotify, Continuous Delivery, Lean, Prince2 Agile и многие другие.

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

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

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

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

как устроена работа в IT-компаниях — Технологии на TJ

Если вы недавно в IT-сфере и как раз ищете свою первую работу в большой компании, скорее всего, Agile — а тем более Scrum, Kanban и Scrumban — вам незнакомы. Этот материал для вас, если вам интересно, зачем компании переходят на гибкие методологии, чем они отличаются и как будет выглядеть ваша работа по ним.

Что такое гибкие методологии и Agile.

Методология — это правила, по которым люди договариваются работать. Agile — семейство принципов, на которых строятся гибкие методологии. То есть работать можно по-разному, но в основе будут одни и те же ценности.

Гибкие методологии отличаются по своим целям, сферам применения и правилам — но все они строятся на одних идеалах Agile. Благодаря им они и называются гибкими. Вот основные:

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

Джим Хайсмит, один из самых известных адвокатов Agile, описал его так: «Мы принимаем моделирование, но не чтобы положить какую-то диаграмму в пыльный корпоративный репозиторий. Мы принимаем документацию, но не сотни страниц правил, которые никогда не обновляют и редко используют. Мы планируем, но принимаем, что наши возможности ограничены турбулентным окружающим миром».

Для IT-компании главное отличие работы по Agile от работы без него — это сроки планирования. Представим ситуацию: нам нужно запустить сервис по вызову такси, интегрированный с доставкой еды и лекарств. Без Agile мы распишем подробное ТЗ и запустим сервис только через год, когда будут готовы все функции. По Agile — мы уже через два месяца выпустим первую версию, в которой будет только такси. Потом обговорим с заказчиком, что запускаем дальше — это может оказаться что-то неожиданное, например, доставка зоотоваров. Если бы мы работали по ТЗ на год, то не смогли бы гибко изменить функционал продукта и «попасть» в рынок.

Дорогой Agile, мне надоело притворяться / Хабр

«Agile мёртв». Люди всё время так говорят. Но обязательно добавляют: «Мы просто шутим». Они типа имели в виду, что это у тебя такие неправильные и глупые практики, что это для тебя Agile мёртв. Но «настоящий» Agile не мёртв. Просто все его делают неправильно. Так что я понял: настоящий Agile — это, знаете ли, Agile в теории. Даже я его внедрял. И знаете что? Мне надоело.

Недавно я видел в статьях ту же самую старую защиту: «Но-но-но, проблема в водопаде, скраме и неправильной реализации Agile, несоблюдении Манифеста… бла-бла-бла». Тогда Боб Маршалл сказал мне правду. Он сказал: «Заткнись, Чарльз. Манифест Agile — это кувшин, который мы наполняем». Он сделал несколько замечаний, с которыми мне пришлось согласиться. Я задумался. Результатом стала эта статья.

Вот вам тест. Как начинается первая строка манифеста Agile? Не подглядывать. Не знаете? Всё в порядке. Это не имеет значения. Там говорится: «Мы открываем более совершенные методы разработки программного обеспечения…» Стоп. Заметьте, написано: «разработка программного обеспечения». Там не говорится: «вытягивание вашей организации», «погашение долга за трансформацию», «выкраивание его с помощью этого командно-контрольного дерьма», «сосредоточение на результатах и улучшение работы по открытию», «исправление вашей средневековой системы бюджетирования» или любой ещё более продвинутой добавленной ценности, которую люди пытались в него вложить. Но дело в том, что когда люди говорят, что Agile относится ко всей организации, это ревизионизм. Это нечестно.

Заметьте также, что он начинается «Мы открываем…» Он не говорит: «Мы получили свыше…» Вам не кажется, что с 2001 года мы кое-чему научились? Я имею в виду, да, большинство крупных организаций всё ещё застряли в 1987 году, но ладно вам. Вопреки распространённому мнению, фотография ниже на самом деле не из акта подписания Манифеста. Можем мы наконец перестать притворяться?

Манифест служил определённой цели, но он не приведёт вас туда, куда вам нужно. Так что приступайте к учёбе. У наших знаний есть срок годности, и не такой большой, как мы думаем. У всех есть коллеги (обычно начальники), которые утверждают, что у них «нет времени учиться». Вы сами знаете, что они слишком самоуверенны в своих знаниях. Так что найдите хороший список книг. Следите за хорошими блогами. Вот для начала: если вы не читали Sense & Respond, Lean Enterprise, A Seat at the Table и Everyone Is a Change Agent, предлагаю сделать это немедленно. И вашим начальникам.

Начните читать посты Джона Катлера, Мелиссы Перри, Боба Маршалла, Аллена Холуба, Лоры Кляйн, Эрики Холл, Нила Киллика и тех, на кого они ссылаются. Они все согласны друг с другом (или со мной)? Нет, но они умны и вас тоже сделают умнее. Приступайте к чтению и поощряйте других. Fast Company говорит, что средний генеральный директор читает 60 книг в год. Сколько книг читают ваши руководители? И что они читают? (Статьи HBR, репортажи Gartner и романы Мейв Бинчи не в счёт). Потому что давайте посмотрим правде в глаза: если ваши руководители мастера Scrum, то вы прочно застряли в 80-х и 90-х годах.

Давайте перейдём к непрерывному обучению и перестанем притворяться, что Agile — какое-то лекарство. Это нужно сказать: Agile есть и всегда был локальной оптимизацией для небольшого повышения эффективности системы. Только Agile несправедливо вынес под микроскоп команды разработчиков программного обеспечения. Это никак не повышает организационную гибкость. НИКАК. Интересно, что, по словам Кена Швабера (см. его «Небезопасно на любой скорости»), Agile был попыткой «компенсировать ущерб, нанесённый водопадом», и всё же никогда не давал организациям целостную, жизнеспособную альтернативу водопаду. Потому что есть разница между теорией и практикой. Работа над продуктом — это скорее практика. Когда мы жалуемся на AINO (Agile In Name Only), мы не честны с самими собой.

Теория против практики, помните? Мы должны быть прагматичными. Agile на практике почти всегда AINO. Похоже, проблема с самим движением, не так ли? В любом случае, есть более важные вещи, о которых нужно узнать, включая (но не ограничиваясь) Lean UX, Lean Enterprise, Beyond Budget, Theory of Constraints, Throughput Accounting, Design Thinking, DevOps, организационная терапия Маршалла и т. д.

Вы спросите, почему Lean UX возглавляет список? Из-за того, что по своей сути Lean UX популяризует концепцию ориентированности на результат. Подумайте: если вы не знаете, какое изменение поведения пытаетесь создать, то не будете понимать свои действия. Если у вас нет однозначной сигнализации «поворота» (pivoting), то вы уже не можете быть гибким. Вот что такое Agile, в конце концов, это pivoting. Некоторые могут возразить: «Но-но-но, проверять и адаптироваться!» Конечно. Теория против практики, помните? Я не вижу гибких команд, которые проверяют и адаптируются. Я вижу, как команды Agile пытаются наверстать отставание, возятся с Jira и Rally и работают так, будто строят кирпичную стену по приказу.

Agile на самом деле имеет тенденцию маскировать основную проблему — это системное, двунаправленное отсутствие вертикального доверия. Коачи Agile уходят, ухудшив ситуацию: они оставляют после себя менеджеров, говорящих на поросячьей латыни, и команды разработчиков, которые перешли на эсперанто. Команды считают, что управление сломано, а руководство считает, что основное внимание по-прежнему надо уделять объёму, срокам и эффективности, игнорируя, что сроки являются произвольными, а оценки времени являются формой отходов. (Знаете ли вы, что стори-поинты на самом деле изобрели, чтобы скрыть время и помочь решить саму проблему? Здесь тоже появились неприятные последствия, не так ли? Теория и практика).

Угадайте, кто победит? Два лагеря с двумя радикально разными перспективами, где один лагерь получает оценки от другого? Если команды похожи на слепых, которые чувствуют слона и не согласны с тем, что это такое, то руководство похоже на слепых слонов, наступающих на людей и соглашающихся, что они все плоские. Выход в том, чтобы признать, что система — это команда. Кончайте уже с локальными оптимизациями и осознайте, что доверие — это проблема №1. Перестаньте несправедливо помещать разработчиков под микроскоп, позволяя остальным прятаться в чёрном ящике. (Почему нас не интересует, как работают команды стратегического развития? Или как архитекторы легаси являются ограничениями в системе?)

И пока мы этим занимаемся, следует перестать относиться к командам разработчиков так, будто они работают на заводе. Мы не штампуем пластиковую посуду. Мы создаём программное обеспечение. Нужно перестать вести себя так, будто мы заправляем пиццерией. Здесь другие правила. Мы не используем один и тот же проверенный рецепт. Мы разрабатываем рецепты. Если вы ещё не поняли, это работа по открытию, а не просто доставка. Пренебрежение открытием приводит к массовым потерям: неиспользуемые функции и другая работа, которая не достигает результатов. Это обнажает ещё один глубокий недостаток Agile. Он предполагает, что пользователей можно воспринимать как морских свинок: «Эй, просто используйте этот дерьмовый продукт, тогда мы улучшим его». За исключением того, что дерьмовый продукт обычно таким и остаётся, не так ли? Будущие улучшения становятся ненужными «затратами».

Но-но-но, Agile действительно нацелен на исследования! Правда? Будем честными. Теория против практики, помните? Если вы зарабатываете на жизнь проектированием или исследованиями, то ответьте на этот вопрос. Как вы обычно относитесь к работе с гибкими командами? Вас изначально рассматривают как ценность и просят помочь «проверить и адаптировать»? Или вас просят «доказать свою ценность»? Как сказал Алан Купер, когда вас просят «доказать свою ценность», вам ясно дают понять, что вы находитесь в системе, которая вас не ценит. Обратите внимание, что они просят отдельного участника доказать свою ценность — они не спрашивают, какая часть их кода на самом деле смещает показатели в правильном направлении. Другими словами, они по-прежнему фокусируются на людях, а не на самой работе. Вероятно, они всё ещё сосредоточены на костах, а не на ценности, игнорируя те области, где значительная часть ценности фактически утекает.

Если вы работаете с гибкими командами, в следующий раз, когда вас попросят «показать свою ценность», попробуйте это. Начните задавать им вопросы. Знают ли они, какова цена задержки? Какие упражнения они используют для оценки этого параметра? Каких конкретных результатов они пытаются достичь? Какая доля их продукта фактически достигает своих показателей? Они не знают? Если есть более быстрые и дешёвые способы узнать, что разрабатывать, кроме как просто выпускать код, заинтересованы ли они в обучении? Какова их эффективность потока? Насколько всё плохо? Сколько времени они проводят на собраниях? Если есть дизайнерские игры и упрощённые действия, которые приведут к лучшим решениям за гораздо меньшее время, они заинтересованы в обучении? Потому что я не просто покажу вам свою ценность — я научу вас создавать больше ценности во всём, что вы делаете.

Это другой способ мышления. Это мета. Это стратегически. Как отмечает Остин Говелла, и Agile, и водопад сосредоточены на разработке. Дизайн — это проверка. Если они не заинтересованы, можно уходить. Если они просто опустив головы выпускают продукт, фокусируясь на издержках, то никогда даже не узнают достаточно, чтобы понять, что вы, как правило, получаете больше того, на чём фокусируетесь (гм, косты). Это фабрика по производству функций. Круговая порука. Они притворяются, что создают пластиковую посуду. У вас есть дела поважнее. Потому что реальная ценность обеспечивается опциями, которые генерируются путём исследования. Чем больше опций вы создаёте и чем более гибок ваш подход, тем больше возможных путей и лучше результат. Чего они пытаются достичь? Исследовали ли они три-пять способов достижения этой цели? Это приведёт к лучшему принятию решений на перспективу. Одна опция — это не выбор. Два — это дилемма. Три — теперь вы кое-чего добились.

Когда-нибудь слышали о Законе необходимого разнообразия? Компонент с наибольшим количеством опций управляет системой. Примените это к тупой борьбе за власть «Agile против водопада». У вас были руководители, которые пытались сохранить контроль над системой сверху, и гибкие команды, которые пытаются приблизить ценность к источнику (реальные пользователи и клиенты). Выход из бессмысленной гражданской войны — научить людей генерировать варианты на всех уровнях. Путь вперёд — не «Agile против водопада». Это умная стратегическая работа сверху вниз (водопад) с эмпирически-ориентированными тактиками снизу вверх. Дизайн и открытие помогают в обоих случаях.

Так… каков выход? Это разумный фокус на чётких результатах, а не на выдаче, с запланированными результатами вместо запланированных отметок, не с проектными, а с надёжными продуктовыми командами, уполномоченными проверять предположения и находить кратчайший путь к ценности.

Теперь к обучению (адаптировано на базе диаграммы Джона Катлера).

Так… значит, Agile уходит? Конечно, нет. Это просто глупое сообщение в блоге. У меня нет никакой власти. И если бы даже была, Agile всё равно не исчез бы. Движение Agile сделало возможным появление многих из упомянутых концепций. Кроме того, вопреки распространённому мнению, гибкие практики не были изобретены движением Agile. Они появились на десятилетия раньше.

Так что нет, я не хочу, чтобы Agile уходил.

Я просто хочу, чтобы мы стали честнее.

Ага ага, какая разница-то? / Хабр

Является ли Agile аналогичным Lean? Когда люди говорят “Agile”, подразумевают ли они на самом деле Scrum? Или люди все еще используют разные типы Agile и почему?

Получая много вопросов в прошлом, я решил расставить все точки над “и”.

Lean пришел из бережливого производства (Lean Manufacturing), он имеет набор принципов, относящихся к качеству, скорости и клиентоориентированности (то же, что мы пытаемся сделать в agile разработке, правильно?)

Мэри и Том Поппендик адаптировали принципы “Бережливого Производства” для разработки программного обеспечения, и я верю, что эти идеи являются основами и причинами того, как agile работает:

1. Устранение потерь.

2. Повышение качества.

3. Создание знаний.

4. Отсроченные обязательства.

5. Быстрая поставка.

6. Уважение людей.

7. Полная оптимизация.

В двух словах, Lean говорит: безжалостно избавляйтесь от всего, что не добавляет дополнительной ценности, и делайте только то, в чем вы абсолютно уверены, что это нужно делать в настоящий момент. Устранять потери означает устранять бесполезные собрания, задачи и документацию. Но это также означает избавляться от временных потерь в любых известных задачах, которые нужно будет сделать в будущем (все постоянно меняется и часто в итоге становится ненужным. Если бы мы сделали что-то наперед, то мы должны были бы потратить время на переделку этого, потому что условия или наше понимание уже изменилось в последствии). Это также означает, что мы должны избавляться от не эффективных способов работы, таких как многозадачность, чтобы мы могли делать поставки быстро.

Lean также делает очень сильный акцент на то, что называется “системой”, т.е. что команда работает как единое целое. Мы всегда должны смотреть на нашу работу “с высоты”, чтобы быть уверенным, что мы улучшаемся в целом. Например, много менеджеров хотят “занять” работой каждого разработчика на 100%, но в большинстве случаев это, на самом деле, контрпродуктивно. Давайте не будем заставлять людей кодировать то, что не нужно (или полностью не определено), только ради того, чтобы они кодировали, потому что в будущем для нас это создает еще больше работы.

Подводя черту, Lean говорит: уважайте людей. Это означает давать людям ту работу, которую они лучше всего знают как надо делать. Дайте им то, что им необходимо, чтобы быть эффективными и затем доверьте им сделать это. Суть программной разработки в постоянном обучении; поэтому строить работу нужно так, чтобы убеждаться, что мы постоянно учимся. И поэтому нужно откладывать принятие решения до последнего момента (ведь мы будем на тот момент знать больше). В итоге разработка идет путем создания качественного продукта, потому что нет другого способа, обеспечивающего постоянную быструю поставку, если нужно возвращаться и убирать наш беспорядок.

“Организации, которые по-настоящему следуют Lean, имеют сильное конкурентное преимущество, потому что они очень быстро и в высшей степени дисциплинированно реагируют на рыночный спрос, а не пытаются предсказывать будущее”, – Мэри Поппендик.

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

Ценности Agile – это:

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

Принципы Agile – это:

1. Наивысший приоритет — удовлетворение пользователей.

2. Изменение требований приветствуется.

3. Работающий продукт следует выпускать как можно чаще.

4. Представители бизнеса и разработки должны работать вместе ежедневно.

5. Над проектом должны работать мотивированные профессионалы.

6. Непосредственное общение является наиболее практичным и эффективным.

7. Работающий продукт — основной показатель прогресса.

8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.

9. Постоянное внимание техническому совершенствованию и качеству проектирования повышает гибкость проекта.

10. Простота — искусство минимизации лишней работы — крайне необходима.

11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

12. Команда должна систематически анализировать возможные способы повышение эффективности и соответственно корректировать стиль своей работы.

Любой проект, который следует этим ценностям и принципам, по праву может считаться agile. Тем не менее, безусловно есть наиболее общие практики для agile команд, следуя которым достигается гибкость (agility).

Наиболее общие это: Scrum или Kanban (или гибрид из обоих) для “Управленческих практик”. Экстремальное программирование (XP) для Технических практик (с новыми практиками становится популярным, во многом из-за Lean Statup, такие как непрерывное развертывание и тестирование на проде).

Хорошие agile команды выбирают часть из управленческих и технических практик, те, что лучше для них. (Плохой пример, когда берут только пару практик, ложно веря, что это “их делает agile”)

Благодарности: Спасибо Юрию Прокудину, Екатерине Кивелевой за помощь в подготовке текста.

Что такое Agile? | Задержка

Руководство по Agile

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

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

Разработчиков хватило. Независимо друг от друга руководители программирования
начали создавать свои «легкие» процессы, поскольку
альтернативы «тяжеловесным» процессам на многих
компании. Эти новые процессы проявлялись во многих формах — Экстремальные
Программирование, Скрам,
и многое другое — но
их приверженцы чувствовали, что разделяют схожие философии.В феврале 2001 г.
группа из семнадцати программистов собралась в лыжном домике в Юте, чтобы попытаться найти
точки соприкосновения.

Компания Agile родилась в заснеженных горах Уосатч.

Что такое гибкая разработка программного обеспечения?

Agile, в
слова
основателей, «способность создавать и реагировать на
менять.» Это подход к разработке программного обеспечения, в котором
гибкость, совместная работа и частые небольшие развертывания.Это не
среда разработки программного обеспечения, скорее, Agile — это образ мышления — набор
ценности и принципы, которые помогают компаниям принимать правильные решения при адаптации
к меняющимся обстоятельствам. Создатели Agile систематизировали эти ценности и
принципы в
Agile
Манифест и
Двенадцать
Принципы гибкого программного обеспечения, которые мы обсудим более подробно в
ближайшие разделы.

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

Хотя эти идеи не были полностью
новый — итеративный
практики разработки существовали с 1950-х годов — создание
Agile открыла новую главу. Это философия адаптивного развития, а не
определенный процесс. Agile объединяет разработчиков с общими ценностями, даже если их
индивидуальные подходы разошлись.Что особенно важно, это помогло организациям переосмыслить
их процессы разработки программного обеспечения — сегодня
97
процент организаций сообщают об использовании гибких методов. Давайте исследуем это
философию более подробно и узнайте, что делает ее такой привлекательной.

Манифест Agile

Семнадцать разработчиков, которые встретились в этом лыжном домике в Юте —
«Agile Alliance», как они сами себя создали, — создал
Манифест для гибкой разработки программного обеспечения, чтобы резюмировать их новую философию,
наряду с Двенадцатью принципами гибкого программного обеспечения для дальнейшей поддержки и
объясните свое мышление.

Манифест — увлекательный документ для ряда
причины — «не последней из которых было заставить 17 человек согласиться на
это », — написал
Члены альянса Agile Мартин Фаулер и Джим Хайсмит. Всего 68 слов
долго, он легко усваивается, но выражает некоторые довольно глубокие идеи о
что разработчики должны ценить и расставлять приоритеты. Давайте посмотрим.

Источник: Agile Manifesto

Манифест примечателен, прежде всего, своим введением.В
подписавшие хотели дать понять, что — пока они считаются
экспертов и лидеров в своей области — разработка программного обеспечения — это постоянная
практики, и они все еще учатся. Выбор слова
«Раскрытие» было преднамеренным, Мартин и Джим
сказать,
«Заверить (или напугать) аудиторию, что члены Альянса не
есть все ответы ». Они просто хотели поделиться тем, что у них было
узнали и продолжали учиться.

Манифест также необычно «мягок» для программного обеспечения.
документ развития (заимствовать
формулировка
члена Agile Alliance Боба Мартина).Он подчеркивает создание человека
связи, как с товарищами по команде, так и с клиентами. Это по замыслу:
«Разработка программного обеспечения — это дело людей», — сказал
Джеймс
Ньюкирк в разговоре с Agile Alliance. Создание программного обеспечения, особенно
в больших масштабах — это совместный процесс — есть много
заинтересованные стороны,
как внутренние, так и внешние. Agile Alliance не утверждал, что
существующие процессы или заключение контрактов — плохая практика, просто
они неадекватны
для успешной навигации по программным проектам.Сотрудничество и командная работа
имеют приоритет.

Наконец, манифест использует проверенные временем мудрые решения в области управления проектами.
голова. «Традиционная практика управления проектами предполагает, что достижение
план равен успеху проекта равен продемонстрированной ценности для клиента »,
записывать
Мартин и Джим — но это просто не так в современном программном обеспечении.
ландшафт развития. Сегодняшние проекты более нестабильны,
часто меняющиеся требования.В первоначальной концепции проекта мало
имея в виду его окончательный успех. Командам важнее быть гибкими
чем выполнить план в точности. Или, как выразились Мартин и Джим,
«Содействие переменам более эффективно, чем попытки предотвратить
Это.»

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

Двенадцать принципов

Agile Alliance также поддержал свой манифест двенадцатью руководящими
принципы. Это помогает объяснить мышление создателей и исследовать
более подробно о практических последствиях манифеста. По словам
Agile
Alliance, это «руководящие принципы, которые помогают командам в
гибкое внедрение и выполнение.”Давайте посмотрим:

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

Почему Agile?

Простота Agile Manifesto и принципов Двенадцати Принципов
может быть обманчивым. Хотя идеалы, выраженные в манифесте, легко понять.
понять, применять их на практике — это
Сильнее
чем кажется, не говоря уже о том, что это противоречит тому, как многие
организации функционируют.У крупных, устоявшихся компаний обычно много
процессы на месте. Они могут захотеть сохранить исчерпывающую документацию по программному обеспечению.
и заключать тщательно сформулированные контракты, чтобы покрыть ответственность
целей. Они могут не иметь возможности адаптироваться к изменениям без
обширное изменение
планирование управления. Так зачем вообще возиться с Agile? Возьмем
смотреть.

Члены Agile-команд счастливее

Это не просто анекдот: исследователи из Университета Бэйлора обнаружили
положительный
взаимосвязь между использованием разработчиками Agile-методов и их работой
удовлетворение.Исследование показало, что у членов Agile-команд больше
автономность. Гибкие разработчики, как правило, активно участвуют в проекте.
управления и имеют более высокую степень контроля над работой, которую они
делать — что продвигает
удовлетворенность работой и благополучие сотрудников.

Agile повышает продуктивность команды

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

Agile улучшает коммуникацию и прозрачность с заинтересованными сторонами

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

Agile приводит к лучшему программному обеспечению

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

Agile дает менеджерам возможность выполнять важную работу

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

Распространенные заблуждения Agile

Agile не является основой для разработки программного обеспечения

Agile — это философия, которую команды могут использовать для принятия решений о том, как лучше
разрабатывать программное обеспечение. Хотя многие Agile-команды используют такие фреймворки, как Scrum,
сами по себе эти процессы не являются Agile. Как Agile-эксперт
Джеймс
Ньюкирк объясняет: «Процесс сам по себе является средством достижения цели. Это не так
конец.» Конечная цель, как указано в Agile Manifesto, — это
«Поиск лучших способов разработки программного обеспечения.”Agile-команды будут
имеют разные процессы и подходы, но все они работают над этим
та же цель.

Agile — это не анархия

Хотя некоторые менеджеры могут вздрогнуть, услышав такие фразы, как
«Самоорганизующиеся команды» Agile не означает хаос и анархию.
Agile-команды не отвергают процесс, они просто не позволяют процессу иметь приоритет
над своими товарищами по команде или целями, над которыми они работают. Фактически, Agile
команды обычно используют какой-то жизненный цикл разработки программного обеспечения
методология, такая как Scrum,
Опираться
Девелопмент или Канбан — они
просто убедитесь, что процесс удовлетворяет их потребности, а не жертвует их
необходимо в процессе.

Принципы Agile подходят не только командам разработчиков программного обеспечения

Это спорный вопрос, поскольку Agile Manifesto и Двенадцать принципов
были написаны специально для разработчиков программного обеспечения. Но другие команды могут
также извлекут выгоду из принятия принципов Agile — например,
энергетический ядерный реактор
использует методы Agile для создания новых радиопрограмм и
Одинокий, уединенный
Planet использует Agile в своей команде юристов. Однако Agile лучше всего работает, когда
условия отражают те, с которыми сталкиваются разработчики программного обеспечения.В
Гарвард
Business Review резюмирует эти условия следующим образом: «
проблема, которую нужно решить, сложна; решения изначально неизвестны, а продукт
требования, скорее всего, изменятся; работа может быть модульной; Закрыть
возможно сотрудничество с конечными пользователями (и быстрая обратная связь от них); а также
творческие команды обычно превосходят командно-административные
группы. »

Руководство по Agile

Гибкость в действии

.

Что такое Agile? Как бы вы дали определение Agile? Что означает Agile?

Как вы определяете Agile? Я видел много дискуссий, в которых люди пытались ответить на вопрос «Что такое Agile?» с очень разными ответами.

Вы действительно имеете в виду Scrum?

Во-первых, существует большая путаница в Agile и Scrum. Scrum настолько широко используется в качестве гибкого подхода, что, когда многие люди говорят «Agile», они на самом деле имеют в виду Scrum.

• Agile — это общая философия
• Scrum — это особый подход Agile

Ознакомьтесь с этой статьей о том, что такое Scrum? Что такое Agile? подробнее об этом.

Чувствуя слона

Я уверен, что вы можете найти по крайней мере 100 определений того, что такое Agile, в Интернете. Это похоже на старую басню «Слепые чувствуют слона»:

«Это было шесть человек из Индостана
, склонных к обучению,
Кто ходил посмотреть на Слона
(Хотя все они были слепыми),
Каждый по наблюдению
Может удовлетворить его разум ^{[18] ”}

У каждого человека свое мнение в зависимости от того, к какой части слона он прикоснулся:

«Каждый, по своему мнению, заключает, что слон похож на стену, змею, копье, дерево, веер или веревку, в зависимости от того, где они коснулись»

Различные взгляды на Agile

То, как люди определяют Agile, в чем-то похоже.В зависимости от того, к какой части вы прикоснетесь, у вас может сложиться разное впечатление о том, что такое Agile:

• Многие люди определяют Agile с точки зрения того, как это делается. Например, многие люди скажут, что это определено в Agile Manifesto. Вот несколько примеров:

«Agile — это набор методов и структур, воплощающих принципы и ценности Agile Manifesto»

«Agile» — это термин, используемый для описания подходов к разработке программного обеспечения с упором на поэтапное выполнение, командное сотрудничество, непрерывное планирование и непрерывное обучение.Термин «Agile» был придуман в 2001 году в Agile Manifesto ».

• Некоторые люди скажут, что это просто образ мышления или образ мышления. Вот пример этого.

«Быть ​​гибким — это образ мышления. Речь идет о поиске того, что нужно строить быстрее (а не просто строить быстрее) »

• Некоторые люди определяют его, сравнивая его с «Водопадом», чтобы сказать вам, что это за , а не . Вот пример этого:

«Agile — это ограниченный по времени итеративный подход к доставке программного обеспечения, при котором программное обеспечение создается постепенно с самого начала проекта, вместо того, чтобы пытаться доставить все сразу ближе к концу.”

Ни одно из этих определений не является неправильным, но это все равно что «почувствовать слона»; на мой взгляд, они не понимают настоящей сути того, что такое «слон».

Как вы определяете Agile?

Лично мне нравится определение, опубликованное Agile Alliance:

«Способность создавать и реагировать на изменения, чтобы добиться успеха в неопределенной и неспокойной среде».

Я думаю, что это лучшее определение, потому что оно раскрывает то, что я считаю реальной сущностью Agile.

«Agile лучше всего подходит для ситуаций с некоторым уровнем неопределенности, где творческий подход и инновации важны для максимизации бизнес-ценности решения, в отличие от других ситуаций с более низким уровнем неопределенности, где более важны планирование и контроль для достижения предсказуемости. ” (Мое определение)

Какие проблемы решает Agile?

Мы должны признать, что Agile — это не решение всех проблем, которые могут у вас возникнуть.Один из способов определить это с точки зрения того, для каких проблем он полезен.

• Если вы согласны с тем, что Agile — это не решение всех проблем, которые могут у вас возникнуть, первое, что вам нужно знать, это «для каких проблем он полезен?»
• Не нужно вдаваться в подробности о том, как это сделать, пока вы не убедитесь, что это полезное решение проблемы, которую вы пытаетесь решить.

Из этого можно сделать интересное наблюдение — люди очень погружаются в механику Agile и вот как они это определяют.Разве не важнее знать, для решения каких проблем он полезен, прежде чем вдаваться в подробности того, как его использовать?

Статьи по теме

Вы можете найти статьи по теме «Понимание Agile» здесь:

Дополнительные ресурсы

Более подробную информацию об этом вы найдете в моем онлайн-тренинге по управлению проектами Agile.

Нравится:

Нравится Загрузка …

.

Что такое модель гибкой разработки программного обеспечения?

• На главную

• Тестирование

  • • Назад
    • Гибкое тестирование
    • BugZilla
    • Cucumber
    • Тестирование базы данных
    • Тестирование ETL
    • 0003
    • Jmeter
    • Загрузка Jmeter

    Jmeter Backing

    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • Центр качества (ALM)
    • RPA
    • SAP Testing
    • Selenium

  • SAP

    • • Назад
      • ABAP
      • APO
      • Начало er
      • Basis
      • BODS
      • BI
      • BPC
      • CO
      • Назад
      • CRM
      • Crystal Reports
      • FICO
      • Pay4
      • HR

      Назад

      • PI / PO
      • PP
      • SD
      • SAPUI5
      • Безопасность
      • Менеджер решений
      • Successfactors
      • SAP Tutorials
  • Назад

    Web

  • Angular

    Web

    • • ASP.Net
      • C
      • C #
      • C ++
      • CodeIgniter
      • СУБД
      • JavaScript
      • Назад
      • Java
      • JSP
      • Kotlin
      • Linux
      • Linux
      • Kotlin
      • Linux

      js

      • Perl
      • Назад
      • PHP
      • PL / SQL
      • PostgreSQL
      • Python
      • ReactJS
      • Ruby & Rails
      • Scala
      • SQL

      000

      • SQL

      000

      0003 SQL

      000

      0003 SQL

      000

      • UML
      • VB.Net
      • VBScript
      • Веб-службы
      • WPF

    • Обязательно учите!

      • • Назад
        • Бухгалтерский учет
        • Алгоритмы
        • Android
        • Блокчейн
        • Business Analyst
        • Создание веб-сайта
        • CCNA
        • Облачные вычисления
        • 00030003 COBOL 9000 Compiler
          9000 Встроенные системы
          • 00030002 9000 Compiler 9000
          • Ethical Hacking
          • Учебники по Excel
          • Программирование на Go
          • IoT
          • ITIL
          • Jenkins
          • MIS
          • Сеть
          • Операционная система
          • Назад
          • Управление проектами Обзоры
          • Salesforce
          • SEO
          • Разработка программного обеспечения
          • VB A

      • Big Data

        • • Назад
          • AWS
          • BigData
          • Cassandra
          • Cognos
          • Хранилище данных

          0003

          • HBOps

          0003

          • HBOps

          0003

          • MicroStrategy

      .

      Что такое гибкая разработка и почему все об этом говорят?

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

      Что такое гибкая методология?

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

      Agile Development была представлена ​​в 2001 году, когда 17 разработчиков программного обеспечения собрались на горнолыжном курорте в горах Уосатч в штате Юта и написали Agile Manifesto:

      «Мы открываем лучшие способы разработки программного обеспечения, делая это и помогая другим в этом. Это.

      Благодаря этой работе мы пришли к выводу:

      • Люди и взаимодействие важнее процессов и инструментов
      • Рабочее программное обеспечение важнее исчерпывающей документации
      • Сотрудничество с клиентом в ходе переговоров по контракту
      • Реагирование на изменения в соответствии с планом

      В то время как предметы справа имеют ценность, мы ценим предметы слева больше.”

      Манифест был переведен более чем на 60 языков по всему миру.

      Кто использует гибкую разработку?

      Согласно опросу, проведенному TechBeacon, более 50% компаний, больших и малых, склоняются к принятию методологии Agile, а 16% перешли на использование Agile-компаний. Они считают, что это более эффективно и действенно при разработке надежных приложений. Например:

      Старое против нового: метод водопада против гибкого

      Метод водопада:

      Этот метод был разработан более 30 лет назад и ориентирован на планирование и документирование.

      Pro: Он заранее обеспечивает выполнение четко определенных требований, а также упрощает планирование бюджетов и сроков.

      Con: Проверка выполняется слишком поздно, и изменение стоит дорого.

      Методология Agile:

      Разработана менее 20 лет назад и ориентирована на гибкость в разработке, при этом продолжая двигаться вперед.

      Pro: Agile более адаптируемо

      Con: Меньше структуры и планирования затрудняют планирование проекта, бюджеты и сроки труднее прогнозировать.

      Что такое Scrum?

      Scrum — самая популярная реализация Agile-методологии. Это структура, которая разбивает сложные проекты на список приоритетов, который затем рассматривается один за другим в заданные временные рамки, известные как «спринт». В команде есть «Скрам-мастер», который управляет командой и помогает им помнить о конечном результате. После спринта товар, подлежащий отправке, рассматривается. Затем следующее в списке снимается и объединяется в следующий спринт.

      Прочтите об игроках и игре здесь: Навыки управления продуктом: Scrum

      .

      No related posts.