Всем привет. Меня зовут Рома, я-разработчик. За короткое время, в одной команде, на одном проекте, я поработал в трёх разных вариациях скрама. Ощущались они по-разному, и каждый новый вариант нравился мне меньше предыдущего. В этой статье я поделюсь своим опытом и выводами.
Начало декабря. Утро понедельника. В переговорной собралась команда для обсуждения планов на спринт.
Накидали несколько задач из бэклога. По требованиям — всё понятно, по срокам — всё адекватно, но в воздухе чувствуется какая-то недосказанность.
Владелец продукта кивнул, принимая тяжёлое, но важное для команды решение, и твёрдо произнёс: «Нам нужно поставить ёлку».
Вчера появился мем на просторах интернета, конечно, он забавный, однако, не имеет отношения к реальности. Да и забавен ровно настолько, насколько процветает ваше непонимание того, что в этих двух колонках.
Не пытаясь выступить адвокатам чего бы то ни было, хотел бы разъяснить определённые неточности мема, потому что, возможно, больше никто этого не сделает, но все примут за чистую монету.
Думаю, мало кто стал бы спорить, что передовые проекты индустрии разработки программного обеспечения, IT отделы корпораций, в своей работе используют инкрементально-итерационные подходы. Со временем, Agile оброс горой идеализма и шарлатанства: коучи, менторы, мотиваторы — случайные люди, рассказывают о том, как нужно поверить в схемки и диаграмки, чтобы проникнутся общей целью.
Цель данной статьи — поставить идеалистичное отношение к Agile с ног на голову — материалистически объяснить, когда Agile работает, как именно работают те или иные ценности и принципы; какой Agile идеалистический, а какой материалистический.
Недавно наше внимание привлёк один вопрос, заданный на stackexchange.com. Этот вопрос был направлен на то, чтобы разобраться с влиянием скрама на работу программистов. Автор вопроса, пользователь Qiulang, поднимает довольно смелую тему: «Скрам превращает хороших разработчиков в программистов средней руки. Возможно ли это?».
Основная идея фреймворка скрам заключается в организации процесса разработки для более быстрого выполнения работ на различных этапах жизненного цикла проекта. Но всегда ли такой подход подталкивает разработчиков к правильным моделям поведения? Многие пользователи, присоединившиеся к обсуждению вышеупомянутого вопроса на Stack Overflow, сталкивались с похожими вещами, когда разработчики «срезают углы», слишком большое значение придают высоким баллам, назначенным их тикетам, или даже прикидываются перед менеджерами высокопроизводительными сотрудниками. Как избежать этих опасностей?
Вопрос, о котором идёт речь, перешёл с workplace.stackexchange.com на softwareengineering.stackexchange.com. Это говорит о том, что программисты рассматривают соображения, связанные со скрамом и с его эффективностью, как нечто достаточно серьёзное, выходящее за рамки управления циклом разработки ПО. Они ощущают воздействие этого метода управления проектами на рабочую обстановку в целом.
Читать полностью »
Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры. Я изучал скрам в колледже. Тогда он считался лучшим методом управления разработкой программного обеспечения. Когда я начал работать, мне нравилось всё, что имеет отношение к скраму: ежедневные встречи, планирование, ретроспективные совещания, спринты и так далее. В конце концов, я пользовался на практике тем, чему меня учили.
Но через несколько лет я начал кое-что замечать: в последние дни спринта все бросаются доделывать всё то, чем занимались в предыдущие две недели, стремясь избежать переноса задач на будущее. Часто те, кто так поступали, брали на себя ненужный риск.
Почему? Разве какие-то задачи не могут подождать до следующей недели? Так ли важно доделать абсолютно всё до выходных? Нет, не так уж это и важно. А всё это происходит из-за того, что «Переносы задач — это плохо».
Читать полностью »
В течение всей истории разработки ПО, мы искали надежные способы оценки времени на реализацию задач и проектов. Но и спустя более чем 60 лет существования отрасли, наши прогнозы все еще оставляют желать лучшего. Может быть, дело не в том, как именно мы пытаемся оценивать, а в том, что мы вообще опираемся на оценки?
К примеру, возьмите методологию Scrum, по которой сегодня работают многие компании. Центральная идея Scrum — брать в спринт не больше задач, чем ваша команда способна за это время выполнить. На первый взгляд, звучит разумно. К сожалению, слишком часто на практике этот подход приводит к замедлению работы команды в обмен на иллюзию планирования. Позвольте объяснить, почему.
Читать полностью »
Доброе время суток, уважаемый Хабр!
Я программист «старой школы», с опытом работы более 20 лет. Участвовал в разработке многих проектов, большая часть из которых довольно известные и успешные. В некоторых проектах занимал руководящие должности, достиг неплохого уровня зарплаты. Но ведь мы собрались здесь не для того, чтобы помериться стажем, опытом, зарплатой и т.д., верно? Поговорим лучше о том, как стартапы используют современные методы управления разработкой программного обеспечения. И что из этого получается.
Читать полностью »
Если он так хорош, то почему все не работают только по этой методологии? А те, кто якобы внедрил, часто демонстрирует чудовищный ScrumBut. Настоящий SCRUM оставляет на вашем сердце шрамы, раны и отметины, и сейчас я расскажу о своих.
Читать полностью »
Наблюдая за применением Scrum в той или иной команде, я сделал вывод, что этот фреймворк, мягко говоря, не совсем правильно применяют. Несколько лет назад, впервые столкнувшись со Scrum (Скрам), я воспринял все происходящее как какой-то неведомый ранее бардак. Увидев очередной вариант бардака в другой компании, я решил прочитать пару книг по теме, а потом мне повезло попасть в стартап в качестве разработчика, где Скрам реально работал.
Читать полностью »
