0. Selikhovkin 415 23.11.18 16:44 Сейчас в теме

"Черные страницы Scrum", по версии Ивана Селиховкина

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

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. user1096347 24.11.18 14:35 Сейчас в теме
Все эти проблемы довольно распространены, на любом качественном тренинге по скрам о них говориться, как и о том, как их решить, конечно же, тоже. :)
Vladimir Litvinenko; +1 Ответить
3. user1096704 25.11.18 13:34 Сейчас в теме
(1) автор ведь не говорит, что решений нет. Он говорит, что решения есть, но они не являются частью кошерного скрама)) и решения эти известны и без ваших тренингов и аджайл-наклеечек
Автору респект и плюс 100 к карме за то, что все баги в одном месте собрал. Обычно спорить лень с последователями Великого и Могучего Гудвина Скрама, теперь их можно к этой ссылке отправлять ;)
DonAlPatino; LordKim; +2 Ответить
2. Vladimir Litvinenko 24.11.18 16:08 Сейчас в теме
Отличная публикация, хорошо отрезвляет.

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


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

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


Книгу тоже прочитал.

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



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


QA. Оно же тестирование.

Частые примеры с тем, что именно разработчик при нехватке ресурсов на тестирование начинает участвовать в тестировании, а не наоборот QA начинает разрабатывать, связан во многом с тем, что обычно компании экономят на QA.

В качестве примера, на текущем моем проекте более 10 разработчиков-кодеров и только 2 инженера QA. Считается что тестировать должны консультанты, которые увы не могут сделать это качественно и всесторонне. Качество очень низкое, руководство начинает метаться между скрамом, водопадом и просто плеткой.

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

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



Velocity - мощность команды

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

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

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


Мощность (velocity) не нужно знать с точностью до десятых часа/сторипонинта. К чему это вообще? Если у вас 5 разработчиков и один из них заболел понять какой будет мощность на следующий спринт и сильно ошибиться сложно. Для этого нужно совсем не знать свою команду. Вы же знаете, сильный это разработчик ушел на больничный или джуниор. Оцените примерно. Даже если ошибетесь на 10%-20% это не фатально, чтобы записывать в жуткий недостаток инкрементального подхода.

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

Это делает спринт - мини проектом (почти по водопадной модели!), а не просто двухнедельным индивидуальным забегом по хаотично набранным задачам из таск-трекера.

Кто-то формулирует цель спринта при планировании чтобы сделать его мини-проектом? Или напрягаться не хочется и слишком лень это делать? )))



Фрейморк - жуткое непереводимое слово

Пожалуйста, хватит уже страдать англофобией. Слово фреймворк - шикарно. И очень хорошо применимо в IT. Оно понимается как набор ограничений и инструментов. Почему “фреймворк Spring” и даже “фреймворк - платформа 1С” в вакансиях от самой фирмы 1С не вызывает взрыва мозга, а “фреймворк Скрам” вызывает англофобию и топанье ногами? Ууух…. страшные иностранные слова….. То ли дело наш тёплый ламповый желтый мир , где всё понятно и мы уже такие опытные )))

Если мы не собираемся строить мост по скрам, а применяем его в ИТ , то слово фреймворк можно и нужно применять.


Противоречие Agile подходу

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

(Здесь должна быть отсылка к публикациям Ивана Белокаменцева)

История конечно мало кому интересна, а жаль.

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



Канбан

На слайде под ним стоит большой черный вопрос. А материалы ведь есть - имена, явки, пароли, руководства. В последнее время несколько раз приходилось делиться ссылкой на уже старенький материал : https://youtu.be/lrDLbp0XeFA?t=287


А за статью еще раз спасибо!
FB_1811930315551820; Valerych; LordKim; +3 Ответить
7. FB_1811930315551820 27.12.18 14:32 Сейчас в теме
(2) Пока читал статью, набрасывал на листок тезисно возражения, чтобы потом ответить "системно"... После Вашего коммента все тезисы пришлось вычеркнуть, кроме одного:

И про планирование:
1. Возьмем самый распространенный срок спринта - 2 недели (1 - никто не делает, 3 - теряется та самая "вовлеченность" и частота релизов).
Планирование спринта - 4-5 часов (6-8 может быть в самом начале проекта, когда много отнимает стратегия)
Ретроспектива - 3-4 часа (хотя это уже не чистое планирование, но об этом потом)
Ежедневки - считать просто недобросовестно (давайте еще перекуры и кофе-паузы посчитаем)
2 недели = 80 часов, план+ретро = (7+12)/2=9.5 часов
Итого имеем около 12% затрат на планирование. В классике водопада - весьма эффективный результат (и по времени, и по стоимости)
Теперь о том, почему эти 12% раза в два эффективнее, чем те же 12%, потраченные в начале проекта.
В НАЧАЛЕ ПРОЕКТА ЗАКАЗЧИК НЕ ЗНАЕТ, ЧТО ИМЕННО ЕМУ НУЖНО! Весь мой скромный опыт говорит, что большая часть первоначальных планов идет в корзину. И потом ВСЕ РАВНО тратится время на перепланировку этих планов. Только проектом и графиком это уже НЕ ПРЕДУСМОТРЕНО! И тогда приходит он - всеми любимый песец аврал. И иногда мы даже укладываемся в график. Ну, то есть заваливаем сроки не так уж чтобы сильно. Вобщем, заказчик тоже человек, он же все понимает, тем более что сам и является основной причиной... И все довольны, все хорошо (если проект взлетел, конечно). Но простите, как же можно при всем при этом говорить, что "Ужасный СКРУМ скрумкал аж 30% от чистого рабочего времени нашего проекта"?? В ЛЮБОМ случае это время будет потрачено на планирование и перепланирование.
И теперь вишенкой на торте: про ретроспективу.
Если что-то на проекте идет не так - стопорится коммит понятного вроде функционала, или прототипы раз за разом не принимаются заказчиком - в любом случае надо уделить этому время, понять причину стопора и постараться ее устранить вместо того, чтобы "пробивать стену лбом". Введение плановой ретроспективы - всего лишь дань очевидной потребности соотносить свою деятельность с меняющейся реальностью. Так что по-хорошему, время на ретроспективу из "затрат на планирование" стоит убрать - ведь в идеальном случае "все идет по плану, проблем никаких" вся ретроспектива занимает минут 30 (а могла бы и меньше, но ведь каждому приятно похвалиться достигнутыми результатами). А в реальном случае "что-то пошло не так" - все время, потраченное на ретро, окупается с лихвой тем, что ценные ресурсы не сжигаются в тупую, потому что "мы ж так изначально планировали, не отступать, не сдаваться!". Вот и выходит. что НА ПЛАНИРОВАНИЕ у нас уходит не более 8% времени.
Vladimir Litvinenko; +1 Ответить
4. CheBurator 3399 26.11.18 17:00 Сейчас в теме
Полезно для меня.
Получил ответы на некоторые вопросы, по которым ощущал что "как-то не так оно"...
Спасибо.
5. Rico17 30 28.11.18 12:37 Сейчас в теме
Было бы намного полезней рассматривать "узкие места" в проектной деятельности (любых проектов?) в сравнении: PMI vs Скрам vs Канбан.
Сразу обнаружится, что это и правда "узкие места" ;)
6. DAV 05.12.18 11:10 Сейчас в теме
(5) Полезно голову включать, а не гоняться за модой. И делать проекты исходя из здравого смысла, а уж как это потом обозвать - дело маркетинга.
ЗЫ. Не примите на свой счет, это именно мое ИМХО. А рассматривать методологии противопоставляя их друг-другу? Что сравнивать, теплое и мягкое? Канбан - речь за процесс, Скрам - речь про продукт, PMI - речь про проект. И да, в водопаде есть еще PRINCE2 например, что же только PMI ограничиваться?
8. FB_1811930315551820 27.12.18 14:54 Сейчас в теме
(6) Согласен с тем, что здравый смысл - всему голова. Все методы и "фреймы" - всего лишь инструменты, а не серебряная пуля. И если ПМ ясно представляет себе задачу, предметную область вообще, и главное - соотносит все со способностями своей команды, то он практически интуитивно (на самом деле - на основе набитых ранее шишек, своих и чужих) должен понимать, какими инструментами надо воспользоваться здесь и сейчас. Нет такого ПМа - бедный, бедный проект...
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день

Программист 1C
Москва
зарплата от 100 000 руб. до 150 000 руб.
Полный день

Программист 1С
Москва
зарплата от 120 000 руб. до 150 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 80 000 руб. до 120 000 руб.
Полный день