Scrum
Совершенно согласна! ПO обязан составить концепцию для разработчиков и организовать составление технических концепций для бэкенда, а также макетов для фронтенда. Потом проверить, соответствует ли реализованное командой этим четким требованиям. А не писать команде "реализация не соответствеут требованиям клиента". Это вообще знак того, что ПО сел в лужу.
Заранее озаботиться передачей дел от уходящего в декрет коллеги должен бы был скраммастер, но и члены команды конечно тоже. В общем, ощущения, что ни ПО, ни скраммастер самый минимум своих функций не выполняют.
Проблема может и не их, но чем-то заниматъся как минимум оден день надо. У нас таких ситуаций не было, потому что ПО таких фокусов себе не позволяет, но иногда бывают небольшие простои и непонятки, и члены команды сами решают, чем им заняться в это время. Правда у нас всегда есть кто-то в доступе, с кем можно посолветоватъся и кто возьмет на себя ответственность за это решение.
Вообще не понимаю, в чем проблема. Пофиксить какой-нить баг или сделать небольшой рефакторинг всегда можно и даже нужно.
В общем, ощущения, что ни ПО, ни скраммастер самый минимум своих функций не выполняют.
Так мы только начали в это играть, ещё не поняли, как на практике применять))
ПО у нас образовался из бератора, который уже лет пять курирует проект на тему коммуникации с клиентами, опыта в написании концептов, да и вообще в объёмном мышлении нет. Совместно набиваем шишки....
Заранее озаботиться передачей дел от уходящего в декрет коллеги должен бы был скраммастер, но и члены команды конечно тоже.
Jain. Эта функция только для этого клиента и ни в одном другом проекте неприменима. Поэтому мы и разделили задачи, что парень пишет один, то, что больше никому не пригодится, а мы, оставшиеся, пишем другую максимально конфигурируемую функцию (с возможностью применить где-либо ещё). И ведь все шло, "как надо", мы на удивление получили возможность протестировать наши новшества через QS, проект считался завершенным, осталась установка. Как, когда и почему ПО стало понятно, что в концепт закралась логическая ошибка - неизвестно. Он до сих пор вне связи...
Это не ваша проблема.
Как бы да, но по факту - моя личная головная боль. Если изменения все же вносить потребуется. Сегодня обратилась к скраммастеру на тему "нужен митинг для передачи", на что получила ответ, что он может только рекомендовать, а не заставлять людей присутствовать. Логично, чо. Парень, который уходит (так уж получилось, самый умный из нас), экстренно латает все места, которые только может залатать до своего ухода. Поэтому передачу задачи, насчёт которой непонятно, будет или нет реализована, находит нерациональным. Я с ним согласна. Жаль, что если все же выстрелит - разгребать мне.
Вообще не понимаю, в чем проблема. Пофиксить какой-нить баг или сделать небольшой рефакторинг всегда можно и даже нужно.
Так не вопрос, чем заняться есть всегда. Но нас долгое время обвиняли в том, что занимаемся чем ни попадя (багфиксинг и рефакторинг, на разработку не оставалось времени), ввели скрам, чтоб наконец-то сдвинуть дело с мертвой точки, вот мы и мечемся теперь, пытаясь понять, что нам делать, если все же поддерживаем скрам, или плюнуть и растереть, и работать как раньше, "nach Abruf". Яркий пример привычности такого процесса - ПО и его письмо в понедельник с утра: "Ребят, обнаружил ошибку, почините по-быстрому и отчитайтесь о готовности!"
Так в том-то и дело, что это все зависит не только от вас, даже в большей части не от вас. Вы (разрабы) не можете взять и ввести скрам на одной шестой части суши, в эту игру должны играть все. И именно для этого и нужен скрам-мастер: его первоочередная функция - защита команды от посягательств ПО. Это все нужно обсуждать на ретро.
Я понимаю, это не все так просто. У меня были настоящие проблемы с ПО, он даже хотел меня выгнать из проекта, но в итоге притерлись :)
Поэтому мы и разделили задачи, что парень пишет один, то, что больше никому не пригодится
В этом и проявляется опытность ПО, что он не делает ставку на то, что пронесёт - пусть уходит без передачи дел единственный знающий человек, авось как-то вырулим, остальные напрягутся и сделают.
Теперь остальные сидят как-то так:
В скраме нет ПЛ :)
а он есть (с) ;-)
а он есть (с) ;-)
ПЛ или процесс? Без последнего прям грустно как-то)))
По факту, ПО решительным движением руки подписал то, что все косяки будем исправлять позже, а в этом спринте идём, как намечено 😏
Это наверно хорошо. А как же ваш коллега, уходящий в декрет и уносящий с собой сакральное знание?
А как же ваш коллега, уходящий в декрет и уносящий с собой сакральное знание?
А это по принципу Скарлетт - "подумаю об этом завтра" (с). У нас так несколько проблем рассосалось. Клиент получал кусок неработающего говна на пару кварталов позже прописанного в договоре срока и вариант "подождите ещё полгодика, мы все исправим!" его не устраивал, он разрывал договор - у нас, разработчиков, отпадала необходимость думать над решением)). Понятно, что при таком подходе денег мы не заработали, да и вообще вопрос о рентабельности проекта/отдела стоит остро, но блин, не понимаю, как мы (низы) модем изменить ситуацию сверху. А без разумного менеджмента мы так и будем "черти что и с боку бантик"...
Н.п.
Ну вот то, о чем я говорила ;)
Н.п.
Ну вот и закончился второй трехнедельный спринт. Я пока довольна. Реально стало более наглядно в вопросе "а чем это вы тут занимаетесь?" Правда, продуктменеджер нет-нет, да и съезжает на привычную модель "я скинул на е-мейл, там быстро", но, думаю, со временем научим и его в таких случаях по-новой приоризировать то, что уже есть в спринте.
Один вопрос меня смущает: длина спринта две или три недели было условием вышестоящего начальства. Но сейчас у нас идёт новая разработка, и за этот срок нереально произвести что-то "завершенное". Получается, что в конце спринта ни на ревью ничего толком не показать, ни в отдел тестирования не отдать...
Ну так вот и получается, что закрыли восемь юзерсториз, на бумаге отчётность, а на экране - две цифры неотформатированные...