Рубрика «scrum» - 16

Думаю, что большинство тех, кто внедрял у себя в командах тот или иной инструмент (особенно, если он родом из страны с другой ментальностью) согласиться, что внедрение не всегда проходит гладко. Однажды один академик мне сказал: «Ну а как ты хотел? Внедрение — это по определению вторжение чужеродного объекта в тело. Должно быть оСВОЕние. Делание своим!». С тех пор, для меня осознание того, что инструмент работает не совсем так, как задумывалось — является лучшим признаком освоения. Команда или сотрудник модернизировали по своему и начали использовать. И еще лучше, когда команда берет два разных инструмента и сама комбинирует их. Так произошло и в этот раз.

Из названия топика и картинки суть идеи будет сразу понятной. Ну а за подробностями, и связью с управлением продуктом, прошу под кат…

SCRUM board + Квадрант Эйзенхауэра для управления продуктом
Читать полностью »

Приветствую!

Сегодня я решился написать свою первую статью на Хабр (так что уж не судите строго).
В этой, как и в большинстве последующих статей от меня, я буду говорить об Agile. Scrum и некоторых моментах из этой серии, на мой взгляд, являющихся интересными тем, кто увлекается данным направлением.
В этой статье я решил поговорить о нулевой итерации в Скрам, ее использовании в массах, и также попробовать определить является ли нулевая итерация частью true-Scrum или одной из темных Скрам-батов, которая приобрела свое название в угоду Скрам-брендингу.
Читать полностью »

По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем? Если вы тоже задавались этими вопросами, добро пожаловать под кат. Читать полностью »

Аты баты шли «скрам баты», или 85 заблуждений и препятствий гибкой разработки

Термин «скрам-бат» (scrumbut) впервые начал использовать Кен Шуэйбер что бы описать неверную трактовку или умышленную модификацию правил скрам, что бы уйти от болезненной правды о процессе, которую он помогает открыть.

Типичная формулировка скрам-бата выглядит так:
У нас скрам, но <Причина>, <ОбходнойПуть>

Где Причина — это описание дискомфорта, неприятного открытия с которым команда в силу тех, или иных причин не может справиться. А Обходной путь — это способ закрыть глаза на проблему, или устранить «симптомы», не разобравшись с причинами «организационного заболевания».

Типичные примеры скрам-батов, соответственно, выглядят так:

  • У нас скрам, но мы не всегда успеваем закончить всю взятую работу, поэтому меняем длину итерации.
  • У нас скрам, но все проблемы, которые мы могли устранить мы уже устранили, поэтому мы не проводим ретроспективы .

Мы стараемся термином «скрамбат» не злоупотреблять, поскольку некоторые типы отклонений свойственны началу внедрения аджайл и являются частью эволюции процесса. Например, если у вас скрам, но вы не делаете TDD, у вас нет парного программирования и слабо выраженное коллективное владение кодом — возможно, вы просто в начале пути. Причины могут быть разными — от неумения «продать» ценность инженерных практик менеджменту до неумения их «готовить». И то и другое можно научиться делать, но это занимает определенное время, верно?

Однако, каждый раз, когда я слышу «у нас скрам, но» в зрелых командах, я пытаюсь услышать нечто большее большее о причинах, которые такую модификацию обуславливают. И знаете, что? Веских причин на самом деле очень мало. Скорее, это непонимание ценностей гибкой разработки, недостаток смелости и силы что бы им следовать, которые вместе образуют процессное «скрамно».

Работая с командами, мы собрали список из 85 заблуждений и препятствий успешного внедрения гибкой разработки. Многие выходят за рамки правил карсасса скрам. В зависимости от контекста проекта, некоторые пункты могут иметь большее или меньшее влияние, и иметь оправдания обстоятельствами. Однако мы верим, что каждый элемент этого списка провоцирует искаженение ценностей и принципов Agile.
Читать полностью »

image

Уважаемые разработчики и специалисты по разработке ПО!

От лица команды конференции DevCon 2013 я с удовольствием анонсирую в рамках конференции проведение мастер-класса Scrum: теория и практика в Visual Studio 2012 от гуру гибких методологий разработки Асхата Уразбаева и Виктора Стрелкова.

Желаете узнать больше про гибкие методологии? Интересуетесь применением Scrum при разработке программного обеспечения? Используете в команде Visual Studio и планируете применять Agile и Scrum?

Тогда мастер-класс от Асхата Уразбаева и Виктора Стрелкова будет вам крайне полезен!

Цель мастер-класса

Scrum — гибкая методология разработки ПО, позволяющая в жесткие фиксированные сроки реализовать наиболее приоритетные задачи.

Благодаря своей эффективности и простоте внедрения, Scrum получил большое распространение среди разработчиков по всему миру: его используют практически все софтверные компании. Система управления жизненным циклом приложения Microsoft Team Foundation Server 2012 позволяет в полной мере реализовать управление проектом и продуктом по методологии Scrum, что будет продемонстрировано в мастер-классе.

Цель мастер-класса — дать возможность участникам увидеть и попробовать, как идеи гибких методологий практически воплощаются в TFS 2012 и Visual Studio 2012.
Читать полностью »

Мотиватция

Однажды в студеную зимнюю пору течении очередного планнинг-митинга на работе, где каждый пользовался своим инструментом для голосования — бумажные карты, всевозможные приложения для телефонов, etc — меня посетила мысль — а зачем сидеть всем в одном помещении, когда планирование можно проводить со своих рабочих мест, или даже из дома.

Итак идея — сделать сервис удаленного планирования, посредством техники Planning Poker, так популярной в agile мире. А также чуть лучше разобраться с тем как работает socket.io и сопутствующие технологии.

Читать полностью »

Ведь, если лампочки зажигают –
значит – это кому-нибудь нужно?

Послушайте!

Кому-нибудь из тех, кто не мыслит жизни без свободы… от наличия на небе естественных светил. А ведь наши далёкие предки, в большинстве своём, безальтернативно посвящали ночное время глубокому сну. Да, чего уж там! Говорят, пока лампа Эдисона не завоевала популярность, люди спали по 10 часов в сутки. Лично я, находясь в потоке, не могу спать больше пяти. Но даже этого слишком много! Часто бывает достаточно трёх. Только без удобного и безопасного искусственного света о подобном оставалось бы лишь мечтать.

И хотя Томаса Эдисона называют королём изобретательства, идея электрической лампы накаливания принадлежит не ему. Зато ему удалось воплотить её в жизнь. Стать батарейкой, позволившей лампочке идеи зажечься. Обеспечить решающий эффект для прорывной технологии.

За несколько лет работы аналитиком, я придумал массу прекрасных ламп программных систем… чтобы потом, с обливающимся кровью сердцем, наблюдать их безжизненные нити. Никакой самоотверженный труд в рамках отведённой роли не позволял увидеть свет в конце проектного туннеля.

В минувшем году я окончательно пришёл к тому, что ныне склонен называть Advanced Agile Analysis. То, что помогло мне, подобно Эдисону, стать человеком-батарейкой, обеспечивая эффект технологических проектов вместо традиционного поклонения краткосрочным успехам, процессам и инструментам.

Читать полностью »

Scrum — достаточно простая методология. Работать же по скраму не так и просто. Точно так же происходит со многими инструментами, например с покером для планирования. Практика сама по себе вполне понятная, но продуктивно её использовать в течении длительного времени затруднительно.
В этой статье я расскажу про технику, которая упрощает процесс оценок в работе скрам команды.
Итак, в чём же сложность?
Как вы знаете, story points — это относительные оценки объёма работы в истории. Нет способа оценить одну единственную историю в story points, вы всегда сравниваете историю с другими историями через story points. Покер может хорошо сработать в начале проекта, когда команды оценивает много историй в течении короткого промежутка времени.
Но позже, во время регулярной переоценки существующих историй и оценок новых историй становится значительно труднее, потому что калибровка одного story point забывается: «что такое один story point», «что-то я не уверен, что эта история действительно в 3 раза больше нашего золотого эталона», «эти две истории размером 5 не выглядят одинаковыми в размере, с моей точки зрения». Знакомые проблемы?
Читать полностью »

В данной статье я привожу обзор организации процесса создания программного обеспечения в команде, в которой работаю. Моя цель – это поделиться опытом разработки и управления командой разработчиков.

Для организации процесса работ над проектом мы решили выбрать популярную методологию Scrum. Отчасти это дань моде, отчасти большое количество публикаций в сети Интернет на тему «Scrum сделал за нас все!».
Читать полностью »

На оригинал данной статьи я наткнулся случайно, разгребая почту и наткнувшись на новостную рассылку от ScrumAlliance. Тема метрик Scrum команд и непосредственно кода, меня интересует уже давно. Особенно любопытно, что с этими метриками делать дальше, и первостепенно — зачем они вообще нужны?

В данной работе автор поднимает важнейшую тему для молодых Scrum команд — почему со временем теряется продуктивность и как сохранить ее в долгосрочной перспективе?
Cкучные предисловия я припас для своего уютного блога, а тебе хаброчитатель предлагаю ознакомиться с самой сутью.

Чтобы расширить свой кругозор, а также получить ответ на свои внутренние вопросы, добро пожаловать под кат…
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js