Как стать автором
Обновить

Плавное введение скрама самими разработчиками (разрешаем противоречия, настраивем команду, избегаем конфликтов)

Время на прочтение 5 мин
Количество просмотров 4.2K
Всего голосов 19: ↑11 и ↓8 +3
Комментарии 16

Комментарии 16

сформирована с достаточно грамотным и разносторонне развитым и опытным тимлидером, который имеет широкие полномочия

вот после этого предложения, закралось ощушение что не на те рельсы скрама вы встали

изначально это был не скрам

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


з.Ы.
Очень странный тимлид, который не мог только нужные поля отдать, но это уже отдельная история.

Очень странный тимлид, который не мог только нужные поля отдать

Ну тут как раз вполне мог быть вопрос с опытом и бОльшим пониманием того, во что превратиться проект в будущем. Грубо говоря, заказчик говорит «хочу авторизацию пользователя». Фронтендер это понимает «должен быть метод, в который передаешь логин-пароль, а тебе в ответ „да“ или „нет“». А тимлид на таких проектах уже собаку съел и знает, что всегда потом захочется иметь разные группы пользователей, разделение доступа, всякие кастомные списки прав и т.п., и закладывает все это сразу в формате данных, чтобы потом два раза не бегать.

Другое дело что конечно отказ от объяснений и срачи — вот это уже некрасиво.
Другое дело что конечно отказ от объяснений и срачи — вот это уже некрасиво.

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

Тут описана попытка перевода с тимлида на скрам. Причем не формально, а решая конкретные проблемы.

Надеюсь что этот опыт не отобьет у вас попытку попробывать еще раз но уже без тим.лида.

В скраме для выявления проблем на ранних этапах и гибкой самонастройки команды, проводятся ретроспективы спринтов


То есть вы утверждаете, что после ранних этапов ретро не нужно?
я не написал что ретро на поздних этапах не проводится, я имел ввиду ретро для раннего выявления проблем, чем раньше тем лучше, а не в конце проекта
Но это же опять что-то не то. Ретро не может по определению скрамгайда проходить в конце проекта. Если это так, это не скрам, а какой-то другой, свой Agile-фреймворк на основе скрама. Скрамгайд четко регламентирует ретро:

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

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


Коллега, извините, но у вас нет понимания, что такое Scrum.

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

вроде много сделано но ничего толком

Почитайте, опять же, скрамгайд: что такое PBR, что такое gold plating и не спирайте, пожалуйста, свое незнание на Scrum
Ну в гайде описаны оптимистические сценарии. А в жизни команда может бесконечно проводить ретроспективы и улучшать свои условия работы за счет заказчика. И не продвигатся в выполнении проекта.
Я сделаю последнюю цитату и на этом, думаю, стоит закончить:

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

medium.com/@analysisparadisis/обзор-книги-scrum-джеффа-сазерленда-38f64706bdfb
То что делала команда, это не скрам.

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

Про бекендера, который правит код на фронте. Это вообще не про скрам.
Типичная ИТ-проблема. Решается типичными ИТ-решениями (тесты, ревью и т.п.). И не важно что бекендер залез во фронт. Вместо бекендера мог быть джун фронтендер, и т.д.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории