0. Selikhovkin 392 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 3389 26.11.18 17:00 Сейчас в теме
Полезно для меня.
Получил ответы на некоторые вопросы, по которым ощущал что "как-то не так оно"...
Спасибо.
5. Rico17 29 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С
Москва
Полный день

Консультант ERP-систем
Москва
Временный (на проект)

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

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