Методологии или модели?
Как показывает опрос, большинство команд предпочитает использовать собственные методологии, нежели брать что-то готовое.
Почему так?
Несмотря на то что и про XP, и про Scrum говорят, что они «могут использоваться как есть, из коробки» — в реальности дела обстоят не так, и для эффективного использования гибких методологий их необходимо долго подгонять под условия, сложившиеся в организации, под особенности проекта и т. д. Так как во всех гибких методологиях гораздо больше сходств, нежели различий, то зачаструю бывает трудно определить, а что же именно у нас используется? :)
Таким образом, правильнее было бы говорить не о конкретной методологии, а об основных моделях — гибкая, итеративная, спиральная, водопада. Из этих 4-х явными лидерами будут гибкие и итеративные модели, причем гибкие больше подходят для небольших, а итеративные — для более крупных проектов.
Почему так?
Несмотря на то что и про XP, и про Scrum говорят, что они «могут использоваться как есть, из коробки» — в реальности дела обстоят не так, и для эффективного использования гибких методологий их необходимо долго подгонять под условия, сложившиеся в организации, под особенности проекта и т. д. Так как во всех гибких методологиях гораздо больше сходств, нежели различий, то зачаструю бывает трудно определить, а что же именно у нас используется? :)
Таким образом, правильнее было бы говорить не о конкретной методологии, а об основных моделях — гибкая, итеративная, спиральная, водопада. Из этих 4-х явными лидерами будут гибкие и итеративные модели, причем гибкие больше подходят для небольших, а итеративные — для более крупных проектов.
Тренды, возведенные в культ
Несколько последних лет ознаменовались появлением большого количества новых терминов, понятий, технологий, течений. Также появилось достаточное количество базвордов, которые заполонили медийное пространство. И заполонили до такой степени, что многие айтишники начинают поддаваться на соблазны и искушения рисующихся золотых перспектив. Но не буду говорить загадками — под катом список понятий, с которыми связано большое количество надежд, холиваров и… заблуждений. Давайте немного разберемся, что к чему.
Опасайтесь обобщений
Существует много модных современных концепций: Agile, Lean Startup, Customer Development, Worse is Better, TDD, SaaS. Все они хороши. Вникание, а тем более использование, сильно расширяет горизонты. Но надо понимать, что это всё довольно общие вещи. Нужно не забывать использовать голову и чётко осознавать применимость в собственном проекте.
Фанатичное следование методологии напоминает восторг от осознания какой-то возможности в языке программирования. Я сам поддавался такому не раз: «Круто, в Python есть метаклассы — срочно используем в проекте» — несмотря на то, что того же самого можно было добиться обычными атрибутами класса. «Вау, макросы Lisp — это супер, накодим их побольше» — хотя можно было обойтись функциями высшего порядка. Сначала делаешь так, а со временем свыкаешься и уже не суёшь эту мощную возможность куда попало, а используешь, только если она действительно нужна.
Все теории когда-то были молодыми. Даже те, что сейчас считаются немодными и устаревшими когда-то были прорывом. Просто сейчас они утратили былой блеск, так же, как утрачивают блеск мощные возможности в языке программирования.
Где тот момент, когда они устаревают? Где те условия, в которых они работают, и в которых уже нет? Может быть, новый тренд уже стал устойчивым стереотипом и необходимо движение дальше? Эти вопросы нужно всегда задавать себе и пользоваться/не пользоваться концепцией не потому что она прогрессивна/устарела, а потому что она подходит/не подходит лично вам в конкретном деле.
Фанатичное следование методологии напоминает восторг от осознания какой-то возможности в языке программирования. Я сам поддавался такому не раз: «Круто, в Python есть метаклассы — срочно используем в проекте» — несмотря на то, что того же самого можно было добиться обычными атрибутами класса. «Вау, макросы Lisp — это супер, накодим их побольше» — хотя можно было обойтись функциями высшего порядка. Сначала делаешь так, а со временем свыкаешься и уже не суёшь эту мощную возможность куда попало, а используешь, только если она действительно нужна.
Все теории когда-то были молодыми. Даже те, что сейчас считаются немодными и устаревшими когда-то были прорывом. Просто сейчас они утратили былой блеск, так же, как утрачивают блеск мощные возможности в языке программирования.
Где тот момент, когда они устаревают? Где те условия, в которых они работают, и в которых уже нет? Может быть, новый тренд уже стал устойчивым стереотипом и необходимо движение дальше? Эти вопросы нужно всегда задавать себе и пользоваться/не пользоваться концепцией не потому что она прогрессивна/устарела, а потому что она подходит/не подходит лично вам в конкретном деле.
О (гибких) методологиях
Я не отношусь к лагерю сторонников или противников той или иной методологии. Это инструмент, который в умелых руках творит чудеса, а в неумелых чудеса не творит. Ранее я уже немного писал о трендах, возведенных в культ, в списке которых гибкие методологии (в просторечии — эджайл), на мой взгляд, занимают важное место. В этой статье тезисно пройдемся по основным моментам использования методологий, в том числе гибких.
Создаем «Восхитительный» продукт (Minimum Delightful Product)
Из песочницы
Minimum Viable Product vs. Minimum Delightful Product
Одна из наиболее популярных идей, появившаяся в индустрии разработки в последние годы, это концепция «Minimum Viable Product (MVP)» (Минимально Жизнеспособный Продукт). Концентрируясь на создании MVP вы уменьшаете шансы, что вы создадите продукт, который не нужен потребителю. Вы можете воспринимать ее как основу широкой методологии, которая оказывает влияние на заказчика и исследует пользователя продукта в процессе разработки.
На первый взгляд MVP отличная идея, потому, что она обращена к главному антипаттерну в продуктовой разработке: создание слишком большого числа фич, в том числе не востребованных, в результате тратится слишком много времени на разработку без запуска проекта или получения реального фидбека от заказчика и пользователей продукта.
Один шаг в новый формат, PM
Recovery mode
Вечером в среду, 28 мая, в Москве состоялось событие, которое может дать ощутимый толчок для развития проджект менеджерам — это встреча участников группы «Управление проектами» сайта Linkedin. Это был не обучающий семинар. Это была не конференция. Формат встречи был уникальный — создатель группы, он же спикер — Дмитрий Джафаров разбирал книгу «Цель: Процесс непрерывного совершенствования» Э. Голдрата. Почему формат события был уникальный? Всё просто — разбиралась реальная методология, которая стала популярной на западе, но не только с проецированием на процессы России, но и с разбором реальных кейсов участников.
Если бы программисты делали блины (по кошерным методологиям)
Waterfall
Заказчик сообщает, что хочет блинов. Компания выделяет проджект менеджера, который говорит: «Говно вопрос! Наша компания специализируется по производству блинов! Мы сделаем вам офигенских блинов за две тысячи человеко-часов!»
Далее начинается аналитическая фаза. Бизнес-аналитик берет эксперта, и они денно и нощно заседают в офисе заказчика, потребляют халявный кофе и пончики, а также тщательно записывают бизнес-требования вплоть до толщины блинной корочки с точностью до микрона. Документы записываются на фирменных бланках компании, после чего заверяются подписью директора компании-заказчика, директора компании-исполнителя, стороннего консультанта по блинному производству, а также печатью Папы Римского. После окончания аналитической фазы на проект остается 1000 часов.
Настройка ума на частоту Agile
Давно и успешно мы помогаем самым разным специалистам делиться собственными знаниями во всех возможных областях, в первую очередь – менеджменте и управлении, который становится все более актуален с течением времени. То же касается и разработки, проектирования и архитектуры.Постепенно мы собрали ключевые техники проектирования из основных методологий и архитектурных стандартов и перевели на человеческий язык. Подключили наш собственный опыт и работающие решения наших многочисленных заказчиков, получив в итоге ряд занятий-тренингов. При этом формат их – практический, поэтому к большинству решений участники придут самостоятельно, что дает колоссальную конверсию навыков в применение на производстве.
Для кого:
- Инженеров: архитекторов.
- Техменеджеров: тимлидов и техлидов.
- Менеджеров: проектных менеджеров и продуктовых менеджеров
- Желателен опыт промышленной разработки от 2 лет.
- Обязательны навыки проектирования в объеме курса «Agile Mindset в проектировании систем», особенно для участия в продвинутом тренинге: «Agile Mindset в проектировании решений».
Разделив весь имеющийся опыт на две больших составляющих одного целого, картина следующая
Agile Turkey Summit 2017, и такая противоречивая «международность» мероприятия
Из песочницы
Учитывая что в Уфе зима приближается решительными марш-бросками, почему бы не поехать в конце октября на конференцию, куда-нибудь, где +20, и хоть немного, напоследок перед зимой, увидеть солнышко? Сказано-сделано: посмотрел конференции, сравнил докладчиков, посмотрел где еще есть early-bird access цены — и забронировал.
В этом году мы с коллегой разделились, и поехали на Agile Greece и Agile Turkey, дабы сравнить мероприятия, ну и рассказать что интересного было на каждой из них. Неоспоримы плюс Agile Turkey в этом году был открывающий доклад от Дейва Сноудена (создателя фреймворка cynefin, о которой вскользь писали на хабре). Обычно на подобных конференциях после докладов, спикеров облепляют заинтересованные, и свои вопросы задать и подискутировать не получается, что и было моим опасением, так как спросить надо было много.
Конференция и организация
Agile Turkey Summit проходит уже не первый год, в отеле Wyndham Grand Levent в Стамбуле (в активно строящемся небоскребно-деловом районе Maslak). Продолжается мероприятие всего 1 день (выпавший в этом году на 19 октября), хотя мастер-классы и воркшопы прошли еще 18-го числа. 4-й конференц-этаж отеля явно неспособен принять ~800 посетителей, что особенно очевидно, когда всех пытаются накормить.
5 техник определения приоритетов для IT команд
Всегда ли просто определить приоритеты в задачах крупного проекта? А если в приоритете находятся пять срочных задач? Десять?
Опытные менеджеры проектов и собственники продуктов знают, что одной интуицией здесь не обойтись. Для того, чтобы не подвести команду и уложиться в сроки, сегодня на помощь менеджерам приходят полезные методологии определения приоритетов, а также современные инструменты, которые помогают визуализировать данные и ничего не упустить в своих рабочих процессах.
Опытные менеджеры проектов и собственники продуктов знают, что одной интуицией здесь не обойтись. Для того, чтобы не подвести команду и уложиться в сроки, сегодня на помощь менеджерам приходят полезные методологии определения приоритетов, а также современные инструменты, которые помогают визуализировать данные и ничего не упустить в своих рабочих процессах.
Когнитивные искажения в освоении “времен” английского языка, или Кто нам мешает, тот нам и поможет
*Феномен Баадера-Майнхоф, или Иллюзия частотности — когнитивное искажение, при котором недавно узнанная информация, появляющаяся вновь спустя непродолжительный период времени, воспринимается как необычайно часто повторяющаяся.
Кругом “баги”...
“Софт” каждого из нас напичкан “багами” —
Опрос по инструментам фронтенда 2019 — результаты
Перевод
TL;DR. В большинстве категорий теперь выделяются явные лидеры — несколько лет назад такого не было. Это помогает накоплению знаний. Поэтому Навыки владения инструментами в среднем становятся глубже у разработчиков всех уровней.
В этом году 3005 разработчиков ответили на 27 вопросов, охватывающих широкий спектр инструментов и методологий фронтенд-разработки. Как всегда, огромная благодарность всем, кто нашёл время заполнить опросник. Со своей стороны, прошу прощения за задержку с публикацией результатов: в этом году работать было непросто из-за рождения малышки.
Как всегда, очень интересно посмотреть на изменения инструментов фронтенда за последние 12 месяцев и как меняются мнения разработчиков в отрасли. Эти результаты (надеюсь) помогут получить представление о текущих тенденциях и уровне освоения инструментов, а также об изменениях во времени, сравнив с цифрами из предыдущих опросов.
Итак, к делу! Возьмите чай/кофе/напиток на свой выбор и посмотрим на результаты…
В этом году 3005 разработчиков ответили на 27 вопросов, охватывающих широкий спектр инструментов и методологий фронтенд-разработки. Как всегда, огромная благодарность всем, кто нашёл время заполнить опросник. Со своей стороны, прошу прощения за задержку с публикацией результатов: в этом году работать было непросто из-за рождения малышки.
Как всегда, очень интересно посмотреть на изменения инструментов фронтенда за последние 12 месяцев и как меняются мнения разработчиков в отрасли. Эти результаты (надеюсь) помогут получить представление о текущих тенденциях и уровне освоения инструментов, а также об изменениях во времени, сравнив с цифрами из предыдущих опросов.
Результаты
Итак, к делу! Возьмите чай/кофе/напиток на свой выбор и посмотрим на результаты…
Нужна ли новая методология разработки?
Из песочницы
Если вы планируете создать свою софтверную компанию, то вы задумываетесь как построить работу людей, как выбрать методологию для работы. Но если приглядеться к известным методологиям, то есть к ним некоторое недоверие, особенно если вы тратите на компанию собственные деньги…
Я взял на себя смелость и попробовал объединить полезные вещи от известных методологий, а также добавил своего опыта и советы друзей. В любом случае, оставлю это здесь, может быть кому-то это принесет пользу.
Чем занимаются и сколько зарабатывают менеджеры в казахстанском IT? Исследование
Блог компании Kolesa Group Исследования и прогнозы в IT *Agile *Управление продуктом *Карьера в IT-индустрии
В январе компания Kolesa Group опубликовала очередное исследование Kolesa Zerttey. В этот раз оно посвящено менеджменту в IT.
Ранее подобные исследования публиковались по направлениям "Data Science-специалисты и аналитики" и "Разработчики" Из него можно узнать о:
– зарплатах, обязанностях и мотивации специалистов;
– популярных на рынке методологиях и фреймворках;
– размере и составе продуктовых команд;
– об источниках знаний и компетенциях в профессии.
Кто создает IT-продукты в Казахстане и сколько они зарабатывают?
Второе исследование Kolesa Group по рынку product-менеджеров в Казахстане за 2021-й год. Мы хотели узнать, чем дышат и занимаются менеджеры, с кем чаще всего контактируют, что их вдохновляет и сколько они зарабатывают?
Мы сравнили данные конца 2020 и начала 2022 годов, чтобы выяснить:
изменились ли задачи и обязанности менеджеров,
какие методологии и фреймворки стали использовать,
а еще узнали, с какими инсайтами столкнулись в 2021-м году.
Программисты-экстремисты
Перевод
Да, это не ошибка: сегодня мы поговорим о самых что ни на есть экстремистских подходах к программированию.
«Если вы не практикуете Test Driven Development (TDD), то не можете считать себя профессиональным разработчиком».
«Парное программирование — обязательное условие для серьезных разработчиков: это намного быстрее, чем одиночная разработка и асинхронная проверка кода»
«Моб-программирование — единственный способ добиться высокой скорости разработки и эффективного обмена знаниями внутри команды»
«TDD обеспечивает надежность кодовой базы и возможность релиза на прод в любое время»
Слышали ли вы когда-нибудь подобные заявления?