Comments 36
Спасибо. Что делаете с задачами дольше пары минут, которые стоят с низким приоритетом — просто забываете по факту?
Почему svn, а не hg/git? Особенно если нужны ветки?
Интересная статья, только вот в большинстве случаев, к сожалению, по плану одно, а на деле другое.
Для этого у нас и проводятся ежедневные стендапы — они позволяют понять, где пошло расхождение с планом. Стендап проходит за 15-30 минут, основные вопросы всё те же:
— что за вчера было сделано;
— что за вчера не было сделано из запланированного и почему, какие проблемы возникли;
— что планируется сделать сегодня.
Разработчику понимание того, что завтра днем придется рассказывать, на что ушел сегодняшний день, очень хорошо помогает удерживаться в рамках плана. Тимлиду — уловить момент, когда пошло отклонение от плана и его скорректировать.
— что за вчера было сделано;
— что за вчера не было сделано из запланированного и почему, какие проблемы возникли;
— что планируется сделать сегодня.
Разработчику понимание того, что завтра днем придется рассказывать, на что ушел сегодняшний день, очень хорошо помогает удерживаться в рамках плана. Тимлиду — уловить момент, когда пошло отклонение от плана и его скорректировать.
30 минут стоя получается или у вас сидячий стенд-ап митинг?
Мне кажется очень долго. Детальные вопросы можно позже обсудить, а чтобы понять картину происходящего 5-10 минут должно хватать. У меня был опыт, когда каждому давали минуту-две по секундомеру, и вполне укладывались.
Мне кажется очень долго. Детальные вопросы можно позже обсудить, а чтобы понять картину происходящего 5-10 минут должно хватать. У меня был опыт, когда каждому давали минуту-две по секундомеру, и вполне укладывались.
Митинги сейчас сидячие.
Да, если все в порядке — то у каждого около двух минут на рассказ, как раз около 15 минут и получается. Если появляются новые задачи, либо возникают проблемы — то стендап затягивается. Мы считаем, что выгодно, когда вся команда (включая дизайнера и верстальщика) в курсе возникающих трудностей.
Да, если все в порядке — то у каждого около двух минут на рассказ, как раз около 15 минут и получается. Если появляются новые задачи, либо возникают проблемы — то стендап затягивается. Мы считаем, что выгодно, когда вся команда (включая дизайнера и верстальщика) в курсе возникающих трудностей.
UFO just landed and posted this here
Интересная статья, но было бы интересно почитать не только про планирование, но и про финальные стадии процесса.
Как оцениваются результаты по итогам?
Как делается релиз или CI?
Что происходит если задача не укладывается в запланированный срок по времени (например, нашелся фатальный баг в используемой библиотеке или что-то такое)?
Как планируются зависимости (по порядку и slack) задач? Например, процент «провала» посчитанный по количеству может быть высок, а из-за slack это на текущую итерацию не влияет на самом деле, что тогда?
Как оцениваются результаты по итогам?
Как делается релиз или CI?
Что происходит если задача не укладывается в запланированный срок по времени (например, нашелся фатальный баг в используемой библиотеке или что-то такое)?
Как планируются зависимости (по порядку и slack) задач? Например, процент «провала» посчитанный по количеству может быть высок, а из-за slack это на текущую итерацию не влияет на самом деле, что тогда?
Сколько времени у вас занимает детализация задач спринта? Какими обязательными характеристиками должна обладать каждая из задач?
Сейчас детализация занимает 2-4 часа. Когда мы начинали использовать эту методику — уходил почти весь рабочий день.
Формулировка задачи должна быть понятна всем разработчикам. Если есть какие-то важные для выполнения и не следующие из формулировки моменты, они выносятся в комментарии к задаче.
Критерий выполнения должен быть ясен и достижим. «Протестировать работу сайта» — задача практически невыполнимая. Если её заменить набором задач вида «протестировать сохранение настроек пользователя», то будет гораздо лучше — в каждом отдельном случае область работы четко очерчена. Это свойство важно ещё и при оценке времени выполнения задачи.
Кроме того, в нашей практике мы пришли к выводу, что задача не должна подразумевать переключения между разными частями проекта. Задача «изменить структуру БД для N» — хорошая, её можно писать в спринт. Задачу «изменить структуру БД и добавить поля ввода для новых атрибутов» надо разбивать на две части перед добавлением.
Формулировка задачи должна быть понятна всем разработчикам. Если есть какие-то важные для выполнения и не следующие из формулировки моменты, они выносятся в комментарии к задаче.
Критерий выполнения должен быть ясен и достижим. «Протестировать работу сайта» — задача практически невыполнимая. Если её заменить набором задач вида «протестировать сохранение настроек пользователя», то будет гораздо лучше — в каждом отдельном случае область работы четко очерчена. Это свойство важно ещё и при оценке времени выполнения задачи.
Кроме того, в нашей практике мы пришли к выводу, что задача не должна подразумевать переключения между разными частями проекта. Задача «изменить структуру БД для N» — хорошая, её можно писать в спринт. Задачу «изменить структуру БД и добавить поля ввода для новых атрибутов» надо разбивать на две части перед добавлением.
Вы видимо немного лукавите, когда пишите такие легкие тексты.
Возможно сейчас все так как написано, но когда-то было все не так.
Хочется почитать как раз про сложности.
Что например делаете, когда у программиста теряется заинтересованность/стимул?
Во-первых, как такие ситуации отслеживаете?
Во-вторых, как стимулируете?
Были ли случаи, когда программист по показателям из месяца в месяц падал. Что тогда?
Оцениваете всей командой? Или каждый разработчик оценивает свои задачи, чтобы он потом за нее отвечал (за нее и за сроки)?
У каждого разработчика своя скорость разработки — как оцениваете задачи в таком случае?
Как поощряете, как наказываете?
Возможно сейчас все так как написано, но когда-то было все не так.
Хочется почитать как раз про сложности.
Что например делаете, когда у программиста теряется заинтересованность/стимул?
Во-первых, как такие ситуации отслеживаете?
Во-вторых, как стимулируете?
Были ли случаи, когда программист по показателям из месяца в месяц падал. Что тогда?
Оцениваете всей командой? Или каждый разработчик оценивает свои задачи, чтобы он потом за нее отвечал (за нее и за сроки)?
У каждого разработчика своя скорость разработки — как оцениваете задачи в таком случае?
Как поощряете, как наказываете?
Вы правы, изначально оно было совсем не так. Основные сложности возникали с организацией: люди не хотели подниматься на стендапы каждый день, было желание пропустить этап оценивания при планировании. Решение — объяснить разработчикам, почему им так будет работать легче и придерживаться жесткой дисциплины, пока это не войдет в привычку. В нашем случае помогло.
Оценивание задачи идет всей командой. На первых спринтах оценки от реальности отличались порой в два-три раза в обе стороны. Сейчас получается достаточно точно, но на получение опыта у нас ушло около четырех недельных спринтов. Скорость разработки может служить основанием для пропорционального увеличения времени выполнения задачи. Напоминаю — команда небольшая и такие вещи легко держать в голове. Когда имеем дело с новыми разработчиками, ставится дополнительная задача вида «изучение архитектуры».
Заинтересованность/стимул — на эту тему было написано много статей, так что что-то новое я вряд ли скажу. Отслеживается это на стендапах и по количественным показателям — время переключения между задачами и скорость выполнения задач. Стимулы в каждом случае свои, иногда работает переключение на новый фронт работ или отпуск/отгул для отдыха. Иногда речь идет о повышении з/пл, если недоследили, либо премия в следующем месяце по результатам работы.
Провалов по показателям из месяца в месяц у нас пока что не было, команда подобралась хорошая. Если будет — постараемся разобраться, почему так происходит. При небольшом количестве людей мне кажется намного более эффективным с каждым таким случаем разобраться отдельно.
Оценивание задачи идет всей командой. На первых спринтах оценки от реальности отличались порой в два-три раза в обе стороны. Сейчас получается достаточно точно, но на получение опыта у нас ушло около четырех недельных спринтов. Скорость разработки может служить основанием для пропорционального увеличения времени выполнения задачи. Напоминаю — команда небольшая и такие вещи легко держать в голове. Когда имеем дело с новыми разработчиками, ставится дополнительная задача вида «изучение архитектуры».
Заинтересованность/стимул — на эту тему было написано много статей, так что что-то новое я вряд ли скажу. Отслеживается это на стендапах и по количественным показателям — время переключения между задачами и скорость выполнения задач. Стимулы в каждом случае свои, иногда работает переключение на новый фронт работ или отпуск/отгул для отдыха. Иногда речь идет о повышении з/пл, если недоследили, либо премия в следующем месяце по результатам работы.
Провалов по показателям из месяца в месяц у нас пока что не было, команда подобралась хорошая. Если будет — постараемся разобраться, почему так происходит. При небольшом количестве людей мне кажется намного более эффективным с каждым таким случаем разобраться отдельно.
Мне иногда кажется, что глубоко разбираться в причинах фейла вообще вредно (польза только одна — удовлетворенное самолюбие). Ну докопался я, допустим, узнал, что программист не справился с задачей, т.к. любит читать Хабрахабр по утрам и тратит на это драгоценное время. А дальше не факт, что лечение пройдет успешно. Чем больше я знаю — тем меньше я знаю :-). На каждой следующей итерации копать надо глубже. Проще — есть результат/нет результата. Если нет — банально либо не хватает времени, либо навыков. Говоря на языке физики, Работа = Мощность × Время. Неизвестных всего две.
Можно я позадаю несколько вопросов, которые интересуют меня и по которым мне интересен чужой опыт?
Например, ваша проблема «люди не хотели подниматься на стендапы каждый день» кажется очень знакомой. Интересует одно из ее проявлений, когда разработчик старше PM'а и успел поучаствовать в большем количестве проектов. Отсюда у него убежденность что тот способ работы, по которому он работает — лучший. Что он существенно опытнее PM'а и т.д.
При этом у этого же разработчика наблюдаются самые банальные проблемы: плохая координация своего времени, постоянная отвлеченность, в общем далеко не идеальная производительность. Нежелание планировать и давать оценки.
Были подобные проблемы? Как решались?
Например, ваша проблема «люди не хотели подниматься на стендапы каждый день» кажется очень знакомой. Интересует одно из ее проявлений, когда разработчик старше PM'а и успел поучаствовать в большем количестве проектов. Отсюда у него убежденность что тот способ работы, по которому он работает — лучший. Что он существенно опытнее PM'а и т.д.
При этом у этого же разработчика наблюдаются самые банальные проблемы: плохая координация своего времени, постоянная отвлеченность, в общем далеко не идеальная производительность. Нежелание планировать и давать оценки.
Были подобные проблемы? Как решались?
>В процессе спринта были добавлены задачи с более высоким приоритетом и задача была отложена
~14 дней спринт, 2 дня на планирование. <=12 дней не потерпеть?
~14 дней спринт, 2 дня на планирование. <=12 дней не потерпеть?
Ребята, вы систематический фейл спринта объявили нормой и даже прямо-таки включили в методологию…
Кстати, отличный вопрос. Если средняя длина спринта, скажем, 100 рабочих единиц, и делают в среднем по 100 рабочих единиц за это время, что лучше: поставить спринт на 95 и знать, что его выполнят (фактор победы) или поставить его на 105 как сейчас и, по факту, дать знать всем, что его не сделают до конца? В первом случае есть желание завысить время задачи, во втором, по факту, тоже — ведь задач-то явно больше, чем нужно, верно?
Точнее даже так: можно объяснить простыми словами, почему именно вы считаете это более эффективным?
Точнее даже так: можно объяснить простыми словами, почему именно вы считаете это более эффективным?
Нагружать задачи «с горкой» — это, по сути, акт недоверия команде.
Типа, «я знаю, что вы меня, манагера, на… ываете с оценками, поэтому я нагружу вам заведомо больше».
И, в результате, команда не только лишена радости («Ура!!! DONE!!!»), но и привыкает, что постоянные долги — это норма.
Некоторые почему-то думают, что «перегрузка» будет оказывать какое-то давление на разработчиков. На самом же деле, все ровно наоборот. Если результат заведомо недостижим, то «копаем от забора до обеда».
Типа, «я знаю, что вы меня, манагера, на… ываете с оценками, поэтому я нагружу вам заведомо больше».
И, в результате, команда не только лишена радости («Ура!!! DONE!!!»), но и привыкает, что постоянные долги — это норма.
Некоторые почему-то думают, что «перегрузка» будет оказывать какое-то давление на разработчиков. На самом же деле, все ровно наоборот. Если результат заведомо недостижим, то «копаем от забора до обеда».
Задачи с горкой мы стараемся не нагружать — это действительно плохо влияет на разработчиков. Мы предпочтем поставить спринт на 90-95 часов, но при этом с самого начала понимать, что могут и будут возникать проблемы и незапланированные задачи посреди спринта.
Причины:
— разработчики не находятся под стрессом невыполнимых сроков и видят, что результат достижим;
— у нас есть запас прочности на случай возникающих проблем;
— в случае если задачи закончатся, у нас всегда есть бэклог и PO.
Желание завысить время работы может возникнуть в любом случае. Решается проставлением времени задачи всей командой при планировании — когда никто лично не заинтересован в завышении оценки — и стендапами. Если разработчик увеличивает время задачи во время выполнения, он должен объяснить, почему так произошло.
Причины:
— разработчики не находятся под стрессом невыполнимых сроков и видят, что результат достижим;
— у нас есть запас прочности на случай возникающих проблем;
— в случае если задачи закончатся, у нас всегда есть бэклог и PO.
Желание завысить время работы может возникнуть в любом случае. Решается проставлением времени задачи всей командой при планировании — когда никто лично не заинтересован в завышении оценки — и стендапами. Если разработчик увеличивает время задачи во время выполнения, он должен объяснить, почему так произошло.
Проект велется лва года двухнедельными спринтами. Будет ли верным предположить, что описания функциональности готового продукта и, тем более, ТЗ на него у вас нет?
Готового — это финальной версии? Тогда документации на готовый продукт у нас нет, причину смотрите чуть ниже.
Документация по текущему состоянию проекта ведется одновременно с разработкой. Необходимое ТЗ на спринт создается до спринта.
Документация по текущему состоянию проекта ведется одновременно с разработкой. Необходимое ТЗ на спринт создается до спринта.
Вы правда думаете, что можно написать ТЗ на разработку социальной сети, потом сделать все по ТЗ и получить не УГ? :)
Как вы поймёте что проект готов?
Когда проект помрет, тогда и будет готов судя по всему.
Ответ выше был, в общем-то, правильным. Мы делаем социальную сеть. Пока она живет, мы её развиваем, правим найденные баги и добавляем новый функционал. Если «готов» читать как «закончена работа над проектом», то готовым проект станет только в момент закрытия.
Давно хочу понять, где в вашем проекте выхлоп? В вас вкладывают деньги, а отдача? Можете не отвечать, если это секрет.
«Практика от идеала сильно отличается, так что у нас в каждом спринте есть две мета-задачи — «разные мелочи» и «тестирование», которые, похоже, неискоренимы.» — следует ли из этих слов, что работа QA в вашей команде относится к «неискоренимым» ненужностям.
Просто к «неискоренимым». Действительно написал непонятно, поясняю.
Работа QA достаточно плохо вписывается в концепцию «цели — задачи». Когда тестировщикам ставится новая задача — например «протестировать добавление друзей по фидбеку от пользователя», ставить для неё цель достаточно глупо. Вместе с тем:
— мы хотим, чтобы работа QA была частью спринта;
— мы хотим уметь прогресс по ней наравне с другими задачами.
Потому мы договорились о выделении метацели, которая кочует из спринта в спринт. Всё незапланированное тестирование уходит подзадачами в неё. Это не более чем удобный организаторский приём.
Работа QA достаточно плохо вписывается в концепцию «цели — задачи». Когда тестировщикам ставится новая задача — например «протестировать добавление друзей по фидбеку от пользователя», ставить для неё цель достаточно глупо. Вместе с тем:
— мы хотим, чтобы работа QA была частью спринта;
— мы хотим уметь прогресс по ней наравне с другими задачами.
Потому мы договорились о выделении метацели, которая кочует из спринта в спринт. Всё незапланированное тестирование уходит подзадачами в неё. Это не более чем удобный организаторский приём.
Sign up to leave a comment.
Как мы поставили процесс разработки на проекте длиной в 2 года