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