На выходных ребята опубликовали русский перевод эпичного кейса из заказной разработки ПО, когда Hertz заказал у Accenture новый сайт-приложение и в итоге обе большие и известные компании этот проект не осилили, дело закончилось судом.
Рекомендую почитать как тем, кто разрабатывает софт, так и тем, кто его заказывает - я думаю каждый сможет провести много параллелей со своим опытом. Дело было в 2017-19 годах, но сути это не меняет 🙂
https://vc.ru/dev/468325-keys-kak-kompaniya-hertz-zaplatila-agentstvu-accenture-32-milliona-dollarov-za-veb-sayt-kotoryy-tak-i-ne-zapustilsya
Оригинал на английском здесь: https://www.henricodolfing.com/2019/10/case-study-hertz-accenture-website.html
Рекомендую почитать как тем, кто разрабатывает софт, так и тем, кто его заказывает - я думаю каждый сможет провести много параллелей со своим опытом. Дело было в 2017-19 годах, но сути это не меняет 🙂
https://vc.ru/dev/468325-keys-kak-kompaniya-hertz-zaplatila-agentstvu-accenture-32-milliona-dollarov-za-veb-sayt-kotoryy-tak-i-ne-zapustilsya
Оригинал на английском здесь: https://www.henricodolfing.com/2019/10/case-study-hertz-accenture-website.html
vc.ru
Кейс: Как компания Hertz заплатила агентству Accenture 32 миллиона долларов за Веб-сайт, который так и не запустился — Разработка…
Или инструкция “как не надо” для управления проектами на примере двух великанов
👍10
Что интересно, такой сценарий просто невозможен в agile подходе, потому что:
• Весь большой продукт обязательно делится на небольшие, логически разделенные части. Поэтому не нужно ждать конца проекта, чтобы выпустить продукт на первых клиентов, это можно было сделать в случае с hertz уже через месяц-два.
• Вся разработка делится на недельные итерации. Поэтому в конце каждой недели можно увидеть небольшой, но реальный прогресс. Например, на тестовом стенде. Таким образом, мгновенно не заметить отсутствие той же адаптивной верстки, как в кейсе Accenture- Hertz, просто невозможно.
• Задачи ставятся и тз пишется не все и сразу, а «в моменте», непосредственно перед началом разработки. Поэтому любые важные изменения требований от заказчика всегда будут учтены.
• И последнее. Никогда, никогда и ещё раз никогда нельзя использовать fixed price модель разработки.
Приведу пример из собственного опыта - меня пригласили в крупный и известный банк, который на тот момент уже 2.5 года, в сотрудничестве с не менее крупной и известной компанией-аутсорсером, разрабатывал новый продукт для юрлиц. И за 2.5 года не было не только работающей версии у клиентов, но и тестовых версий с хотя бы одним работающим сквозным сценарием. Напоминает кейс Accenture-Hertz, верно?
Только в данном случае вовремя осознали, что нужно срочно менять подход к ведению проекта, перешли на Agile и все стало хорошо (но, конечно, не сразу).
А первое, что я сделал в этом проекте в качестве консультанта - перевёл взаимодействие банка, который уже был готов подавать судебный иск, и подрядчика на T&M контракт.
Конечно, чтобы выпустить успешный продукт мы потратили ещё несколько месяцев. Но уход от Fixed price модели принципиально сделал успех этого проекта возможным. Жаль, что в Hertz не догадались до этого. Ну или не хватило политической воли, чтобы реализовать такой переход.
Обычно мы в деталях разбираемся, как перейти из традиционного проекта в Agile на нашем тренинге Agile Project Management. Поэтому если интересно, приходите, можно будет разобрать любой кейс по вашему проекту.
• Весь большой продукт обязательно делится на небольшие, логически разделенные части. Поэтому не нужно ждать конца проекта, чтобы выпустить продукт на первых клиентов, это можно было сделать в случае с hertz уже через месяц-два.
• Вся разработка делится на недельные итерации. Поэтому в конце каждой недели можно увидеть небольшой, но реальный прогресс. Например, на тестовом стенде. Таким образом, мгновенно не заметить отсутствие той же адаптивной верстки, как в кейсе Accenture- Hertz, просто невозможно.
• Задачи ставятся и тз пишется не все и сразу, а «в моменте», непосредственно перед началом разработки. Поэтому любые важные изменения требований от заказчика всегда будут учтены.
• И последнее. Никогда, никогда и ещё раз никогда нельзя использовать fixed price модель разработки.
Приведу пример из собственного опыта - меня пригласили в крупный и известный банк, который на тот момент уже 2.5 года, в сотрудничестве с не менее крупной и известной компанией-аутсорсером, разрабатывал новый продукт для юрлиц. И за 2.5 года не было не только работающей версии у клиентов, но и тестовых версий с хотя бы одним работающим сквозным сценарием. Напоминает кейс Accenture-Hertz, верно?
Только в данном случае вовремя осознали, что нужно срочно менять подход к ведению проекта, перешли на Agile и все стало хорошо (но, конечно, не сразу).
А первое, что я сделал в этом проекте в качестве консультанта - перевёл взаимодействие банка, который уже был готов подавать судебный иск, и подрядчика на T&M контракт.
Конечно, чтобы выпустить успешный продукт мы потратили ещё несколько месяцев. Но уход от Fixed price модели принципиально сделал успех этого проекта возможным. Жаль, что в Hertz не догадались до этого. Ну или не хватило политической воли, чтобы реализовать такой переход.
Обычно мы в деталях разбираемся, как перейти из традиционного проекта в Agile на нашем тренинге Agile Project Management. Поэтому если интересно, приходите, можно будет разобрать любой кейс по вашему проекту.
❤8👍4
OnAgile Learning Hub 💎
В чем отличие Agile от Lean? Люди, знакомые с Lean или работающие в компаниях, где он применяется, часто спрашивают нас, а в чем отличие Agile от Lean? Вроде бы очень похожие подходы по ценностям и некоторым инструментам. Тем не менее разница значительная.…
В этом году на тренингах снова часто спрашивают, в чем основное отличие Agile от Lean.
Я обычно объясняю это так.
Другими словами, задача Lean - оптимизировать операционные процессы, задача Agile - оптимизировать разработку новых нетиповых решений за счет коротких циклов проверки гипотез.
Добавите что-нибудь?
Я обычно объясняю это так.
Другими словами, задача Lean - оптимизировать операционные процессы, задача Agile - оптимизировать разработку новых нетиповых решений за счет коротких циклов проверки гипотез.
Добавите что-нибудь?
Telegram
Agile 💎 Thinking
В чем отличие Agile от Lean?
Люди, знакомые с Lean или работающие в компаниях, где он применяется, часто спрашивают нас, а в чем отличие Agile от Lean? Вроде бы очень похожие подходы по ценностям и некоторым инструментам.
Тем не менее разница значительная.…
Люди, знакомые с Lean или работающие в компаниях, где он применяется, часто спрашивают нас, а в чем отличие Agile от Lean? Вроде бы очень похожие подходы по ценностям и некоторым инструментам.
Тем не менее разница значительная.…
👍10
Сила продуктовых команд
Одна из самых сильных сторон Agile подхода заключается в вовлечении каждого участника команды в создание конечного продукта.
И это даже не просто про понимание того, что мои локальные задачи на выходе превратятся во что-то большее и я должен смотреть шире и помогать своим коллегам и условно быть активным на стендапах.
Самое важное - это понимание клиентов, для которых мы делаем продукт, и их потребностей.
Каждым из участников команды, вне зависимости от роли: бэкэнд разработчик, seo-специалист, логист или юрист.
Сила продуктовой команды в крутости обсуждаемых гипотез и скорости их проверки.
И чем больше вовлеченных людей будут драйвить этот процесс, тем лучше будут результаты.
Приведу пример вопросов из реальной команды недавно запущенного продукта, которые мы обсуждаем все вместе:
1. Почему у нас только X% клиентов начинают регистрацию?
2. Почему у нас только X1% завершают регистрацию?
3. Почему только Y% зарегистрированных людей делает целевое действие, а Y1% уходит и не возвращается?
4. Почему так мало (до K%) клиентов возвращаются и повторно делают целевое действие?
5. Что не так с СегментомХ клиентов, живущих в СтранеY?
Понятно, что вначале бывает сложно переключить мозг каждого в команде на мышление такими категориями.
Самое частое возражение - «у нас ведь есть продакт и аналитик, это же их работа».
Тем не менее, через несколько недель команду уже, как правило, не узнать.
А у вас был опыт переключения коллег в продуктовое мышление? Как работали с возражениями?
Одна из самых сильных сторон Agile подхода заключается в вовлечении каждого участника команды в создание конечного продукта.
И это даже не просто про понимание того, что мои локальные задачи на выходе превратятся во что-то большее и я должен смотреть шире и помогать своим коллегам и условно быть активным на стендапах.
Самое важное - это понимание клиентов, для которых мы делаем продукт, и их потребностей.
Каждым из участников команды, вне зависимости от роли: бэкэнд разработчик, seo-специалист, логист или юрист.
Сила продуктовой команды в крутости обсуждаемых гипотез и скорости их проверки.
И чем больше вовлеченных людей будут драйвить этот процесс, тем лучше будут результаты.
Приведу пример вопросов из реальной команды недавно запущенного продукта, которые мы обсуждаем все вместе:
1. Почему у нас только X% клиентов начинают регистрацию?
2. Почему у нас только X1% завершают регистрацию?
3. Почему только Y% зарегистрированных людей делает целевое действие, а Y1% уходит и не возвращается?
4. Почему так мало (до K%) клиентов возвращаются и повторно делают целевое действие?
5. Что не так с СегментомХ клиентов, живущих в СтранеY?
Понятно, что вначале бывает сложно переключить мозг каждого в команде на мышление такими категориями.
Самое частое возражение - «у нас ведь есть продакт и аналитик, это же их работа».
Тем не менее, через несколько недель команду уже, как правило, не узнать.
А у вас был опыт переключения коллег в продуктовое мышление? Как работали с возражениями?
👍14❤5
Друзья, привет, обычно мы так не делаем, но 🙂
У вас есть уникальная возможность посетить последний в этом году тренинг "Управление проектами в Agile" с огромной 25% скидкой!
Вы получите ценные знания и навыки, которые помогут вам эффективно управлять проектами в Agile среде, а так же ваш международный сертификат от ICAgile. Не упустите шанс инвестировать в себя и свою карьеру.
13-15 декабря 2022, онлайн
Всего 5 мест с такой скидкой, запишитесь прямо сейчас: https://icagile.ru/agile-project-management.
P.S. Места со скидкой закончились :)
#agile #управлениепроектами #скидка #профессиональноеразвитие
У вас есть уникальная возможность посетить последний в этом году тренинг "Управление проектами в Agile" с огромной 25% скидкой!
Вы получите ценные знания и навыки, которые помогут вам эффективно управлять проектами в Agile среде, а так же ваш международный сертификат от ICAgile. Не упустите шанс инвестировать в себя и свою карьеру.
13-15 декабря 2022, онлайн
Всего 5 мест с такой скидкой, запишитесь прямо сейчас: https://icagile.ru/agile-project-management.
P.S. Места со скидкой закончились :)
#agile #управлениепроектами #скидка #профессиональноеразвитие
icagile.ru
Сертификационный курс по управлению проектами и их эволюционированию в Agile-среде | Agile Project Management
Вы получите практические навыки адаптации фундаментальной теории к Agile-окружению
👍6❤2
Друзья, привет! Мы решили немного обновить название и концепцию канала в новом году.
Будем по-прежнему публиковать полезные на наш взгляд материалы, но с утроенной энергией и частотой 🙂 А еще добавим бесплатные онлайн встречи по самым интересным темам.
Итак, встречайте - OnAgile Learning Hub.
Кстати, первый пост у нас вышел почти 5 лет назад, 10 мая 2018 года. Если кто-то из наших дорогих подписчиков помнит то время, напишите в комментариях или поставьте сердечко 🙂
Будем по-прежнему публиковать полезные на наш взгляд материалы, но с утроенной энергией и частотой 🙂 А еще добавим бесплатные онлайн встречи по самым интересным темам.
Итак, встречайте - OnAgile Learning Hub.
Кстати, первый пост у нас вышел почти 5 лет назад, 10 мая 2018 года. Если кто-то из наших дорогих подписчиков помнит то время, напишите в комментариях или поставьте сердечко 🙂
❤8🔥1
Хочу поделиться очень понятной вводной статьей про работу с графиком распределения Leadtime, надеюсь, вам будет интересно прочитать: https://mauvisoft.com/2020/10/08/how-to-read-lead-time-distribution/
Мы часто используем такую диаграмму для анализа эффекта от нашей работы по улучшению процессов в командах у клиентов. Причем стараемся делать исходных срез данных еще на старте работ, чтобы потом было с чем сравнить.
Самое удобно в этой диаграмме то, что она может работать с любым процессом, будь то Scrum, Kanban-метод или любой другой существующий в компании процесс разработки и поставки.
Достаточно просто выбрать сущность, время работы над которой хотим измерять (например, Эпик или Инициатива), определить первое состояние жизненного цикла, откуда начнем считать время (например, переход в Анализ) и финальное состояние (обычно это переход в Готово).
Ну а самое приятное - это через несколько месяцев увидеть, как распределение начинает смещаться влево, в сторону более быстрой поставки результатов.
Мы часто используем такую диаграмму для анализа эффекта от нашей работы по улучшению процессов в командах у клиентов. Причем стараемся делать исходных срез данных еще на старте работ, чтобы потом было с чем сравнить.
Самое удобно в этой диаграмме то, что она может работать с любым процессом, будь то Scrum, Kanban-метод или любой другой существующий в компании процесс разработки и поставки.
Достаточно просто выбрать сущность, время работы над которой хотим измерять (например, Эпик или Инициатива), определить первое состояние жизненного цикла, откуда начнем считать время (например, переход в Анализ) и финальное состояние (обычно это переход в Готово).
Ну а самое приятное - это через несколько месяцев увидеть, как распределение начинает смещаться влево, в сторону более быстрой поставки результатов.
❤6👍2
В дополнение к предыдущему посту про LeadTime, небольшая иллюстрация как именно он считается.
Есть два ключевых понятия.
1. Commitment point (точка Взятия обязательств) - когда мы пообещали, что начали работу над конкретной задачей и соответственно время ожидания в глазах наших заказчиков или клиентов начало идти.
2. Delivery point (Точка Поставки) - когда мы отдаем обещаный результат и заказчик/клиент может его принимать.
По каждой сделанной задаче (прошедшей Delivery Point) мы отмечаем дату, когда задача была сделана, вычитаем из нее дату, когда задача была взята в работу (прошла Commitment Point) и получаем время работы над задачей (LeadTime).
Дальше добавляем это значение на график и получаем нужное распределение, которое не только показывает нашу эффективность, как команды, но и позволяет заказчикам выстраивать более точные ожидания по срокам.
Источник иллюстрации: https://www.projectwizards.net/en/blog/2019/01/kanban-corepractices
Есть два ключевых понятия.
1. Commitment point (точка Взятия обязательств) - когда мы пообещали, что начали работу над конкретной задачей и соответственно время ожидания в глазах наших заказчиков или клиентов начало идти.
2. Delivery point (Точка Поставки) - когда мы отдаем обещаный результат и заказчик/клиент может его принимать.
По каждой сделанной задаче (прошедшей Delivery Point) мы отмечаем дату, когда задача была сделана, вычитаем из нее дату, когда задача была взята в работу (прошла Commitment Point) и получаем время работы над задачей (LeadTime).
Дальше добавляем это значение на график и получаем нужное распределение, которое не только показывает нашу эффективность, как команды, но и позволяет заказчикам выстраивать более точные ожидания по срокам.
Источник иллюстрации: https://www.projectwizards.net/en/blog/2019/01/kanban-corepractices
👍7
Друзья, мы сейчас составляем список тем для вебинаров, которых хотим провести для вас в феврале-марте.
Подскажите, на какие темы вам интересно было бы поговорить?
Подскажите, на какие темы вам интересно было бы поговорить?
Anonymous Poll
13%
Запуск и развитие Scrum команд
17%
Оценка задач и планирование
11%
Проектирование и развитие Канбан-систем
6%
Оценка зрелости Agile команд
15%
Навыки крутого Скрам-мастера и Agile коуча
14%
Применение Agile в компаниях, не связанных с разработкой ПО
7%
Современные практики работы с людьми
7%
Масштабирование Agile на уровень подразделения/компании
9%
Понимание потребностей клиентов (Custdev)
2%
Другая тема, напишу в комментариях
Друзья, приглашаем вас принять участие в первом вебинаре нашей новой серии, в понедельник 6 марта 18.00.
Рассмотрим на примерах самые актуальные вопросы, связанные с оценкой и планированием задач.
Какие инструменты применить и что сделать, чтобы повысить точность оценки и перестать переживать за озвученные сроки.
Ссылку на подключение опубликуем в этом сообщении за час до вебинара.
До встречи! 6 марта 18.00 мск
(🗓 не забудьте добавить себе в календарь)
Рассмотрим на примерах самые актуальные вопросы, связанные с оценкой и планированием задач.
Какие инструменты применить и что сделать, чтобы повысить точность оценки и перестать переживать за озвученные сроки.
Ссылку на подключение опубликуем в этом сообщении за час до вебинара.
До встречи! 6 марта 18.00 мск
(🗓 не забудьте добавить себе в календарь)
👍10❤7
Новая версия SAFe 6.0 уже успела обрасти правдивыми шутками 🙂
Вообще этот момент очень показательный.
Когда организация задумывается о применении agile / scrum в масштабе и выбирает фреймворк, можно такой вопрос руководителям и задавать.
Вы ОК продолжать жить с теми зависимостями (и следовательно, проблемами), что есть сейчас?
Тогда SAFe подойдет, чтобы улучшить процессы в компании.
Или готовы вложить чуть больше личных сил и энергии, набраться смелости и попробовать зайти в редизайн (организационный и технологический), чтобы от этих зависимостей просто отказаться?
В этом случае LeSS поможет вам стать действительно быстрой и гибкой продуктовой компанией.
Вообще этот момент очень показательный.
Когда организация задумывается о применении agile / scrum в масштабе и выбирает фреймворк, можно такой вопрос руководителям и задавать.
Вы ОК продолжать жить с теми зависимостями (и следовательно, проблемами), что есть сейчас?
Тогда SAFe подойдет, чтобы улучшить процессы в компании.
Или готовы вложить чуть больше личных сил и энергии, набраться смелости и попробовать зайти в редизайн (организационный и технологический), чтобы от этих зависимостей просто отказаться?
В этом случае LeSS поможет вам стать действительно быстрой и гибкой продуктовой компанией.
👍6🤔2
🚀 Друзья, у нас отличные новости! Мы обновили тренинг для Владельцев продуктов в соответствии с последними трендами рынка, касательно роли РО.
Вгляд бизнеса на роль Владельца продукта меняется: новшества пришли из интерпрайза и SAFe, но уже закрепились в крупном и среднем бизнесе вне зависимости от используемого фреймворка.
ICAgile теперь предлагает разделять обучение для менеждера продукта и для владельца продукта.
Для Product Owner'а ключевые измения состоят в том, что:
✅ теперь он больше фокусируется на выстраивании взаимодействия со стейкхолдерами: как вести диалог, как их изучать, как вовлекать стейкхолдеров
✅ обеспечивает поставку и всё, что с ней связано, за счет смещения фокуса от исследований к технологиям управления и поставки продукта.
Подробнее о новых инструментах, необходимых каждому Владельцу продукта.
Вгляд бизнеса на роль Владельца продукта меняется: новшества пришли из интерпрайза и SAFe, но уже закрепились в крупном и среднем бизнесе вне зависимости от используемого фреймворка.
ICAgile теперь предлагает разделять обучение для менеждера продукта и для владельца продукта.
Для Product Owner'а ключевые измения состоят в том, что:
✅ теперь он больше фокусируется на выстраивании взаимодействия со стейкхолдерами: как вести диалог, как их изучать, как вовлекать стейкхолдеров
✅ обеспечивает поставку и всё, что с ней связано, за счет смещения фокуса от исследований к технологиям управления и поставки продукта.
Подробнее о новых инструментах, необходимых каждому Владельцу продукта.
👍6❤1
Обновленный тренинг для Владельцев продуктов в Agile стартует после майских, 17-19 мая.
👉 Мы добавили еще больше практических упражений: одни из примеров — коммуникационный план работы со стейхолдерами и разработка стратегии для достижения целевых бизнес-показателей
👉 После тренинга вас ждет международный сертификат Agile Product Ownership (ICP-APO)
Не упустите возможность актуализировать ваши знания в соответствии с последними тенденциями рынка 🌟
А для тех, кто не уехал в отпуск и готов принимать решения на праздниках, до 10 мая специальная цена - всего 43 400 руб.
🥇 Забронировать участие
👉 Мы добавили еще больше практических упражений: одни из примеров — коммуникационный план работы со стейхолдерами и разработка стратегии для достижения целевых бизнес-показателей
👉 После тренинга вас ждет международный сертификат Agile Product Ownership (ICP-APO)
Не упустите возможность актуализировать ваши знания в соответствии с последними тенденциями рынка 🌟
А для тех, кто не уехал в отпуск и готов принимать решения на праздниках, до 10 мая специальная цена - всего 43 400 руб.
🥇 Забронировать участие
❤3
Друзья, хотим поделиться с вами статьей, которая поможет повысить эффективность работы в agile-команде. В ней рассмотрены основные факторы формирования самоорганизованной команды и какие действия помогут ей стать более продуктивной.
Мы все знаем, что в работе важно совместное участие и самоорганизация. Но как можно помочь своей команде достичь этого?
Ключевое здесь — правильно организовать процесс работы и общения, чтобы у всех было понимание к чему стремиться и в каком направлении двигаться. В статье мы рассмотрим 5 необходимых факторов самоорганизации и шаги, которые необходимо предпринять лидеру или Скрам-мастеру для помощи команде в этой задаче.
Чтобы узнать больше, переходите по ссылке и читайте статью. Желаем успешной работы в команде!
Мы все знаем, что в работе важно совместное участие и самоорганизация. Но как можно помочь своей команде достичь этого?
Ключевое здесь — правильно организовать процесс работы и общения, чтобы у всех было понимание к чему стремиться и в каком направлении двигаться. В статье мы рассмотрим 5 необходимых факторов самоорганизации и шаги, которые необходимо предпринять лидеру или Скрам-мастеру для помощи команде в этой задаче.
Чтобы узнать больше, переходите по ссылке и читайте статью. Желаем успешной работы в команде!
👍6
Друзья, прямо сейчас мы проводим для одной из школ вебинар по роли QA специалиста в Agile.
Уровень начальный, но подача материала очень интересная!
Update: трансляция закончилась, спасибо тем кто слушал :)
Уровень начальный, но подача материала очень интересная!
Update: трансляция закончилась, спасибо тем кто слушал :)
👍2🔥1
Друзья, привет! Мы сейчас делаем с клиентом проект по внедрению LeSS (скрам в масштабе), хочется поделиться информацией на тему Актуализации бэклога (Product Backlog Refinement, или сокращенно PBR).
Несмотря на то, что многое в LeSS повторяет Скрам, такая вещь как Актуализация бэклога очень сильно отличается, в первую очередь из-за количества участников процесса и необходимого уровня обмена информацией.
Описали три вида PBR и их основные отличия, посмотрите кому интересно. В нашем текущем кейсе мы на первых спринтах начали с Общего PBR, но сейчас уже начали обсуждать многокомандный, как целевой формат проведения.
https://onagile.ru/trends/business-agility/less-product-backlog-refinement
Несмотря на то, что многое в LeSS повторяет Скрам, такая вещь как Актуализация бэклога очень сильно отличается, в первую очередь из-за количества участников процесса и необходимого уровня обмена информацией.
Описали три вида PBR и их основные отличия, посмотрите кому интересно. В нашем текущем кейсе мы на первых спринтах начали с Общего PBR, но сейчас уже начали обсуждать многокомандный, как целевой формат проведения.
https://onagile.ru/trends/business-agility/less-product-backlog-refinement
👍14❤1
Друзья, привет! Это Артем из команды OnAgile.
В последнее время я часто сталкиваюсь с вопросами о сути Agile - это методология, философия, набор практик или что-то совсем другое?
Порой ответ на этот вопрос может быть сложнее, чем кажется на первый взгляд.
Я решил помочь разобраться в этом вопросе и написал статью, в которой ясно и просто объясняю основные принципы Agile.
Это не просто теория, это - подкрепленные реальными примерами истории, которые помогут вам не только понять Agile, но и увидеть, как эти принципы применяются на практике.
Статью можно использовать как справочник для любого, кто хочет впервые погрузиться в мир Agile или уточнить свои знания. Приятного чтения!
https://onagile.ru/trends/agile/what-is-agile
В последнее время я часто сталкиваюсь с вопросами о сути Agile - это методология, философия, набор практик или что-то совсем другое?
Порой ответ на этот вопрос может быть сложнее, чем кажется на первый взгляд.
Я решил помочь разобраться в этом вопросе и написал статью, в которой ясно и просто объясняю основные принципы Agile.
Это не просто теория, это - подкрепленные реальными примерами истории, которые помогут вам не только понять Agile, но и увидеть, как эти принципы применяются на практике.
Статью можно использовать как справочник для любого, кто хочет впервые погрузиться в мир Agile или уточнить свои знания. Приятного чтения!
https://onagile.ru/trends/agile/what-is-agile
👍10
Приветствуем, друзья!
Сегодня мы хотели бы обсудить тему тестирования в Agile, на примере Манифеста Тестирования. Возможно, некоторые из вас уже с ним знакомы.
Предлагаем рассмотреть 5 ключевых принципов из Манифеста, которые, как мы уверены, способны значительно улучшить процесс работы вашей команды над тестированием и обеспечением качества продукта.
Приятного чтения! https://onagile.ru/trends/agile/agile-testing-manifesto
Сегодня мы хотели бы обсудить тему тестирования в Agile, на примере Манифеста Тестирования. Возможно, некоторые из вас уже с ним знакомы.
Предлагаем рассмотреть 5 ключевых принципов из Манифеста, которые, как мы уверены, способны значительно улучшить процесс работы вашей команды над тестированием и обеспечением качества продукта.
Приятного чтения! https://onagile.ru/trends/agile/agile-testing-manifesto
👍12