Scrum
А расскажите про ваш опыт работы со скрамом
Как вы к нему относитесь, что он изменил, в чем помог, чем помешал.
Как вы к нему относитесь
Есть в этой жизни вещи, которые нужно просто пережить: детский день рожднения с 10ю детьми, поход в магазин со своей половиной, недельный визит тёщи/свекрови ну и скрам. ;-)
Де-факто стандарт в организации процессов в ИТ.
В принципе полезная вещь, позволяет упорядочить деятельность, наладить обратную связь от всех членов команды.
Включает ритуалы типа регулярных митингов, стикеры с идеями и т.д.
Проблема в том, что если основное руководство (PO) хреновое, то Скрам заполняет собой вакуум и становится вещью в себе, т.е. пустой тратой времени на эти самые ритуалы.
Очень даже полезная штука при правильном применении. Особенно если действительно использовать ретро для файнтунинга процесса.
Я тут собрала негативные отзывы про скрам, что скажете?:
1. Скрам-менеджеры, которые закончила трехнедельные курсы и мнят себя гуру, при этом не в курсе специфики разработки и не интересуются судьбой продукта, а пытаются укрепить свое влияние.
2. Ритуалы как самоцель - митинги как например ретро, где каждый должен что-то сказать, даже если по сути ему сказать нечего, и поэтому изрекает что-то вроде "мне понравилась взаимопомощь в команде и не понравилась гетерогенность команды". А потом скрам-мастер важно зачитывает с листочка все эти реплики.
3. Искусственные деадлайны (конец спринта), вжимающие разработчика, работающего над комплексной проблемой, в слишком тесные рамки.
4. Идея о универсальности разработчика ("в команде каждые должен мочь делать все"). В результате вместо того, чтобы глубоко вработаться в одну тему и в один проект, люди вынуждены прыгать по верхам и "учиться всему понемножку", делая то дно, то другое. В итоге нет и Codeownership, никто не чувствует себя по настоящему ответственным.
1. Скрам-мастера скорее имеются ввиду. Они просто модераторы на всех этих митингах, никакого влияния.
2. Ретро бесит по многим причинам:) Стараюсь избегать по возможности.
3. Если нереально успеть сделать что-то к сроку, то нереально. Значит, переносится на следующий спринт. Ошибка планирования.
4. Да. Это попытка избежать наличия "незаменимых людей".
Я тут собрала негативные отзывы про скрам, что скажете?
Проблематика раскрыта довольно точно.
Я видел скрам-мастерицу, после курсиков-шмурсиков, облающая нулевыми знаниями в ИТ и в people management, возомнила себя начальницей. Пыталась командовать закалёнными в боях ИТ-шниками, в т.ч. с 15-ти летним опытом. Пришлось ставить на место. Но допускаю, что встречаются мастера и поумнее.
Ритуалы как самоцель - точно. Если ПО никакущий, ни стратегии, ни тактики, а скрам мастер активный.
Ретро на самом деле довольно полезен. Если человеку вообще нечего сказать после 2-х недельного спринта, то наверное человек в команде не нужен.
По поводу искусственных дедлайнов и универсальности - да, нужно договариваться.
Многое зависит от product owner, он должен быть лидером, а скрам-мастер как помощник без лишнего гонора. ИМХО.
1,2 - все так. Прошли это лет 5-10 назад. Нанимается скрам-мастер за кучу денег, который создаёт видимость бурной деятельности, генерит кучу бесполезных митингов и всем мешает. В итоге через примерно год этой суеты руководство понимает, что лучше не стало, и от него избавляются.
1. Скрам-мастер - это обслуга. Его должно быть как хорошего официанта не видно и не слышно, но при этом он должен возникать из небытия при первой же организационной проблеме и решать её.
2. Цель ретро - улучшение процесса. Естественно, что не каждый должен высказываться. И высказывания должны быть типа "мы тут применили метод Х и получили классные результаты, надо внедрить его более широко". Или "наш билд косячит и блокирует процесс, надо выделить в следующем спринте время для устранения проблем".
3. Комплексные проблемы разбиваются на части, которые умещаются в один спринт. Максимальная оценка задачи - один спринт. Иногда это невозможно, и это нормально. В последнем проекте я три спринта работал над одной задачей один, ибо никто другой не имел достаточной квалификации для её
решения. Разбивка на подзадачи формально была, но фактически большого смысла не имела. Такие задачи переносятся на планировании в следующий спринт.
4. Codeownership и не должно быть, но при наличии специализаций их надо просто учитывать при планировании. В итоге мы планировали достаточное количество пунктов для бекенда, фронтенда, и для меня отдельно, если были сложные темы.
На самом деле, имхо сложнее всего правильно организовать дейли чтобы не бесил. Дейли нужен для координации ежедневных задач, не надо там рассказывать романы о деталях проделанной работы.
Я видел скрам-мастерицу, после курсиков-шмурсиков, облающая нулевыми знаниями в ИТ и в people management, возомнила себя начальницей. Пыталась командовать закалёнными в боях ИТ-шниками, в т.ч. с 15-ти летним опытом. Пришлось ставить на место. Но допускаю, что встречаются мастера и поумнее.
Речь о немцах? Давно я не видела немцев, ставящих кого-то, кто это заслужил, на место. У нас матерые специалисты сидят и молчат в ответ на произвол скрам-публик
Многое зависит от product owner, он должен быть лидером, а скрам-мастер как помощник без лишнего гонора.
Скрам-мастер аргументирует правилами скрама и например обьявляет ПО, что те и эти вещи он решать не имеет права. Если скрам-мастер из рядов команды, то с ним легко договориться, а вот засланные мастера гнут свою линию. Их ситуацию облегчает непонимание специфики и желание расширить влияние скрамаи тем самым усилить свою роль
1,2 - все так. Прошли это лет 5-10 назад. Нанимается скрам-мастер за кучу денег, который создаёт видимость бурной деятельности, генерит кучу бесполезных митингов и всем мешает. В итоге через примерно год этой суеты руководство понимает, что лучше не стало, и от него избавляются.
Эх, хорошо бы. Часто сначала уходят все полезные люди, прежде чем всем станет ясно, что от бесполезных людей и процессов надо избавляться
Речь о немцах?
Нет, я тоже замечаю что немцы те ещё терпилы. Я сам вежливо обясняю, что уважаемая мастерица, ты несёшь херню, я буду делать так как правильно, а не как ты придумала. Она "сложила уши" очень быстро.
Скрам-мастер аргументирует правилами скрама и например обьявляет ПО, что те и эти вещи он решать не имеет права.
Ну вобщем правильно. В определённом смысле разделение властей. Но только скрам не должен касаться принципиальных продуктовых вопросов. Шедулить митинги, timeboxing, букирование проектора и прочая дребедень. А продукт трогать не надо.
Нет, я тоже замечаю что немцы те ещё терпилы. Я сам вежливо обясняю, что уважаемая мастерица, ты несёшь херню, я буду делать так как правильно, а не как ты придумала. Она "сложила уши" очень быстро
Вот у нас я единственная не-терпила, но толку малоНо только скрам не должен касаться принципиальных продуктовых вопросов.
Но только скрам не должен касаться принципиальных продуктовых вопросов.
Например по скраму ПО не имеет права решать, какие войдут в спринт, а какие нет. А это принципиальный вопрос
1. Скрам-мастер - это обслуга. Его должно быть как хорошего официанта не видно и не слышно, но при этом он должен возникать из небытия при первой же организационной проблеме и решать её.
Мечта! Но обычно такие типы не любят держаться в тени.
Codeownership и не должно быть, но при наличии специализаций их надо просто учитывать при планировании. В итоге мы планировали достаточное количество пунктов для бекенда, фронтенда, и для меня отдельно, если были сложные темы.
Мне кажется, чем лучше специалист, тем меньше ему нравится метаться между отдельными карточками, а хочется заниматъся своим проектом, углубляясь как можно сильнее в него. Пкм у моих коллег так.
Не знаю, мне понятно желание иметь "свой код", чтобы никто кроме тебя в нем никто ничего не мастерил. И чтобы иметь возможность нести полную ответственность за него и пронимать решения.
А что тогда ПО решает, если не вопрос что делать?
Типа, ПО наполняет бэклог, а что оттуда взять в спринт, решает команда
Господи, как маленькие дети. Полюбовно-то нельзя вопрос решить, создав процесс в котором учитываются все мнения? Приоритетность задач знает только ПО, взаимосвязи между задачами - команда. Дело СМ - вообще десятое.
У нас для этого делают "тандемы". Для снижения bus factor.
Господи, как маленькие дети. Полюбовно-то нельзя вопрос решить, создав процесс в котором учитываются все мнения? Приоритетность задач знает только ПО, взаимосвязи между задачами - команда. Дело СМ - вообще десятое.
Конкретно у нас проблема в том, что на команду падают дополнительные технические задания. Например какие-то техические расширения типа необходимости подстроиться по дновые типы баз данных, облак итд. Или какая-то копмпонента перестала справлятъся с нагрузкой. Или какую-то аркитектуру сделали по-простому на скорую руку, а теперь она вызывает проблемы, и все надо переделывать. И все это срочно и важно. А мне как ПО это мешает достигать целей по развитию продукта и создает впечатление, что мы не можем сфокусироватъся на одной задаче за спринт, а мечемся туда-сюда. Но эти необходимые посторонние работы лоббируют наше техники, например архитектор, потому что его более или менее прижимайuт к стенке начальство или смежники.
Учитесь управлять своими и чужими ожиданиями. Expectation management.
Резервируйте часть ресурсов на разгребание этого unresolved technical debt, он есть и будет у всех, не только у вас. Ресурсы всегда ограничены, поэтому в основном всё строят по принципу "х@як-х@як и в продакшн!", по умному MVP. Потом в пожарном порядке латают на ходу. Ничего нового.
По Фрейду))
Идея о универсальности разработчика ("в команде каждые должен мочь делать все"). В результате вместо того, чтобы глубоко вработаться в одну тему и в один проект, люди вынуждены прыгать по верхам и "учиться всему понемножку", делая то дно, то другое.
Типа, ПО наполняет бэклог, а что оттуда взять в спринт, решает команда
ПО отвечает за бизнес часть. Он должен знать, какой продукт должен получиться. Он же доожен приоризировать вещи в бэклоге.
На мой взгляд ПО самая сложная и ответственная роль. Он единственный, кто работает со стекхолдерами.
Роли все важные.
Но естественно ПО определяет тематическое развитие продукта. Этими задачами в порядке приоризации он и наполняет бэклог.
Н.п.
Вот и у нас планируют вводить скрам. Точней, уже стартанули с первым спринтом (правда, я в отпуске... Подождать не могли, ибо после моего отпуска коллега уходит в эльтерцайт 👍)
Как это должно функционировать - загадка. Нет, нас полным составом высадили на обучение, мы два полных дня слушали теорию и искренне пытались представить, как это применить на практике. По итогу - лично мое ощущение, как у отвечавшего выше: это надо просто пережить. Думаю, до конца лета мы наиграемся в эту модель рабочего поведения.
Я не буду загадывать, как будет на самом деле (если тема не уйдет в архив, отпишусь потом), но уже предвижу проблемы: у нашего проекта уже проданных задач до середины 2022 года, это если мы впятером, как предполагалось изначально, будем трудиться над разработкой и не отвлекаться ни на что. Но - одного разработчика на 50% перекинули в другой проект, и практика показала, что 50% там пожар не потушить, так что он полностью выпал из нашей обоймы, второго (самого толкового) "по совместительству" назначили системным архитектором всех проектов фирмы. Помимо того, что парень в целом ведёт отдельный проект, с нашим не пересекающийся... Третий товарищ только начал работать, но по нелепому стечению обстоятельств залетел на долгий больничный (не придуривается, увы). Остаюсь я, тридцатичасовая рабочая сила, и студент, который программировать не умеет, но согласно поставленной начальством задаче - должен научиться в короткие сроки. И это все на фоне сдачи одной крупной части проекта в июле и ещё одной - в начале сентября. При этом "рассчитывать на проверку отделом тестирования" мы не можем (unterbesetzt), поэтому полноценное перекрестное тестирование должно входить в спринт. Ну и ключевое: денег мы толком не приносим, поэтому фертриб стремится продавать как можно больше фишек, которые надо сделать "прямо сейчас" (несмотря на план до июля 2022). Ну и классические блокеры, когда у клиента "вдруг опять что-то не работает".
При этом роль ПО почему-то поделили на две части (не, в теории оно неплохо, в нашей реальности сейчас совсем лишнее), где есть ответственный за fachlichen и technischen Themen. Причем на техническую часть взяли нового человека, который "плохо знаком с процессами фирмы", но точно знает, "как должно быть" 🙈
Скраммастер зато у нас золото. И парень хороший, и в проекте не замешан (то есть реально беспристрастный), и сам из разработчиков, и опыт немалый (хоть и не в скраме). Уверена, что со своей ролью он справится. И да, ещё один плюс - команда дружная и сработанная, лёгкое и открытое общение должно помочь нам пережить это недоразумение, как скрам)))
При этом роль ПО почему-то поделили на две части (не, в теории оно неплохо, в нашей реальности сейчас совсем лишнее), где есть ответственный за fachlichen и technischen Themen. Причем на техническую часть взяли нового человека, который "плохо знаком с процессами фирмы", но точно знает, "как должно быть" 🙈
LOL ну точно как у нас. В итоге одного выжили 
Так вот, тот, который fachlich (и с которым мы работали до сегодняшнего дня), тоже, как и Алла, удивлен, что до продукта, собственно, задачи не доходят. Все какие-то организационные моменты и технические необходимости. Я, как разработчик, понимаю, что если не починим основание, колдовать над фичами по меньшей мере нерационально. Но и "продажную сторону" понимаю тоже: продукт, где год надо вложить на ремонт (читай, не будет приносить денег) - нерентабелен. И скрам тут мало поможет...
Скраммастер зато у нас золото. И парень хороший, и в проекте не замешан (то есть реально беспристрастный), и сам из разработчиков, и опыт немалый (хоть и не в скраме). Уверена, что со своей ролью он справится. И да, ещё один плюс - команда дружная и сработанная, лёгкое и открытое общение должно помочь нам пережить это недоразумение, как скрам)))
Ну это уже очень классно. В нашей расстановке меня бесит скраммастер, ведущий себя как гуру и шеф, но не понимающий ничего в теме.
При этом роль ПО почему-то поделили на две части (не, в теории оно неплохо, в нашей реальности сейчас совсем лишнее), где есть ответственный за fachliche und technische Themen. Причем на техническую часть взяли нового человека, который "плохо знаком с процессами фирмы", но точно знает, "как должно быть"
Это уже хуже. Но в принципе разграничение между Fachlichkeit и техникой на мой взгляд логично (если оба этих аспекта есть в проекте). Потому что быть корифеем техники и архитектуры, и в курсе современных техник невозможно, если ты одновременно должен быть знатоком бизнес-процессов.
Ну и ключевое: денег мы толком не приносим, поэтому фертриб стремится продавать как можно больше фишек, которые надо сделать "прямо сейчас" (несмотря на план до июля 2022). Ну и классические блокеры, когда у клиента "вдруг опять что-то не работает".
Ну вот, отлично 
Хотя кто знает, может вам скрам как раз поможет. Ведь пкм формально скрам как раз защищает команду от внезапных поручений со стороны продаж, им можно ответить, что спринт уже идет, и ничего нового вы в него пронимать не станете (разве что оставить пуффер на случай внезапных срочных поручений в связи с поломками или угрозой срыва проекта).
И надостаток ресурсов с помощью скрама можно сделать более явным. Ведь по результатам спринтов измеряется средняя скорость обработки стори пойнтов командой. Поэтому любую задачу команда может оценить в стори пойнтах или в днях, требуемых для ее реализации. И потом показать ответственным: нам поставили такие-то задачи, мы оценили, что на них потребуются 4 года с нашей скоростью - что скажете? Ставьте проиритеты, вычеркивайте второстепенное, так чтоб срок реализации оказался приемлимым.
Проблема нашего времени в том, что большинство руководителей не пrинимает неудобные решения, а сваливает ответственность на разработчиков.
Так вот, тот, который fachlich (и с которым мы работали до сегодняшнего дня), тоже, как и Алла, удивлен, что до продукта, собственно, задачи не доходят. Все какие-то организационные моменты и технические необходимости. Я, как разработчик, понимаю, что если не починим основание, колдовать над фичами по меньшей мере нерационально.
Да я как раз понимаю необходимость чинить технику, инвестироватъ время в архитектуру итд. Я не понимаю, какие претензии могут быть о мне как к ПО, если в результате фичи продукта имплементируются очень медленно. Если мне выдали машину, которая ездит с максимально 50 км/час, и я не автомеханик и не шофер, а пассажир и навигатор, то не моя вина, что я прибуду к месту назначения позже назначенного срока. Значит срок назначен неверно, либо неверно выбрана техника. Но не я оба этих решения принимаю, зато я оказываюсь невинной жертвой. Которой выдвигают обвинения, что она выбрала неправильный маршрут, сбилась с пути итд. Но е-мое, если расстояние по прямой известно, и скорость известна, то какие могут быть основания для этих подозрений?
Судя по тому, что Вы описывали ранее, я бы подумала что скрам, это то что вам нужно. Вы ответственны только за те задания, которые вы, реалистично оценив ауфванд, сами себе смогли "застолбить". Ни кто больше не сможет на вас что-то взвалить. Коллеги тоже не смогут, важные задания оставить на потом, потому как, если вы от них зависите, то ваши часы просто перестают тикать "blocked internal/external". И сразу станет заметно, что у вас, salopp gesagt, некому работать
ПС: прочла только что, оказывается выше вам уже написали что-то подобное, сорри.
Значит срок назначен неверно, либо неверно выбрана техника. Но не я оба этих решения принимаю, зато я оказываюсь невинной жертвой. Которой выдвигают обвинения, что она выбрала неправильный маршрут, сбилась с пути итд.
А как вы хотели? Это часть стандартной офисной возни: кто на кого спихнет ответственность, кого накажут за провалы и кого наградят за успехи (реальные или мнимые). Вы наверное недавно в руководстве?
Судя по тому, что Вы описывали ранее, я бы подумала что скрам, это то что вам нужно.
Дай Бог! Я только "за" хоть какую-то системность. То, что не верю в реалистичность - это другое.
Вы ответственны только за те задания, которые вы, реалистично оценив ауфванд, сами себе смогли "застолбить". Ни кто больше не сможет на вас что-то взвалить.
Вот именно это и смущает. В частности, сегодня вышла проверить почту, и уже вижу, как идёт первый спринт. Т.к. в июле первая крупная продажа нашего проекта в этом году, то начальство заинтересовано в минимальном качестве. И у тестировщиков "вдруг нашлось время". Соответственно, запланированные задания сместились под давлением вернувшихся из тестирования багов. А т.к. планировать, когда у тестировщиков будет "свободная минутка" мы не можем, то и включить потенциальное время на устранение багов в спринт не получается. Ладно, будем считать, что это просто первый блин комом 😉
Тестирование это отдельная тема. Вообще-то тесты должны быть интегральной частью разработки. И каждая фича должна перед деплойментом быть протестирована всеми возможными способами. Юнит-тесты вообще часть разработки, насколько я понимаю. В Build-Pipeline проходят тесты. Акцептанc-тесты, автоматические и мануальные. Автоматические систем-тесты, UI-Тесты. Это все должно быть частью процесса. То есть многое тестируют прямо разработчики. И после всех этих тестов и отправки апдейта клиентам, не должно обнаруживаться множества багов. Естественно, на системе клиента что-то может пойти не так из-за иных условий чем в системе разработки, но это все должно держатъся в рамках.
А если у вас просле проверки экстернами-тестировщиками все время начинает уходить на устранение багов, то значит в разработке что-то идет не так.
Баги очень мешают выполнять всё запланированное. У нас "баг" не заschитывается как полноценное задание и времени на него не зарезервировано. Но вам бы следовало только баги исправлять, к кторым вы как разработчиk физически причастны. Нужно просто привыкнуть не щёлкать клювом на планунгсмитинге. А еще лучше "обнаглеть", иначе с ума можно сойти от давления
если у вас просле проверки экстернами-тестировщиками все время начинает уходить на устранение багов, то значит в разработке что-то идет не так.
Логично. Мы латаем, то что сыпется на лету. Проект, написанный человеком-самоучкой, мы переняли после года с момента его увольнения. Документации нет, как должно работать - пытаемся угадать из кода. Видимо, не до всех углов добрались, раз до сих пор падает на тестировке. То, что на внутренней не упадет - знаю точно... До мая месяца нас было двое (кто помнит мою историю про быстрого/медленного коллегу - так медленного от нас убрали), и "мышление у нас одинаковое". Что встроили, то и протестили, а где ещё зацепит по касательной - видим не всегда. Надеялись, что с расширением команды - будет лучше тестирование, но "что там с командой" - я уже описала выше 😒
Юнит-тесты вообще часть разработки, насколько я понимаю. В Build-Pipeline проходят тесты. Акцептанc-тесты, автоматические и мануальные. Автоматические систем-тесты, UI-Тесты. Это все должно быть частью процесса.
Это все - должно быть. Но этого нет. И времени, чтоб даже начать вкручивать хоть понемногу - тоже нет. Сейчас две крупные задачи до сентября, двух товарищей надо по-быстрому вработать (то есть объективно рассчитывать на их участие в проекте раньше декабря - не приходится), ещё один разработчик уходит в эльтерцайт. То есть остаюсь я "на все случаи жизни": текущие инсталляции, активная разработка/тестирование, введение новых коллег в материал и "срочное разруливание проблем клиента". Понимаю, что до автоматизированных тестов не дойду. Дай Бог мануальные своими силами провернуть.
Нанимается скрам-мастер за кучу денег, который создаёт видимость бурной деятельности, генерит кучу бесполезных митингов и всем мешает.
А что ещё ему остаётся делать, чтобы своё существование оправдать. Мне кажется, скрам-мастер как отдельная должность имеет смысл только для ооочень большой организации. У нас фирма маленькая и стратег по совместительству скрам-мастер. Думаю, у него в неделю часа 3 на эту обязанность уходит. Был бы отдельный человек для этих целей, так точно бы всем только мешал, чтобы хоть как-то своё рабочее время занять.
Да! Опасное сочетание избытка свободного времени, недостатка знаний и желания оправдать свое существования несет нехорошие плоды
Я ПО и со скрам мастером никак не пересекаюсь. Все вопросы бизнес-логики или координации технических обновлений полностью на мне. Как может скрам-мастер после двухнедельных курсов конкурировать с ПО, у которого многолетний опыт работы у одного из крупнейших клиентов рынка, на который мы работаем, финансово-математическое и инженерное образование, острый ум и модные платья?
Н.п.
Ну вот скрам, такой скрам 🙈
Первый спринт закрыли, ревью сделали, оценили наши успехи/провалы, распланировали второй. Сегодня старт. Утром в почтовом ящике письмо от ПО: "Ребята, косяк, тот проект, что мы устанавливаем 1.07 и уже протестировали - не соответствует заявленным требованиям клиента" 😯 Ну, мы ж не зря просили написать концепт перед началом разработки... Нам его "как-то там" написали, парень, который программировал именно эту часть, догадывался, что так будет, поэтому перед началом разработки все же представил детальную выкладку перед ПО, объяснив, что от чего зависеть будет и как он это сделает. Получил "добро", принялся за реализацию. И вот сегодня - сюрприз. Сюрприз ещё и в том, что парень через два дня уходит в эльтерцайт, знания по этой части проекта только у него (и, как водится, не задокументированные), мы в стадии активного старта другого проекта...
В общем, зависли сегодня. А, да, ещё ни одного руководителя на месте не оказалось. ПО на выезде у клиента, недоступен, технический руководитель по понедельникам не работает, скраммастер сказал, что он такие решения (ставить эту информацию, как блокер спринту) не принимает. А мы растерялись: то ли вымучивать из товарища последние два дня знания, которые у него есть по "косячной" части проекта, то ли дальше писать проект, который стартует. Если брать "строго по скраму" - задача с ошибкой ещё не внесена в спринт, значит, работаем над текущими задачами в порядке приоритета...
А как вообще быть должно по уму? Наверное, если б не парень в отпуск, не было бы такой истерики - день-два подождать ПО. Но опять же, там изменений на добрых недели три, и это если опустить тестирование QS... Как впредь избежать таких ошибок? С нашей, программистской, стороны все чисто, на что опирались (концепт) есть, но даже если это ошибка ПО - осадочек неприятненький. Не сделала в срок команда...
Так вы ж вроде жаловались недавно, что только скрам-мастер решает, что включить в спринт...
Решает он в том, смысле, что следит за тем, чтобы ПО не решал, что включать в спринт. Сам он решать не может по причине отсутствия нужной информации.
А с какой целью ПО написал вам "Ребята, косяк, тот проект, что мы устанавливаем 1.07 и уже протестировали - не соответствует заявленным требованиям клиента"?
Цhего он от вас ожидает?
Это косяк ПО. Он должен четко знать «как должно быть» и убедиться, что его представление совпадает с представлением заказчика.
Косяк ваш как команды в том, что есть большой кусок функционала, в котором разбирается только один человек, и двойной косяк - что не организовали передачу дел от уходящего в эльтернцайт сотрудника. Ведь помимо того, что надо все переделать, там могли позже найтись баги, необходимости доработки и тд.
Как этого избежать впредь: ПО согласовывает концепт с заказчиком до начала разработки + уходящие организовывают грамотную передачу дел + все важное должно быть задокументировано ещё на этапе разработки.
Совершенно согласна! ПO обязан составить концепцию для разработчиков и организовать составление технических концепций для бэкенда, а также макетов для фронтенда. Потом проверить, соответствует ли реализованное командой этим четким требованиям. А не писать команде "реализация не соответствеут требованиям клиента". Это вообще знак того, что ПО сел в лужу.
Заранее озаботиться передачей дел от уходящего в декрет коллеги должен бы был скраммастер, но и члены команды конечно тоже. В общем, ощущения, что ни ПО, ни скраммастер самый минимум своих функций не выполняют.
Проблема может и не их, но чем-то заниматъся как минимум оден день надо. У нас таких ситуаций не было, потому что ПО таких фокусов себе не позволяет, но иногда бывают небольшие простои и непонятки, и члены команды сами решают, чем им заняться в это время. Правда у нас всегда есть кто-то в доступе, с кем можно посолветоватъся и кто возьмет на себя ответственность за это решение.
В общем, ощущения, что ни ПО, ни скраммастер самый минимум своих функций не выполняют.
Так мы только начали в это играть, ещё не поняли, как на практике применять))
ПО у нас образовался из бератора, который уже лет пять курирует проект на тему коммуникации с клиентами, опыта в написании концептов, да и вообще в объёмном мышлении нет. Совместно набиваем шишки....
Заранее озаботиться передачей дел от уходящего в декрет коллеги должен бы был скраммастер, но и члены команды конечно тоже.
Jain. Эта функция только для этого клиента и ни в одном другом проекте неприменима. Поэтому мы и разделили задачи, что парень пишет один, то, что больше никому не пригодится, а мы, оставшиеся, пишем другую максимально конфигурируемую функцию (с возможностью применить где-либо ещё). И ведь все шло, "как надо", мы на удивление получили возможность протестировать наши новшества через QS, проект считался завершенным, осталась установка. Как, когда и почему ПО стало понятно, что в концепт закралась логическая ошибка - неизвестно. Он до сих пор вне связи...
Это не ваша проблема.
Как бы да, но по факту - моя личная головная боль. Если изменения все же вносить потребуется. Сегодня обратилась к скраммастеру на тему "нужен митинг для передачи", на что получила ответ, что он может только рекомендовать, а не заставлять людей присутствовать. Логично, чо. Парень, который уходит (так уж получилось, самый умный из нас), экстренно латает все места, которые только может залатать до своего ухода. Поэтому передачу задачи, насчёт которой непонятно, будет или нет реализована, находит нерациональным. Я с ним согласна. Жаль, что если все же выстрелит - разгребать мне.
Вообще не понимаю, в чем проблема. Пофиксить какой-нить баг или сделать небольшой рефакторинг всегда можно и даже нужно.
Так не вопрос, чем заняться есть всегда. Но нас долгое время обвиняли в том, что занимаемся чем ни попадя (багфиксинг и рефакторинг, на разработку не оставалось времени), ввели скрам, чтоб наконец-то сдвинуть дело с мертвой точки, вот мы и мечемся теперь, пытаясь понять, что нам делать, если все же поддерживаем скрам, или плюнуть и растереть, и работать как раньше, "nach Abruf". Яркий пример привычности такого процесса - ПО и его письмо в понедельник с утра: "Ребят, обнаружил ошибку, почините по-быстрому и отчитайтесь о готовности!"
Так в том-то и дело, что это все зависит не только от вас, даже в большей части не от вас. Вы (разрабы) не можете взять и ввести скрам на одной шестой части суши, в эту игру должны играть все. И именно для этого и нужен скрам-мастер: его первоочередная функция - защита команды от посягательств ПО. Это все нужно обсуждать на ретро.
Я понимаю, это не все так просто. У меня были настоящие проблемы с ПО, он даже хотел меня выгнать из проекта, но в итоге притерлись :)
Поэтому мы и разделили задачи, что парень пишет один, то, что больше никому не пригодится
В этом и проявляется опытность ПО, что он не делает ставку на то, что пронесёт - пусть уходит без передачи дел единственный знающий человек, авось как-то вырулим, остальные напрягутся и сделают.
Теперь остальные сидят как-то так:
а он есть (с) ;-)
ПЛ или процесс? Без последнего прям грустно как-то)))
По факту, ПО решительным движением руки подписал то, что все косяки будем исправлять позже, а в этом спринте идём, как намечено 😏
Это наверно хорошо. А как же ваш коллега, уходящий в декрет и уносящий с собой сакральное знание?
А как же ваш коллега, уходящий в декрет и уносящий с собой сакральное знание?
А это по принципу Скарлетт - "подумаю об этом завтра" (с). У нас так несколько проблем рассосалось. Клиент получал кусок неработающего говна на пару кварталов позже прописанного в договоре срока и вариант "подождите ещё полгодика, мы все исправим!" его не устраивал, он разрывал договор - у нас, разработчиков, отпадала необходимость думать над решением)). Понятно, что при таком подходе денег мы не заработали, да и вообще вопрос о рентабельности проекта/отдела стоит остро, но блин, не понимаю, как мы (низы) модем изменить ситуацию сверху. А без разумного менеджмента мы так и будем "черти что и с боку бантик"...
Н.п.
Ну вот и закончился второй трехнедельный спринт. Я пока довольна. Реально стало более наглядно в вопросе "а чем это вы тут занимаетесь?" Правда, продуктменеджер нет-нет, да и съезжает на привычную модель "я скинул на е-мейл, там быстро", но, думаю, со временем научим и его в таких случаях по-новой приоризировать то, что уже есть в спринте.
Один вопрос меня смущает: длина спринта две или три недели было условием вышестоящего начальства. Но сейчас у нас идёт новая разработка, и за этот срок нереально произвести что-то "завершенное". Получается, что в конце спринта ни на ревью ничего толком не показать, ни в отдел тестирования не отдать...
нп
А у нас тут OKR (Objectives and Key Results) хотят ввести. Наше подразделение первый подопытный кролик.
Первое впечатление - прямая ассоциация с юностью проведённой в условиях реально сущесвующего социализма.
Типа мы поставим себе план и цели и будем их самоотвеженно опережать!
Есть ли у кого личный опыт с этим OKR?
Что-то похожее было в моей карьере, только там решили ввести канбан.
Расскажи, чем дело кончилось?
Н.п.
Отчитываюсь по нашему скраму. Мой коллега вернулся из эльтерцайт, работа закипела снова, но ему на скрам плевать. Его позиция - я сейчас в этом углу, так и напишу сразу все, а не кусками. Попритягивал в спринт кучу задач, которых не было, оставив лежать те, что были.
Плюс наш новенький чухнул в неизвестность, не дожив до конца исп.срока. Шустрый коллега с помощью начальства вывел и нашего "студента" (парень на аусбильдунга, которому за два года его обучения мы так и не смогли донести основы программирования,, максимум, что он может самостоятельно: корректировать тексты) из командного состава. Ибо товарища все время считали, как рабочую единицу, а по факту - работа делилась на нас двоих, а не троих.
Теперь, когда нас двое, вроде как скрам с его тысячью митингами совсем бесполезен. Хотят пробовать канбан)))
Теперь, когда нас двое, вроде как скрам с его тысячью митингами совсем бесполезен
Какие конкретно митинги бесполезны? Планирование спринта? Одна минута утром дабы скоординировать свои действия? Показ результатов работы в конце спринта? Или анализ и рихтовка процесса? Важно понимать цель конкретного рода митинга, а не его формальности.
Мы вдвоем, сидим друг напротив друга (только глаза выше монитора поднять, чтоб переговорить)... Когда оба "между задачами" - перебросились парой слов, кто где, вместо "положенного времени по утрам". Так же рефакторинг - столкнулись с проблемой, глаза подняли, обсудили, один из нас записал, сс отправили ПО. Ревью в конце - зачем, если мы по нескольку раз в день сливаем в общий код, чтобы не сильно расходились версии. То есть каждый видит весь функционал каждый день. Планирование спринта - нам ещё учиться и учиться этому процессу (зачем? Если сейчас это ТОРМОЗИТ разработку). ПО берет задачи, оцененные в пунктах, чтоб было "и больших, и маленьких, чтоб всего понемногу", не взирая, что некоторые задачи не могут быть сделаны ДО других, иногда даже нам, разработчикам, не сразу ясно, что эту задачу прийдется отложить... Поэтому разумней иметь просто набор задач и нам, разработчикам, брать их по мере готовности материала...
Скрам, как математика, "мозг в порядок приводит". Он может реально улучшить вашу мышиную возню (не в обиду, знаю о чем говорю), научиться структурированно работать и нормально планировать. То, что сначала выглядит как потеря времени, со временем приводит к повышению эффективности и удовлетворенности от результатов, как для вас самих, так и для ПО, и пользователей.
То, что вас двое, ничуть не мешает.
У нас на скрам-митингах проблема заключается в участии скрам-мастера. Нет ничего хуже человека, не понимающего сути выполненной или планируемой работы, но стремящегося не только участвовать в дискуссии, но ещё её и доминировать. Начинаются долгие обсуждения незначительных формальных деталей, переспрашивание известных всем остальным тем итд.
Я добилась только того, что он конкретно меня боится или недолюбливает. Остальным это вроде не сильно мешает или они не хотят разборок.
Я в скрамах уже 10 лет в разных ролях. Если перефразировать поговорку, то "кто в скраме работал, тот в цирке не смеется" :)
Правда я в больших корпах работал, поэтому тут своя специфика (за стартапы и др. шарашкины конторы не знаю). Тут это все сверху спускается и дополняет уже существующие бюрократические процедуры. На скрам-мастера или ПО в основном берут тех, кто ничего делать не может или не хочет. Кроме того, их нагоняют со стороны в т.ч. переученных из непрофильных направлений (ну типа всякие бывшие проект-менеджеры). Особенно в последние два года чтобы ненужных людей устроить. Ответная реакция разрабов разная. Например, скрытый саботаж путем увеличения оценок ну др. методами. Но есть и всякий молодняк, который занимается шапкозакидательством в попытке выпендриться и
маниакальным желанием прикрутить какой-то модный фреймворк или либу.
Но в целом метод медленно, но работает. Возможно, без скрама вообще ничего бы не делалось. Причина имхо в том, что люди наверху обычно не знают и не понимают что собственно делают разрабы. А люди внизу не очень понимают чего там делают наверху. Ну и еще добавляется scrum-of-scrums, agile release train и пр. сатанинщина. Я лично стараюсь держаться подальше от этих цирков или в идеале вообще не участвовать - нервы дороже. Но тут уж как получится - иногда не отбрехаться.
Так мы с ним и не работаем вместе. Я работаю, разработчики работает, а он отвлекает. С теми, с кем я работаю, я с большим уважением и тактом общаюсь.
На скрам-мастера или ПО в основном берут тех, кто ничего делать не может или не хочет. Кроме того, их нагоняют со стороны в т.ч. переученных из непрофильных направлений (ну типа всякие бывшие проект-менеджеры). Особенно в последние два года чтобы ненужных людей устроить.
скрытая безработица.
в основном берут тех, кто ничего делать не может или не хочет. Кроме того, их нагоняют со стороны в т.ч. переученных из непрофильных направлений
Плохо не то, что их нагоняют, а то, что их зачем-то учат доминировать. И это как мининмум комично.
Плохо не то, что их нагоняют, а то, что их зачем-то учат доминировать. И это как мининмум комично.
Вот это точно. Лишние люди есть всегда, но когда самые ненужные всях доминячат или "присматривают" за командой - это отстой .
И постоянно говорят "мы": "Мы смогли решить эту проблему", "Мы вовремя успели зафиксить баг". Так даже разработчик не скажет, если он не сам конкретно этот баг исправил. А кто-то сбоку припеку так выступает 
Вот статья неплохая:
https://www.golem.de/news/20-jahre-agiles-manifest-die-ges...
Интересны также комментарии, например:
"Ich kann ja falsch liegen. Aktuell sehe ich das wie folgt:
- oberes Management: Im Prinzip wollen die sich nicht damit abgeben wie die Software funktioniert. Es gibt Produktmanager und die wollen features, features, features.
- mittleres Management: kommt dann ggf. aus den Entwicklerteams und das Wissen schwindet da immer mehr. Die wollen sich auch nicht damit auseinandersetzen wie das aktuell noch funktioniert. Die geben nur die Sachen von oben 1:1 runter und reden ggf. noch mit rein weil sie denken, dass es noch so alles funktioniert wie früher. Längerfristige Planung ist da meistens Fehlanzeige
- Entwickler: Interessieren sich meistens dann nur für coole neue Features in der Programmierung. Am liebsten dann die neuste lib aus github einbinden. Meistens dann eher froh wenn man was zeigen darf im nächsten review. Das höchste der Gefühle ist dann, wenn sie mal unittests schreiben. Das ist aber meistens langweilig und doof.
- ScrumMaster, Personaler, sonstiges Personal: haben davon null Ahnung wie gearbeitet wird und fühlen sich völlig unentbehrlich.
was meistens komplett fehlt, sind dann Architekten, bzw. eine vernünftige Dokumentation und gute (System-/Integrations)Tests, bzw. Schnittstellen dafür. Meistens wird ja nur von Sprint zu Sprint geplant und dann verbaut man sich zukünftige Features, weil der Entwickler ja von der Vision nichts wusste. Tests abseits von Unittests gibts meistens nur manuell, weil man ja keine Schnittstellen spezifiziert, da man ja immer nur von Sprint zu Sprint arbeitet."
Похоже на наши наблюдения.
Разработчики, работающие ради прикольных новомодных техник, менеджеры, которые только диктуют новые фичи и главный бич - скрам-мастеры, которые в каждой бочке затычка, но не понимнают ничего.
А архитекторов, которые технически и стратегически координировали бы работу всех команд и выбирали бы подходящие всем техники, нет или мало.
Разработчики, работающие ради прикольных новомодных техник, менеджеры, которые только диктуют новые фичи и главный бич - скрам-мастеры, которые в каждой бочке затычка, но не понимнают ничего.
Ну это все как и желание доминировать это не грех скрама - этого и без него достаточно.
А архитекторов, которые технически и стратегически координировали бы работу всех команд и выбирали бы подходящие всем техники, нет или мало.
А вот отсутствие архитектора в скраме это меня всегда убивало. Но это факт. Ну типа если вы хотите строить себе дом без архитектора по скраму, то как это будет происходить. Построим сперва стены (это самое очевидное), но без фундамента (а зачем?) Потом в следующий спринт умный ПО скажет, что без крыши никак нельзя, а потому сделаем крышу. Но потом вроде как-бы надо фундамент, поскольку шатается конструкция. Поэтому снимем крышу, разберем стены, сделаем фундамент, а потом обратно. Потом ПО скажет, что надо бы окна сделать, но где и как решится в будущем спринте. Потом окажется, что места для дверей не осталось, потому надо окна в другом месте. Ну и т.п.
Но почему-то в софтвере именно так многое и делается. Архитекторов на свалку истории. И фичи привинчиваем по мере надобности. Видимо потому, что реально людей, кто бы имел план в стиле строительства дома или моста нет. Поэтому работу доверяют бригадам шабашников под руководством СМ, которые делают поэтапно что им скажут без ответственности за конечный результа, а только за один спринт.
У нас есть архитекторы и даже много (и вполне толковые), но они сами обычно спрашивают типа "пришлите мне архитектуру того, чего вы собираетесь делать". Т.е. они больше наблюдатели без ответственности, чем руководители проекта. А по мне так архитектор он и в африке архитектор и должен быть главным по любому инжинерному проекту.
Да, пассивная роль или отсутствие архитектора - для меня тоже главная проблема.
Правда, здесь регулярно говорят плохие слова про ПО и мне уже надоело оправдываться. Но в сложных бизнес-решениях, где речь не о не банальном магазине, а о сложных процессах, математических алгоритмах, симуляциях, оптимизации, ПО необходим.
В строительстве роль ПО как раз играет архитектор, и нормальный архитектор не только знает, что дому нужна крыша, но и во всех деталях описывает все части здания, включая эстетику, пропорции и выбор по ГОСТу оконных рам, дверей итд. А вот инженер-статик - тот, кто в разработке архитектор. Он решает, как сделать несущие конструкции.
А вот отсутствие архитектора в скраме это меня всегда убивало.
Эммм... кто мешает запланировать задачи для архитектора? Для дизайна? Для спецификаций? И так далее? С ревью и приёмкой? Вот для этого и существует ретро - чтобы понять необходимость таких вещей, и соответствующим образом модифицировать процесс.
Во многих командах просто нет архитекторов. Решения выбираются от балды - кому какая технология кажется круче и хайповее, а не по рациональным критериям. Это же агильно, что долго думать. Агильность поощрает хакеров, ненавидящих договариваться со смежниками и иметь концепцию. Архитекторы, если они все же есть, не учитывают потребности всех смежных модулей. Каждый делает свое, пусть и неплохое, но вместе это не работает или работает с трудом. Новые клиенты покупают сразу целый набор модулей и начинаются мучения с их установкой, авторизацией, автоматизации, внедрением в веб-фрейм итд.
А кто на ревью будет оценивать выполнение задач архитектором? Скрам мастер, ни бельмеса не смыслящий? ПО, который технические решения оценить не может? Он может задать перформантность и стабильное функционирование новых фич, но откуда он знает, не возникнет ли впоследствии конфликт с фичами следующих спринтов или с интерфейсами? Это могли бы частично решить тесты, но тесты это тоже больное место скрама, кроме юнит-тестов.
Ну это все как и желание доминировать это не грех скрама - этого и без него достаточно
Хотеть не вредно. Но такого рая для Шариковых всех мастей как в скраме где-то ещё вряд ли найдёшь. Не нужны ни знания, ни связи, ни пробивные способности, ни человеческие качества. Закончил двухнедельный курс, не требующий никаких базовых знаний, и тебя прямо с улицы возьмут на позицию, где ты с порога можешь доминировать.
Это могли бы частично решить тесты, но тесты это тоже больное место скрама, кроме юнит-тестов.
С чего бы это? Вы просто не используете ретро для рихтовки процесса. При адекватном подходе за пару месяцев всё приводится в работоспособную форму, за полгода - приближается к оптимуму. Ну и право голоса на ретро есть у всех. Берёшь и убеждаешь. Easy.
Но такого рая для Шариковых всех мастей как в скраме где-то ещё вряд ли найдёшь. Не нужны ни знания, ни связи, ни пробивные способности, ни человеческие качества. Закончил двухнедельный курс, не требующий никаких базовых знаний, и тебя прямо с улицы возьмут на позицию, где ты с порога можешь доминировать.
Тут на соседней ветке кто-то переориентироваться собирался...🤔
Пиф-Паф.Построим сперва стены (это самое очевидное), но без фундамента (а зачем?) Потом в следующий спринт умный ПО скажет, что без крыши никак нельзя, а потому сделаем крышу. Но потом вроде как-бы надо фундамент,
Пока будешь полтора года проектировать по ГОСТу, то, как говорится, все черепахи уже разбегутся. Сейчас темп жизни другой.
Потому да, лепят кое-как, но быстро. Нужна аналогия не с пропущенным фундаментом, а, например, строим навес, потом стены из веток, потом вырезаем окна, пристраиваем помещение из досок, потом крыша получше и так далее.
Классическая картинка про MVP, во втором случае всегда есть хоть и убогий, но хоть как-то полезный продукт.
С чего бы это? Вы просто не используете ретро для рихтовки процесса. При адекватном подходе за пару месяцев всё приводится в работоспособную форму, за полгода - приближается к оптимуму. Ну и право голоса на ретро есть у всех. Берёшь и убеждаешь. Easy.
Так а чья это роль в скраме - брать и убеждать писать правильные тесты или вабирать техники по рациональным критериям, учитывая мир вокруг? Ее-то как раз вроде как не предусмотрено.
Тут на соседней ветке кто-то переориентироваться собирался...
Кстати я уже когда писала, об этом подумала
Кто готов захватить лидерство и повести за собой - того и роль. Обычно моя.
Классическая картинка про MVP, во втором случае всегда есть хоть и убогий, но хоть как-то полезный продукт.
Это где как. Mы тоже живем в нашем времени, но стрoим сразу машину, пусть по частям. Потому что на самокате наши пользователи никогда кататъся не будут. Лучше будут ездить на такси, пока машину не доставили.
Кто готов захватить лидерство и повести за собой - того и роль. Обычно моя.
Так это редкость, что в команде находится разработчик с реальным, многогранным опытом в различных технологиях. С аналитическим мышленим, позволяющим принимать обоснованные решения, с умением видеть всю картину. Да еще с задатками лидера. Это придется в каждую команду нанимать технического лида извне. Либо искать хороших архитекторов. Но где они в системе скрама?
Н.п.
Все, мы сегодня официально похоронили скрам. Смешав все возможные митинги вместе))) этакий ревью, ретроспективу и рефакторинг с планингом заодно))) Переходим на канбан: два ПО, и я единственный разработчик на 30 часов 🤦 Ну круто, чо))) Но хоть от этого безумия, когда надо угадать, как работа пойдет в ближайшие три недели, и запланировать нереальное - ушли. Теперь - по мере поступления. Договорились, что держим тридцать открытых задач, отсортированных ПО по приоритетам. А я, как разработчик, сама решаю, что делаем и когда. По логике, а не по приоритету)))
Все, мы сегодня официально похоронили скрам
Здорово! Скорее весего с канбан будет лучше. А я вам теперь завидую!!! У нас невозможно просто так придти к разумному выводу, что 2 недели слишком короткий срок для выполнения сложных задач и прекратить всё это. Хотя больше нет сраммастерши, которая постоянно повторяла, что технический профан, поэтому встревала и одёргивала, и собственно не давала возможности ни к какому конструктивному разговору по существу, и всё же задачи планируют глобальные и всеобъемлющие, но в кратчайший срок и без описания. Я не програмирую софт, но консолидирую данные из разных гетерогенных систем и для моих заданий по краиней мере можно было бы обеспечить меня инструкциями к этим системам, но так не бывает...
Вообще абсурд - есть некий американский тул и есть течническая поддержка, котороj я не имею права показывать наши данные, имена серверов и проч.. Вот как мне с этим хотлайн проконсультироваться ничего им не показывая? А спринт уже в среду заканчивается...
Скорее наоборот, большинство с долголетним опытом, но дело не в этом. Нужен именно специфический опыт принятия решений по архитектуре и технологиям.
И я пишу именно о рамках скрама. Что любые рамки можно изнасиловать или расширить до неузнаваемости - не вопрос. Либо просто сказать: вот назначили вам ревью-митинг и давайте, растите, исправляет ошибки. Я могу прислать всем приглашение на митинг "стройте ракету и улетайте в космос", но этого мягко говоря недостаточно, если нет подходящих ролей и специалистов.