Comments 15
Scrum, Kanban и другие «эталонные» методы ведения проектов далеко не идеальны и многое упускают.
Метко сказано, наш выбор: ГОСТ 2, 19, 54869! Только хардкор!
Друзья, описываемые вами проблемы не от того, что "скрам, канбан и другие", а от того, что вы не понимаете и не знаете не первого, не второго не другого. Большая часть ваших "решений" проистекает оттуда же и ничего не решает.
Такое количество абсолютно неверных утверждений даже не позволяет ответить конструктивно, объём ответа будет сравним со статьёй.
Я вот не могу понять, наверное я живу в другом мире, где "классические" подходы не применяются "по букварю". Статей на эту тему валом, и часто, как и тут, почему-то на полном серьезе обсуждается: "вот есть методология, но вот она не работает, мы от нее отошли". А что ... правда есть те, кто прочитал scrum guide и по нему пытается работать буква в букву? А зачем?
Во-первых, есть внешняя среда. У меня много интеграционных проектов, где количество команд может легко достигнуть числа 10, или проектов разработки под заказчика, где часто ты сидишь на том, что есть у него. Методология удобна тем, что хотя бы вводит какой-то словарь и некоторое общее понятие правил, но использовать ее слепо ... странно
При большом числе участников трудно воплотить в жизнь и один из ключевых управленческих принципов Agile — самоорганизацию.
К примеру, для меня Agile начинается (и заканчивается) тут https://agilemanifesto.org/principles.html и тут https://agilemanifesto.org/iso/ru/manifesto.html. Я вот даже пошел и прочитал на русском, и не могу понял, откуда вы взяли выделенное как цитату? Ну правда. Agile - это 4 "ценности" и 12 принципов. Дальше их бесконечное постижение. Где вы взяли про самоорганизацию? Т.е. ... получается, что проблема ведь на в Agile, а в том, что люди используют что-то, чего так нет, оно не работает, или работает - не важно. Важно что это просто само по себе.
Отчасти поэтому классический Agile и предписывает работать группами по 5 — 9 человек
Опять, откуда это? Это чья-то интерпретация? Ну ОК, если кто-то придумал - тогда в чем собственно вопрос? Если мы придумываем свои правила, они как-то влияют на ваши процессы - то причем здесь Agile?
Тут мне кажется все просто, но возможно кому-то и будет обидно. Agile это скорее как условные "10 заповедей". Они требуют осмысления, понимания и работы согласно им. Ну или не согласно им. Тут каждый выбирает свое :) Но не стоит делать из этого карго культ. Это не имеет смысла. Принципы и ценности - это как мораль, в каком-то смысле. Внутренний критерий, что такое хорошо, а что такое плохо. Но не алгоритм, как сделать так чтобы "прилетела большая птица и из нее вышли белые люди и раздали ништяки".
По конкретным вопросам
Гибкие методологии не учитывают состав и численность команд
Да никто не учитывает. Все идет в банальный лимит "управления". Если у вас конвеер, то вам и 10000 работников несложно трудоустроить. Примеров валом. Только ИТ разработка пока еще не конвеер, как бы в методологии не пытались что-то рисовать. Больше людей - больше работы надо банально согласовать. Ну просто чтобы получить в конце рабочий продукт. Ну представьте - 10 разрабов. Что дальше? Если вы пилите идеальный "микросервисный" зоопарк - теоретически да. А если нет? Микросервисы же не снимают проблему согласования логики. Если Вася пилит проверку баланса, а Петя - списание со счета, а еще 8 человек что-то рядом, то вместе к финишу оно может прйити только согласованным, иначе счет за воду вы не оплатите. И архитектура вам не поможет в этом месте, потому что все равно надо чтобы работало все. А чем больше людей, тем больше косяков. Один не так понял, второй сует "инт" там где строка. Всего по мелочи, а в итоге на первых итерациях не работает ничего. И методология не поможет в том смысле, что как вы их не расставляйте, ничего не поменяется.
Работает работа. Согласование спек, контрактов. Общение и верификация, что все пониманиют одинаково. И все остальное. В какой методологической среде оно живет не так важно.
Разрабы выгорают и непонятно, что с этим делать
Ну как, все приедается. Тут конечно приятно, когда можно типа выделить спринт на тех. долг. Только срок проекта и заказчик имеют другое мнение :(
Возможно, вам, например, удалось разработать свою методику работы
Да работать надо. Качественно :) И правильно все делать. А методологам дать направление и проследить, чтобы они туда шли и никуда не сворачивали :)
Где вы взяли про самоорганизацию?
По вашей первой ссылке, пятый пункт:
"Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done."
Про самоорганизацию это из руководства по scrum (Кен Швабер и Джефф Сазерленд)
Мне трудно здесь увидеть здесь "самоорганизацию". Вы строите проект вокруг мотивированных процессионалов, но вы как менеджер, и в целом организация, создаете им окружение и решаете их "вопросы", в том числе и организацию процесса работы. Как тренерский штаб и прочие вокруг спортивной команды
И еще важный момент, строить проект вокруг мотивированной команды - это совсем не тоже самое, что
в команде только мотивированные профессионалы
они сами все сделают
-------------
"Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им."
Обратите внимание, насколько отличается перевод :) Причем этот пункт переведен максимально коряво :)
Я вот не могу понять, наверное я живу в другом мире, где "классические" подходы не применяются "по букварю".
О, это отдельная тема для разговора - немного порассуждали о ней в другой статье.
Поработал некоторое время по аджаилу и выделил следующие минусы:
Никто не знает как оно работает - чаще всего вся «документация» размазывается по задачам и команда имеет историю изменений по крупицам, но не обладает единой общей картиной на последний момент времени. Оттого поиск «сакрального знания» затягивается и повышает кол-во ошибок человеческого фактора. Поиск этот ведется 1-4 местах, в зависимости от их наличия: код (он есть всегда), таски (есть в 80-90% случаев), тесты, пользовательская документация (это как пойдет). Мне попадались компании, где существовала бизнес документация, но в них «почему-то» маячил призрак ватерфолла. На маленьких проектах и с маленькой командой (1-2 чел) - максимально полным сакральным знанием обладает самый старый программист. И весь адажил крутится вокруг него. И тут разумеется bus factor = 1
Давайте все перепишем. Разработка архитектуры так же подвергается спринтованию. В аджаиле фокус на реализацию необходимого минимума в сжатые сроки. Поэтому сначала делаешь все на коленке. Потом приходит крупный клиент с условным «хай-лоадом» и начинается двух недельный спринт «давайте поменяем архитектуру». Клиент всегда приходит внезапно и неожиданно, как первый снег и к нему никогда не бываешь готов. Даже если где-то в бэклоге / тех долге год назад затесалась задача по переработке наколенного mvp во что-то более нормальное
Такое ощущение, что создатели аджаила совершенно не учли наличие тестировщиков. Потому как, если спринт две недели - неделю программисты кодят, неделю тестировщики тестируют. Что делать программистам вторую неделю? Если они начнут кодить что-то еще - вся команда войдет в бесконечный спринт. И начинаются попытки как-то это решить. Ну там ветки всякие, гитфлоу, 100500 тестовых стендов, мержи, конфликты, откаты к монорепо. А потом все равно еще раз тестировать все вместе, потому что по отдельности оно работало, а вместе не хочет, да еще и намержили там чего ни попадя.
Такое ощущение, что создатели аджаила совершенно не учли наличие тестировщиков
Да, но нет. В практике приходили иногда к трем одновременным спринтам: В №1 идёт сбор требований, аналитика, прототипирование и согласования. в №2 сама разработка. в №3 тестирование, авторская приемка, пользовательское тестирование и перенос в прод. Потом сдвиг вправо. Собственно получается искусственное раздутие спринта в 3 раза и разбитие его 3 этапа (ну или опять таки мини-каскад). Но всем есть чем заняться в каждой итерации, НО всегда есть тех.долг от предыдущего спринта, который нужно обязательно включать в текущий или следующий.
Вот меня тоже мучает вопрос архитектуры, или, если хотите, идеологии системы. Я не понимаю, как их уложить в agile. Короткие спринты и пиление фич хороши для кастомизации и отрисовки новых окошек. Хороший сервер так не написать, по-моему.
Такое ощущение, что создатели аджаила совершенно не учли наличие тестировщиков. Потому как, если спринт две недели - неделю программисты кодят, неделю тестировщики тестируют. Что делать программистам вторую неделю?
А где в манифесте написано про спринты? Правильно нет там этого. Это про идеалогию...
Коллега, приятно увидеть, что не только мы пришли к таким практическим гибридам.
За 10 лет мы пробовали внедрять, кажется, все, что только можно.
В итоге через "кровь и пот" пришли к гибридам. Прописали свои манифесты и правила (Как правила дорожного движения - "написанные кровью").
Продолжаю читать статьи и раз за разом вижу теории.
И "о чудо!" первый раз вижу команду, которая пришла к абсолютно такой же схеме работы.
Разве что оценки у вас в "мерках", а у нас в числах Фибоначчи.
Буду следить за вашим опытом теперь.
Удачи вам и нам - меньше страданий, больше эффекта.
Спасибо за статью.
Agile не поможет. Ищем решения острых проблем в разработке