Agile *

Всем хабрапривет!

Хочу поделиться переводом краткой, но достаточно толковой шпаргалки по Agile-трансформации.

Оригинал статьи тут.

Чтобы достичь успеха в сегодняшней рыночной ситуации, компании должны быстро поставлять клиентам качественный инкремент продукта (product increment – «ощутимый результат работы одного спринта» (например, новая функция продукта, прототип приложения и т.д.) — te-st.ru/2017/07/04/12-terms-of-scrum).

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

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

Дано: Компания, использующая фреймворк Scaled Agile (SAFe) для масштабирования Agile-разработки в рамках всей организации; 10 команд разработки, объединённых в одну большую команду (Agile Release Train, согласно терминологии SAFe), доставляющую общий продукт; необходимость проведения двухдневного квартального планирования (PI Planning) для определения плана работы ИТ-команд на ближайшие 3 месяца*; три офиса разработки, расстояние между самыми удалёнными превышает 6 тысяч километров с соответствующей разницей в 5 часов рабочего времени; предыдущий опыт планирования, предусматривавший физическое присутствие ключевых коллег в одном помещении и использование аналоговых досок/вайтбордов/маркеров/липких бумажечек.

* Тяжеловесный конструкт “План работы ИТ-команд на ближайшие 3 месяца” грозит серьёзно увеличить объем текста, поэтому в дальнейшем я планирую вместо него писать просто – “коммитмент”. Соответственно, составить и принять план работы – “закоммититься”.

Зачем это понадобилось?

1) Усталость от аналоговых методов работы. В то время, как космические корабли бороздят просторы, а Илон Маск роет тоннели, мы, «айтишники», упорно пишем маркерами на липучих бумажках и лепим их на доски – есть в этом некий диссонанс. Так выглядел наш коммитмент некоторое время назад:

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

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

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

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

В комментариях велели картинку для привлечения внимания вставить. Исполняю.



Сейчас она работает директором проектного департамента одного из крупнейших и известнейших предприятий Челябинска. А я сижу и пишу про нее статью.

Определение DevOps очень сложное, поэтому приходится каждый раз запускать дискуссию об этом заново. Только на Хабре тысяча публикаций на эту тему. Но если вы это читаете, то наверняка знаете, что такое DevOps. Потому что я — нет. Привет, меня зовут Александр Титов (@osminog), и мы просто поговорим о DevOps, и я поделюсь своим опытом.



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

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

Меня эти вопросы волнуют особенно. Я последние два года работаю над системой управления YouGile.

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

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

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

Наш мир устроен очень странно. И чем дальше, тем становится страннее. И хрен поймешь, в чем дело.

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

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

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

Надоело тратить время на выяснение что происходит в компании? Информация теряется в бесконечных групповых чатах WhatsApp-а? Нарушена коммуникация внутри команды? От слежения за (не)выполненными правками пухнет голова? Непонятна нагрузка на сотрудников и вообще кто чем сейчас занимается?

Если хотя бы на два вопроса из вышеперечисленных вы можете ответить утвердительно, просим под кат. Мы побеседовали с известной московской фотостудией “Bolshakova Studio” и они поделились своим опытом решения классических проблем управления.

Прямо сейчас — 13-минутное видео беседы. Ниже — краткое изложение интервью с цитатами.

Начну с главного: если ваши программисты сами выбирают себе задачу, то у вас большие проблемы.

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

А что есть выбор, выполняемый человеком? Это не мгновенный алгоритм, а процесс. У этого процесса есть начало, конец (дай-то Бог), и, главное – продолжительность. Сколько, по-вашему, может длиться выбор задачи?

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

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

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

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

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

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

Бывают и четвертые часы – когда мы выставляем клиенту сумму, отличную от заранее обговоренной. Разумеется, если условия нашего сотрудничества позволяют так поступать.

А теперь внимание, вопрос: где тут можно поработать над эффективностью? Или по-другому: эффективность чего мы будем повышать?

После публикации резюме того парня произошли два хороших события.

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

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

Практику ускорения разработки я давно хотел систематизировать, но не было повода. А потом ко мне обратилась одна компания и предложила разработать курс, чтобы потом его продавать в определенной (чего уж там — 1Сной) среде. Предполагалось, что это будет видеокурс, с какими-нибудь презентациями и заданиями — скукота, в общем. Я решил убить двух зайцев — написать текст, типа книгу, а потом из него уже видеокурс делать. Таким образом, получилось бы два продукта. Минимальными усилиями из нее получился бы и третий.

Структура книги давно известна, что там написать — тоже, надо просто сесть и сделать. Я написал, на данный момент, 6 глав из 20, т.е. ~30%. И, раз пошла такая пьянка, выложить их в виде статей. Девушка, кстати, прочитала только 3 главы.

Сейчас будет первая, вводная глава. Есть небольшая специфика — раз книга, по сути, создавалась на заказ, то она про разработку на 1С. Убрав упоминания 1С, я бы и сделал из нее третий продукт — это заняло бы полдня.

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

Друзья, нам с вами несказанно повезло. Тот парень еще не уехал, и я выпросил у него резюме. Не потому, что хочу взять его на работу — не тот я человек. Просто мне кажется, оно стоит того, чтобы быть опубликованным. Хотя бы потому, что в нем 22k букв. Вы еще где-нибудь такой кошмар встречали?

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

Итак, дальше — сплошная цитата без моих правок.

Я не люблю стандартные резюме. Но объективно понимаю, что вы, скорее всего, обо мне ничего не знаете, и этот пробел надо восполнить. Поэтому я напишу необычное резюме. Резюме-статью.

Наливайте чайку или кофейку, у нас тут лонгрид.

Гибкая методология разработки — отличная идея, которую слишком усложнили. Agile Lite — попытка упростить ситуацию. Вам не нужны книги или семинары, чтобы объяснить Agile Lite. Нужен только небольшой текст с несколькими пунктами. Вот этот текст.

Agile Lite довольно прост. Его можно применить к любому проекту при условии, что работа разбивается на более мелкие задачи (issue). Как и другие гибкие методологии, он использует короткие циклы разработки  — спринты. Но в отличие от них, Agile Lite явно признает распространённость выгорания в индустрии разработки программного обеспечения и пытается смягчить его напрямую путём внедрения цикла «три недели разработки/одна неделя отдыха.

Не знаю почему, но вам понравилась история про одного парня. Если помните, он ушел.

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

Я, как вы поняли, с ним знаком. И не просто знаком – мы вместе учились на приборостроительном факультете. На носу День Радио, и он прилетел обратно в нашу дыру на встречу выпускников. Позвал меня выпить пива, и рассказал мне одну историю. Про одну девушку.

Я уже пытался лечить «механический» scrum (часть 1, часть 2, часть 3), а в этой статье постараюсь выписать универсальное лекарство от «подгорания». Само по себе «подгорание», «бурление» и т.п. — это хорошо, это значит вам не все равно (а ведь безразличие — это шаг к унынию, или, как принято в IT — к выгоранию). На тему вреда выгорания написано и снято много материалов, например: вот, вот, вот или вот.

Одна распространенная мудрость гласит: «Баттхёрты — двигатель прогресса». Но часто бывает так: пригорело => быстро принимается поверхностное решение, маскирующее проблему => решение воплощается в жизнь => пригорать продолжает. Другими словами, вместо того, чтобы разобраться и поставить диагноз, мы сразу приступаем к лечению. Попытаюсь это проиллюстрировать примерами.

В этом посте я расскажу о тех проблемах с которыми в течении года сталкивалась наша Scrum Front End команда при работе над приличным проектом. Мы начинали разрабатывать проект с нуля используя стек технологий React + Typescript. Оглядываясь назад я вижу многие миллионы выброшенные впустую просто из-за того, что процесс разработки не был поставлен с самого начала правильно. Но на это есть свои причины.

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

А что делать большим традиционным компаниям, которые годами жили в WATERFALL проектах и чтобы согласовать новую кнопку на сайте проходят семь кругов бюрократического ада?

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

В 2001 году группа технологов и программистов, разделявших небанальные теории о том, как следует управлять разработкой ПО, встретились на горнолыжном курорте Сноубёрд, чтобы письменно изложить некоторые из этих концепций. Так родился «манифест Agile» — обманчиво простой документ, призванный пересмотреть догмы разработки ПО. Разработка ПО в стиле Agile превратилась в новый стандарт организации труда программистов в организации. Такие компании как Facebook, Amazon, Apple, Google и Netflix выстроили свои внутренние процессы разработки в соответствии с базовыми положениями этого манифеста. Учитывая абсолютные масштабы Agile и его общественный резонанс среди сторонников, легко убедиться, что Agile — самая влиятельная из всех когда-либо формализованных трактовок разработки ПО. Однако, Agile — это идеология. Нормативная система ценностей и убеждений, практически до основания впитавшихся в дело разработки ПО. Таким образом, софтверная индустрия сегодня дает интересную возможность оценить, как номинальные цели некоторой идеологии согласуются с ее воплощением на практике.

Наверняка каждый из нас когда-нибудь задумывался о том, а какая она, эта самая команда мечты? Команда крутых друзей Оушена? Или команда сборной Франции по футболу? А может быть команда разработчиков из Google?

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



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

21-22 марта 2019 г. мы с коллегами посетили конференцию AgileDays 2019, и я бы хотел немного об этом рассказать.



Место проведения: г. Москва, Центр международной торговли

Что такое AgileDays?

AgileDays – это ежегодная конференция по гибкому управлению процессами, которая проводится уже в 13-ый раз. Если тебе не знакомы такие понятия как «плоская структура организации» и «самоорганизация команды», то советую тебе почитать про Agile.

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

В конце прошлого года меня пригласили выступить на мероприятии Worldwide Conversation on Women’s Higher Education and Equality in the Workplace на факультете компьютерных наук ВШЭ. Это беседа о том, как в современном мире женщина может построить успешную карьеру в области науки, образования или информационных технологий, с какими сложностями она при этом сталкивается и как может их преодолеть.

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