Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.
Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.
Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.
Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.
Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.
Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.
Основные обязанности и ответственность Product Owner при управлении Product Backlog:
Scrum Team (скрам тим) – собирательный образ команды, состоящей из Development Team, Scrum Master и Product Owner. Команда полностью самодостаточна и не зависит от внешних специалистов или заказчиков.
Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.
Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.
Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
User – пользователь продукта.
Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.
Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.
User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.
Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.
Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.
Sprint Goal (спринт гоол) – цель спринта.
Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.
Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.
Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.
Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?
Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.
Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.
Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.
Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.
Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.
Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.
Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.
Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.
Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.
123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.
User Story
Уточнение и оценка Product Backlog
Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?
Формируется Sprint. Sprint Planning Meeting. Scrum Poker
Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.
Scrum Poker (Planning Poker).
Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:
Daily Scrum Meeting
Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.
Sprint Review Meeting
Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?
Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.
Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.
Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.
Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.
Мини-справочник Scrum
Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.
Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.
Основные обязанности и ответственность Product Owner при управлении Product Backlog:
- определение элементов бэклога продукта;
- правильное расположение элементов для оптимизации достижения цели;
- обеспечение понятности и прозрачности Product Backlog;
- обеспечение прозрачности и понятности требований, над которыми предстоит работать всей Scrum Team;
- общая оптимизация для достижения наибольшей ценности работы Development Team;
- ответственность за понимание бэклога командой разработки.
Scrum Team (скрам тим) – собирательный образ команды, состоящей из Development Team, Scrum Master и Product Owner. Команда полностью самодостаточна и не зависит от внешних специалистов или заказчиков.
Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.
Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.
Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
User – пользователь продукта.
Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.
Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.
User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.
Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.
Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.
Sprint Goal (спринт гоол) – цель спринта.
Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.
Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.
Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.
Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?
Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.
Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.
Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.
Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.
Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.
Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.
Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.
Руководство Scrum
Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.
- Основные поля в карточке: id, название, важность, оценка, релиз, описание, автор, исполнитель;
- Дополнительные поля в карточке. Например, поле «Тематика» – рейтинг товара в интернет-магазине сейчас не нужен, а в рейтинг входят пара задач. Тогда можно изменить «важность» всех задач с этой тематикой;
- Задачи лучше разбивать по одинаковым типам.
Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.
123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.
User Story
- Получение от заказчика Бизнес-цели. Составляем Impact Map для каждой бизнес-цели: Why?->Who?->How?->What? (Зачем?->Кто?->Как?->Что надо сделать?);
- Формулировка User Story:
Будучи пользователем <…> я хочу сделать <…>, чтобы получить <…>.
Как менеджер склада я получаю отчет о товарных остатках, чтобы БЫСТРЕЕ принять решение;
Формулировка без ЧТОБЫ (так лучше).
Как <пользователь>, я <что-то хочу получить>, <с такой-то целью>.
Как менеджер склада я получаю отчет о товарных остатках БЫСТРЕЕ. - Разделение «актеров» на группы: целевая, важная, менее важная и т.д. Присвоение уникальных названий актерам в этих группах, даже если есть одинаковые роли «Пользователи системы»;
- Написание истории с точки зрения этих актеров с указанием уникальных названий;
- В результате можно увидеть, какие истории необходимы для актеров целевой группы, важной группы итд. Следовательно можно выстроить приоритет;
- Действие. Важно описывать историю на уровне «Что?» делает, а не «Как?», описать проблему, а не ее решение. «Как?» находится вместе с командой;
- Ценность. Отказ от формулировки «Чтобы». Для каких-то историй можно указать ценность истории в формате «Чтобы», но не для большинства;
- Переход с понятия «ценность» (value) на понятие «влияние» (impact). История не обязательно должна иметь ценность, но обязательно должна оказывать влияние на того актера, который указан в истории. Это влияние в конечном итоге ведет к цели;
- User Story разбиваются по важности и функциональности и далее разбиваются на задачи в бэклоге.
Уточнение и оценка Product Backlog
Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?
Формируется Sprint. Sprint Planning Meeting. Scrum Poker
Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.
- Первая часть митинга могут участвовать все.
Право голоса у Product Owner и Developer Team. Выбор User Story и Задач из Product Backlog в Sprint Backlog;
Формулировка цели спринта — Sprint Goal. Определение ценности для бизнеса. Краткое описание бизнес-цели, ради которой выполняется данный спринт. Помогает команде принимать бизнес-обоснованные решения, или альтернативные решения. - Вторая часть митинга участвуют только Scrum Team. Наполнение Sprint Backlog.
Определение, каким образом будет реализован объем работ. Обсуждение технических деталей;
Scrum Poker (Planning Poker).
Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:
- Scrum Master ведет собрание;
- Product Owner представляет краткие обзоры каждой задачи;
- Происходит обсуждение, задаются вопросы;
- Участники Developer Team выбирают по одной карте, потом переворачивают;
- Если в результате голосования есть большой разброс в очках, то выслушивают двоих, перевернувших карты с минимальным и максимальным значением;
- Затем голосуют вновь и присваивают задаче Story Points.
Daily Scrum Meeting
Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.
- Проводится в одно и то же время;
- Длится строго не более 15 минут. Решение проблем выносится за рамки митинга и в составе лиц, непосредственно затронутых данным препятствием;
- Все отвечают только на три вопроса, отвечают друг другу, не Scrum Master-у: Что я сделал вчера? Что я буду делать сегодня? Какие проблемы есть у меня и команды на пути к цели?
Sprint Review Meeting
Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?
Комментарии (22)
Co0l3r
24.08.2019 22:06Agile – это методология (наука), а Scrum – это метод достижения цели
Что за бредовое предложение я прочитал. Agile – это английское слово, которое всего лишь означает «гибкий». A Scrum – это одна из методологий гибкого управления проектами (но не наука).
mikechips
25.08.2019 23:13Мысль всего лишь подводилась к тому, что Agile — это обобщение, а Scrum — уже конкретная методология.
chilicoder
24.08.2019 23:39+1> Agile – это методология (наука), а Scrum – это метод достижения цели.
Agile — набор из 4 ценностей и 12 принципов. Все. Но попробуйте работать по этим принципам и соблюдать эти ценности.
Scrum — методология разработки (изначально дизайна автомобилей, но сейчас в основном софта). Считается, что позволяет работать в соответствии с agile принципами. На практике… мягко говоря не всегда получается. Да и, откровенно говоря, многие только декларируют, что работают по Scrum. Например, говорят, что работают по Scrum, а с пользователями не общаются. Или не делают Sprint Review. Или не делают Sprint Retrospective. и тд.
> Scrum Master
Забыли одну из самых ключевых функций scrum-master — устранение внешних блокировок. Хоть команды в скраме и самодостаточные в вакууме, но на деле очень даже зависимые (еще бы, это софт, а не машины). Поэтому неудивительно, что у команды возникают зависимости от решения задач другими командами. Так вот, скрам методология предполагает, что следить за тем, что сторонние команды действительно решат такие задачи, будет именно скрам-мастер.
> Story Points
Если мне не изменяет память не входит в методологию Scrum. Также как и Velocity.
> User Story
Вы написали много пунктов, но не написали главного. User story — это приглашение команде обсудить детали с пользователем. Это важно, т.к. люди, придумавшие User Story не предполагали, что команды будут бросаться пилить эти стори не поговорив. см Mike Cohen «User Stories Applied»
Lofer
24.08.2019 23:52Agile — набор из 4 ценностей и 12 принципов.
А можно поинтересоваться первоисточником на это утверждение?
Kanut
25.08.2019 00:24Lofer
25.08.2019 10:37-1А… эти «розовые сопли» наивых «пони на радуге», которые размазываются о пункты контракта «бюджет и сроки исполения», «штрафные санкциии» и «критерии приемки» :)))
Эти наивные «пони на радуге» так забавно бьются в истерике, когда приходят юристы, вставляют им этот манифест в одно место и «поджигают»…Kanut
25.08.2019 11:14Вы вообще о чём сейчас? Какие юристы? Это изьявление намерений со стороны разработчиков. Естественно оно само по себе не применяется автоматически к любому контракту. Просто как разработчик/фирма ты можешь следовать этому манифесту(и тогда уже при необходимости составлять соответствующие контракты с клиентами) или нет.
Но это именно та самая база, на которой строится Agile, как таковой. И именно тот первоисточник о котором вы спрашивали.Lofer
25.08.2019 15:43Но это именно та самая база, на которой строится Agile, как таковой. И именно тот первоисточник о котором вы спрашивали.
Нет. База для Agile строится на другом — на требованиях бизнеса, на бюджете, на рисках.
Обобщенные практики с конца 90х начала 2000х вылились в эту декларацию, причем не самого лучшего разлива. Этот манифест декларируют «что делать», но не объясняют «зачем». Спички детям не игрушка :)
Например «не правильный Agile» рекомендует:
- Первая рабочая версия системы должна быть создана как можно раньше, а сам продукт фактически проявляется из прототипов путем повторения итераций в цикле разработки.
- Прежде всего, поставляйте базовую функциональность.
- Не создавайте новых версий, если они не увеличивают ценность решения
- Осуществляйте частые итерации разработки.
- Формализуйте процедуры контроля изменений в проекте.
Вы путаете причину и следствие :)Kanut
25.08.2019 15:57Ещё раз: "Agile" базируется именно на этом манифесте и этот манифест считается его первоисточником.
Вы можете придумать гораздо более лучший концепт, который гораздо лучше соответствует требованиям бизнеса. Но если он не будет следовать манифесту, то это уже не будет "Agile".Lofer
25.08.2019 17:06History: The Agile Manifesto
In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the begeebers (you can’t use the word ‘shit’ in a professional paper) out of traditionalists.
…
Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as «hackers» are ignorant of both the methodologies and the original definition of the term hacker.
первоисточник, в котором сами авторы манифиста, это и говорят: решения бизнес проблем… иные Agile методологии.
«XP programming» книжка была уже в 2000 году- я ее изучал.
Как он может быть первоисточником если «or any of the other Agile Methodologies»
MSF 3 версии была уже в 2002 году.
Разработка методологии, публикация книг в 2000..2002 году это не 5 минут…Kanut
25.08.2019 17:34Я что-то не совсем понимаю в чём ваша проблема. Естественно у любого концепта могут предпосылки и предшественники. Но первоисточником «Agile» является именно «Manifesto for Agile Software Development».
Другое дело что «Agile» не подразумевает под собой абсолютно все методики и способы «гибкой разработки»(или как это правильно перевести на русский).
Lofer
25.08.2019 19:46-1Я что-то не совсем понимаю в чём ваша проблема.
Спасибо что беспокоитесь :)
Естественно у любого концепта могут предпосылки и предшественники. Но первоисточником «Agile» является именно «Manifesto for Agile Software Development».
Вы декларируете что манифест является «родоначальником» гибких методологий разработки. Но таковым он таковым не является, а «компиляцией» уже существовавших, детально проработанных и применяемых «других Agile» за годы до манифеста. Удачно распиаренный маркетинговый ход «Agile Alliance»
Это все равно что я напишу «манифест о солнечной системе» и его объявят родоночальником «гибкой астрономии»
Из ваших слов следует что до «Manifesto for Agile...» были «темные века» и о гибкой разработки не подозревали, не применяли. А как только появился манифест все получили «откровение», все внезапно «прозрели».
На мой взгляд, это введение в заблуждение :)Kanut
25.08.2019 20:24+1Вы декларируете что манифест является «родоначальником» гибких методологий разработки.
В каком месте я это делаю? Я «декларирую» что манифест является первоисточником одной гибкой методологии разработки под названием «Agile».
Из ваших слов следует что до «Manifesto for Agile...» были «темные века» и о гибкой разработки не подозревали, не применяли. А как только появился манифест все получили «откровение», все внезапно «прозрели».
Ещё раз: где вы такое у меня вычитали то? Статья про «Scrum» и «Agile», писал я здесь вроде бы тоже только про них. Даже вроде специально ещё уточнил что:
«Agile» не подразумевает под собой абсолютно все методики и способы «гибкой разработки».
…Lofer
26.08.2019 00:49Я «декларирую» что манифест является первоисточником одной гибкой методологии разработки под названием «Agile».
Это и есть введение в заблуждение.
«Agile» не подразумевает под собой абсолютно все методики и способы «гибкой разработки».
Именно что Agile общее название семейства методик XP, Scrum, Kanban, MSF и т.д.Kanut
26.08.2019 07:59Это и есть введение в заблуждение
Кого именно и каким образом я ввожу этим в заблуждение?
Именно что Agile общее название семейства методик XP, Scrum, Kanban, MSF и т.д.
Agile это общее название метожик, которые базируются или хотя бы выполняют манифест.
Но это не включает в себя абсолютно все гибкие методики и не означает что какая то отдельная Agile методика не могла существовать до появления манифеста и/или была подогнана под него позже.
И это то как понимаю Agile я и люди с которыми я работаю, работал или каким-то образом пересекался по этой теме в своей профессиональной жизни.
Похоже что у вас какое-то другое понимание Аgile, но лично мне сложно понять откуда оно взялось и на чём оно базируется.Lofer
26.08.2019 10:23Agile это общее название методик, которые базируются или хотя бы выполняют манифест.
Т.е если для выполнения бизнес требований придется кастомизировать процесс Scrum, таким образом, что «нарушится» хоть один пункт манифеста, он перестанет быть Agile? Например итерации не раз в пару недель а раз в пару месяцев (потому что так бизнесу нужно)
Одна из базовых целей Agile:
Agile methods are adaptive rather than predictive. Engineering methods tend to try to plan out a large part of the software process in great detail for a long span of time, this works well until things change. So their nature is to resist change. The agile methods, however, welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves
И это то как понимаю Agile я и люди с которыми я работаю, работал или каким-то образом пересекался по этой теме в своей профессиональной жизни.
Не могу отвечать за Ваше понимание или вашего окружения. Но если почитать первоисточники и «отцов-основателей» то обнаружим:
Базировалось на (прочие можно тоже найти):
XP (Extreme Programming)
During the early popularity of agile methods in the late 1990's, Extreme Programming was the one that got the lion's share of attention. In many ways it still does.
…
Scrum
Scrum also developed in the 80's and 90's primarily with OO development circles as a highly iterative development methodology. It's most well known developers were Ken Schwaber, Jeff Sutherland, and Mike Beedle.
Середина 2000-го года:
During the course of the workshop we decided to use 'agile' as the umbrella name, and came up with values part of the manifesto. The principles section was started at the workshop but mostly developed on a wiki afterwards.
а чуть ранее
The term 'agile' refers to a philosophy of software development. Under this broad umbrella sits many more specific approaches such as Extreme Programming, Scrum, Lean Development, etc.
…
Probably the most noticeable change to software process thinking in the last few years has been the appearance of the word 'agile'. We talk of agile software methods, of how to introduce agility into a development team, or of how to resist the impending storm of agilists determined to change well-established practices
…
This essay was originally part of this movement. I originally published it in July 2000. I wrote it, like most of my essays, as part of trying to understand the topic. At that time I'd used Extreme Programming for several years
Вы пытаетесь «быть святее Папы...» и искажете факты и их исторический порядок подгоняя под свое «ожидание», чем вводите в заблуждение.Kanut
26.08.2019 10:35Т.е если для выполнения бизнес требований придется кастомизировать процесс Scrum, таким образом, что «нарушиться» хоть один пункт манифеста, он перестанет быть Agile?
Именно так. Он может быть останется гибкой методикой, но перестанет быть Agile. Более того я слабо себе представляю как надо «кастомизировать» Scrum, чтобы он перстал быть Agile, но остался Scrum. Скорее это будет уже просто какая-то новая методика имеющая Scrum в предшественниках.
И в принципе ничто не мешает Agile отказаться от манифеста если он вдруг перестанет быть актуальным. Но опять же на мой взгляд это скорее будет новая группа методик, которая будет иметь какой-то свой новый «манифест»/набор базовых принципов и иметь Agile как предшественника.
Вы пытаетесь «быть святее Папы...» и искажете факты и их исторический порядок подгоняя под свое «ожидание», чем вводите в заблуждение.
Опять же если вы это так видите, то это ваше мнение. Мне наоборот кажется что ваше понимаие Agile сильно отличается от общепринятого.Lofer
26.08.2019 12:05Вы не согласны с авторами The Agile Manifesto
Я привел выдержки Martin Fowler — одного из его авторов, а так же «History: The Agile Manifesto»
Мои аргументы исчерпаны :)Kanut
26.08.2019 12:09Вы не согласны с авторами The Agile Manifesto
Я не согласен с вашим пониманием и интерпретацией. Потому что например для меня «Agile», как конкретная методика, и 'agile', как общий подход, это разные вещи. Для вас похоже нет ну или как минимум вы их постоянно смешиваете.
Но думаю да, дискуссия уже ни к чему новому не приведёт.
stalkers
25.08.2019 00:59>> Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса
— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.
Какие-то розовые слонята в голове у этого простигосподи «эксперта». Успешнее в чём? Что является успехом и его мерилом? Откуда цифры? Они как-то подсчитаны? По какой методологии и формуле? Почему он(а) считает, что работать «не зря» это всенепременнейше развивать бизнес? Не находит ли «эксперт», что, возможно, для некоторых «работать не зря» — это просто заниматься любимым делом и/или обеспечивать семью?
DragFAQ
Поделитесь у кого как происходит работа с «User story».
Кто именно дальше разбивает ее на задачи и должен ли он быть в теме разработки (быть техническим специалистом и понимать глубоко как устроен код и архитектура проекта)?
Kanut
У нас для «Уточнение и оценка Product Backlog» есть отдельный таймслот, который называется «Backlog Refinement».
Проходит перед planing или даже в течении предыдущего спринта. Участвуют ПО, весь devteam и при необходимости другие люди(например архитект всего проекта). И там в том числе решается насколько сложна user story, реализуема она в принципе или нет, как это выглядит в плане архитектуры проекта и есть ли зависимости от других команд/людей.
А на задачи user story разбивается уже на sprint planing. Или если видно что user story совсем банальная и её можно сделать в одиночку, то это потом при необходимости делает тот человек, которому она достанется.