Comments 28
Спасибо.
Действительно, коротко, ясно, но достаточно для того, чтобы познакомиться с Agile
Действительно, коротко, ясно, но достаточно для того, чтобы познакомиться с Agile
Коротко и по делу, спасибо вам.
Интересно, а вы действительно разрабатываете по этому плану? Используете Task Board? И стараетесь все делать как в документе?
P.S. Честно первый раз даже так «кратко» настолько подробно вникаю в Agile/Scrum.
P.S. Честно первый раз даже так «кратко» настолько подробно вникаю в Agile/Scrum.
Все, что написано в этом чеклисте — мы используем в нашей практике.
Что касаемо TaskBoard — мы его не используем очень в редких случаях (Распределенная разработка аля Москва-Чикаго-Сингапур).
Это лучший способ визуализировать процесс разработки для команды, хороший способ сделать многие проблемы открытыми для решения внутри команды.
Что касаемо TaskBoard — мы его не используем очень в редких случаях (Распределенная разработка аля Москва-Чикаго-Сингапур).
Это лучший способ визуализировать процесс разработки для команды, хороший способ сделать многие проблемы открытыми для решения внутри команды.
Вообще, мне очень понравился ваш checklist, пожелание это в конце все таки сделать сноски от всяких «Planning poker». Пробежав по вашему блогу и чеклисту могу точно сказать, что на прошлой работе у нас был «типа agile», хорошо это или плохо сложно сказать, в настоящем Agile я не участвовал, но для меня он привлекателен.
В ближайшее время (месяц, два) мы постараемся выпустить книгу о Гибкой-разработке ПО с упором на Российский опыт (он отличен от Американского — ценности разные у нас). Сохраним локаничность стиля изложения, но добавим так же немаловажные аспекты разработки: долгосрочное планирование, организация тестирования, управление требованиями с кейсами отечественных компаний.
Кстати где можно скачать презентации, которые показывал Андрей на последней встрече?
Спасибо, с интересом прочитал.
Спасибо, ребят! :) очень полезный материал
Большое спасибо за чеклист!
После прочтения возникла пара вопросов.
Что делать в случае если команда не кроссфункциональна (верстальщик, 2 программиста, дизайнер-интерфейсник, тестировщик)?
У вас указаны пункты «В случае отставания от плана команда делает корректирующие действия», «Члены команд могут легко поменять план итерации». Означает ли это, что члены команды могут поменять план итерации внутри итерации?
После прочтения возникла пара вопросов.
Что делать в случае если команда не кроссфункциональна (верстальщик, 2 программиста, дизайнер-интерфейсник, тестировщик)?
У вас указаны пункты «В случае отставания от плана команда делает корректирующие действия», «Члены команд могут легко поменять план итерации». Означает ли это, что члены команды могут поменять план итерации внутри итерации?
Кроссфункциональность начинается с того, что вы снимаете ярлыки и решаете проблемы вместе(например: если у вас много задач по тестированию, то не нужно ждать пока тестировщик все доделает — помогите ему, сделайте кросстестинг (разработчик тестирует задачу, которую писал другой разработчик), или быть может в итерации много задач по верстке, возможно со времинем, разработчики могут помогать с версткой, верстальщикам и наоборот у нас были случаи когда, верстальщики начинали учить php и помогать разработчикам). Безусловно это не так просто начать, но это придает гибкости вашей команде и снижает риски. Как минимум должны быть кросфункциональны программисты. Дизайнеров — код учить писать не надо (используйте здравый смысл) :).
Корректирующие действия:
— Вы понимаете, что не успеваете. Идете к PO и говорите, что нужно сделать descope (убрать некоторые задачи)
Вы не успеваете и понимаете, что не правильно спланировали итерацию — лучше остановить итерацию и перепланировать.
Вы предоставляете информацию о ваших успехах — PO определяет, что делать со списком работ на итерацию (отменить, выбрать приоритетные, сфокусировать на одной и так далее...)
Корректирующие действия:
— Вы понимаете, что не успеваете. Идете к PO и говорите, что нужно сделать descope (убрать некоторые задачи)
Вы не успеваете и понимаете, что не правильно спланировали итерацию — лучше остановить итерацию и перепланировать.
Вы предоставляете информацию о ваших успехах — PO определяет, что делать со списком работ на итерацию (отменить, выбрать приоритетные, сфокусировать на одной и так далее...)
большое спасибо за инфу, распечатал, изучил. не понял только как строить графики с оценкой скорости выполнения задач. они там как-бы равнозначны, но ведь бывает задача на пять минут, а бывает на два дня…
1) Декомпозируйте фитчи на задачи. (Каждую большую фунциональность можно декомпозировать на несколько маленьких, каждую маленькую фитчу декомпозируем на задачи (написать класс, протестировать, база данных и так далее...))
2) Если итерация 1 неделя — рекомендуется декомпозировать задачи так чтобы они были не больше 8 часов елси 2 недели — то 13 если месячная итерация не больше 20.
3) BurnDownChart — вы сжигаете часы которые перешли в done. сжигаете столько сколько написано было на задачи. В чеклисте они не равнозначны. Иначе бы график сжигался бы равномерно, на картинками он скачками.
2) Если итерация 1 неделя — рекомендуется декомпозировать задачи так чтобы они были не больше 8 часов елси 2 недели — то 13 если месячная итерация не больше 20.
3) BurnDownChart — вы сжигаете часы которые перешли в done. сжигаете столько сколько написано было на задачи. В чеклисте они не равнозначны. Иначе бы график сжигался бы равномерно, на картинками он скачками.
и снова спасибо, теперь понятно.
еще вопрос:
если нет возможности повесить таскбар на стенку, какие программы/сервисы порекомендуете?
еще вопрос:
если нет возможности повесить таскбар на стенку, какие программы/сервисы порекомендуете?
Эхххх, давайте покоментирую. Сразу скажу, работу проделали не зря. Вещь очень достойная! Тем более ничего подобного пока не попадалось.
А теперь буду придираться:
1. «Команда сидит в одном месте (colocaltion) » — зря так сразу в первом разделе и первым пунктом :) Будто сами не видели распределенных скрам-команд :) Это тебование ортодоксального ХР, а не скрама.
2. «Для каждой фичи из баклога указаны приемочные тесты » — Зачем? Для каждой фичи, запланированной на эту итерацию — еще куда не шло. А для всего беклога-то зачем? Не исключено, что у меня половина беклога заменится совершенно новыми фичами и получится, что я зря для старых расписывал приемочные тесты. А если будете говорить, что приемочные тесты не надо расписывать подробно, то тогда чем этот пункт будет отличаться от следующего: «Для каждой фичи из баклога указан сценарий демонстрации»
3. «Все истории имеют оценки » — правильный пункт! Только место ему не в «Планировании итерации», а в «Product Backlog». Пока в бэклоге у нас есть юзер сторизы без оценок, у нас нет контроля проекта на макро-уровне.
4. «Длительность каждой из задач не превышает двух дней» — зачем тут абсолютная величина? Если спринт в неделю, а задачи в два дня, то по чеклисту я пройду, а берндаун будет похож на зубы акулы. Мое мнение: декомпозировать истории на задачи надо так, что бы каждый член команды, практически на каждом стендапе мог ответить на «Что ты сделал вчера», просто назвав ID завершенной задачи.
5. «Оценки задач каждый день корректируются» да ну? Мое ИМХО, оценки остаются как есть, просто если вскрылись сложности, то это повод добавить еще одну задачу, а не подкручивать оценку уже имеющейся. Но тут дело вкуса. Почему задача оказывается недооцененной? Скорее всего не учли, что нужно сделать еще то-то и то-то. «сделать еще то-то и то-то» — это уже дополнительные задачи.
6. «Члены команды могут легко поменять план итерации » — ээээ, а это как? Типа я не отвечаю за базар перед продакт оунером? ЗАхотел поменял, не захотел не помнял? :)
7. " Баклог продукта корректируется в соответствии с пожеланиями заинтересованных лиц ". Он не корректируется. Его корректирует продакт оунер! Естественно, учитывая пожелания заинтерисованных лиц. Когда беклог сам корректируется на основании мнении толпы стейкхолдеров (половину из которых занесло на демку случайным ветром) результат может не оправдать ожидания. Ну это так :)
8. «РЕКОМЕНДОВАННОЕ ЧТЕНИЕ » — а как же Алистер Коберн (Agile Software Development), Крэг Ларман (Agile andIterative software development: Manager's guide, вообще пипец полезно для новичков!)? :)
Буду ждать второго релиза. Кстати, очень неплохая заготовка под модель зрелости :)
А теперь буду придираться:
1. «Команда сидит в одном месте (colocaltion) » — зря так сразу в первом разделе и первым пунктом :) Будто сами не видели распределенных скрам-команд :) Это тебование ортодоксального ХР, а не скрама.
2. «Для каждой фичи из баклога указаны приемочные тесты » — Зачем? Для каждой фичи, запланированной на эту итерацию — еще куда не шло. А для всего беклога-то зачем? Не исключено, что у меня половина беклога заменится совершенно новыми фичами и получится, что я зря для старых расписывал приемочные тесты. А если будете говорить, что приемочные тесты не надо расписывать подробно, то тогда чем этот пункт будет отличаться от следующего: «Для каждой фичи из баклога указан сценарий демонстрации»
3. «Все истории имеют оценки » — правильный пункт! Только место ему не в «Планировании итерации», а в «Product Backlog». Пока в бэклоге у нас есть юзер сторизы без оценок, у нас нет контроля проекта на макро-уровне.
4. «Длительность каждой из задач не превышает двух дней» — зачем тут абсолютная величина? Если спринт в неделю, а задачи в два дня, то по чеклисту я пройду, а берндаун будет похож на зубы акулы. Мое мнение: декомпозировать истории на задачи надо так, что бы каждый член команды, практически на каждом стендапе мог ответить на «Что ты сделал вчера», просто назвав ID завершенной задачи.
5. «Оценки задач каждый день корректируются» да ну? Мое ИМХО, оценки остаются как есть, просто если вскрылись сложности, то это повод добавить еще одну задачу, а не подкручивать оценку уже имеющейся. Но тут дело вкуса. Почему задача оказывается недооцененной? Скорее всего не учли, что нужно сделать еще то-то и то-то. «сделать еще то-то и то-то» — это уже дополнительные задачи.
6. «Члены команды могут легко поменять план итерации » — ээээ, а это как? Типа я не отвечаю за базар перед продакт оунером? ЗАхотел поменял, не захотел не помнял? :)
7. " Баклог продукта корректируется в соответствии с пожеланиями заинтересованных лиц ". Он не корректируется. Его корректирует продакт оунер! Естественно, учитывая пожелания заинтерисованных лиц. Когда беклог сам корректируется на основании мнении толпы стейкхолдеров (половину из которых занесло на демку случайным ветром) результат может не оправдать ожидания. Ну это так :)
8. «РЕКОМЕНДОВАННОЕ ЧТЕНИЕ » — а как же Алистер Коберн (Agile Software Development), Крэг Ларман (Agile andIterative software development: Manager's guide, вообще пипец полезно для новичков!)? :)
Буду ждать второго релиза. Кстати, очень неплохая заготовка под модель зрелости :)
Спасибо, за ваши пожелания. Наша задача была не дать все, что мы знаем. А дать Академический минимум.
Думаю, читателям данного поста, будут интересны ваши замечания.
Думаю, читателям данного поста, будут интересны ваши замечания.
> 1. «Команда сидит в одном месте (colocaltion) » — зря так сразу в первом разделе и первым пунктом :)
Идея тут была скорее упомянуть, что людей, сидящих в разных комнатах надо бы свести в одну. Распределенные команды – тема отдельного чеклиста ИМХО.
> 2. «Для каждой фичи из баклога указаны приемочные тесты » — Зачем?
Соласен, исправлено – перенес оба пункта в чеклист для плана итерации
> 3. «Все истории имеют оценки » — правильный пункт! Только место ему не в «Планировании итерации», а в «Product Backlog».
Требовать, чтобы каждый пункт Product Backlog имел оценку на мой взгляд излишне жестко. Они должны регулярно оцениваться — это да.
> 4. «Длительность каждой из задач не превышает двух дней» — зачем тут абсолютная величина?… Мое мнение: декомпозировать истории на задачи надо так, что бы каждый член команды, практически на каждом стендапе мог ответить на «Что ты сделал вчера», просто назвав ID завершенной задачи.
Замечание принимается. Однако твой исправленный вариант ничем не лучше – имхо называть ID завершенной задачи есть антипаттерн. Если мы так напишем, половина людей решат, что это и есть цель daily scrum и он привратится в статус митинг :)
> 5. «Оценки задач каждый день корректируются» да ну?
Выкинул «каждый день»
> 6. «Члены команды могут легко поменять план итерации » — ээээ, а это как? Типа я не отвечаю за базар перед продакт оунером? Захотел поменял, не захотел не помнял? :)
Это я плохо сформулировал.Тут акцент был на слове «легко». Имелось ввиду, что не нужно просить скрам мастера поменять задачу да и вообще, что не скрам-мастер занимается актуализацией плана.
Сделал так: Все члены команды могут самостоятельно поменять план итерации: добавлять и удалять задачи, изменять статусы и оценки
>7. " Баклог продукта корректируется в соответствии с пожеланиями заинтересованных лиц ". Он не корректируется. Его корректирует продакт оунер!
Поправил :-)
8. «РЕКОМЕНДОВАННОЕ ЧТЕНИЕ » — а как же Алистер Коберн (Agile Software Development), Крэг Ларман (Agile andIterative software development: Manager's guide, вообще пипец полезно для новичков!)? :)
Добавил :-)
> Буду ждать второго релиза. Кстати, очень неплохая заготовка под модель зрелости :)
Сегодня выложу апдейт
Спасибо тебе огромное за замечания :-)
Идея тут была скорее упомянуть, что людей, сидящих в разных комнатах надо бы свести в одну. Распределенные команды – тема отдельного чеклиста ИМХО.
> 2. «Для каждой фичи из баклога указаны приемочные тесты » — Зачем?
Соласен, исправлено – перенес оба пункта в чеклист для плана итерации
> 3. «Все истории имеют оценки » — правильный пункт! Только место ему не в «Планировании итерации», а в «Product Backlog».
Требовать, чтобы каждый пункт Product Backlog имел оценку на мой взгляд излишне жестко. Они должны регулярно оцениваться — это да.
> 4. «Длительность каждой из задач не превышает двух дней» — зачем тут абсолютная величина?… Мое мнение: декомпозировать истории на задачи надо так, что бы каждый член команды, практически на каждом стендапе мог ответить на «Что ты сделал вчера», просто назвав ID завершенной задачи.
Замечание принимается. Однако твой исправленный вариант ничем не лучше – имхо называть ID завершенной задачи есть антипаттерн. Если мы так напишем, половина людей решат, что это и есть цель daily scrum и он привратится в статус митинг :)
> 5. «Оценки задач каждый день корректируются» да ну?
Выкинул «каждый день»
> 6. «Члены команды могут легко поменять план итерации » — ээээ, а это как? Типа я не отвечаю за базар перед продакт оунером? Захотел поменял, не захотел не помнял? :)
Это я плохо сформулировал.Тут акцент был на слове «легко». Имелось ввиду, что не нужно просить скрам мастера поменять задачу да и вообще, что не скрам-мастер занимается актуализацией плана.
Сделал так: Все члены команды могут самостоятельно поменять план итерации: добавлять и удалять задачи, изменять статусы и оценки
>7. " Баклог продукта корректируется в соответствии с пожеланиями заинтересованных лиц ". Он не корректируется. Его корректирует продакт оунер!
Поправил :-)
8. «РЕКОМЕНДОВАННОЕ ЧТЕНИЕ » — а как же Алистер Коберн (Agile Software Development), Крэг Ларман (Agile andIterative software development: Manager's guide, вообще пипец полезно для новичков!)? :)
Добавил :-)
> Буду ждать второго релиза. Кстати, очень неплохая заготовка под модель зрелости :)
Сегодня выложу апдейт
Спасибо тебе огромное за замечания :-)
Жаль, что ссылка не работает.
а где файл?
UFO just landed and posted this here
Sign up to leave a comment.
Agile-чеклист в помощь Agile-командам