Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Я таки хочу добавить, что scrum-у также всё равно занимаетесь вы разработкой ПО или нет, ибо это фреймворк для менеджмента. Пару лет назад в Киеве на Agile Base Camp, очень порадовал хулиганский доклад о строительной фирме работающей по scrum.
Scrum хорош только для команды разработчиков (и то не всегда). Поясню почему:
1. Ну во первых Заказчик/Менеджер/Кто либо другой не могут менять функционал (таски) забитый в текущий спринт (Очень хорошо для команды, не очень хорошо для Owner-а). Хотя с другой стороны и для команды не гуд переписывать готовый функционал в следующем спринте из-за того что передумал Owner.
2. Для неопытной команды Стенд ап митинги в половине случаев бесполезны
Сам по себе Scrum в каждой компании претерпевает некоторые изменения… Следователь назвать его хорошим/плохим подходом к разработке нельзя…
1. Ну во первых Заказчик/Менеджер/Кто либо другой не могут менять функционал (таски) забитый в текущий спринт (Очень хорошо для команды, не очень хорошо для Owner-а). Хотя с другой стороны и для команды не гуд переписывать готовый функционал в следующем спринте из-за того что передумал Owner.
2. Для неопытной команды Стенд ап митинги в половине случаев бесполезны
Сам по себе Scrum в каждой компании претерпевает некоторые изменения… Следователь назвать его хорошим/плохим подходом к разработке нельзя…
Делать правильные вещи правильно и быстро. Любопытно взглянуть, как Scrum нам помогает достигать эти цели?
Scrum не для того создавался. Это методология, которая призвана защищать разработчиков, автоматизирующих бизнес, от заказчиков со стороны этого бизнеса, слишком часто меняющих требования. Все. Это реально все, что делает Scrum. На это заточены все его практики, начиная от бэклогов и заканчивая ретроспективой. Да, часть его практик универсальна — но именно в изложении Scrum и как оно собрано вместе — это способ договориться разработчикам, которые с трудом предсталяют что такое активно-пассивный счет с кредитовым остатком, и менеджера со стороны банка, для которого компьютер — это такой телевизор с одноклассниками :)
Для создания веб страничек командой из пяти человек используются другие методологии.
> Для создания веб страничек командой из пяти человек используются другие методологии.
Полностью согласен. Для обработки потока коротких (менее 1го месяца) проектов scrum совершенно не подходит. Тем более когда одна и та же команда работает одновременно над 3-5ю проектами на разных этапах.
Полностью согласен. Для обработки потока коротких (менее 1го месяца) проектов scrum совершенно не подходит. Тем более когда одна и та же команда работает одновременно над 3-5ю проектами на разных этапах.
В целом скрам можно использовать, если одна команда работает над разными проектами. Сложность в том, чтобы разбить все эти проекты на отдельные юзер стори. Тогда легко создать спринт и накидать туда юзер стори из разных проектов. Правда, если у проектов разные оунеры, им придется договориться между собой о приоритетах, что бывает сложно :) Но все равно это полезнее, ведь иначе приоритеты расставят разработчики.
Дополнение вполне себе хорошее, но «это реально все, что делает скрам» — не соответствует действительности.
" In Scrum, we introduce chaos into the development process and then use an empirical control harness to inspect and adapt a rapidly involving system." — цитата Сезерленда. С его точки зрения, все гораздо сложнее. — «SCRUM is based on complexity theory and artificial life experiments at Thinking Machines using highly parallel simulation of systems evolution. It induces the phenomenon known as „punctuated equilibrium“ seen in the evolution of biological species.»
Иными словами, ожидается, что набор простых правил скрам порождает сложное, умное поведение системы (команды разработчиков). Ну и прочие свойства сложных адаптивных систем применимы. То есть прерывистое равновесие, когда переход на новый уровень происходить скачкообразно и неожиданно. То есть компетенция команды не растет плавно, а скачками с периодами застоя.
В общем, ваш посыл про скрам неполон.
" In Scrum, we introduce chaos into the development process and then use an empirical control harness to inspect and adapt a rapidly involving system." — цитата Сезерленда. С его точки зрения, все гораздо сложнее. — «SCRUM is based on complexity theory and artificial life experiments at Thinking Machines using highly parallel simulation of systems evolution. It induces the phenomenon known as „punctuated equilibrium“ seen in the evolution of biological species.»
Иными словами, ожидается, что набор простых правил скрам порождает сложное, умное поведение системы (команды разработчиков). Ну и прочие свойства сложных адаптивных систем применимы. То есть прерывистое равновесие, когда переход на новый уровень происходить скачкообразно и неожиданно. То есть компетенция команды не растет плавно, а скачками с периодами застоя.
В общем, ваш посыл про скрам неполон.
Посоветуйте, пожалуйста, какие методологии можно использовать в маленькой команде. Мы делаем веб-странички и пишем своё SaaS.
Методологии отвечают на конкретные вопросы — «много багов», «срыв сроков», «программисты не работают, а сидят в контакте». Универсальной методологии я, увы, не знаю.
Чтобы что-то посоветовать, нужен контекст. Пока его явно недостаточно. Так что для получения разумных советов нужно потрудиться и описать текущее положение дел как можно подробнее, включая количество людей, проектов, что это за проекты, какие у компании приоритеты, какие скилы у людей, какие проблемы на ваш взгляд есть сейчас, какой технологический стек.
Есть такой вопрос:
Вы проводите ретроспективу, после нее выясняете проблему и как скоро вам её удается решить?
Могу сказать, что наши ретроспективы крайне непродуктивны, никогда ни на что не хватает времени :(
Вы проводите ретроспективу, после нее выясняете проблему и как скоро вам её удается решить?
Могу сказать, что наши ретроспективы крайне непродуктивны, никогда ни на что не хватает времени :(
У нас часть проблем удалось решить
основной плюс который получили — детальный разбор технических решений на груминг сессиях
как результат мы стали быстрее и сработались лучше
основной плюс который получили — детальный разбор технических решений на груминг сессиях
как результат мы стали быстрее и сработались лучше
У нас в свое время была такая проблема. Ретроспективы выявляли несколько проблем и мы намечали 8-10 экшн айтемов. Через 2 недели собирались снова, опять намечали несколько и частенько брали незаконченные из предыдущих. Короче накапливались они. А накапливались по той причине, что проблемы были достаточно фундаментальными (автоматизация тестов) и решения их вообще занимают месяцы, а не дни.
Так что как пару простых советов я предлагаю
1 — фокусироваться на 1-2 главных проблем и пытаться их решить
2 — разбивать решения этих проблем на как можно более мелкие задачи, которые можно закончить за пару недель.
Ну и в целом, так как скрам ничего не говорит о формате ретроспектив, хорошо бы узнать побольше о системном мышлении и поучиться решать проблемы с помощью всяких полунаучных подходов, типа диаграммы ишикавы, статистики и тп. Демминг об этом отлично писал с примерами, хотя бы в книжке Выход из кризиса.
Так что как пару простых советов я предлагаю
1 — фокусироваться на 1-2 главных проблем и пытаться их решить
2 — разбивать решения этих проблем на как можно более мелкие задачи, которые можно закончить за пару недель.
Ну и в целом, так как скрам ничего не говорит о формате ретроспектив, хорошо бы узнать побольше о системном мышлении и поучиться решать проблемы с помощью всяких полунаучных подходов, типа диаграммы ишикавы, статистики и тп. Демминг об этом отлично писал с примерами, хотя бы в книжке Выход из кризиса.
груминг сессиях
можете коротко описать, что это?
Product owner готовит бэклог
Команда раз в неделю обсуждает изменения в спеках
Продумывает как технически это реализовать
И проводит оценку полученных задач — это и есть груминг
На планинг митинге с PO решается что взять в следуёщий
Спринт на основании резулььатов предыдущих спринтов
У нас сейчас недельные спринты — первое время не успевали
Сейчас вошли в ритм
Команда раз в неделю обсуждает изменения в спеках
Продумывает как технически это реализовать
И проводит оценку полученных задач — это и есть груминг
На планинг митинге с PO решается что взять в следуёщий
Спринт на основании резулььатов предыдущих спринтов
У нас сейчас недельные спринты — первое время не успевали
Сейчас вошли в ритм
около года работаю по системе scrum (в rocketsoftware), у нас большая свобода по срокам и scrum с его спринтами и daily scrum call позволяет «держать себя в тонусе». ну и конечно, очень многое зависит от scrum мастера.
пиши-код-блять.рф
Individuals and interactions over processes and tools (Manifesto for Agile Software Development).
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done (Principles behind the Agile Manifesto).
Как пошутил Кен Швабер в своём знаменитом выступлении (Scrum et al, 5.09.2006): «Вы вполне можете научить работать по Скраму кучку идиотов… и получать в конце каждой итерации дерьмо» (вольный перевод).
Скрам обеспечивает минимальную формальную инфраструктуру для мотивированных талантливых людей. Это его единственное назначение. «Скрам — не методология» (Кен, дослушайте сравнение с шахматами до конца). Если:
1) Люди не мотивированы — вы получите дерьмо.
2) Люди не талантливы — в конце первой итерации вы получите дерьмо. Но если они мотивированы настолько, что готовы совершенствоваться, есть все шансы получить годный продукт на одной из последующих итераций.
3) Людям не нужна инфраструктура —
Таким образом:
1) Правильные вещи делают мотивированные люди.
2) Вещи правильно делают талантливые люди.
3) Быстро делать вещи вышеперечисленным людям помогает Скрам — за счёт вымеренной годами непрерывной практики минимальной формальной инфраструктуры (в первую очередь — фиксированных временных рамок — timeboxes).
Как мне показалось, Ваш взгляд на Скрам либо слишком узок, либо недостаточно компетентен. И в том, и в ином случае советую, как минимум, более вдумчиво перечитать Манифест и Руководство. Да и в видео Кен довольно прозрачно отвечает на все перечисленные в статье «проблемы».
Я пожалуй поспорю со всеми пунктами.
1. Мотивации совершенно недо статочно, чтобы сделать правильную вещь. Нужно еще очень много чего. Понимание потребностей пользователей, умение наладить с пользователями контакт и выяснить, что же для них на самом деле сработает (причем прямые ответы на такие вопросы редко нужно воплощать в жизнь). Соответственно нужны процессы, которые помогают узнавать, правильную ли вещь мы делаем. Скрам молчит по этому поводу.
2. Практически каждый человек в чем-то талантлив. Я так понимаю, мы сужаем тему до талантливых разработчиков/тестировщиков/дизайнеров. Довольно общая фраза. В меру сложные продукты можно делать без особого таланта. Чтобы делать прорывные продукты пожалуй без таланта не обойтись. Ну и талант еще нужно правильно развить. Скрам ничего про это не говорит, а принимает по умолчанию.
3. Самый важный пункт. Вы не добавили ничего нового к статье этим пунктом. Я уже говорил, что скрам дает быстрый фидбек (очевидно, благодаря спринтам). Ну да, дает. Вы уверены, что не существует других способов ускорения фидбека? Конечно существуют. Их достаточно много, включая прототипирование, юзабилити тесты, и вообще переход на безитерационную разработку типа канбан.
Итак мы пожалуй согласились, что скрам можно отнести только к категории инструментов, который помогает ускоряться (и то весьма органиченно, за счет ускорения обратной связи). И никак не решает самые важные проблемы — правильные вещи правильно. Ведь скорость на мой взгляд менее важна.
1. Мотивации совершенно недо статочно, чтобы сделать правильную вещь. Нужно еще очень много чего. Понимание потребностей пользователей, умение наладить с пользователями контакт и выяснить, что же для них на самом деле сработает (причем прямые ответы на такие вопросы редко нужно воплощать в жизнь). Соответственно нужны процессы, которые помогают узнавать, правильную ли вещь мы делаем. Скрам молчит по этому поводу.
2. Практически каждый человек в чем-то талантлив. Я так понимаю, мы сужаем тему до талантливых разработчиков/тестировщиков/дизайнеров. Довольно общая фраза. В меру сложные продукты можно делать без особого таланта. Чтобы делать прорывные продукты пожалуй без таланта не обойтись. Ну и талант еще нужно правильно развить. Скрам ничего про это не говорит, а принимает по умолчанию.
3. Самый важный пункт. Вы не добавили ничего нового к статье этим пунктом. Я уже говорил, что скрам дает быстрый фидбек (очевидно, благодаря спринтам). Ну да, дает. Вы уверены, что не существует других способов ускорения фидбека? Конечно существуют. Их достаточно много, включая прототипирование, юзабилити тесты, и вообще переход на безитерационную разработку типа канбан.
Итак мы пожалуй согласились, что скрам можно отнести только к категории инструментов, который помогает ускоряться (и то весьма органиченно, за счет ускорения обратной связи). И никак не решает самые важные проблемы — правильные вещи правильно. Ведь скорость на мой взгляд менее важна.
1. Скрам и не должен ничего говорить по этому поводу, вы его явно с чем-то путаете.
2. Правильное развитие качеств команды обеспечивается за счёт ретроспектив. Здесь я соглашусь с Хенриком Книбергом, что это вторая по значимости (после планирования спринта) церемония Скрама. А то и первая. Здесь наибольшего проявления достигает самая важная из трёх составляющих управления эмпирическим процессом — адаптация (почитайте про модель Такмана, к примеру).
3. Способов множество, вы вольны выбирать любой. Я уверен в том, что Скрам настолько хорошо «протестирован», что, как писал тот же Хенрик, «работает прямо из коробки». Дальше его можно совершенствовать до момента, когда вы выйдите на уровень Ри и вообще забудете, что работаете по Скраму.
Я искренне не понимаю, почемы вы ждёте от правил игры в шахматы описания тактики игры гроссмейстера. И самое главное: «Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices». Приветы от Хенрика: Scrum and XP, Scrum and Canban.
2. Правильное развитие качеств команды обеспечивается за счёт ретроспектив. Здесь я соглашусь с Хенриком Книбергом, что это вторая по значимости (после планирования спринта) церемония Скрама. А то и первая. Здесь наибольшего проявления достигает самая важная из трёх составляющих управления эмпирическим процессом — адаптация (почитайте про модель Такмана, к примеру).
3. Способов множество, вы вольны выбирать любой. Я уверен в том, что Скрам настолько хорошо «протестирован», что, как писал тот же Хенрик, «работает прямо из коробки». Дальше его можно совершенствовать до момента, когда вы выйдите на уровень Ри и вообще забудете, что работаете по Скраму.
Я искренне не понимаю, почемы вы ждёте от правил игры в шахматы описания тактики игры гроссмейстера. И самое главное: «Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices». Приветы от Хенрика: Scrum and XP, Scrum and Canban.
Видимо с годами у меня теряется способность выражать свои мысли. Поясню, к чему я все это писал. В области разработки ПО много проблем и областей, где есть явные пробелы. Я попытаюсь перечислить их тут кратко.
— Знание предментой области
— craftsmanship
— умение решать проблемы (системное мышление, научный подход)
— разработка сложных систем в больших масштабах
— UX
— быстрая обратная связь
Все носятся со скрамом и внедряют его, решая только последнюю проблему и затрагивая только последнюю область. Остальному уделяется гораздо меньше внимания. Это не то чтобы плохо. Но скрам далего не сильвер балит. И вообще не факт, что лучший фреймворк для софтверных команд. Взгляд на скрам Книберга мне вполне симпатичен, но к сожалению большинство при внедрении скрама смотрят на него как на достаточную вещь, а он всего лишь необходимая вещь при трансформации процессов из вотерфольных в что-то более гибкое.
Аналогия с шахматами неплохая, мне понравилась. Примерно про это я и говорил
«Благодаря внешней простоте процесса, Scrum показался очень привлекательным для многих управленцев. Но для неопытной команды без внешних консультантов улучшить свой процесс на основе Scrum достаточно сложно. Это трудоемкий и долгий процесс, который может занять годы.»
— Знание предментой области
— craftsmanship
— умение решать проблемы (системное мышление, научный подход)
— разработка сложных систем в больших масштабах
— UX
— быстрая обратная связь
Все носятся со скрамом и внедряют его, решая только последнюю проблему и затрагивая только последнюю область. Остальному уделяется гораздо меньше внимания. Это не то чтобы плохо. Но скрам далего не сильвер балит. И вообще не факт, что лучший фреймворк для софтверных команд. Взгляд на скрам Книберга мне вполне симпатичен, но к сожалению большинство при внедрении скрама смотрят на него как на достаточную вещь, а он всего лишь необходимая вещь при трансформации процессов из вотерфольных в что-то более гибкое.
Аналогия с шахматами неплохая, мне понравилась. Примерно про это я и говорил
«Благодаря внешней простоте процесса, Scrum показался очень привлекательным для многих управленцев. Но для неопытной команды без внешних консультантов улучшить свой процесс на основе Scrum достаточно сложно. Это трудоемкий и долгий процесс, который может занять годы.»
То есть Вы писали как раз о том, что многие люди неверно понимают назначение Скрама и слишком многого от него ждут. Что же, могу только подтвердить сей печальный факт. Но движение растёт, а вместе с ним и общий уровень компетентности.
Поскольку моя основная специализация — системный и бизнес-анализ, с перечисленными проблемами мне приходится сталкиваться ежедневно.
Сейчас, внедряя Скрам, я делаю на их решение основной акцент, пропагандируя такие практики, как применение гибких баз знаний (live wiki), кроссфункциональность (наши программисты с радостью обсуждают с дизайнерами вопросы UX, а менеджеры заливают релизы на боевой сервер), привлечение разработчиков на самых ранних проектных этапах (вплоть до этапа подписания контракта; на прошлой неделе провели общий предпроектный воркшоп по результатам обследования одного из объектов автоматизации, получили отличные результаты) и т.д. Это выходит за рамки Скрама, но превосходно с ним сочетается.
Большую часть из вышеперечисленного я склонен называть, как пальчиковые батарейки — AAA (Advanced Agile Analysis). Надеюсь, в ближайшие месяцы созрею на серьёзную статью по этому поводу.
Поскольку моя основная специализация — системный и бизнес-анализ, с перечисленными проблемами мне приходится сталкиваться ежедневно.
Сейчас, внедряя Скрам, я делаю на их решение основной акцент, пропагандируя такие практики, как применение гибких баз знаний (live wiki), кроссфункциональность (наши программисты с радостью обсуждают с дизайнерами вопросы UX, а менеджеры заливают релизы на боевой сервер), привлечение разработчиков на самых ранних проектных этапах (вплоть до этапа подписания контракта; на прошлой неделе провели общий предпроектный воркшоп по результатам обследования одного из объектов автоматизации, получили отличные результаты) и т.д. Это выходит за рамки Скрама, но превосходно с ним сочетается.
Большую часть из вышеперечисленного я склонен называть, как пальчиковые батарейки — AAA (Advanced Agile Analysis). Надеюсь, в ближайшие месяцы созрею на серьёзную статью по этому поводу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой взгляд на Scrum