Comments 180
Зачем нужны ежедневные стендапы?
Серьезно, зачем они нужны? К счастью у нас на работе их нет. И я правда не понимаю, зачем они нужны. То есть, в 1986 году, когда не было ни жиры, ни гита, в этих митингах был смысл. Но сейчас-то они зачем?
Что я сделал с последнего собрания? — смотрите в гите
Что я буду делать сегодня? — смотрите в жире
Какие сложности нужно будет решить? — смотрите в жире
Многие говорят, что на митингах можно решить проблемы взаимодействия. Те которые «Не могу выполнить свою задачу, пока Вася не запилит бэк/Коля не скинет макет/Саша не скинет контент» ну и тому подобные. ИМХО, при возникновении таких проблем, их надо сразу говорить менеджеру, чтоб это становилось его головной болью и он пинал всех причастных.
при возникновении таких проблем, их надо сразу говорить менеджеру, чтоб это становилось его головной болью
Суть в том, чтобы при возникновении проблем, они оперативно решались внутри команды, а не становились головной болью менеджера.
Кстати, именно поэтому в Scrum отсутствует такая роль (менеджер). Человек, у которого постоянно болит голова, никак не помогает выпуску продукта.
Спасибо за вопрос :)
Стендапы нужны, чтобы синхронизировать работу команды, не все изменения видны в гите, и не все заводится в джире, созвониться проще и быстрее. И не надо забывать о ламповости таких мероприятий, живое общение тоже нужно, оно помогает поддерживать командный дух, тем более если не вся команда работает в одном офисе / городе.
«при возникновении таких проблем, их надо сразу говорить менеджеру, чтоб это становилось его головной болью и он пинал всех причастных.» — у нас другой подход, стараемся все вопросы решать сами, без привлечения руководителей.
Стендапы нужны, чтобы синхронизировать работу команды, не все изменения видны в гите, и не все заводится в джире, созвониться проще и быстрее. И не надо забывать о ламповости таких мероприятий, живое общение тоже нужно, оно помогает поддерживать командный дух, тем более если не вся команда работает в одном офисе / городе.
«при возникновении таких проблем, их надо сразу говорить менеджеру, чтоб это становилось его головной болью и он пинал всех причастных.» — у нас другой подход, стараемся все вопросы решать сами, без привлечения руководителей.
Как я уже писал выше, под менеджером я подразумеваю product owner'a / project manager'a / хоть горшком назови, только в печь не клади
Как-то обидно из владельца продукта превратиться в менеджера.
Тогда ответ такой, если команда взяла задачу в спринт — ее реализация является «головной болью» всей команды, в т.ч. и продукт оунера.
Если что-то не готово по задаче, то зачем брать ее в спринт?
Тогда ответ такой, если команда взяла задачу в спринт — ее реализация является «головной болью» всей команды, в т.ч. и продукт оунера.
Если что-то не готово по задаче, то зачем брать ее в спринт?
А кто владелец продукта как не менеджер? Причём основной его ресурс — человеческий :)
Да с какое это стороны? Он не может руководить командой. Его дело проталкивать задачи. Это все, что он может. Команда решит что, когда и как будет делать. PO может что-то себе планировать исходя из опыта и капасити/велосити, но решать-то не моежт. Это отличие от менеджера, как мне видится.
Что значит «проталкивать» в вашем понимании? Убеждать команду «ну сделайте, пожалуйста, вот такую фичу, мы без неё деньги терям?»
Проталкивать и есть. Добиться попадания задачи в продукт. Приоритезация задачь не влияет напрямую на их попадание в спринт. Она может быть недостаточно описала или сложна в раелизации и может находиться в топе очень долго. Как PO добъется ее исполнения неизвестно. Вполне возможно он может поти на поводу у команды и отказаться от задачи. У нас такое бывает очень часто.
Не совсем так, владелец продукта только расставляет приоритеты и ожидает выполнения задачи. Менеджер же следит за выполнением задач в момент ее реализации и пытается держать под контролем разработку, что в скраме лежит на команде
Владелец продукта — владелец продукта, он генерируют задачи для улучшения своего продукта. Менеджер, в моем понимании, непосредственный руководитель сотрудников. Я таковым не являюсь.
Видимо, у вас какой-то другой, негативный пример работы с ПО.
Можете поделиться?
Видимо, у вас какой-то другой, негативный пример работы с ПО.
Можете поделиться?
Ну смотрите. Допустим мне надо запилить какую-то фичу на фронте. Эта фича завязана на бэк. Задача и по фронту и по бэку в этом спринте(по крайней мере везде где я работал, задачи по фронту и бэку делались в одном спринте, если это касалось одной фичи). Так вот я как фронт разработчик не должен ходить и тыкать палочкой бэка, мол давай сделай мне пожалуйста эндпоинт. Я должен просто прийти к тому, кто отвечает за выпуск продукта(неважно, как называется его должность) и сказать «смотри, я замокал данные и сделал свою часть, но бэк не готов и мне потребуется еще какое-то время, чтоб заменить мок на реальные данные и проверить, что все работает. у нас там на горизонте фичефриз, и если бэк будет готов вечером перед днем фичефриза, то я не успею подогнать фронт». И вот тогда этот человек должен сам ходить и пинать бэк, чтоб они поскорее сделали свою часть. И это я имел в виду, когда говорил, что это должно быть головной болью менеджера, а не разработчика. А смысл моего первоначального сообщения был в том, что о таких проблемах, когда они возникают, надо сразу говорить человеку, отвечающему за выпуск продукта, а не ждать митингов.
Я же говорю, что параллельно работаете. Делаете mock service. Все у вас есть бэкэнд. Делаете свою задачу спокойно. А бэк делается параллельно. Все в одном спринте. Никто никого не держит.
> мне потребуется еще какое-то время, чтоб заменить мок на реальные данные и проверить, что все работает. у нас там на горизонте фичефриз, и если бэк будет готов вечером перед днем фичефриза, то я не успею подогнать фронт»
Фронт на две недели? Очевидно, что нет, иначе неправильная разбивка. То есть задача закончилась в первую неделю и все можно было успеть.
Фичефриз не то, чтобы кодефриз?
Можно сколько угодно спорить. В спринт можно уложить и разработку и проверку. Бывают исключения. В 80% случаев можно все сделать.
Фичефриз не то, чтобы кодефриз?
Можно сколько угодно спорить. В спринт можно уложить и разработку и проверку. Бывают исключения. В 80% случаев можно все сделать.
В идеальном мире все было бы идеально. Ну или взаимодействие с бэком сводится к «утянуть гетом какой-нибудь объект», то тоже оно потом просто меняется с мока на реальные данные и норм. Ну или если на бэке сидят все супер-крутые программисты, а джунов и мидлов нет совсем. В реальности нередко сталкиваюсь с тем, что после замены мока на реальные данные, что-то отваливается и надо ждать пока бэк поправит. И бывает всё это делается не в одну итерацию.
Но вообще мы сейчас спорим не о том)) Изначально разговор был про то, что при возникновении любых проблем их надо решать сразу, а не ждать митингов.
Но вообще мы сейчас спорим не о том)) Изначально разговор был про то, что при возникновении любых проблем их надо решать сразу, а не ждать митингов.
. А смысл моего первоначального сообщения был в том, что о таких проблемах, когда они возникают, надо сразу говорить человеку, отвечающему за выпуск продукта, а не ждать митингов.
Мне кажется, это вообще не является проблемой.
Если бэк не успел что-то сделать, ты сказал, что у тебя все готово, и ты сможешь заменить фейковые данные на реальные, как только бэк доделает на своей стороне — молодец, именно это и можно озвучить на ежедневном стендапе.
А ты пока можешь сделать что-то еще полезное для себя или для продукта.
А если стендапы сводятся именно к статусам задач в джире или, в лучшем случае, к сделанным коммитам/PR?
На практике достаточно часто проблема, которая бы ушла в бекграунд, всплывает во время стендапа. Так как присутствует и внимательно слушает вся команда, то проблему можно оперативно купировать еще рано утром.
На практике достаточно часто проблема, которая бы ушла в бекграунд, всплывает во время стендапа.
Самый тупой карандаш заменяет самую острую память.
Не записали (в Jira/TFS/) Task/Bug/Issue — сами себе злые мудаки-буратины.
Метафора про карандаш хорошая.
Тупой карандаш это обмен информацией на дэйли.
Острая память — надежда, что все посмотрят твой комментарий в жире, правильно поймут формулировку задачи или не пропустят уведомление из жиры об очень важной штуке.
Тупой карандаш это обмен информацией на дэйли.
Острая память — надежда, что все посмотрят твой комментарий в жире, правильно поймут формулировку задачи или не пропустят уведомление из жиры об очень важной штуке.
Сркам вообще штука забавная. Он даёт несколько петель обратной связи чтобы корректировать движение по многим фронтам. Используется в условиях серьезной неопределенности для корректировки как самого продукта так и процессов. Неопределенность сложно и долго решать через жиру. Прямая коммуникация как минимум быстрее. Можно конечно нанять аналитика, который всё заранее просчитает и сам решит, но аналитики чаще всего не владеют всей полнотой умений для принятия единоличного решения да и ситуация меняется или появляется новая информация в том числе внутри спринта, которая влияет на ход работы.
Просто «фигачить код» в разработке с большой неопределенностью, к сожалению, не работает.
Просто «фигачить код» в разработке с большой неопределенностью, к сожалению, не работает.
Метафора про карандаш хорошая.
Тупой карандаш это обмен информацией на дэйли.
Из моего опыта — записать в Jira/TFS и потом на дейли это повторить закончив "… тикеты заведены можете читать" приводит куда к более продуктивной работе чем «есть проблемы X Y Z. Нет пока не записал», а через з дня это просто «выпадет из памяти» и дает граблями в лоб потом.
Нужно просто дрессировать на вырабатывание рефлекса «записал-> на дейли обозначил» (может быть даже ногами). Жестоко и не по «правилам и лучшим практикам» — но зато дешевле для бизнеса и заказчика.
Да на ретроспективе куда детальнее анализ с «бумажным» детальным источником.
Можно конечно нанять аналитика, который всё заранее просчитает и сам решит, но аналитики чаще всего не владеют всей полнотой умений для принятия единоличного решения да и ситуация меняется или появляется новая информация в том числе внутри спринта, которая влияет на ход работы
Задача аналитика не «решать», а предоставить в формализованном, согласованном между собой собой и непротиворечивом виде. Что бы коллегам дальше «по цепочке» не пришлось лезть «в первоисточники». Если это пришлось сделать — косяк аналитика. Его результат не пригоден к применению, как для программиста «код не компилируется».
Что я сделал с последнего собрания? — смотрите в гите
Это если только вы делаете код. Бывают также вещи типа "обяснил Пете и Саше структуру модуля X" — т.е. если команда работает как одно целое часто есть вклад в чужие коммиты и вообще в какие-то вещи, которые коммитами не являются.
Какие сложности нужно будет решить? — смотрите в жире
Какие сложности возникли — в принципе можно добавлять в жиру организационные баги, типа "петрович из соседнего отдела опять продолбал сроки" но я не видел, чтобы так делали. У вас так?
Многие говорят, что на митингах можно решить проблемы взаимодействия. Те которые «Не могу выполнить свою задачу, пока Вася не запилит бэк/Коля не скинет макет/Саша не скинет контент» ну и тому подобные. ИМХО, при возникновении таких проблем, их надо сразу говорить менеджеру, чтоб это становилось его головной болью и он пинал всех причастных.
У менеджера нет запланированных дел. Вместо того, чтобы послушать 10 минут статусы он должен весь день быть готовым к асинхронному вызову от других кодеров. Да, кодеры занимаются только коммитами, один кодер не может другому помочь узнать, кому написать, чтобы пропинали Васю.
Привет, scrum не панацея для всех отраслей разработки. Простой и жизненый пример зачем нам нужен утренний стендап — мы планировали катиться в прод, но пока распланированные задачи решались всплыли новые технические задачи критичные для выхода(их нет в бэклоге, жире, гите), после стендапа мы потратили еще 10 минут, распределили задачи и пошли работать. У каждого были свои технические проблемы, но понять что они каскадом накладываются у нас мы смогли только пообщавшись с утра, и как результат переиграть дальнейшие действия.
Для продуктов с дооолгими релизами это не так критично, ну так серебрянной пули то и не существует.
У нас команда сидит в одной комнате. Почти все слышно. Проблемы озвучиваются на всю комнату обычно. Стендап почти всегда избыточен.
Простите, а когда вы работаете, если вы целый день озвучиваете свои и прислушиваетесь к чужим проблемам?
Это один из принципов XP — создание информационного пространства, чтобы информация воспринималась между прочим — визуализация и сидение в одной комнате.
Опен спейс правда несколько избыточен для этого т.к. чаще всего в опен спейсе сидит куча людей, которые не имеют отношения к команде.
Но тем не менее — ежедневный стендап это петля обратной связи. Возможно конкретно вы всё и так знаете, но я не видел такой команды, которая могла бы синхронизироваться без дэйли. Находятся вопросы для прояснения, обсуждения и корректировки. Да, не каждый раз, но и времени дэйли занимает немного — не более 15 минут. Зато при должном исполнении даёт гарантию, что ничего не забыто. Потом при релизе никто не говорит — вот это забыли, вот это забыли и вон то сделали неправильно. Всё уже давно обсудили и решили на дэйли.
Опен спейс правда несколько избыточен для этого т.к. чаще всего в опен спейсе сидит куча людей, которые не имеют отношения к команде.
Но тем не менее — ежедневный стендап это петля обратной связи. Возможно конкретно вы всё и так знаете, но я не видел такой команды, которая могла бы синхронизироваться без дэйли. Находятся вопросы для прояснения, обсуждения и корректировки. Да, не каждый раз, но и времени дэйли занимает немного — не более 15 минут. Зато при должном исполнении даёт гарантию, что ничего не забыто. Потом при релизе никто не говорит — вот это забыли, вот это забыли и вон то сделали неправильно. Всё уже давно обсудили и решили на дэйли.
Если признать, что информированность всех членов команды важна, то ежедневный «стендап» реализует достижение этой цели. Во время такой встречи происходит обмен информацией.
Если команда обменивается информацией иначе, то ежедневные встречи могут быть избыточными.
А возможность «посмотреть в гите» была и остается, только ведь разница в том, посмотрю ли я или буду иметь возможность посмотреть. В нашей практике всегда было проще проактивно рассказать, что важного произошло за прошлый день, чем ожидать правильного самостоятельного понимания изменений от других членов команды и отвечать всем десять раз на один и тот же вопрос.
Если команда обменивается информацией иначе, то ежедневные встречи могут быть избыточными.
А возможность «посмотреть в гите» была и остается, только ведь разница в том, посмотрю ли я или буду иметь возможность посмотреть. В нашей практике всегда было проще проактивно рассказать, что важного произошло за прошлый день, чем ожидать правильного самостоятельного понимания изменений от других членов команды и отвечать всем десять раз на один и тот же вопрос.
Тут вон в 90 секунд и даже меньше предлагают ограничивать доклад одного человека. Такие доклады, имхо, выливаются в видимость информированности.
Прощу прощения, а в чем вопрос по существу? Мы говорим о цели подобного ежедневнного собрания. А подобные предложения пытаются заменить цель формой. Каждый член команды в своей работе прекрасно ощущает, хватает ли ему информации для его работы. Если такое состояние достигается за 90 секунд, то все сэкономили время.
Ну может цель обмен информацией, а может цель у большинства участников — исполнение ритуала ради «плюсиков», а информацию они добывают менее формализованными способами, чем заслушивание скороговорки из списка закрытых и ещё открытых тикетов от десятка человек.
А почему это должна быть именно скороговорка и именно по закрытым тикетам?
Потому что за 90 секунд описания тикетов иначе не прочитать. По закрытым и открытм, которые вчера закрыл и которые сегодня будешь пилить,
Почему нужно именно описание тикетов? Если их много, можно обобщить.
Заголовок спойлера
Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
— What did I do yesterday that helped the Development Team meet the Sprint Goal?
— What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
— The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.
The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
— What did I do yesterday that helped the Development Team meet the Sprint Goal?
— What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
— The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.
Вот и обобщают: я закрыл вчера 5 тасок, чем приблизил команду к цели спринта на 1%. сегодня планирую 3, но это будет 1,5%
Боюсь дэйли можно проводить хреново как, собственно, и описывать задачи. За 90 секунд можно сказать многое. Но вообще-то такого ограничения нет, есть только ограничение 15 минут на весь дэйли. Если возникают вопросы, которые надо обсудить детально — назначаются отдельные встречи с заинтересованными сторонами.
В таком случае, если человек готов к дейли и не размазывает сопли вместо того чтобы коротко и ясно изложить свой вклад, то 90 секунд бывает даже много.
Сделал задачи такие-то, планирую сделать такие-то, не понимаю такую-то задачу — Вася, давай обсудим. Петя, когда вы собираетесь обсуждать то-то? Меня подключите к обсуждению. Бывает и 30 секунд достаточно.
В таком случае, если человек готов к дейли и не размазывает сопли вместо того чтобы коротко и ясно изложить свой вклад, то 90 секунд бывает даже много.
Сделал задачи такие-то, планирую сделать такие-то, не понимаю такую-то задачу — Вася, давай обсудим. Петя, когда вы собираетесь обсуждать то-то? Меня подключите к обсуждению. Бывает и 30 секунд достаточно.
Очередной антипаттерн в Scrum.
Daily Scrum не про то, что вы пишете.
Большинство так и пребывают в счастливом (хотя нет, скорее, в несчастном, раз так всё бесит) неведении, для чего эта встреча.
Много писать не буду, так как обычно это всё равно что "метать бисер...", скажу только, что три вопроса, которые вы привели — это про обычный, как правило бессмысленный, ежедневный отчёт. С таким же успехом туда же можно про количество "чаёв и походов в туалет" добавить.
Daily Scrum — это про статус в части движения к цели спринта. А теперь спросите вокруг, кто понял о чём это. Кстати, в Scrum Guide и про цель спринта тоже написано.
Беда в том, что множество "Scrum-команд" (именно в кавычках) понятия не имеют, что такое Scrum Guide. А если и имеют понятие, то не поняли, или поняли, но не осознали написанного.
Пришёл сертифицированный скрам-мастер, сказал нам что надо делать и нарёк нас скрам- командой. Что не так? Он мошенник?
Ну я вот прочитал по его совету, чтобы лишних вопросов о том, что делать надо, не задавать. Объяснения «зачем» стал опускать быстро, поскольку реально ответ на него у меня есть: «начальнки сказал, что делаем скрам». А цель спринта у нас всегда одна была: выполнить все таски из лога спринта.
Ну я вот прочитал по его совету, чтобы лишних вопросов о том, что делать надо, не задавать. Объяснения «зачем» стал опускать быстро, поскольку реально ответ на него у меня есть: «начальнки сказал, что делаем скрам». А цель спринта у нас всегда одна была: выполнить все таски из лога спринта.
На самом деле весь скрам процесс преследует одну единственную задачу:
Переложить задачу давления на команду (чтобы народ не расслаблялся) на саму команду.
Все остальное — это красивые фразы и обертки. Ну и вещи которые при любом процессе хороши:
— планирование — полезно
— общение в команде — полезно
— регулярно проверять что продукт работает — полезно
Переложить задачу давления на команду (чтобы народ не расслаблялся) на саму команду.
Все остальное — это красивые фразы и обертки. Ну и вещи которые при любом процессе хороши:
— планирование — полезно
— общение в команде — полезно
— регулярно проверять что продукт работает — полезно
Можно обобщить — не просто давление, а менеджмент. Скрам стал «менеджментом для бедных», это то, что проще всего «изучить» (ну сколько в этом манифесте пунктов, штук 10 — 20 максимум), не имея за плечами ни компетенции, ни опыта.
Давление в скраме как раз взято под контроль. Команда берет в спринт то что считает, что успеет сделать. А дальше да — взяли на себя ответственность по объему спринта — обязаны сфокусировать усилия именно на нём. Причем именно сфокусировать усилия, а не непременно завершить. А с тем скрамом, что вы описали (с блэкджеком и давлением), увы, потрясающих успехов не достичь.
В решении этой проблемы помогает символическое поощрение от человека, который находит общий язык с командой. Однажды забавы ради я сказал, что буду отмечать в календаре тех, кто приходит на стендапы, и начал ставить плюсики.
Это поощрение?
Ключевое слово — «символическое».
Да, это скорее манипуляция :)
Стендап — это уже манипуляция
В чём манипуляция? Кого и через что стендапы заставляют менять обычное поведение?
Не прикидывайтесь. Разработчику приходится думать что он скажет на завтрашнем стендапе. Это тонкое психологическое давление с целью заставить людей работать. Если бы это было не так, разрабы охотно бы бежали на стендапы без всякого напоминания — разве плохо пятнадцать минут языком потрепать вместо работы?
Скрам манипулятивен по своему духу — с одной стороны изобразить заказчику что работа идет, с другой стороны подстегнуть разрабов.
Скрам манипулятивен по своему духу — с одной стороны изобразить заказчику что работа идет, с другой стороны подстегнуть разрабов.
Обычно достаточно за 5 минут до него распечатать по фильтра из джиры. Главное чтобы очереди не было на один принтер на 200 девов, у которых митинг в 11 :)/
упс, с телефона пишу. А в чём подстегивание-то?
Читаю статью (заодно вспоминаю своих коллег):
— часто разработчик считает что сделал меньше чем должен (результат неверной оценки задачи) и недоволен собой, а учитывая что разрабы люди обычно самолюбивые, необходимость публичного признания (хотя остальным до лампады его проблемы) рождает либо нежелание идти на стендап, либо переработки у особо ответственных.
Если на стендап-встречи не хочет идти вся команда…
я сказал, что буду отмечать в календаре тех, кто приходит на стендапы
— часто разработчик считает что сделал меньше чем должен (результат неверной оценки задачи) и недоволен собой, а учитывая что разрабы люди обычно самолюбивые, необходимость публичного признания (хотя остальным до лампады его проблемы) рождает либо нежелание идти на стендап, либо переработки у особо ответственных.
Частично так. Но по нашему опыту людям не стыдно сказать я вчера, сегодня и завтра буду делать то-то. И так три дня подряд, хотя всем ясно, что работы там на день. Скрам для стыдливых японцев из тойоты работать может.
Разработчику приходится думать что он скажет на завтрашнем стендапе.
Неужели разработчик не помнит, что он делал вчера, и что будет делать сегодня?
У нас ребята к стендапам не готовятся.
В «Scrum: Революционный метод управления проектами» есть все ответы.
Если решили внедрять скрам, то книжка обязательна к прочтению.
Если решили внедрять скрам, то книжка обязательна к прочтению.
Короткий спринт — это понижение КПД команды, скрам ради скрама. Три недели — оптимальный спринт. А если объединить скрам-мастера с тим-лидом?
Про скрам ради скрама — не соглашусь, если правильно выстроены процессы CI/CD вполне себе рабочая схема. Сами пока не пробовали, но у коллег из Альфа-банка неплохо получается.
Про объединение, тут надо понимать, что у тим лида тоже есть свои интересы, kpi и т.п. а скрам-мастер в первую очередь слуга самого процесса.
Про объединение, тут надо понимать, что у тим лида тоже есть свои интересы, kpi и т.п. а скрам-мастер в первую очередь слуга самого процесса.
Короткий спринт — это понижение КПД команды, скрам ради скрама.
А почему понижение КПД? Накладные расходы на спринт — это время для демо, ретроспективы и планирования. Время планирования и демо зависит от количества задач и поэтому при длинном спринте также увеличатся. Ретроспектива — зависит от сыгранности команды и вообще может пройти за 20 минут, когда у команды уже было 10-20 ретроспектив.
В любом случае — оптимальная длина спринта зависит от огромного количества факторов. По моему опыту, чаще командам комфортнее работать в спринте 2 недели. Но видел команды со спринтом и в 1 неделю, и в 3, и в 4. Если 4 и больше, то надо приглядеться, но вполне может быть, что так надо.
А если объединить скрам-мастера с тим-лидом?
Примерно в 70-80% случаев первым скрам-мастером становится экс-тим-лид. Ну или его правая рука, если сам тим-лид становится PO.
проблема, упоминания которой я почти нигде не нашел. Не нужно пытаться объединить скрам-мастера и product owner’а.
об этом чёрным по белому написано в Scrum guide
На сколько я помню, как основной минус объединения ролей там приводиться в пример, что продукт оунер более заинтересован в качестве, а скрам-мастер в сроках. У меня же физически не хватало времени (и/или опыта). Конфликта интересов не было.
Но отсутсвие времени на одно в связи занятостью другим — это и есть проявление конфликта интересов.
Канонический скрам-мастер отвечает за практики (скрам-практики) и рост команды (самоуправление).
Канонический продукт-оунер отвечает за успешность продукта. А что для этого нужно, качество, скорость, надежность, или что-то еще, в каждом конкретном случае по разному. Т.к. продукты разные и жизнь переменчива.
Канонический продукт-оунер отвечает за успешность продукта. А что для этого нужно, качество, скорость, надежность, или что-то еще, в каждом конкретном случае по разному. Т.к. продукты разные и жизнь переменчива.
Скрам, вероятно, есть противопожность семье в толстовской репрезентации: бОльшая часть проблем скрама идентична, и лишь счастье от него приводит компании к разным финансовым результатам.
У нас тоже вызывает недоумение необходимость стэндапов. В опенспейсе их необходимость мала. Но, подневольным нам, приходится ходить на них. Очень редко мы можем уложиться в пол-часа. И это бесит. Я думаю, что основная и единственная цель стэндапа — самоорганизация на основе совестливости команды, недостижима. Кому работать тот работает. Не скажу, что стэндапы не поднимают каких-то важных проблем или не дают быстрого решения тому, кто попал в тупик мысли, однако это редкость. Мне лично проще повернуться и громогласно попросить помощи, если надо. Может быть тут важно, что я не стесняюсь этого, но тут ведь персональное дело.
Вопрос необходимости скрама как стиля работы актуален для всех. Ведь это решение для бизнеса, а не для людей. Развитие и карьерные перспективы тут убиваются самим принципол полной и мгновенной заменимости любого члена команды.
Скрам сосвсем не способен решить вопрос контроля качества. Сазерленд прямо говорит о необходимости отсутствия команды QA. Наш очень долгий опыт показывает, что команда QA поднимает качество продукта на недостижимую юниттестами и code review высоту. То есть это преднамеренная потеря качества.
Как это ни глупо, но скрам рождает гораздо больше менеджмента, чем иерархическая структура. Возможно, это актуально только для интернациональных распределенных команд, но для нас это актуально.
Есть еще беда неприспособленности скрама к внешнему воздействию. Проблемы пользователей не укладываются в него напрямую. Решать проблему, возникшую у пользователя в текущем спринте нельзя, а неделя для кого-то может быть безумно долгим сроком.
Беды борьбы и управления бэклогом у всех, очевидно, одинаковы и набили аскомину. Исторически у нас сложилось игнорирование эпиков и формирования карманов из неактивных спринтов, что отвратительно, но есть. Возможно кто-то решает это эффективнее. Возможно для небольших проектов вроде клиент-банка такой беды и нет, но для большого прокукта с историей она остра.
Ну и самое смешное, что в конце спринта мы никогда не имеем рабочег продукта. Нам надобится дополнительный спринт на тестирование и залатывание програмных дыр в конце релизного цикла.
Ретроспектива еще одна забытая и бесполезная штука. Я не видел улучшений независящих от команды, наверное, никогда. По идее скрам-мастер должен решать остальное, но у нас его нет. Видимо, в этом=то вся беда и кроется.
Если подытожить, то я никак не вижу радости от внедрения скрама.
У нас тоже вызывает недоумение необходимость стэндапов. В опенспейсе их необходимость мала. Но, подневольным нам, приходится ходить на них. Очень редко мы можем уложиться в пол-часа. И это бесит. Я думаю, что основная и единственная цель стэндапа — самоорганизация на основе совестливости команды, недостижима. Кому работать тот работает. Не скажу, что стэндапы не поднимают каких-то важных проблем или не дают быстрого решения тому, кто попал в тупик мысли, однако это редкость. Мне лично проще повернуться и громогласно попросить помощи, если надо. Может быть тут важно, что я не стесняюсь этого, но тут ведь персональное дело.
Вопрос необходимости скрама как стиля работы актуален для всех. Ведь это решение для бизнеса, а не для людей. Развитие и карьерные перспективы тут убиваются самим принципол полной и мгновенной заменимости любого члена команды.
Скрам сосвсем не способен решить вопрос контроля качества. Сазерленд прямо говорит о необходимости отсутствия команды QA. Наш очень долгий опыт показывает, что команда QA поднимает качество продукта на недостижимую юниттестами и code review высоту. То есть это преднамеренная потеря качества.
Как это ни глупо, но скрам рождает гораздо больше менеджмента, чем иерархическая структура. Возможно, это актуально только для интернациональных распределенных команд, но для нас это актуально.
Есть еще беда неприспособленности скрама к внешнему воздействию. Проблемы пользователей не укладываются в него напрямую. Решать проблему, возникшую у пользователя в текущем спринте нельзя, а неделя для кого-то может быть безумно долгим сроком.
Беды борьбы и управления бэклогом у всех, очевидно, одинаковы и набили аскомину. Исторически у нас сложилось игнорирование эпиков и формирования карманов из неактивных спринтов, что отвратительно, но есть. Возможно кто-то решает это эффективнее. Возможно для небольших проектов вроде клиент-банка такой беды и нет, но для большого прокукта с историей она остра.
Ну и самое смешное, что в конце спринта мы никогда не имеем рабочег продукта. Нам надобится дополнительный спринт на тестирование и залатывание програмных дыр в конце релизного цикла.
Ретроспектива еще одна забытая и бесполезная штука. Я не видел улучшений независящих от команды, наверное, никогда. По идее скрам-мастер должен решать остальное, но у нас его нет. Видимо, в этом=то вся беда и кроется.
Если подытожить, то я никак не вижу радости от внедрения скрама.
Очень редко мы можем уложиться в пол-часа.
Из-за чего? Нет ли какого-то несоответствия размера команды или повестки митинга Гайду?
Решать проблему, возникшую у пользователя в текущем спринте нельзя
Вы можете процитировать гайд на эту тему?
У нас нескрамовская команда в 13 человек. Животрепещущие темы обсуждаются сразу же.
Гайдов у нас нет. Причина проста — берндаун чарт полезет вверх. Скоуп спринта не должен меняться для нас посулат. Менеджерский постулат, выведенный из слушания Сазерленда. Так уж получилось, что все его слушали как-то особенно и услышали совершенно разное. Каких-то материальных потверждений этого выслушивания они не привезли. Ну колоды карт не в счет.
Гайдов у нас нет. Причина проста — берндаун чарт полезет вверх. Скоуп спринта не должен меняться для нас посулат. Менеджерский постулат, выведенный из слушания Сазерленда. Так уж получилось, что все его слушали как-то особенно и услышали совершенно разное. Каких-то материальных потверждений этого выслушивания они не привезли. Ну колоды карт не в счет.
Я думал больше проблем чем у нас не бывает :)
Подскажите, пожалуйста, зачем и как у вас началось внедрение Скрама?
Кажется, что основная проблема в том, что это было решение сверху, сотрудники его не приняли, а внедрение проходило без соответствующего сопровождения, в связи с чем накопилось много проблем, которые никто не решает и решать не хочет.
Я могу ошибаться, но сейчас картина выглядит именно так.
Подскажите, пожалуйста, зачем и как у вас началось внедрение Скрама?
Кажется, что основная проблема в том, что это было решение сверху, сотрудники его не приняли, а внедрение проходило без соответствующего сопровождения, в связи с чем накопилось много проблем, которые никто не решает и решать не хочет.
Я могу ошибаться, но сейчас картина выглядит именно так.
А зачем сотрудникам (читай — разработчикам) скрам или ещё что другое? Моральное удовлетворение от уменьшения тайм-ту-маркет?
Я просто не могу себе представить сложившейся команды, которая в один день проснулась и попросила скрама. Людям не нужен скрам — он обесценивает их и препятствует карьерному росту. Скрам нужен компании и это разные вещи. Можно было бы коротко ответить да сверху, но это слишком банально.
Сопровождение скрама в наших реалиях невозможно просто теоретически: нас и PO разделяют континеты. Раньше были страны, но теперь решили улучшить ситуацию, по аналогии увеличения любви к теще с увеличением расстояния до нее, видимо. Скрам у нас песня очень забавная. Он нам с проектом в наследство достался. А проблемы для скрама решать никто и не должен. Основная идея в том, что скрам саморешающая затея. У нас скрам мастера-то нет. А тут проблемы внедрения… Ну главное отрапортовать, что скрамим со всей силы и демы. А там хоть не рассветай. Интересно, что за последние два года количество посещающих демы уменьшилось в несколько раз. Маркетинг с них просто исчез. При этом продажи выросли и довольно значительно. Что-то не так с этим скрамом в наших реалиях…
Сопровождение скрама в наших реалиях невозможно просто теоретически: нас и PO разделяют континеты. Раньше были страны, но теперь решили улучшить ситуацию, по аналогии увеличения любви к теще с увеличением расстояния до нее, видимо. Скрам у нас песня очень забавная. Он нам с проектом в наследство достался. А проблемы для скрама решать никто и не должен. Основная идея в том, что скрам саморешающая затея. У нас скрам мастера-то нет. А тут проблемы внедрения… Ну главное отрапортовать, что скрамим со всей силы и демы. А там хоть не рассветай. Интересно, что за последние два года количество посещающих демы уменьшилось в несколько раз. Маркетинг с них просто исчез. При этом продажи выросли и довольно значительно. Что-то не так с этим скрамом в наших реалиях…
Очень редко мы можем уложиться в пол-часа. И это бесит.
Что сказали или предложили остальные участники команды на ретроспективе? Если вас 13 человек (это многовато, но терпимо), то пробовали просто взять и договориться о лимите в 90 секунд на каждого?
Стендап не про совесть. А про то, что если условный Петя делает задачу третий день, а она оценена в 1 день, то на невыполненный спринт попадает не Петя, а команда. Стендам помогает не превратить эти 3 дня в 5 или 7. Тут вопрос не в том, стесняется Петя или нет. Может он и правда верит, что сегодня всё доделает (и так второй месяц :) ), тут вопрос, чтобы команда увидела риск до провала.
Есть еще беда неприспособленности скрама к внешнему воздействию. Проблемы пользователей не укладываются в него напрямую. Решать проблему, возникшую у пользователя в текущем спринте нельзя, а неделя для кого-то может быть безумно долгим сроком.
Ну так договоритесь с PO о правилах, как он может emergency в текущий спринт вставлять. Какие критерии, что задача emergency, а не просто приоритетная. Как договориться о том, какие задачи эта emergency пододвигает. Договоритесь о том, что "цена" впихивания в спринт — это рефакторинг или устранение техдолга в следующем с нижней границей оценки 30-50%.
Что-то сильно не то вы делаете, судя по симптомам.
Конечно у нас установлены лимиты :) Конечно их не соблюдают. У нас нет скрам мастера и следить за регламентом некому. Выбранному следящему остается только кричать. Но он устает от этого день на третий и мы возвращаемся к началу.
Проблема срыва сроков не настолько важна. Нет ни одной фичи без которой продукт нельзя выпусить. Поэтому постоянно застревающий человем остается с фичей на два-три релиза и копается с ней. Мы не можем его уволить. Сослать в другую команду тоже не можем. Так и живем.
У нас на члена команды по менеджеру в абсолютном выражении. Самый бесправный из них PO. У нас 12 часов разницы и невозможность его влиять на процесс. Он приоритезатор бэклога в лучшем случае. Иногда просто никто. Когда совсем деградирует мы его игнорируем. Его меняют и так по кругу.
Проблема срыва сроков не настолько важна. Нет ни одной фичи без которой продукт нельзя выпусить. Поэтому постоянно застревающий человем остается с фичей на два-три релиза и копается с ней. Мы не можем его уволить. Сослать в другую команду тоже не можем. Так и живем.
У нас на члена команды по менеджеру в абсолютном выражении. Самый бесправный из них PO. У нас 12 часов разницы и невозможность его влиять на процесс. Он приоритезатор бэклога в лучшем случае. Иногда просто никто. Когда совсем деградирует мы его игнорируем. Его меняют и так по кругу.
по Scrum пока что работают только разработчики ДБО
Не только :)
Вообще, я бы даже рекомендовал по возможности уменьшать длительность спринта с двух недель до одной.
А вы ставите релиз после каждого спринта?
Почитав комменты выше, складывается впечатление, что скрам зло и вообще… Так никто и не говорит, что скрам — это панацея от всех бед и проблем.
Наша команда работает по чистому скраму и вполне успешно. Соседние команды на этом же проекте работают кто на чистом канбане, кто исползует смесь канбана и скрама. Кому как удобно и кому как лучше подходит.
У вас от использования скрама одни проблемы? Тут важно понять, что это за проблемы и решаются ли они в рамках скрама. Может, вам лучше от него отказаться и тспользовать другой подход? Такое возможно.
Если у вас очень долгие стендапы — это то, что можно решить не отказываясь от скрама. У нас такое было тоже, но сейчас укладываемся в 15 минут. То, что помогло нам — небольшая подготовка к стендапу, просто вспомни, что ты делал, что планируешь. Можно просто открыть свой рабочий to-do лист и по нему быстро сориентроваться. Если надо что-то обсудить — просим остаться кому надо на дополнительные 10 минут, а остальные могут расходиться работать.
Я не защищаю скрам, я не знаю, какая именно у вас там ситуация (это к тем, кто негативно отзывался). Просто не стоит категорически делить на чёрное и белое. Отладить процесс, тем более новый и незнакомый — это дело времени и упорства. Сразу никогда не получится получить хорошие результаты. Но проанализировать, что не так и как можно это решить — вот это более правильный подход, как по мне.
Наша команда работает по чистому скраму и вполне успешно. Соседние команды на этом же проекте работают кто на чистом канбане, кто исползует смесь канбана и скрама. Кому как удобно и кому как лучше подходит.
У вас от использования скрама одни проблемы? Тут важно понять, что это за проблемы и решаются ли они в рамках скрама. Может, вам лучше от него отказаться и тспользовать другой подход? Такое возможно.
Если у вас очень долгие стендапы — это то, что можно решить не отказываясь от скрама. У нас такое было тоже, но сейчас укладываемся в 15 минут. То, что помогло нам — небольшая подготовка к стендапу, просто вспомни, что ты делал, что планируешь. Можно просто открыть свой рабочий to-do лист и по нему быстро сориентроваться. Если надо что-то обсудить — просим остаться кому надо на дополнительные 10 минут, а остальные могут расходиться работать.
Я не защищаю скрам, я не знаю, какая именно у вас там ситуация (это к тем, кто негативно отзывался). Просто не стоит категорически делить на чёрное и белое. Отладить процесс, тем более новый и незнакомый — это дело времени и упорства. Сразу никогда не получится получить хорошие результаты. Но проанализировать, что не так и как можно это решить — вот это более правильный подход, как по мне.
Какую ценность даёт скрам для обычных разработчиков? Максимум, в теории, — посылать всех с «тут быстро и срочно» к по и см. Так тот же водопад ещё больше возможностей для этого даёт. Скрам и прочий формальный аджайл — это, прежде всего, про минимизацию зря выполненой работы.
Как итеративный процесс может привести к минимуму лишней работы? У вас должен быть законченный продкут каждый спринт. Вы выполните работу под доделке каждый раз переделывая неудачные с точки зрения PO реализации. Я действительно не вижу как тут можно получить выгоду.
Корпоративные выгоды я вижу легко, но мне это безразлично.
Корпоративные выгоды я вижу легко, но мне это безразлично.
Предполагается, что доставляя готовый продукт короткими итерациями, и получая обратную связь, можно лучше и точнее понимать, а что нужно сделать для улучшения и это улучшение будет реально полезно.
В противоположность тому, когда итерации длинные, и обратной связи нет, соответственно прогноз полезности будущих улучшений хуже.
В противоположность тому, когда итерации длинные, и обратной связи нет, соответственно прогноз полезности будущих улучшений хуже.
Накладные расходы на доделку до готового продукта это никак не уменьшает. По сути скрам предполагает прототипирование на готовом продукте.
Продукты бывают разные.
Есть те, которые можно регулярно улучшать, и эти улучшения сразу становятся доступны пользователям. Слушая пользователей, можно понимать куда дальше двигаться в улучшении продукта.
И есть другие продукты, которые сложно регулярно улучшать, и сложно доставлять эти изменения до пользователей.
Очевидно во втором случае, выгоды от agile-подходов не очевидны.
Есть те, которые можно регулярно улучшать, и эти улучшения сразу становятся доступны пользователям. Слушая пользователей, можно понимать куда дальше двигаться в улучшении продукта.
И есть другие продукты, которые сложно регулярно улучшать, и сложно доставлять эти изменения до пользователей.
Очевидно во втором случае, выгоды от agile-подходов не очевидны.
Не знаю как у кого. У нас PO должен повертеть продукт с заказанной функциональностью. Потом потребует поменять. И каждое требование нельзя предтставить в виде полуработающего прототипа или слепить на коленке — протукт должен быть готовым. Вот те накладные расходы скрама про которые я говорю. Пользователь тут безразличен. Это дело PO слушать его или нет и чаще всего нет в виду отсутствия прямой связи PO-пользователь. PO-маркетинг или PO-support вполне работающий диалог, а конечный пользователь недоступен… Ну у нас так.
Agile-подходы не универсальны. Запустить ракету на Луну по agile не получится. Да даже не ракету, гаджет какой-нибудь изготовить в товарных количествах и продать.
Если есть регулярная обратная связь от конечных пользователей, то слушая ее, можно попробовать не делать лишнего. Это «про минимизацию зря выполненой работы».
Если у вас конечный пользователь недоступен, то регулярная доставка улучшений становится несколько выхолощенной. А если уж совсем формализоваться, то ее (регулярной доставки) и нету.
зы
это не означает, что у вас все плохо, и вы не умеете работать.
разные продукты — разные практики.
Если есть регулярная обратная связь от конечных пользователей, то слушая ее, можно попробовать не делать лишнего. Это «про минимизацию зря выполненой работы».
Если у вас конечный пользователь недоступен, то регулярная доставка улучшений становится несколько выхолощенной. А если уж совсем формализоваться, то ее (регулярной доставки) и нету.
зы
это не означает, что у вас все плохо, и вы не умеете работать.
разные продукты — разные практики.
Agile-подходы не универсальны.
Да, они хороши для небольших команд и немастабных задач.
Запустить ракету на Луну по agile не получится.
И египетские пирамиды тоже не соберёшь. Но каждая из команд, которая участвует в процессе вполне может работать по гибким методологиям.
Вот мне очень понравилась книга «Scram. Революционный метод управления проектами». Само название, конечно очень кричащее, но книга хорошая. Из неё я сделала такой вывод. Джеф Сазерленд в своей работе сталкивался с определёнными проблемами (организации проекта и процессов). Чтобы их решить, он применил определённые методики. Собрав эти решения воедино, он назвал это «Scrum».
Очевидно, эти решения проблем не помогут вам, если у вас другие проблемы.
Если вам надо забить гвоздь и вы берёте картонный лист для этого, то это не значит, что картон плохой. Каждой задаче свой инструмент. Вот и всё.
Очевидно, эти решения проблем не помогут вам, если у вас другие проблемы.
Если вам надо забить гвоздь и вы берёте картонный лист для этого, то это не значит, что картон плохой. Каждой задаче свой инструмент. Вот и всё.
Эм… Тойота как-то выпускает машины аджайлом, говорят. Может врут…
Что касается обратных связей, то это инструмент PO. Это никак не связано с процессом разработки. В далекие нулевые годы мы разрабатывали продукт исходя из запросов пользоввателей без аджайла. Очень редко мы переделывали что-то в те далеки благодатные времена. А с аджайлом делать одно и тоже несколько раз приходилось. Дурные понятия UX и дизайн в целом портят кровь…
Что касается умения работать, то меряться тут нет смысла. Продукт наш общеизвестен и приносит очень хорошую прибыль хозяевам. Это единственный важный критерий, думается. Мне безразлична оценка эффективности аджайла в компании. Я против него.
Что касается обратных связей, то это инструмент PO. Это никак не связано с процессом разработки. В далекие нулевые годы мы разрабатывали продукт исходя из запросов пользоввателей без аджайла. Очень редко мы переделывали что-то в те далеки благодатные времена. А с аджайлом делать одно и тоже несколько раз приходилось. Дурные понятия UX и дизайн в целом портят кровь…
Что касается умения работать, то меряться тут нет смысла. Продукт наш общеизвестен и приносит очень хорошую прибыль хозяевам. Это единственный важный критерий, думается. Мне безразлична оценка эффективности аджайла в компании. Я против него.
Как раз потому что итеративный. Быстрая обратная связь на неудачные решения. Не пилим фичу из 50 экранов 2 года, а потом оказывается что никому она не нужна, а быстро делаем 5 экранов, запускаем и смотрим результаты, может и не надо остальные 45 делать.
Ну конкретно в скраме еще много внимания уделяется команде, которая непрерывно качественно растет (во всех аспектах — люди, процессы, инструменты, культура и т.д.)
Я не могу себе представить чистого скрама в жизни живущего продукта. Эскалейшены и прочие срочные беды всегда его нарушают. Возможно, что в среде аутсорса или подобных независимых команд, он может существовать. Но в жизни продукта после 1.2 я его представить не могу.
Скрам хорош для экстравертов. Я мало видел программистов экстравертов. Скрам нужен менеджменту как средство уменьшения рисков. А зачем он человеку я представить не могу.
Скрам хорош для экстравертов. Я мало видел программистов экстравертов. Скрам нужен менеджменту как средство уменьшения рисков. А зачем он человеку я представить не могу.
Предполагается, что вам (разработчику) он (скрам) нужен, потому что вы получаете кайф не от написания крутого кода, а от того что сделали мир чуточку лучше вместе с чуваками из вашей команды. «Сделали мир чуточку лучше» — в смысле есть реальные люди, которые реально тащатся от того, что пользуются вашим продуктом. И эта польза не какая-то виртуальная польза (типа была красная кнопочка, а стала синяя, ненавижу красный цвет), а реальная (типа экономлю свое время, трачу меньше денег, стал больше зарабатывать, и т.д.)
А как быть с позицией «чем тратить время на все эти ритуалы, я лучше фичу запилю или баг пофикшу, чтобы людям жить стало легче»?
Типичный ит-шный подход.
Вы мне скажите чо залабать, а я залабаю. Зачем, почему, меня не волнует.
Он, этот подход, не хороший и не плохой.
Но иногда приходит осознание, что чем меньше между конечным пользователем и реальным реализатором промежуточных звеньев, тем лучше. (быстрее, точнее, дешевле и т.д.) Собственно скрам про то, как это (продуктовую направленность всех активностей команды) прошить в ДНК членов команды. Чтобы в принципе не было фраз «Вы мне скажите чо залабать, а я залабаю».
Вы мне скажите чо залабать, а я залабаю. Зачем, почему, меня не волнует.
Он, этот подход, не хороший и не плохой.
Но иногда приходит осознание, что чем меньше между конечным пользователем и реальным реализатором промежуточных звеньев, тем лучше. (быстрее, точнее, дешевле и т.д.) Собственно скрам про то, как это (продуктовую направленность всех активностей команды) прошить в ДНК членов команды. Чтобы в принципе не было фраз «Вы мне скажите чо залабать, а я залабаю».
От скрама количество звеньев не меняется, а может даже увеличивается (стейкхолдеры напрямую к разработчикам не обращаются, если надо что-то срочно запилить).
И дело не в «Вы мне скажите чо залабать, а я залабаю», а в «чтоя сделал, что я собираюсь делать и какие проблемы — можете в джире прочитать, а я пилить буду»
И дело не в «Вы мне скажите чо залабать, а я залабаю», а в «чтоя сделал, что я собираюсь делать и какие проблемы — можете в джире прочитать, а я пилить буду»
Не единым стейкхолдером жив человек.
Некоторое время назад канонический процесс разработки выглядел как-то так. Хотелки в том или ином виде прилетают к Аналитикам. Аналитики рождают ТЗ. Разработчики на основании ТЗ ваяют поделку. Тестировщики на основании ТЗ и поделки, проводят тестирование. Админы на основании инструкции к накату и поделки, выкатывают в прод. Каждый из этапов формализован, расчерчен SLA-ем, создается и сохраняется куча артефактов. На любом из этапов можно вернуться назад на любой предыдущий.
Скрам же утверждает, что ни Аналитиков, ни Разработчиков, и т.д. нет. Есть только команда, саморазвивающаяся и кроссфункциональная, которая отвечает за продукт от начала до конца. В рамках процесса делаем только то, что реально кому-то приносит пользу. В общем это «про минимизацию зря выполненой работы». Количество звеньев существенно уменьшается.
Про «можете в джире прочитать». Это всего лишь индикатор зрелости спеца (и в какой-то мере его окружения). Раз так говорит, значит еще не понимает что такое команда и почему 1 + 1 > 2.
Некоторое время назад канонический процесс разработки выглядел как-то так. Хотелки в том или ином виде прилетают к Аналитикам. Аналитики рождают ТЗ. Разработчики на основании ТЗ ваяют поделку. Тестировщики на основании ТЗ и поделки, проводят тестирование. Админы на основании инструкции к накату и поделки, выкатывают в прод. Каждый из этапов формализован, расчерчен SLA-ем, создается и сохраняется куча артефактов. На любом из этапов можно вернуться назад на любой предыдущий.
Скрам же утверждает, что ни Аналитиков, ни Разработчиков, и т.д. нет. Есть только команда, саморазвивающаяся и кроссфункциональная, которая отвечает за продукт от начала до конца. В рамках процесса делаем только то, что реально кому-то приносит пользу. В общем это «про минимизацию зря выполненой работы». Количество звеньев существенно уменьшается.
Про «можете в джире прочитать». Это всего лишь индикатор зрелости спеца (и в какой-то мере его окружения). Раз так говорит, значит еще не понимает что такое команда и почему 1 + 1 > 2.
Или просто не понимает, чем ежедневные митинги, сильно ограниченные по времени и содержанию, лучше других способов информирования, шаринга знаний. Я вот только что тест прошёл на свои каналы восприятия, который показал, что лучше всего мне читать, потом смотреть "картинки" типа графиков и диаграмм, а только потом слушать.
Это для студентов хорошо. В качестве самореализации. Для меня это не важно. Я делал продкуты, которыми пользовались и их закрывали. И писал дрянь, которая успешно продается по сию пору.
Вид процесса производства продукта в любом случае никак не изменяет удовольствие/стыд от произведенного.
Наш цикл выдачи продукта конечному пользователю — квартал. Разные команды выпускают разные продукты разными процессами примерно в эти сроки.
То есть не вижу никакой радости аджайла опять…
Вид процесса производства продукта в любом случае никак не изменяет удовольствие/стыд от произведенного.
Наш цикл выдачи продукта конечному пользователю — квартал. Разные команды выпускают разные продукты разными процессами примерно в эти сроки.
То есть не вижу никакой радости аджайла опять…
Еще один типично ит-шный подход.
Я сделал коричневую субстанцию, но она отлично продается. Мне за это стыдно.
И я сделал конфетку, но она не продается. Реально классная штука.
Опять же, это не хорошо, не плохо.
Так устроены ит-шники
Просто в реальном мире, если твоей гениальной поделкой никто не пользуется, то это поделка бесполезна. Если согласиться с этим тезисом, то жизнь сильно упроститься.
Я сделал коричневую субстанцию, но она отлично продается. Мне за это стыдно.
И я сделал конфетку, но она не продается. Реально классная штука.
Опять же, это не хорошо, не плохо.
Так устроены ит-шники
Просто в реальном мире, если твоей гениальной поделкой никто не пользуется, то это поделка бесполезна. Если согласиться с этим тезисом, то жизнь сильно упроститься.
Никак не могу понять — какое место занимает тестирование в спринте?
Если спринт завершен без тестирования, то не факт что функциональность рабочая, т е фактически спринт не может считаться завершенным без тестирования. Если включить тестирование в спринт, то сроки почти наверняка погорят из выявленных ошибок (допустим уровня critical).
Если спринт завершен без тестирования, то не факт что функциональность рабочая, т е фактически спринт не может считаться завершенным без тестирования. Если включить тестирование в спринт, то сроки почти наверняка погорят из выявленных ошибок (допустим уровня critical).
Никак не могу понять — какое место занимает тестирование в спринте?
То, что задача протестирована — один из критериев Definition of done. Не протестированная задача не считается закрытой.
Не протестированная задача не считается закрытой.
— ну и сколько отводится на тестирование и устранение дефектов? Дефект вещь не предсказуемая способная легко поломать спринт. А разработчик норовит тянуть завершение задачи до конца спринта. Из Вашего ответа я не сумел понять сколько времени закладывать в каждую задачу на тестирование. Может есть какие то рекомендации, практики?
Так же как на разработку. В смысле не столько же, а сначала от балды, с последующим анализом выявленных багов. Багов в оценке и качестве тестирования.
И что, тестировщики присутствуют на планировании спринта? Ни разу не видел. И насчет «балды» поражен. А как же «покер планирования»?
В итоге хочу узнать: в Вашей версии планирования итерации какой процент времени отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?
В итоге хочу узнать: в Вашей версии планирования итерации какой процент времени отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?
Тестировщики присутсвуют на планировании спринта, конечно, если являются частью скрам-команды. Но возможна и организация тестирования в виде «внешнего сервиса» скрам-команды. В обоих случаях нет никаких принципиальных проблем в планировании (и постепенном уточнении в последующих спринтах) затрат на тестирование.
если являются частью скрам-команды
— а если не являются, то команда пишет код без ошибок?
возможна и организация тестирования в виде «внешнего сервиса» скрам-команды
— что позволяет разработчикам закрывать спринты с нетестированным кодом, т е кодом который возможно вообще не работает или работает неверно.
нет никаких принципиальных проблем в планировании
— пожалуйста, подскажите: какой процент времени итерации в Вашей команде отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?
а если не являются, то команда пишет код без ошибок?
Если не являются, то роль тестирования на себя берут либо сами программисты, либо внешний сервис, как я и сказал.
что позволяет разработчикам закрывать спринты с нетестированным кодом, т е кодом который возможно вообще не работает или работает неверно.
У каждой истории утверждается т.н. definition of down («условия приёмки»), в некоторых случаях это действительно бывают условия, не включающие тестирование напрограммированного, но чаще всего, конечно, кейсы тестирования являются частью содержимого задачи (и рождаются на «груминге» в ходе уточнения требований к пользовтаельским историям и декомпозирования их на технические таски).
какой процент времени итерации в Вашей команде отводится на тестирование
Определяется для каждой задачи отедельно.
и за сколько дней до конца итерации разработчики должны закончить работу
Тестировщикам и программистам по возможности должно быть всегда, чем заняться на спринте. Включая задачи «разогрева» пользовательских историй для следующих спринтов (декомпозиции или даже намёток кода). Считать спринт забегом, подготовка к которому не является его частью или после которого хоть трава не расти — не совсем о скраме, скрам — это про итеративный, повторяющийся процесс, и на каждой следующей итерации всегда есть наработки из прошлого. И тестеры, конечно, не сидят и не ждут, пока программисты закончат свою работу, чтобы начинать тестировать, у них уже хватает и без этого тестирования (недоисправленные и недодеплоенные задачи из прошлого спринта, превратившиеся в новые задачи текущего, например, или другие «короткие» для кодирования задачи).
по возможности должно быть всегда
— похоже речь идет о теории, а не о практике (верный симптом наличие общих фраз и отсутствие каких то чисел). Как практик я знаю, что слабое место скрама — это сдача в конце итерации не протестированных фич (самотестирование разработчиком это чепуха), которые потом возвращаются в следующую итерацию. Заказчику при этом бывает сложно объяснить, почему мы опять делаем то, что ему уже показывали как сделанное.
У каждой истории утверждается т.н. definition of down («условия приёмки»)
— по моему опыту необходимость и глубина тестирования, в первую очередь связаны с личностью разработчика пилившего фичу. Про кого то я знаю что его код не потребуется править, про кого то могу сказать что почти наверняка функционал не реализован так как надо. Конечно что то зависит и от сложности задачи, но основной фактор это личность разработчика. Опытный тимлид учитывает это в разработке. Но в любом случае это плохо вписывается в теорию скрама. Во всяком случае я ясного ответа о том как планировать тестирование в итерацию не получил.
верный симптом наличие общих фраз и отсутствие каких то чисел
Думаю, что наши с вами команды, задачи, ограничения спринтов, а так же участие в скрам-группах тестеров (и других некроссфункциональных единиц — например, Java Developer + PHP developer) будут превращать любые данные мной цифры для вас в случайный шум, у вас всё естественно будет совсем иначе. (Да, я тоже считаю нашу практику не совсем скрамной, и у нас и без этого хватает отличий от «настоящего» скрама. И, уверен, у вас тоже не «идеальный сферический» скрам, ибо идеальные сферы на практике обречены превращаться в катышки опыта).
по моему опыту необходимость и глубина тестирования, в первую очередь связаны с личностью разработчика пилившего фичу
Вот и у вас не скрам, похоже, который слегка против перекосов компетенций в команде (у вас, видимо, джуны с сеньорами). Вообще, тестирование, зависимое от личности разработчика — очень плохая практика безотносительно скрама.
Во всяком случае я ясного ответа о том как планировать тестирование в итерацию не получил.
Думаю, в режиме «ага, удивите меня» вы вряд ли сможете найти такое решение. Оно вытекает из личной практики и организации процессов (скрам не освобождает от необходимости применять когнитивные усилия по ведению проекта).
Зачем писать общие фразы? Вопрос о том как планировать тестирование в итерацию. Скрамомерством заниматься не интересно.
как планировать тестирование в итерацию
«Какие юзерсториесы должны быть воспроизводимы на демо в этой задаче? Какие аспекты, какие критерии качества выполнения этой задачи важны стекхолдерам, что именно в этой юзерстории создаёт вэлью, ценность для пользователей, добавляет конкурентное преимущество продукту? Какие шаги нужны для воспроизведения юзерстории от начала до конца? Какое поведение тестируемого продукта ожидается, как его залогировать/идентифицировать/измерить?» — причём, все эти вопросы задаются и уточняются на всём жизненном цикле задачи, сначала при грумминге со стороны бизнеса продуктовнером для продуктового бэклога, потом груммингом программистами и тестировщиками для бэклога спринта. Да, сами тестировщики ещё при планировании реализации могут в силу своего проф-опыта видеть «уязвимые» места в пользовательских сценариях, корректировать их, предлагать свои варианты, в этом их польза на грумминге ровно такая же, как остальных участников — вложить в описание задачи до её взятия в работу максимально экспертной инфы о потенциальных подводных камнях и рисках со стороны каждого этапа реализации (в том числе и прохождения тестирования). И точно так же каждый участник помогает оценить задачу со своей стороны, а решение расхождений в оценках сложности задачи в ходе скрам-покера помогает каждому узнать о сложностях «чужих» (не своей специализации) этапов реализации «своей» (в скраме всё — «наше» :)) задачи.
Да, перечитал всё написанное мной выше — читается как анекдот. Идеальные процессы, идеальные люди, и всё это обмазано смузи и коворкингами. А на самом деле — да, просто собирается толпа людей, спорят о процессах и ролях, апеллируя ко всем заветам скрама, забывая про спринт, продуктовнера и свои профессии, несогласованно между собой создают в ишью-трекере кучу противоречивых задач (оформляя их кто во что горазд), назначают кучу встреч и кучей других способов играют в офис. При этом скрам-коучи обещают, что вот-вот шит-шторминг стихнет, и мы (в пике Балмера, видимо) сразу покажем 100500% эффективности. Это версия для любителей депрессивных интерпретаций.
Если у вас есть тестировщики (и прочие выделенные «части скрам-команды»), то у вас не скрам. Под-команды явно запрещены в скрам-гайде. Тестированием должны заниматься сами разработчики, либо внешние сервисы.
Если в критерии завершенности задачи входит тестирование, а на планировании тестировщиков нет, то это что угодно, но не скрам, имхо.
Вы говорите максимы, но не отвечаете на вопросы. Речь идет о каком то теоретическом скраме? Ведь не трудно ответить на вопрос, вспомнив как прошло прошлое планирование: «в Вашей версии планирования итерации какой процент времени отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?»
Речь идет о каком то теоретическом скраме?
У меня о практическом.
Ведь не трудно ответить на вопрос, вспомнив как прошло прошлое планирование: «в Вашей версии планирования итерации какой процент времени отводится на тестирование
Какой-то процент времени не выделяется. Тестировщики вместе со всеми участвуют в планировании и повышают сторипойнты на задачу если её сложно протестировать.
за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?
Спринты двухнедельные, как правило задачу надо сдать в начале второй недели, чтобы её протестировали, вернули дефекты, поправили их и закрыли. Пока ведётся разработка, тестировщики как правило пишут план тестирования.
Спринты двухнедельные, как правило задачу надо сдать в начале второй недели, чтобы её протестировали, вернули дефекты, поправили их и закрыли.
— это понятно и звучит логично, но возникает вопрос: чем занимаются разработчики вторую неделю, пока тестировщики тестируют фичу? Допустим все получилось сразу и дефектов нет. Получится что разрабы пинают балду до конца итерации или в итерацию начинается подброс не запланированных задач.
Там где был скрам в моей практике или что-то к нему близкое, единственное время было — это время спринта. Ни сколько времени займёт решение задачи, ни сколько процентов в этом решении займёт тестировании мы не оценивали. Два основных подхода: задачу оценивают (в сторипоинтах) разработчик(и) и тестировщик вместе и на тестирование отдельная задача. Так что вопросов «сколько процентов» или «за сколько дней до конца» не возникает.
Никак не могу согласиться. Зачем разработчику тянуть с задачей до конца спринта? Если задача нестолько долгая, что занимает почти весь спринт, то она должна быть побита на подзадачи. А задача на три дня не должна породить багов на спринт. Мне так кажется. Бывает все, но нетривиальные задачи довольно редки. По моему очень богатому опыту.
Пример: Спринт двухнедельный. Фича — очень длинное древовидное меню, чтобы не положить фронт использовать автоподсос, для реализации нужно сделать что то на бэке, что то на фронте. Задействуем двух разработчиков — один на фронт, второй на бэк, каждому задача на неделю. Оба начинают одновременно и в какой то момент должны объединить свои усилия. По плану остается неделя на тестирование и устранение дефектов.
Дальше все идет не так как планировали) Фронт готов, бэк оказался сложнее чем думалось и затянулся, потом пытаемся соединить — оказалось что фронт и бэк не стыкуются в некоторых местах, фронт дорабатываем, бэк дорабатываем, стыкуем, ловим кучу ошибок (без всякого тестирования). Как результат — вроде сделано, но уперлись в конец спринта и получили фичу без тестирования. Ну а в следующем спринте соответственно получаем тестирование фичи, еще ошибки (уже не тривиальные) и тратим еще неделю на их устранение.
Дальше все идет не так как планировали) Фронт готов, бэк оказался сложнее чем думалось и затянулся, потом пытаемся соединить — оказалось что фронт и бэк не стыкуются в некоторых местах, фронт дорабатываем, бэк дорабатываем, стыкуем, ловим кучу ошибок (без всякого тестирования). Как результат — вроде сделано, но уперлись в конец спринта и получили фичу без тестирования. Ну а в следующем спринте соответственно получаем тестирование фичи, еще ошибки (уже не тривиальные) и тратим еще неделю на их устранение.
Классическая ИТ-проблема. Скрам на нее никакого ответа не дает. Скрам про другое.
Как синхронно внести изменения и выкатить в две и более тесно взаимодействующие системы? Решается ИТ-средствами — версионирование API, управляющие флаги, выкатка в прод в несколько этапов, и т.д.
Как синхронно внести изменения и выкатить в две и более тесно взаимодействующие системы? Решается ИТ-средствами — версионирование API, управляющие флаги, выкатка в прод в несколько этапов, и т.д.
Как синхронно внести изменения и выкатить в две и более тесно взаимодействующие системы?
— не усложняйте, это типичная фича размером в 2 человеко недели, разбитая на двух разработчиков. Если тут начать «версионировать API» — заказчик этого не поймет.
Вы только что говорили, что реальная доставка будет только через 2,5 спринта (исходя из опыта). А сейчас говорите что заказчику обещаете доставить за 1 спринт. Один из топов проблем, знаем что не сделаем в обещанный срок, но все равно обещаем данный срок.
И версионирование API не единственное и не обязательное решение. Подойдет любой подход, который снимет известные риски за приемлемую цену.
И версионирование API не единственное и не обязательное решение. Подойдет любой подход, который снимет известные риски за приемлемую цену.
Вы только что говорили, что реальная доставка будет только через 2,5 спринта
— ничего такого не говорил. Спринт двухнедельный, фича на 2 человека недели пилится одновременно двумя разрабами. Есть еще неделя на тестирование и устранение дефектов. Ничто не предвещало) Но это все чепуха, это был лишь пример того как в конце спринта можно получить запиленную (?), но не протестированную фичу. Наверняка можно и другие случаи из жизни вспомнить. Вопрос в том что с этим дальше делать? Вот тут люди пишут — «Задача является выполненной, если она протестирована» (правда формулировка тоже наводит на мысли, похоже автор не уверен в том что то что не протестировано, то не выполнено). Правильно пишут.
У нас не вебовый продукт. Все, что вы говорите неактуально для разработки. Однако наш продукт предназначен для решения этой ситуации. Прототипируем бэкэнд за пару часов. Делаем его макет с ограниченным количеством ответов. Пишем фронтэнд на этом прототипе и закрываетм протестированный таск. Делаем бэк и видим, что параметры не подходят. Дальше или останавливаем и перепланируем спринт или делаем бэк как договорились. Задачи совершенно параллельны и объеденения не требуют. Тестирование в спринте в любом случае.
Вроде ничего не упустил.
Вроде ничего не упустил.
Все, что вы говорите неактуально для разработки.
— не вежливо прозвучало
У нас не вебовый продукт
— это был пример ситуации, когда запланированная фича оказалась не протестирована, а не исследование Вашего гениального продукта. Могу слова «фронтэнд/бэкенд» заменить на что то иное, если Вам сложно абстрагироваться.
Прототипируем бэкэнд за пару часов.
— это было сделано, как и другие необходимые телодвижения. Все это можно обсудить на ретроспективе и понять что пошло не так (как всегда виноваты люди). Проблема не в этом конкретном случае, а в ситуации когда фича вроде бы запилена, а времени на тестирование в спринте не осталось.
Уж простите, если вдруг обидел. У каждого свое видение. Ваш пример взаимозависимых задач не актуален для десктопных приложений. Собственно все, что я хотел сказать.
Если прототип был вначале спринта, то как бэкэнд держал фронт задачу?
Тут просто неправильно оценена задача бэкэнда. Такое бывает. Это исключение. В неисключительных случаях все можно успеть за спринт.
Словом никаких проблем закончить задачу в спринте нет. Это если хотеть.
Если прототип был вначале спринта, то как бэкэнд держал фронт задачу?
Тут просто неправильно оценена задача бэкэнда. Такое бывает. Это исключение. В неисключительных случаях все можно успеть за спринт.
Словом никаких проблем закончить задачу в спринте нет. Это если хотеть.
Не знаю как у кого. Мы включает тестирование в спринт. Сроки на него закладываются изначально. При большом количестве серьезных багов можно говорить о неправильной оценке задачи. Что делать с ней дальше дело десятое. При правильной оценке сроки не горят.
— допустим, теперь вопрос: разработчики у вас заканчивают пилить фичи за сколько дней до конца итерации?
Почему вы думаете, что это должно как-то регламентироваться? Кто как закончит, так и будет. В последний день итерации подходит вполне. И, ктсати, тестируют у нас тоже разработчики. Сазерленд требует тестировщиков увольнять. Команда должна быть универсальна и равномерна. Это требование скрама от апологета.
И, ктсати, тестируют у нас тоже разработчики. Сазерленд требует тестировщиков увольнять. Команда должна быть универсальна и равномерна. Это требование скрама от апологета.
— идиотское требование: у тестировщика и разработчика разная психология, разное отношение к тому что существенно, а что нет, разный набор знаний. Даже обсуждать не интересно. По такой логике и техписы не нужны — разработчик сам все задокументирует)))
Техписателей у нас тоже заменяли. Качество без QA значетельно ухудшается это проверенный временем факт. Я говорю о технологии. Апологет скрама Джефф Сазерленд в ответ на вопрос нашего PO о судьбе QA сказал буквально «get rid of them». Не о чем спорить.
Кстати я работаю на компанию, которая производит известные утилиты для QA. Можете на слово поверить, что я знаю очень много о QA и разработчиках. Можете и не верить.
Кстати я работаю на компанию, которая производит известные утилиты для QA. Можете на слово поверить, что я знаю очень много о QA и разработчиках. Можете и не верить.
Если требование не устраивает, значит скрам вам не подходит — используйте другую методику. Пусть она похожая, но это не скрам.
В некоторых случаях это значит меняйте место работы. В небольших городах это не всегда возможно.
В общем, мыши будут плакать и колоться пожирая кактусы…
В общем, мыши будут плакать и колоться пожирая кактусы…
— а можно скрам оставить, а Сазерленда, который как то обходится без профессионального тестирования, в игнор? Или Вы скрамонаци?
Ну это как оставить ленинизм отрекшись от вождя мирового пролетариата. Проще сделать новую ветку и назвать это все рускрамом или нашакомпаниярамом. Это просто другое.
Я не защищаю скрам. Я его ненавижу. Все, что происходит навязывается мне. Возможно потому я и негативен. Все что я пишу это просто попытка разобраться в потенциальной применимости скрама к разработке.
Я не защищаю скрам. Я его ненавижу. Все, что происходит навязывается мне. Возможно потому я и негативен. Все что я пишу это просто попытка разобраться в потенциальной применимости скрама к разработке.
Как раз мне Scram нравится, как ко всему отношусь к нему не как к догме с авторитетными вождями. Единственный вопрос который меня смущает, это то что тестирование способно разрушить любую итерацию, а отсутствие тестирования лишает смысла рапорт заказчику о готовности фичи.
Это просто получается одна из аджайл технологий. Не скрам, не канбан, а что-то там. От меня же требуют скрама и следования ему. В качестве иконы поднимают его над моей головой и толкают. И я никогда не видел ни одной команды, которая бы могла ему следовать идеально. Меня бесит, что следовать всему неприятному в нем должен я, но все приятное в нем может быть убрано.
Потому в scrum рекомендуется автоматизировать большую часть кода/функционала. Чтобы CI/CD pipeline работал и выявлял ошибки. Чтобы можно было делать как можно больше итерации. А держать QA дорого и долго.
— Ваше замечание только подтверждает мысль, что в Scrum тема качества и тестирования плохо продумана
Строго наоборот, она продумана и именно вокруг этой продуманности и построена. Скрам — для быстрого вывода на рынок продукта, быстрого получения фидбэка и быстрой коррекции курса развития. Сначала занять место под солнцем, привлечь бабло, и лишь потом уже закрепляться качеством и построением «взрослых» процессов вместо скрама. Т.е., скрам именно про «лучше хуже, но раньше», именно про снижение издержек на вывод продукта путём некритичного и контролируемого снижения качества (меньше бюрократии в процессах, меньше предположений о рынке, больше реального «прощупывания»).
Скрам — для быстрого вывода на рынок продукта, быстрого получения фидбэка и быстрой коррекции курса развития.
Это общая цель всех Agile методологий, а не только Scrum. Просто в Scrum ориентация на ритмичность поставок, даже в ущерб «результату» (давайте сделаем один справочник вместо двух нужных для фичи, потому что в итерацию влазит только один)
Всё так, скрам — лишь один из аджайл-подходов. И его ритмичность присуща не только скраму, вообще говоря, это аспект любого повторяющегося процесса. Без водителя ритма никакая схема не взлетит.
Какой может быть «вывод на рынок» у не работающего продукта?
У нас тестеры в команде и присутствуют на планировании. Если задача обширная для тестов, они накидывают поинтов. Также бывают задачи только на тестирование, их тоже берем в спринт и оцениваем.
Задача является выполненной, если она протестирована ( ручное + по возможности you)и все баги исправлены. ( было бы здорово ещё включать время на написание юнит -тестов и код ревью, но ещё не сделали так)
Если в ходе выполнения вылазят критиков баги, требующие много времени на исправление, то можем и на следующий спринт перенести. Либо делаем в текущем, а потом переоцениваем задачу. Все зависит от загрузки и приоритета задач.
Автору спасибо за то, что поделился, как трансформация идёт в его компании.
Судя по написанному работы у вас ещё очень много и вы на пути к Scrum.
Понимаю, что бесплатный совет обычно не обладает высокой ценностью :-), но рекомендовал бы больше внимания уделить Scrum Guide'у, как основному документу про Scrum (обратите внимание на End Note).
Не соглашусь с тезисом про то, что мало где пишут про то, что нельзя совмещать роли PO и SM. На самом деле это одна из самых часто упоминаемых тем, суть которой в ярком конфликте интересов у этих двух ролей.
Можете на схожие темы погуглить: PO vs. PM, SM vs. PM и т.д. найдёте очень много интересного и полезного для себя и своих коллег.
Для всех непонимающих (обычно это касается событий в Scrum, например Daily Scrum): вы, скорее всего, не знаете и не понимаете фреймворка и его сути. Здесь я ничего никому доказывать не буду, потому что комментарий разрастётся до размера статьи и даже больше :-) Обратите лишь внимание на следующие определения в Scrum и попробуйте осознать их глубину, особенно последнего, третьего:
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master
В заключение хочу сказать, что в служении "карго-культу Scrum" я замечен не был :-), и основная проблема компаний и команд в том, что они Scrum'ом называют НЕ Scrum, а что-то другое, при этом страдают ни в чём невиновные команды :-)…
В Scrum'е я немного понимаю, так как практикую его уже некоторое время и являюсь сертифицированным (Scrum.org: для знающих людей ценность сертификации на этом ресурсе должна быть понятна) специалистом .
вы, скорее всего, не знаете и не понимаете фреймворка и его сути.
…
Simple to understand
Противоречиво немного :) А по сути, зачем простым разработчикам его понимать? Скрам-мастер должен понимать и говорить остальным членам команды что, как и когда делать, нет?
Покажу разницу (интерпретация на русском языке): "простой для понимания" vs. "трудный для совершенного овладения".
Что должен делать Скрам-мастер также написано в Scrum Guide. В первую очередь, несёт ответственность за продвижение и поддержку Scrum в соответствии со Scrum Guide.
Говорить остальным членам команды что и как делать идёт вразрез с понятием самоорганизующейся (self-organizing) команды и больше похоже на руководство детским садом, например.
"Простым" разработчикам, возможно, и незачем его понимать.
Так команда вполне может самоорганизоваться, а бизнес, руководство требует именно скрам, требует соблюдения ритуалов, плюсики вон ставят выполнил или нет очередной пункт ритуала, может даже премии дают по количеству плюсиков ).
Или скрам подразумевает, что команда должна самоорганизоваться ровно так как описано в гайде, не читая его? А если читать его нужно, то это уже организация автором гайда. И зачем тогда читать всем, если один может прочитать и описать необходимые ритуалы?
Как по мне, то самоорганизующаяся команда — это, прежде всего, команда, которой не нужны начальники, чтобы работать по утвержденному и приоритезированному списку задач. В работе такой команды должно быть минимизировано количество ситуаций "нечего делать", "жду когда закончат блокер", "а я не знал, что сосед по столу мог объяснить мне эту задачу за 5 минут и я сделал бы за два часа, а не на 5 дней завис" и прочие организационные неувязки. Скрам для этого не нужен, скрам — это рамки (одно из значений "фреймворк"), в которую загоняют команду. Ну описал скрам-мастер рамки, в которых нужно работать, вздохнули, выучили и работаем. Пару раз по голове получили за выход из рамок типа взятия задачи от стейкхолдера без участия, как минимум, продактаунера — перестали так делать. Все довольны, нет? Бизнес рапортует — у нас внедрён модный скрам, разработчики выполняют ритуалы, недолюбливая их, но находя плюсы типа того, что любого стейкхолдера можно послать к скрам-мастеру или по, не вникая в детали — ничего не знаем, у нас спринт, у нас бэклог.
Постараюсь ответить коротко.
- Я ни разу ещё в своей практике не встречал такую дрим-тим, чтобы ей не нужно было ничего рассказывать, показывать, организовывать процесс, улучшаться и т.д.
- Я не настаиваю на использовании именно Scrum, DSDM, XP и т.д. На мой взгляд, данные фреймворки способствуют формированию эффективного процесса работы. Они формализованы. В то, что БОЛЬШИНСТВО знает как эффективно организовать свою работу лично я не верю. Отчасти можете посмотреть на концепцию сюхари, тогда должно стать понятнее, для чего все эти "рамки".
- Основная проблема организаций, которые трансформируются и идут в Agile/Scrum/… заключается в том, что либо они сами не понимают, какую проблему они решают, и как им в этом поможет та или иная методология/фреймворк. Либо они не могут это нормально донести до сотрудников. В результате, в том же Scrum получаем не "роли, события, артефакты и правила, которые их связывают", а "ритуалы", "психотерапевтические ретро", "доставку пиццы по пятницам" и т.п. (излюбленная тема про зону ответственности Scrum-мастеров).
- Хорошо, когда находится человек, которому интересна эта тема, и который может попытаться донести всю глубину (а она реально большая) того, для чего весь этот Agile и Scrum. По опыту же получается бездумное служение "карго-культу" и дискредитация Agile/Scrum.
1. Кому нужно? Как по мне, то обычно определенная организация процесса нужна бизнесу, менеджменту для, прежде всего, прозрачности и предсказуемости, управляемости, контроле — в их понимании. Самой команде обычно всё это не нужно, фичи и фиксы, польза пользователям доставляются по мере готовности согласно намеченному плану.
2. Я тоже не верю. Но я и не верю, что авторы какой-то книги, которую руководство воспринимает как догмат, знают как эффективно организовать команду людей, которых они никогда не видели.
3. Да может они и смогли донести понятно, но проблема организации если и стала проблемой команды, то на уровне «мы не решим нашу проблему — проблемы (увольнения, депремирования и т. п.) будут у вас». Команда радостно соглашается исполнять требуемых от них ритуалы и играть назначенные роли, производить события и артефакты, искренне надеясь, что даже если проблема бизнеса не решится, то команду виноватой не сделают и у неё проблем не будет, поскольку делала всё согласно гайду или прямым указаниям.
2. Я тоже не верю. Но я и не верю, что авторы какой-то книги, которую руководство воспринимает как догмат, знают как эффективно организовать команду людей, которых они никогда не видели.
3. Да может они и смогли донести понятно, но проблема организации если и стала проблемой команды, то на уровне «мы не решим нашу проблему — проблемы (увольнения, депремирования и т. п.) будут у вас». Команда радостно соглашается исполнять требуемых от них ритуалы и играть назначенные роли, производить события и артефакты, искренне надеясь, что даже если проблема бизнеса не решится, то команду виноватой не сделают и у неё проблем не будет, поскольку делала всё согласно гайду или прямым указаниям.
Самой команде обычно всё это не нужно, фичи и фиксы, польза пользователям доставляются по мере готовности согласно намеченному плану.
Для того, чтобы так было нужна организация, обладающая определенными свойствами. Например, может быть организация разработки где принято делать релизы раз в год. Какие-то фичи готовы, но чтобы зарелизить, надо стабилизировать код — поэтому нельзя выкатить фичу отдельно.
Так команда вполне может самоорганизоваться, а бизнес, руководство требует именно скрам, требует соблюдения ритуалов, плюсики вон ставят выполнил или нет очередной пункт ритуала, может даже премии дают по количеству плюсиков ).
Рад, что вас зацепило :)
Противоречиво немного :)
С учетом того, что большинство и не пытается, в этом нет противоречия.
А по сути, зачем простым разработчикам его понимать? Скрам-мастер должен понимать и говорить остальным членам команды что, как и когда делать, нет?
Первые 2-3 спринта — может быть и должен. А дальше он должен быть заменимым. Скрам-мастер не может же за команду решать на ретроспективе. Не может за команду вносить изменения в процесс.
Спасибо, что прочитали и оставили комментарий :)
Да, мы еще на пути к Scrum, нельзя сказать, что процесс трансформации завершился.
Да, мы еще на пути к Scrum, нельзя сказать, что процесс трансформации завершился.
del, не на то сообщение ответил
Вот в медицине есть понятие двойного слепого теста, который объективно показывает насколько лекарство правда работает. Это достаточно долгий, затратный, но всё же дающий хорошее понимание вещей процесс. Можно ли придумать что-то подобное в ИТ, например, для оценки успешности применения того же скрама? Мнение участников при этом, конечно, аргументом быть не может (ну типа как мнение разработчиков лекарства о том, что оно работает, совершенно не влияет на результат двойного слепого теста). Было бы интересно придумать методику оценки.
Я думаю можно такое провести, если запретить разработку без лицензии.
В противном случае ни для кого из участников это не окупит. Есть разные исследования проессов на студентах — например TDD, кажется. Но на боевых задачах и квалифицированных специалистов это безумно дорого.
В противном случае ни для кого из участников это не окупит. Есть разные исследования проессов на студентах — например TDD, кажется. Но на боевых задачах и квалифицированных специалистов это безумно дорого.
Ну так и для тех же лекарств это безумно дорого. Но компании и государства на это идут, поскольку это ещё и безумно важно. Сколько лет и миллиардов в своё время угрохали в ватерфол, пока поняли, что он ущербен чаще, чем полезен? Сколько ещё угрохают в скрам, пока поймут, что и он не всегда панацея. Для какого-нибудь Гугла было бы легко отдать пару миллионов на оценку эффективности технологий (условно говоря, набрав две одинаковых команды и дав им одинаковые задачи при разных методологиях ведения проекта). Интересно, делает ли это тот же Гугл и если делает, то готов ли делиться результатами.
Сколько лет и миллиардов в своё время угрохали в ватерфол, пока поняли, что он ущербен чаще, чем полезен?
Кто сказал что он ущербен? нужно применять правильно. Сделайте ядерный реактор, операцию человеку, нефтяную скважину по Scrum. Есть куча проектов где просто нельзя сделать MVP, потренироваться на кошках, а потом допиливать на ходу.
Так же есть куча проектов, где можно и на кошках тренироваться, и подпиливать на ходу.
Вопрос запланированных ожиданий, рисков и цены всего этого. Готовность оплатить озвученную цену так же стоит учитывать.
Бизнес — ничего личного :)
Ну так и для тех же лекарств это безумно дорого. Но компании и государства на это идут, поскольку это ещё и безумно важно.
Вы хотите, чтобы разработать hello, world или бухгалтерию стоило столько же, сколько выпустить новое лекарство?
Sign up to leave a comment.
Семь проблем внедрения Scrum, о которых мы не знали