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

Все оценки сроков разработки ПО — ложь - 1

▍ Разработка ПО — это исследование

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

В разработке ПО мы не тратим время на задачи, решения которых знаем. Если решения уже существуют, мы добавляем в качестве зависимости пакет или библиотеку с этим решением, или копируем старый код, или делаем что-то ещё, на что требуются секунды, а затем можем переходить к следующей задаче. Почти всё время разработки тратится на новые задачи, ответов на которые мы не знаем. Часто они новы ужасно скучным образом, например, «как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?» Но именно из-за них эта ситуация отличается от всех остальных (или, по крайней мере, от тех, которые мы смогли найти) и именно это занимает всё наше время.Читать полностью »

Хоть раз в жизни каждый из нас задумывался о том, как прошлый опыт, ошибки и достижения привели его в ту точку, в которой он находится в данный момент. Человеку свойственно рефлексировать, анализируя все плюсы и минусы собственных жизненных решений.

Для команды разработки такой процесс также не чужд. Мы называем его ретроспективой. Чтобы оптимизировать в будущем работу, необходимо регулярно проводить это безусловно важное мероприятие в agile методологии. Давайте детально разберём преимущества ретро и научимся правильно проводить такие встречи.

Как ретро помогает решать проблемы?

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

Подобная статья должна была появиться раньше, лет десять или -надцать назад, когда Agile только начинал внедряться в компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, если бы менеджеры сразу подходили к вопросу правильно …

Зато за это время накопился опыт "внедрений" Agile в разных условиях, в разных компаниях, который следует обобщить и повсеместно распространять.

Дисклеймер или отказ об ответственности

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

Главная ложь SCRUM. Откуда берётся карго-культ - 1

Дисклеймер

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

Начало декабря. Утро понедельника. В переговорной собралась команда для обсуждения планов на спринт.

Накидали несколько задач из бэклога. По требованиям — всё понятно, по срокам — всё адекватно, но в воздухе чувствуется какая-то недосказанность.

Владелец продукта кивнул, принимая тяжёлое, но важное для команды решение, и твёрдо произнёс: «Нам нужно поставить ёлку».

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

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

Scrum-мем на злобу дня - 1

Не пытаясь выступить адвокатам чего бы то ни было, хотел бы разъяснить определённые неточности мема, потому что, возможно, больше никто этого не сделает, но все примут за чистую монету.

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

Думаю, мало кто стал бы спорить, что передовые проекты индустрии разработки программного обеспечения, IT отделы корпораций, в своей работе используют инкрементально-итерационные подходы. Со временем, Agile оброс горой идеализма и шарлатанства: коучи, менторы, мотиваторы — случайные люди, рассказывают о том, как нужно поверить в схемки и диаграмки, чтобы проникнутся общей целью.

Agile без идеализма. Когда и как именно работает гибкий менеджмент. Политэкономический памфлет - 1

Цель данной статьи — поставить идеалистичное отношение к Agile с ног на голову — материалистически объяснить, когда Agile работает, как именно работают те или иные ценности и принципы; какой Agile идеалистический, а какой материалистический.

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

Недавно наше внимание привлёк один вопрос, заданный на stackexchange.com. Этот вопрос был направлен на то, чтобы разобраться с влиянием скрама на работу программистов. Автор вопроса, пользователь Qiulang, поднимает довольно смелую тему: «Скрам превращает хороших разработчиков в программистов средней руки. Возможно ли это?».

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

Правда ли то, что скрам уничтожает отличных программистов, или дело в том, что его неправильно применяют? - 1

Вопрос, о котором идёт речь, перешёл с workplace.stackexchange.com на softwareengineering.stackexchange.com. Это говорит о том, что программисты рассматривают соображения, связанные со скрамом и с его эффективностью, как нечто достаточно серьёзное, выходящее за рамки управления циклом разработки ПО. Они ощущают воздействие этого метода управления проектами на рабочую обстановку в целом.
Читать полностью »

Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры. Я изучал скрам в колледже. Тогда он считался лучшим методом управления разработкой программного обеспечения. Когда я начал работать, мне нравилось всё, что имеет отношение к скраму: ежедневные встречи, планирование, ретроспективные совещания, спринты и так далее. В конце концов, я пользовался на практике тем, чему меня учили.

Скрам умер. Да здравствует канбан - 1

Но через несколько лет я начал кое-что замечать: в последние дни спринта все бросаются доделывать всё то, чем занимались в предыдущие две недели, стремясь избежать переноса задач на будущее. Часто те, кто так поступали, брали на себя ненужный риск.

Почему? Разве какие-то задачи не могут подождать до следующей недели? Так ли важно доделать абсолютно всё до выходных? Нет, не так уж это и важно. А всё это происходит из-за того, что «Переносы задач — это плохо».
Читать полностью »

В течение всей истории разработки ПО, мы искали надежные способы оценки времени на реализацию задач и проектов. Но и спустя более чем 60 лет существования отрасли, наши прогнозы все еще оставляют желать лучшего. Может быть, дело не в том, как именно мы пытаемся оценивать, а в том, что мы вообще опираемся на оценки?

К примеру, возьмите методологию Scrum, по которой сегодня работают многие компании. Центральная идея Scrum — брать в спринт не больше задач, чем ваша команда способна за это время выполнить. На первый взгляд, звучит разумно. К сожалению, слишком часто на практике этот подход приводит к замедлению работы команды в обмен на иллюзию планирования. Позвольте объяснить, почему.
Читать полностью »


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