И снова про story point
Прочитал статью Ron Jeffries про SP и с удивлением обнаружил, что… SP - это идеальные дни. С идеальными днями, как известно, надо еще оценивать фокус-фактор, заморачиваться с тем, чтобы его наращивать, но Рон говорит, что у них в XP-практике было проще - они умножали на 3, чтобы получить количество реальных дней.
Как (возможный) автор термина, ему оч жаль, что он его придумал, ибо:
- sp использует, кто как хочет, но не как было задумано
- использовать sp для ответа на вопрос «когда?» не самая лучшая идея
- сравнивать оценки sp с реальностью - как минимум пустая трата времени
- сравнивать команды через velocity - наверняка вредно
В статье Джеффри в целом выступает за следующие 2 пункта:
1. Если вы можете не использовать оценки - не используйте их. #NoEstimates
2. #Agile - это про то, как взять самое важное и поставить как можно раньше (если что Рон - один из подписантов http://agilemanifesto.org).
Ну и если они вам помогают, используйте на свой страх и риск, так как использовать это неверно оч даже вероятно:
- При планировании считать SP на человека (а не на команду)
- Сравнение команд
- Использовать velocity как одну из метрик, за которой смотрит менеджмент
- Как следствие девальвация SP (хакинг метрики в угоду «хорошему образу при плохой игре»)
- и тд.
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
Прочитал статью Ron Jeffries про SP и с удивлением обнаружил, что… SP - это идеальные дни. С идеальными днями, как известно, надо еще оценивать фокус-фактор, заморачиваться с тем, чтобы его наращивать, но Рон говорит, что у них в XP-практике было проще - они умножали на 3, чтобы получить количество реальных дней.
Как (возможный) автор термина, ему оч жаль, что он его придумал, ибо:
- sp использует, кто как хочет, но не как было задумано
- использовать sp для ответа на вопрос «когда?» не самая лучшая идея
- сравнивать оценки sp с реальностью - как минимум пустая трата времени
- сравнивать команды через velocity - наверняка вредно
В статье Джеффри в целом выступает за следующие 2 пункта:
1. Если вы можете не использовать оценки - не используйте их. #NoEstimates
2. #Agile - это про то, как взять самое важное и поставить как можно раньше (если что Рон - один из подписантов http://agilemanifesto.org).
Ну и если они вам помогают, используйте на свой страх и риск, так как использовать это неверно оч даже вероятно:
- При планировании считать SP на человека (а не на команду)
- Сравнение команд
- Использовать velocity как одну из метрик, за которой смотрит менеджмент
- Как следствие девальвация SP (хакинг метрики в угоду «хорошему образу при плохой игре»)
- и тд.
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
agilemanifesto.org
Manifesto for Agile Software Development
We are uncovering better ways of developing software
by doing it and helping others do it. These are our
values and principles.
by doing it and helping others do it. These are our
values and principles.
#Ретроспектива 15.07.2019
Какое-то время назад я сознательно стал вставлять в тренинги “базовый #agile” тему по декомпозиции задач.
В блоке обязательно обсуждается принцип #INVEST (вот старая статья на английском https://xp123.com/articles/invest-in-good-stories-and-smart-tasks, вот на русском https://link.medium.com/pLqmQddumY, но в целом гуглится на раз). Далее, выдаются шаблоны декомпозиции, по которым можно будет порезать в целом любую историю. В завершении участники тренинга решают кейс на декомпозицию (например «Карпаччо из слона» от Алистера Коберна).
Зачем я начал так делать? Потому что мне немного надоело смотреть на плоские burndown графики, которые появляются, когда команда планирует в спринт 1-2 больших историй, а дальше у владельца продукта в голове разыгрываются сценарии, что будет если ребята успеют/не успеют. От больших историй плохо всем (не только РО).
И тут забавный кейс из жизни про то, как можно запороть проект, через докидывание в него новых задач https://t.me/changemarketing/402
Друзья, а вы декомпозициею задачи, чтобы в спринт помещалось 5-10 шт, и чтобы соблюдался INVEST?
Какое-то время назад я сознательно стал вставлять в тренинги “базовый #agile” тему по декомпозиции задач.
В блоке обязательно обсуждается принцип #INVEST (вот старая статья на английском https://xp123.com/articles/invest-in-good-stories-and-smart-tasks, вот на русском https://link.medium.com/pLqmQddumY, но в целом гуглится на раз). Далее, выдаются шаблоны декомпозиции, по которым можно будет порезать в целом любую историю. В завершении участники тренинга решают кейс на декомпозицию (например «Карпаччо из слона» от Алистера Коберна).
Зачем я начал так делать? Потому что мне немного надоело смотреть на плоские burndown графики, которые появляются, когда команда планирует в спринт 1-2 больших историй, а дальше у владельца продукта в голове разыгрываются сценарии, что будет если ребята успеют/не успеют. От больших историй плохо всем (не только РО).
И тут забавный кейс из жизни про то, как можно запороть проект, через докидывание в него новых задач https://t.me/changemarketing/402
Друзья, а вы декомпозициею задачи, чтобы в спринт помещалось 5-10 шт, и чтобы соблюдался INVEST?
Xp123
INVEST in Good Stories, and SMART Tasks - XP123
XP teams have to manage stories and tasks. The INVEST and SMART acronyms can remind teams of the good characteristics of each.
Про чек-листы и Scrum Master’а
В некоторых компаниях, которые меняют процесс производства на agile-рельсы, имеется тенденция к “переименованию”. Так, если в командах работа организовывается по Scrum, то Владельцем Продукта называется бывший бизнес-аналитик, или какой-нить зам.зам начальника-прокси-не-пойми-кто. А в скрам-мастеры записывают либо по остаточному принципу (кого не жалко “потерять”), либо того, кому не нашлось места в новой ролевой модели (например, Scrum Guide ничего не говорит о роли руководителя проекта).
Scrum master — это принципиально новая роль — не возможно получить методом переименования. В Scrum заложено 2 цикла обратной связи, направленных на инспекцию работоспособности Scrum — это ретроспективы (#retro) и сам SM.
Из-за того, что роль новая и не до конца понятная, ей дают определение лоскутно, вырывая “понятные” блоки из Scrum Guide. Например, так "SM - это человек, который фасилитирует события Scrum в команде и снимает блокеры на пути движения команды”, тактично забыв сообщить, что SM стремится сделать крутую команду. Чем же определяется крутость команды? Уровнем проблем, с которыми команда может справиться самостоятельно (с) Асхат Уразбаев.
Из-за непонимания роли, люди стремиться свести ее к чек-листам. Если есть спрос, значит будет и предложение :)
Существует масса различных чек-листов по #agile #scrum и отдельно для #scrummaster
Например, подборку можно найти тут.
Мне лично понравился (хотя он и немного “староват”) чек-лист от Майкла Джеймса (Eng , Рус. ).
❓Чем он мне понравился?
Тем, что дает понимание, что же в фокусе внимания у хорошего SM?
1. Команда
2. ВП
3. Организация
4. Инженерные практики
⚠️ Со временем, у хорошего SM, фокус внимания с первых 2х пунктов со временем снижается, и начинает смещаться на оставшиеся 2.⚠️
❣️Пусть в компаниях будут клевые Scrum Master’а, которые понимают свою роль сильно за рамками фасилитации и работы с ВП.
В некоторых компаниях, которые меняют процесс производства на agile-рельсы, имеется тенденция к “переименованию”. Так, если в командах работа организовывается по Scrum, то Владельцем Продукта называется бывший бизнес-аналитик, или какой-нить зам.зам начальника-прокси-не-пойми-кто. А в скрам-мастеры записывают либо по остаточному принципу (кого не жалко “потерять”), либо того, кому не нашлось места в новой ролевой модели (например, Scrum Guide ничего не говорит о роли руководителя проекта).
Scrum master — это принципиально новая роль — не возможно получить методом переименования. В Scrum заложено 2 цикла обратной связи, направленных на инспекцию работоспособности Scrum — это ретроспективы (#retro) и сам SM.
Из-за того, что роль новая и не до конца понятная, ей дают определение лоскутно, вырывая “понятные” блоки из Scrum Guide. Например, так "SM - это человек, который фасилитирует события Scrum в команде и снимает блокеры на пути движения команды”, тактично забыв сообщить, что SM стремится сделать крутую команду. Чем же определяется крутость команды? Уровнем проблем, с которыми команда может справиться самостоятельно (с) Асхат Уразбаев.
Из-за непонимания роли, люди стремиться свести ее к чек-листам. Если есть спрос, значит будет и предложение :)
Существует масса различных чек-листов по #agile #scrum и отдельно для #scrummaster
Например, подборку можно найти тут.
Мне лично понравился (хотя он и немного “староват”) чек-лист от Майкла Джеймса (Eng , Рус. ).
❓Чем он мне понравился?
Тем, что дает понимание, что же в фокусе внимания у хорошего SM?
1. Команда
2. ВП
3. Организация
4. Инженерные практики
⚠️ Со временем, у хорошего SM, фокус внимания с первых 2х пунктов со временем снижается, и начинает смещаться на оставшиеся 2.⚠️
❣️Пусть в компаниях будут клевые Scrum Master’а, которые понимают свою роль сильно за рамками фасилитации и работы с ВП.
scrumguides.org
Home | Scrum Guides
Scrum is a framework for developing and sustaining complex products. The Scrum Guide contains the official definition of Scrum as authored by Ken Schwaber and Jeff Sutherland.
Интересный пост, который характеризуется фразой "сампожник без сапог" (учитель продактов, который сам не оч следует тому, как правильно). А еще спрашивают, зачем нужен независимый человек извне, который может тебе вовремя дать ОС? Вот именно за этим и нужен, потому что он 1) знает и 2) верит, как нужно делать без энтузиазма от нахождения в процессе. У нас это #agile_coach, в стартапах - это трекер. Суть дела не меняет.
Telegram
Венчур адвенчур
Вот уж точно, мотивация определяет поведение. Я так много рассказывал другим как делать продукты и строить организации, что почти поверил в то, что сам буду делать «правильно» когда настанет время. Время настало, но вместо постоянного общения с пользователями…
Тестирую гипотезу привлечения (acquisition)Один мой коллега подсказал, что для увеличения органики в трафике есть 2 идеи:
1️⃣ партнерка (кросс-продвижение)
2️⃣ мемасики ;;))
Буду тестировать #мемы
Все как всегда: смешно (а иногда и через боль) в основном лично мне, но если кому-то понравится, шарьте с друзьями и в чатиках (любая помощь зачтется в карме).
Все мемы будут в категориях #IT, #agile, #Продукт, #КровавыйИнтерпрайз ;;))
О результатах теста сообщу, когда буду подводить итоги месяца.
Не все то #agile и #бирюза, что так о себе говорит.
https://t.me/changemarketing/498
Будьте осторожны, остерегайтесь подделок(с)
https://t.me/changemarketing/498
Будьте осторожны, остерегайтесь подделок(с)
Telegram
Бабаева, к доске!
В 2011 году, пока была в Штатах, сделала в Zappos несколько заказов. В 2012 году они слили мои данные вместе с 24 млн. других клиентов, включая пароли, мейлы — в общем все, что у них было (по биллингу тоже, но только что у них хранилось, без кода и пр).…
#agile #mindset в #startup’ах
Один из принципов диалектики — это единство и борьба противоположностей. Этот принцип позволяет по-другому посмотреть на приведённые в ссылке статью.
1. Компании для развития нужно иметь большое видение, при этом в противовес надо сфокусироваться на чем-то маленьком (#mvp) и итерировать это маленькое для получения ценности
2. Надо понимать (и соответственно управлять) набор самых больших рисков, с которыми компания столкнётся в ближайшем будущем, и при этом надо откладывать решения на самый последний (из возможных) моментов, потому что мы постоянно учимся, получаем новые факты о продукте, клиентах и рынке, (в частности за счёт ранней и частой поставки) и принятие решения ‘заранее’ — это чистые потери — затрата интеллектуальных и временных ресурсов на то, что потом будет изменено ещё 1000 раз
https://hackerchick.com/agile-mindset-for-your-startup/
Один из принципов диалектики — это единство и борьба противоположностей. Этот принцип позволяет по-другому посмотреть на приведённые в ссылке статью.
1. Компании для развития нужно иметь большое видение, при этом в противовес надо сфокусироваться на чем-то маленьком (#mvp) и итерировать это маленькое для получения ценности
2. Надо понимать (и соответственно управлять) набор самых больших рисков, с которыми компания столкнётся в ближайшем будущем, и при этом надо откладывать решения на самый последний (из возможных) моментов, потому что мы постоянно учимся, получаем новые факты о продукте, клиентах и рынке, (в частности за счёт ранней и частой поставки) и принятие решения ‘заранее’ — это чистые потери — затрата интеллектуальных и временных ресурсов на то, что потом будет изменено ещё 1000 раз
https://hackerchick.com/agile-mindset-for-your-startup/
Abby Fichtner
Agile Mindset for Your Startup - Abby Fichtner
I got to share the stage with the other half last week at Harvard Innovation Lab, when Jeffrey Beir & I took turns presenting dueling views on building your startup. Myself from the product perspective, Jeffrey from the investor’s viewpoint. While we had…
Forwarded from Agile Collage
30 января пройдёт митам по несильно популярному, но очень мощному подходу работе с требованиями и тестированию: Specification by Example
Подробности
“Традиционная модель сбора требований и создания спецификации основана на большом количестве формальностей, передач и переводов “с одного языка на другой”. Бизнес-аналитики извлекают знания из заказчика, и делают по ним спецификацию, затем перекидывают их разработчикам и тестировщикам. Разработчики извлекают знания из спецификации и переводят их в исполняемый код, который потом передается тестировщикам. Затем тестировщики берут спецификации. извлекают знания из них и переводят их в проверочные скрипты которые исполняются над готовой системой, которая передается им от разработчиков.
В теории это должно замечательно работать и все должны быть счастливы. На практике этот процесс имеет существенные недостатки и обычно приводит к огромной разнице между изначально просил заказчик и что он на самом деле получает. Существуют огромные разрывы в коммуникации на каждом шаге. Важные идеи попадают в эти провалы и загадочным способом исчезают. После каждого “перевода” информация искажается и неправильно понимается, увеличивая степень отклонения от ожидаемого изначально поведения разрабатываемой системы. Независимая интерпретация может помочь исправить ошибочную интерпретацию разработчиков или может быть совершенно другой неправильной интерпретацией требований к системе.”
При помощи Agile-процессов разработки циклы обратной становятся значительно короче, поэтому проблемы обнаруживаются раньше. […] Однако, вместо обнаружения проблем нам в первую очередь нужно работать над тем как избавиться от их появления.”
Это выдержка из книги Gojko Adzic “Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing” вышедшей в свет в 2009 году. Прошло десятилетие, однако индустрия разработки ПО по-прежнему страдает старыми болячками. Давайте лечиться :)
На первом митапе в этом году мы начнем знакомиться с подходом Specification by Example(Spec.by Example, SbE). SbE - это когда все люди, участвующие в создании решения, совместно определяют требования. Подход помогает выявить пробелы и несоответствия в требованиях ещё до создания софта. При его помощи мы можем создать достаточный объем спецификаций, который потом превращается в “живую документацию” в виде автотестов и конечно же это сильно упрощает работу разработчиков и снижает риск создания “неправильного” ПО. Само название “Specification by Example” появилось на свет в 2004 году с легкой руки Мартина Фаулера, однако, сам подход “совместного анализа” уходит корнями в 90е (а может и ещё раньше) и имеет другие разные названия - Behavior Driven Development (BDD), Acceptance Test Driven Development (ATDD), Test-Driven Requirements и тд.
Нам предстоит поучаствовать в так называемом Specification Workshop, в ходе которого мы совместно создадим требования для настоящей IT-системы :)
https://www.meetup.com/ru-RU/Technical-Excellence/events/267932278/
#DevOps #Agile #Scrum
Подробности
“Традиционная модель сбора требований и создания спецификации основана на большом количестве формальностей, передач и переводов “с одного языка на другой”. Бизнес-аналитики извлекают знания из заказчика, и делают по ним спецификацию, затем перекидывают их разработчикам и тестировщикам. Разработчики извлекают знания из спецификации и переводят их в исполняемый код, который потом передается тестировщикам. Затем тестировщики берут спецификации. извлекают знания из них и переводят их в проверочные скрипты которые исполняются над готовой системой, которая передается им от разработчиков.
В теории это должно замечательно работать и все должны быть счастливы. На практике этот процесс имеет существенные недостатки и обычно приводит к огромной разнице между изначально просил заказчик и что он на самом деле получает. Существуют огромные разрывы в коммуникации на каждом шаге. Важные идеи попадают в эти провалы и загадочным способом исчезают. После каждого “перевода” информация искажается и неправильно понимается, увеличивая степень отклонения от ожидаемого изначально поведения разрабатываемой системы. Независимая интерпретация может помочь исправить ошибочную интерпретацию разработчиков или может быть совершенно другой неправильной интерпретацией требований к системе.”
При помощи Agile-процессов разработки циклы обратной становятся значительно короче, поэтому проблемы обнаруживаются раньше. […] Однако, вместо обнаружения проблем нам в первую очередь нужно работать над тем как избавиться от их появления.”
Это выдержка из книги Gojko Adzic “Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing” вышедшей в свет в 2009 году. Прошло десятилетие, однако индустрия разработки ПО по-прежнему страдает старыми болячками. Давайте лечиться :)
На первом митапе в этом году мы начнем знакомиться с подходом Specification by Example(Spec.by Example, SbE). SbE - это когда все люди, участвующие в создании решения, совместно определяют требования. Подход помогает выявить пробелы и несоответствия в требованиях ещё до создания софта. При его помощи мы можем создать достаточный объем спецификаций, который потом превращается в “живую документацию” в виде автотестов и конечно же это сильно упрощает работу разработчиков и снижает риск создания “неправильного” ПО. Само название “Specification by Example” появилось на свет в 2004 году с легкой руки Мартина Фаулера, однако, сам подход “совместного анализа” уходит корнями в 90е (а может и ещё раньше) и имеет другие разные названия - Behavior Driven Development (BDD), Acceptance Test Driven Development (ATDD), Test-Driven Requirements и тд.
Нам предстоит поучаствовать в так называемом Specification Workshop, в ходе которого мы совместно создадим требования для настоящей IT-системы :)
https://www.meetup.com/ru-RU/Technical-Excellence/events/267932278/
#DevOps #Agile #Scrum
Meetup
Вход в Meetup | Meetup
Not a Meetup member yet? Log in and find groups that host online or in person events and meet people in your local community who share your interests.
Forwarded from Agile Collage
18 марта пройдёт Play4Agile Meetup
Вот уже десятый год под Франкфуртом проводится конференция Play4Agile. Это площадка для обмена идеями, опытом по использованию игр в командах и организациях.
18 марта Agile-коуч Кадрия Кот поделится всем, что было особенно интересно на конференции.
https://leader-id.ru/event/45663/
#agile #facilitation
Вот уже десятый год под Франкфуртом проводится конференция Play4Agile. Это площадка для обмена идеями, опытом по использованию игр в командах и организациях.
18 марта Agile-коуч Кадрия Кот поделится всем, что было особенно интересно на конференции.
https://leader-id.ru/event/45663/
#agile #facilitation
Привал ⛺️ или причал ⚓️ , пока не решил, но точно пауза...
С 15.09.2020 на этом канале не выходят посты.
У этого есть ряд причин:
🔗 Смена работы и позиции
🔗 Огромная загрузка по приоритетам
🔗 Тема agile стала для меня слишком узкой
Однако интересные (возможно только мне 💆♂️) темы никуда не делались, и теперь они почти на 💯% никакого отношения к #agile #scrum не имеют (этим в моей команде занимаются другие люди, и они вроде справляются отлично;)), а крутятся вокруг данных🗄, их обработки и аналитики📈.
В более сжатом формате (иногда даже просто репост) я делюсь ими в другом канале https://t.me/VisualElephant
Сейчас там 66 постов, которые выходят с разной периодичности (ибо не может быть интересно ровно Х элементов в день 🧐), но в следующие пару лет я планирую его наполнить изрядно ♾
Если есть желание, присоединяйтесь.
Что будет с этим каналом я пока не знаю 🤷♂️
🤷🏻 возможно, у меня найдутся силы продолжить вести его (контента ещё много из неизданного),
🤷🏻 может появятся ребята, кто готов подхватить канал — будем посмотреть (контакты все есть — велкам).
Спасибо всем, кто был здесь все это время, комментировал 📝, писал в личку, всячески говорил спасибо и тем, кто просто читал 📚. Надеюсь, кроме моей личной прокачки, это ещё помогло кому-то в бизнесе 💰 или в работе с командами 🤗
Telegram
Visual Elephant
Каждому, кто работает с визуализацией данных нужна насмотренность на красивые графики, подходы и проч. В канале будут re-посты всех понравившихся мне визуализаций, статей по цветам, UI|UX, art и проч.
Видео от Simon Wardly про его #WardlyMaps у некоторых особенно рьяных #agile коучей может вызвать приступ неприятия.
У адекватных людей, которые хорошо знаю модель Киневин, про отсутствие серебряных пуль и ошибочность желания притянуть #scrum/agile/что-угодно к решению всех проблем, получат истинное удовольствие, как от контента, так и от манеры подачи.
Саймон с юмором и троллингом приводит интересные примеры необоснованных #digital-трансформаций.
Рекомендую к просмотру
У адекватных людей, которые хорошо знаю модель Киневин, про отсутствие серебряных пуль и ошибочность желания притянуть #scrum/agile/что-угодно к решению всех проблем, получат истинное удовольствие, как от контента, так и от манеры подачи.
Саймон с юмором и троллингом приводит интересные примеры необоснованных #digital-трансформаций.
Рекомендую к просмотру
YouTube
An Introduction to Wardley Maps (Simon Wardley)
Simon will be taking to the stage again at SEACON 2023 on Thursday 19th October in-person (The Oval, London) and live-streamed.
Join Simon, 30+ other amazing speakers and 400+ like-minded attendees by getting your ticket via https://www.seacom.online/seacon…
Join Simon, 30+ other amazing speakers and 400+ like-minded attendees by getting your ticket via https://www.seacom.online/seacon…
Всем привет.
Как некоторые из вас знают из моего fb, я вернулся в область орг.консультирования по #agile.
Как и ранее, я занимаюсь этим in-house: до этого в #СБЕР, а сейчас в #МВидео.
Как следствие, я начну/продолжу снова публиковать посты от своего имени.
Год обещает быть жарким, как по объёму работы, так и по новым инсайтам.
Как некоторые из вас знают из моего fb, я вернулся в область орг.консультирования по #agile.
Как и ранее, я занимаюсь этим in-house: до этого в #СБЕР, а сейчас в #МВидео.
Как следствие, я начну/продолжу снова публиковать посты от своего имени.
Год обещает быть жарким, как по объёму работы, так и по новым инсайтам.
В #МВидео есть школа #agile, которую сейчас ведем мы с Антоном Чижовым.
Весь 2й спринт мы говорим, что agile (scrum, kanban, less, you name it) — не серебрянная пуля, не работает принцип one fit for all и обязательно надо понимать, задача из какого домена (Cynefin) пришла. Мне кажется, отличная заметка на тему.
Весь 2й спринт мы говорим, что agile (scrum, kanban, less, you name it) — не серебрянная пуля, не работает принцип one fit for all и обязательно надо понимать, задача из какого домена (Cynefin) пришла. Мне кажется, отличная заметка на тему.
Telegram
Диаграмма Гатлинга | Управление проектами, Agile, Менеджмент
Некоторое время назад прочел книгу #NoProjects от Evan Leybourn, апологета Business Agility, и Shane Hastie, известного как автор программ в ICAgile. Книга с провокационным названием, но довольно понятным посылом. Авторы говорят, что мы, мол, живем в мире…
Доброе утро ☀️
Нам с Антоном Чижовым выпала честь выступать первыми на Agile Days 26 мая в 10:30.
Расскажем, как разработанная нами школа #agile помогла Даше поменять карьеру 👩🏫
Зы
Кстати, у меня ДР будет в день выступления.
Совпадения?… не думаю 🤣
Будем рады всех видеть!
Нам с Антоном Чижовым выпала честь выступать первыми на Agile Days 26 мая в 10:30.
Расскажем, как разработанная нами школа #agile помогла Даше поменять карьеру 👩🏫
Зы
Кстати, у меня ДР будет в день выступления.
Совпадения?… не думаю 🤣
Будем рады всех видеть!
Нашёл у Макса Дорофеева одну статью, откуда процитирую отрывок про #waterfall:
1. Сначала мы напишем все-все требования учтем в них всё-всё
2. Потом по этим требованиям мы сделаем архитектуру. Хорошую-прехорошую, чтоб не переделывать. Это будет не сложно, у нас же будут все-все требования
3. Дальше мы все это закодируем. По понятной архитектуре это просто.
4. Потом протестируем. По идее ошибок много быть не должно. Ведь все будет описано в ТЗ, нам будет все понятно. Ну и архитектура будет продумана до мелочей
5. Потом мы исправим те незначительные баги, которые найдут тестировщики
6. Затем мы напишем пользовательскую документацию. По готовому софту оно же легко
7. Дальше мы всех пользователей обучим. Тем более, когда документация есть, какие тут сложности?
8. Внедрим систему. Это уже будет совсем просто, так как пользователи обучены, документация готовая, ошибки исправлены, архитектура понятна…
9. Получаем профит. Ну и редкие запросы на незначительные доработки. Мы же в самом начале всё учли…
#scrum #agile
1. Сначала мы напишем все-все требования учтем в них всё-всё
2. Потом по этим требованиям мы сделаем архитектуру. Хорошую-прехорошую, чтоб не переделывать. Это будет не сложно, у нас же будут все-все требования
3. Дальше мы все это закодируем. По понятной архитектуре это просто.
4. Потом протестируем. По идее ошибок много быть не должно. Ведь все будет описано в ТЗ, нам будет все понятно. Ну и архитектура будет продумана до мелочей
5. Потом мы исправим те незначительные баги, которые найдут тестировщики
6. Затем мы напишем пользовательскую документацию. По готовому софту оно же легко
7. Дальше мы всех пользователей обучим. Тем более, когда документация есть, какие тут сложности?
8. Внедрим систему. Это уже будет совсем просто, так как пользователи обучены, документация готовая, ошибки исправлены, архитектура понятна…
9. Получаем профит. Ну и редкие запросы на незначительные доработки. Мы же в самом начале всё учли…
#scrum #agile
#ШколаAgile #ПерваяСтупень #Agile
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о первом воркшопе Школы, который посвящен agile-манифесту и модели Киневин👂
Кажется странным начинать учебу в Школе Agile не с Agile-манифеста?! Вот и мы так подумали и после первого потока Школы решили поменять последовательность воркшопов, так чтобы внутри каждого учебного спринта воркшопы были сбалансированы по hard и soft 💪
За деталями по воркшопу можно обратиться в документ, внутри которого есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблица с таймингом.
В настоящий момент пока еще доступна miro-доска
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и в PDF и пошарили все в папке.
В комментах напишите, стоит ли сразу начинать с темы agile и может лучше начать с чего-то софтового, например, c фасилитации?
🤙 Остаемся на связи
____
Сергей и Антон
Канал 2%
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о первом воркшопе Школы, который посвящен agile-манифесту и модели Киневин👂
Кажется странным начинать учебу в Школе Agile не с Agile-манифеста?! Вот и мы так подумали и после первого потока Школы решили поменять последовательность воркшопов, так чтобы внутри каждого учебного спринта воркшопы были сбалансированы по hard и soft 💪
За деталями по воркшопу можно обратиться в документ, внутри которого есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблица с таймингом.
В настоящий момент пока еще доступна miro-доска
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и в PDF и пошарили все в папке.
В комментах напишите, стоит ли сразу начинать с темы agile и может лучше начать с чего-то софтового, например, c фасилитации?
🤙 Остаемся на связи
____
Сергей и Антон
Канал 2%
Google Docs
Agile
Воркшоп. Agile-manifesto Цели Изучить модель Киневин и увидеть, что agile не является серебряной пулей, так как есть домены, где он не нужен. Понять, почему при всем этом все пошли в agile и при чем тут продуктовых подход. Изучить манифест Ценности, Принципы.…
#Статистика канала за #июль
Решил подбить статистику в канале по сделанным публикациям.
Получилось:
📚25 публикаций в июне (то есть почти каждый день! — в августе не чувствую в себе столько сил, но продолжу выполнять обязательства 2022г)
🫂 на канале стало 1900 подписчиков (это +240 человека за месяц)
Всем большое спасибо, что здесь, на канале, надеюсь, вы находите ценное для вас, для вашей работы и/или команд!
Если есть вопросы/пожелания по контенту, пишите мне @SergeArt
Ниже топ-посты за июнь!
👀
1️⃣ Что делать, если вам пишут в выходной или в отпуск?!
2️⃣ Первый Воркшоп в #ШколаAgile про #Agile #Киневин
3️⃣ Процесс найма agile-коучей
🎁
1️⃣ Запрос помощи у Community по раскрытию контента #ШколаAgile
2️⃣ Эффект Супер Марио или про выстраивание обучения в нормальных компаниях
3️⃣ Воркшоп ШколаAgile по обратной связи
ТОП собирал руками🤬
Если вдруг кто-то может помочь с API, чтобы можно было доставать всякие штучки из публикаций, напишите в комментах — буду благодарен!🥺
Решил подбить статистику в канале по сделанным публикациям.
Получилось:
📚25 публикаций в июне (то есть почти каждый день! — в августе не чувствую в себе столько сил, но продолжу выполнять обязательства 2022г)
🫂 на канале стало 1900 подписчиков (это +240 человека за месяц)
Всем большое спасибо, что здесь, на канале, надеюсь, вы находите ценное для вас, для вашей работы и/или команд!
Если есть вопросы/пожелания по контенту, пишите мне @SergeArt
Ниже топ-посты за июнь!
👀
Самые популярные (🔝 по просмотрам посты)1️⃣ Что делать, если вам пишут в выходной или в отпуск?!
2️⃣ Первый Воркшоп в #ШколаAgile про #Agile #Киневин
3️⃣ Процесс найма agile-коучей
🎁
Самые популярные (🔝по количеству public и private шарингу)1️⃣ Запрос помощи у Community по раскрытию контента #ШколаAgile
2️⃣ Эффект Супер Марио или про выстраивание обучения в нормальных компаниях
3️⃣ Воркшоп ШколаAgile по обратной связи
ТОП собирал руками🤬
Если вдруг кто-то может помочь с API, чтобы можно было доставать всякие штучки из публикаций, напишите в комментах — буду благодарен!🥺
Слезь с дохлой клячи
1️⃣ Люди, занятые в проектном бизнесе, по-разному приходят к #agile. В основном, правда, через боль (может это в ДНК сапиенсов, а может это просто потому, что мозг работает только, когда он должен обеспечить выживание?).
2️⃣ Я много работал в классических проектах, когда все все продумано заранее на год(ы) вперед. И мы даже как-то умудрялись попадать в сроки (да, но нет ;).
3️⃣ Когда не попадали даже с умножением на Pi винили во всем «качество планирования».
4️⃣ Снова и снова мы вкладывались в получение оценок сроков, но чудо случилось очень редко.
Ну не безумие ли это?
зы
Кстати, Эйнштей фразу про безумие возможно и не говорил, от этого, правда, только смешнее.
#NoEstimate
1️⃣ Люди, занятые в проектном бизнесе, по-разному приходят к #agile. В основном, правда, через боль (может это в ДНК сапиенсов, а может это просто потому, что мозг работает только, когда он должен обеспечить выживание?).
2️⃣ Я много работал в классических проектах, когда все все продумано заранее на год(ы) вперед. И мы даже как-то умудрялись попадать в сроки (да, но нет ;).
3️⃣ Когда не попадали даже с умножением на Pi винили во всем «качество планирования».
4️⃣ Снова и снова мы вкладывались в получение оценок сроков, но чудо случилось очень редко.
Ну не безумие ли это?
зы
Кстати, Эйнштей фразу про безумие возможно и не говорил, от этого, правда, только смешнее.
#NoEstimate
#ШколаAgile #ВтораяСтупень #Коучинг #Agile
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «Коучинг agile-команд».
В Школе есть 2 воркшопа по коучингу: «Коучинг agile-команд» и «Основы коучинга». Проведение воркшопов идет именно в такой последовательности. Причина такой “нелогичности” простая: агенты изменения на второй ступени большую часть времени проводят в работе с командой, поэтому необходимо, кроме фасилитации, которой посвящена большая часть первой ступени, дать еще инструменты работы с agile-командой в коучинговом подходе.
Cлоган для этого воркшопа можно сформулирвоать так:
Коучинг – путь к созданию команды мечты
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, какому коучингу вы уже успели обучиться: индивидуальному, групповоу, коучингу команд или еще какому-то?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Сашей Цоем и Марией Одинцовой (ведет канал про коучинг) в рамках запроса о помощи community.
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «Коучинг agile-команд».
В Школе есть 2 воркшопа по коучингу: «Коучинг agile-команд» и «Основы коучинга». Проведение воркшопов идет именно в такой последовательности. Причина такой “нелогичности” простая: агенты изменения на второй ступени большую часть времени проводят в работе с командой, поэтому необходимо, кроме фасилитации, которой посвящена большая часть первой ступени, дать еще инструменты работы с agile-командой в коучинговом подходе.
Cлоган для этого воркшопа можно сформулирвоать так:
Коучинг – путь к созданию команды мечты
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, какому коучингу вы уже успели обучиться: индивидуальному, групповоу, коучингу команд или еще какому-то?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Сашей Цоем и Марией Одинцовой (ведет канал про коучинг) в рамках запроса о помощи community.