Scrum
А что тогда ПО решает, если не вопрос что делать?
Типа, ПО наполняет бэклог, а что оттуда взять в спринт, решает команда
Господи, как маленькие дети. Полюбовно-то нельзя вопрос решить, создав процесс в котором учитываются все мнения? Приоритетность задач знает только ПО, взаимосвязи между задачами - команда. Дело СМ - вообще десятое.
У нас для этого делают "тандемы". Для снижения 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инимает неудобные решения, а сваливает ответственность на разработчиков.