Comments 11
Скрам нормально работает при фиксед прайс термс, если не зафиксирован скоуп работ.Сами говорите просто выполнение новых хотелок за счёт отмены начальных.
Дэйли митинги не про "сделал-буду делать", а про выявление проблем.
В том формате, в котором работаю я, проблемы могут оговариваться в рамках митинга сделал/не сделал, потому что… Если начинать обсуждать каждую проблему на митинге, может быть: а) слишком поздно, ибо часть времени уже потеряна б) потеряно много времени на обсуждение.
На грумминге выявляются предполагаемые проблемы, на дэйли озвучивается то, что на груминге было не выявлено по каким-то причинам. И решается как, кем и когда будет решаться проблема, если решение нельзя озвучить за 30 секунд. Имхо, конечно же.
Может не точно выразился, я имел в виду, что на дэйлике прежде всего озвучиваются проблемы, которые могут помешать достигнуть целей спринта, закрыть весь бэклог спринта. Если проблему можно решить за 30 секунд, то тут же и решается, если нужен митинг, то собирается после дэйлика. А если проблема такая, что решить её в рамках спринта нельзя, то решается фэйлим или отменяем спринт вообще, делаем груминг, плэнинг и начинаем новый спринт.
У меня на проекте, например, есть крутой тестировщик, которому я делегировал 90% обязанностей владельца продукта (оставшиеся 10% это то, что приходит мне от заказчика, а я уже передаю своему коллеге)
Эммм… Простите, но это не так работает в аутсорсе. Если вы пилите с заказчиком что-то по скраму, то роль РО — это только заказчик. Он накидывает в эклог требования, он их приоритезирует, он принимает у команды работу на sprint review. Ни Вы, ни QA не могут выполнять эту роль. Обычно Заказчику продают в помощь бизнес/системного аналитика, который прорабатывает бэклог и доводит юзер сотри до состояния ready for refinement/planning. Это удобно и Заказчику (у него по требованиям single point of contact) и команде — они задают вопросы по требованиям человеку в команде.
Дело в том что, когда оцениваете таски в часах, то часы получаются у всех разные, у кого-то уйдет 6 часов на создание доменной сущности (условный таск), у кого-то 7, у кого-то 8. В стори поинтах же у всех будет одинаково = 8.
Вы не совсем поняли что такое оценка сложности насколько я понял из написанного. Сравнивать часы и сотри поинты это сравнивать мягкое с кислым. Могу порекомендовать книгу Кона «Оценка и планирование Agile проектов».
Не нужно работать по вотерфоллу или по скраму, чтобы управлять проектами успешно. Нужно работать круто. Только и всего.
А чтобы не болеть — живите здоровыми.
Спасибо за рекомендацию, ознакомлюсь. В этом параграфе я писал о приятных бонусах стори поинтов (в том числе об оценке сложности). Стоило затронуть составление юзер сторис и потом перейти к оценке в часах с переводом в стори поинты.
По-моему, вы две разные ситуации обсуждаете.
Одна — заказчик согласен работать по скраму или даже настаивает на этом. Тут ПО должен быть со стороны заказчика и активно участвовать в процессах, быть готовым коммуницировать с каждым участником команды разработки без всяких "на ближайшую неделю у меня всё расписано, давай на следцющей обсудим". Приоретизация, первичное формирование сторей/фич и т. п. — его ответственность.
Вторая — подрядчик решает использовать скрам по своей инициативе, а заказчик говорит "Меня эти нюансы не интересуют, вот ТЗ, вот сроки — делайте. И будьте готовы, что у меня возникнут новые хотелки"
Разбитие фич/сторей на таски — отвественность команды всегда.
У меня на проекте, например, есть крутой тестировщик, которому я делегировал 90% обязанностей владельца продукта (оставшиеся 10% это то, что приходит мне от заказчика, а я уже передаю своему коллеге). Кроме того, что он занимается тестированием (а это он делает отменно), он еще ведет и пополняет бэклог, пишет доку, строит флоу и таблицы сущностей: проделывает огромную работу (не в ущерб своей основной), на которую у меня просто нет времени, ввиду занятости на других проектах.
Хочется верить, что тестирование не страдает от этого, и что этот крутой тестировщик получает вознаграждение за дополнительные обязанности.
Возможно у меня паранойя, но рискованно возлагать столько на одного человека, все может развалиться, если он/она вдруг уйдет.
Ну и вы так красочно расписали крутость тестировщика, что показалось, что он может и вас заменить, и все будет ок;)
Не буду спорить с тем, что присутствует басфактор, однако стараюсь его минимизировать — не отпускаю работу на самотек, проверяю сделанное и полностью погружаюсь в него, иногда прошу переделывать. Конечно, если вдруг он уйдет, будет грустно и сложно — все опять свалится на меня, а я, ввиду занятости на других проектах, буду делать эту работу некачественно, либо перестану спать вообще.
Насчет заменить не знаю — у него не будет времени на процессы, и на другие проекты, но если он в будущем станет пмом, я буду только рад.
Можно ли применять Scrum в аутсорс-разработке?