Scrum
Так вот, тот, который fachlich (и с которым мы работали до сегодняшнего дня), тоже, как и Алла, удивлен, что до продукта, собственно, задачи не доходят. Все какие-то организационные моменты и технические необходимости. Я, как разработчик, понимаю, что если не починим основание, колдовать над фичами по меньшей мере нерационально.
Да я как раз понимаю необходимость чинить технику, инвестироватъ время в архитектуру итд. Я не понимаю, какие претензии могут быть о мне как к ПО, если в результате фичи продукта имплементируются очень медленно. Если мне выдали машину, которая ездит с максимально 50 км/час, и я не автомеханик и не шофер, а пассажир и навигатор, то не моя вина, что я прибуду к месту назначения позже назначенного срока. Значит срок назначен неверно, либо неверно выбрана техника. Но не я оба этих решения принимаю, зато я оказываюсь невинной жертвой. Которой выдвигают обвинения, что она выбрала неправильный маршрут, сбилась с пути итд. Но е-мое, если расстояние по прямой известно, и скорость известна, то какие могут быть основания для этих подозрений?
Судя по тому, что Вы описывали ранее, я бы подумала что скрам, это то что вам нужно. Вы ответственны только за те задания, которые вы, реалистично оценив ауфванд, сами себе смогли "застолбить". Ни кто больше не сможет на вас что-то взвалить. Коллеги тоже не смогут, важные задания оставить на потом, потому как, если вы от них зависите, то ваши часы просто перестают тикать "blocked internal/external". И сразу станет заметно, что у вас, salopp gesagt, некому работать
ПС: прочла только что, оказывается выше вам уже написали что-то подобное, сорри.
НП
...и да, пенетрантные скрам-мастера сильно бесят! Наша "мастер" к счастью ушла в декрет. А то ведь так назрело, что за очередное одёргивание илi мотивирующую "шутку-прибаутку" хотелось уже ей отвесить
Значит срок назначен неверно, либо неверно выбрана техника. Но не я оба этих решения принимаю, зато я оказываюсь невинной жертвой. Которой выдвигают обвинения, что она выбрала неправильный маршрут, сбилась с пути итд.
А как вы хотели? Это часть стандартной офисной возни: кто на кого спихнет ответственность, кого накажут за провалы и кого наградят за успехи (реальные или мнимые). Вы наверное недавно в руководстве?
Судя по тому, что Вы описывали ранее, я бы подумала что скрам, это то что вам нужно.
Дай Бог! Я только "за" хоть какую-то системность. То, что не верю в реалистичность - это другое.
Вы ответственны только за те задания, которые вы, реалистично оценив ауфванд, сами себе смогли "застолбить". Ни кто больше не сможет на вас что-то взвалить.
Вот именно это и смущает. В частности, сегодня вышла проверить почту, и уже вижу, как идёт первый спринт. Т.к. в июле первая крупная продажа нашего проекта в этом году, то начальство заинтересовано в минимальном качестве. И у тестировщиков "вдруг нашлось время". Соответственно, запланированные задания сместились под давлением вернувшихся из тестирования багов. А т.к. планировать, когда у тестировщиков будет "свободная минутка" мы не можем, то и включить потенциальное время на устранение багов в спринт не получается. Ладно, будем считать, что это просто первый блин комом 😉
Тестирование это отдельная тема. Вообще-то тесты должны быть интегральной частью разработки. И каждая фича должна перед деплойментом быть протестирована всеми возможными способами. Юнит-тесты вообще часть разработки, насколько я понимаю. В Build-Pipeline проходят тесты. Акцептанc-тесты, автоматические и мануальные. Автоматические систем-тесты, UI-Тесты. Это все должно быть частью процесса. То есть многое тестируют прямо разработчики. И после всех этих тестов и отправки апдейта клиентам, не должно обнаруживаться множества багов. Естественно, на системе клиента что-то может пойти не так из-за иных условий чем в системе разработки, но это все должно держатъся в рамках.
А если у вас просле проверки экстернами-тестировщиками все время начинает уходить на устранение багов, то значит в разработке что-то идет не так.
Баги очень мешают выполнять всё запланированное. У нас "баг" не заschитывается как полноценное задание и времени на него не зарезервировано. Но вам бы следовало только баги исправлять, к кторым вы как разработчиk физически причастны. Нужно просто привыкнуть не щёлкать клювом на планунгсмитинге. А еще лучше "обнаглеть", иначе с ума можно сойти от давления
если у вас просле проверки экстернами-тестировщиками все время начинает уходить на устранение багов, то значит в разработке что-то идет не так.
Логично. Мы латаем, то что сыпется на лету. Проект, написанный человеком-самоучкой, мы переняли после года с момента его увольнения. Документации нет, как должно работать - пытаемся угадать из кода. Видимо, не до всех углов добрались, раз до сих пор падает на тестировке. То, что на внутренней не упадет - знаю точно... До мая месяца нас было двое (кто помнит мою историю про быстрого/медленного коллегу - так медленного от нас убрали), и "мышление у нас одинаковое". Что встроили, то и протестили, а где ещё зацепит по касательной - видим не всегда. Надеялись, что с расширением команды - будет лучше тестирование, но "что там с командой" - я уже описала выше 😒
Юнит-тесты вообще часть разработки, насколько я понимаю. В Build-Pipeline проходят тесты. Акцептанc-тесты, автоматические и мануальные. Автоматические систем-тесты, UI-Тесты. Это все должно быть частью процесса.
Это все - должно быть. Но этого нет. И времени, чтоб даже начать вкручивать хоть понемногу - тоже нет. Сейчас две крупные задачи до сентября, двух товарищей надо по-быстрому вработать (то есть объективно рассчитывать на их участие в проекте раньше декабря - не приходится), ещё один разработчик уходит в эльтерцайт. То есть остаюсь я "на все случаи жизни": текущие инсталляции, активная разработка/тестирование, введение новых коллег в материал и "срочное разруливание проблем клиента". Понимаю, что до автоматизированных тестов не дойду. Дай Бог мануальные своими силами провернуть.
И надостаток ресурсов с помощью скрама можно сделать более явным.
Я так и предполагал всегда, что его придумали для того, чтобы раздуть персонал :)
Нанимается скрам-мастер за кучу денег, который создаёт видимость бурной деятельности, генерит кучу бесполезных митингов и всем мешает.
А что ещё ему остаётся делать, чтобы своё существование оправдать. Мне кажется, скрам-мастер как отдельная должность имеет смысл только для ооочень большой организации. У нас фирма маленькая и стратег по совместительству скрам-мастер. Думаю, у него в неделю часа 3 на эту обязанность уходит. Был бы отдельный человек для этих целей, так точно бы всем только мешал, чтобы хоть как-то своё рабочее время занять.
Да! Опасное сочетание избытка свободного времени, недостатка знаний и желания оправдать свое существования несет нехорошие плоды 
Я подозреваю, что скрам-мастера ещё придумали, чтоб ПО быстрее крутил педали, их "экологические ниши" немного пересекаются.
Я ПО и со скрам мастером никак не пересекаюсь. Все вопросы бизнес-логики или координации технических обновлений полностью на мне. Как может скрам-мастер после двухнедельных курсов конкурировать с ПО, у которого многолетний опыт работы у одного из крупнейших клиентов рынка, на который мы работаем, финансово-математическое и инженерное образование, острый ум и модные платья?
Ни разу не видел "чистого" скрам мастера. Всегда у него есть ещё и другие задания и роли. В том числе это может быть и Product Owner. Я вроде не на маленькой фирме работаю.
Так вы ж вроде жаловались недавно, что только скрам-мастер решает, что включить в спринт...
Но против таких козырей как модные платья не попрёшь, конечно.
Н.п.
Ну вот скрам, такой скрам 🙈
Первый спринт закрыли, ревью сделали, оценили наши успехи/провалы, распланировали второй. Сегодня старт. Утром в почтовом ящике письмо от ПО: "Ребята, косяк, тот проект, что мы устанавливаем 1.07 и уже протестировали - не соответствует заявленным требованиям клиента" 😯 Ну, мы ж не зря просили написать концепт перед началом разработки... Нам его "как-то там" написали, парень, который программировал именно эту часть, догадывался, что так будет, поэтому перед началом разработки все же представил детальную выкладку перед ПО, объяснив, что от чего зависеть будет и как он это сделает. Получил "добро", принялся за реализацию. И вот сегодня - сюрприз. Сюрприз ещё и в том, что парень через два дня уходит в эльтерцайт, знания по этой части проекта только у него (и, как водится, не задокументированные), мы в стадии активного старта другого проекта...
В общем, зависли сегодня. А, да, ещё ни одного руководителя на месте не оказалось. ПО на выезде у клиента, недоступен, технический руководитель по понедельникам не работает, скраммастер сказал, что он такие решения (ставить эту информацию, как блокер спринту) не принимает. А мы растерялись: то ли вымучивать из товарища последние два дня знания, которые у него есть по "косячной" части проекта, то ли дальше писать проект, который стартует. Если брать "строго по скраму" - задача с ошибкой ещё не внесена в спринт, значит, работаем над текущими задачами в порядке приоритета...
А как вообще быть должно по уму? Наверное, если б не парень в отпуск, не было бы такой истерики - день-два подождать ПО. Но опять же, там изменений на добрых недели три, и это если опустить тестирование QS... Как впредь избежать таких ошибок? С нашей, программистской, стороны все чисто, на что опирались (концепт) есть, но даже если это ошибка ПО - осадочек неприятненький. Не сделала в срок команда...
Так вы ж вроде жаловались недавно, что только скрам-мастер решает, что включить в спринт...
Решает он в том, смысле, что следит за тем, чтобы ПО не решал, что включать в спринт. Сам он решать не может по причине отсутствия нужной информации.
А с какой целью ПО написал вам "Ребята, косяк, тот проект, что мы устанавливаем 1.07 и уже протестировали - не соответствует заявленным требованиям клиента"?
Цhего он от вас ожидает?
Это косяк ПО. Он должен четко знать «как должно быть» и убедиться, что его представление совпадает с представлением заказчика.
Косяк ваш как команды в том, что есть большой кусок функционала, в котором разбирается только один человек, и двойной косяк - что не организовали передачу дел от уходящего в эльтернцайт сотрудника. Ведь помимо того, что надо все переделать, там могли позже найтись баги, необходимости доработки и тд.
Как этого избежать впредь: ПО согласовывает концепт с заказчиком до начала разработки + уходящие организовывают грамотную передачу дел + все важное должно быть задокументировано ещё на этапе разработки.
