Рубрика «гибкая разработка»

Дети, рожденные в год подписания Agile Manifesto, в этом году празднуют совершеннолетие. А взрослые люди продолжают спорить, где Agile применим. Обычно бьют по площадям: можно ли использовать Agile вне IT. Иногда добавляют драмы: пробовали ли вы строить атомную электростанцию по Agile? Для художественного эффекта так, конечно, лучше. Но если вы хотите сделать продукт, а не победить в конкурсе ораторов, то лучше смотреть применительно к конкретной ситуации.

В этой статье мы расскажем о нескольких моделях оценки применимости Agile и подробнее остановимся на одной их них — Agile Suitability Model, представленной в Agile Practice Guide от PMI и Agile Alliance.
Читать полностью »

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

Перед вами продолжение истории под названием «Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода» об Agile-трансформации в ivi. На TeamLead Conf технический директор компании Евгений Российский (eross) рассказал, почему может понадобиться откатить всю реорганизацию команды, как при этом не переругаться и помочь разработчикам, а еще и сохранить и приумножить бизнес-эффективность.

Во имя нового продукта - 1
Читать полностью »

Все дело в Agile — 2: особенности внедрения гибкой разработки - 1

Продолжаем про нюансы гибкой разработки (Agile), которые случаются на практике. Как понять, правильно ли внедрен Agile, какая практика годится для какой задачи и отрасли, кто в компании должен переводить работу на «Agile-рельсы»? Своим опытом с редакцией блога Mail.Ru Cloud Solutions продолжает делиться Agile-коуч ScrumTrek Василий Савунов.

В прошлый раз Василий рассказал, что такое Agile, какие он включает методологии и какие вокруг него сформировались стереотипы. Теперь поговорим о его внедрении.
Читать полностью »

Проблемные личности среди менеджеров проектов - 1

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

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

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

Что такое Agile?

Agile вырос из среды веб-консалтинга, где он приносил определённую пользу: при работе с привередливыми клиентами, которые не знают, чего они хотят, обычно приходится выбирать из двух вариантов. Или одолеть клиента: установить ожидания, соответствующую оплату за переделки и поддерживать отношения равенства, а не подчинения. Или принять некорректное поведение клиента (как, скажем, приходится многим дизайнерам) и ориентировать рабочий поток вокруг клиентской дисфункции.
Читать полностью »

Многие другие крупные IT-компании, начиналась со стартапа, и Badoo не исключение. За последние годы компания прошла путь от нескольких десятков инженеров до нескольких сотен. Николай Крапивный был на передовой на большей части этого пути и принимал решения: что лучше делать, а что не делать, как справляться с проблемами. Его доклад на TeamLead Conf был посвящен этому опыту и картине мира, которая в результате сформировалась.

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

Масштабируем разработку: от стартапа до сотни инженеров - 1

Рассказ состоит и трех частей. Первая — про коммуникации, про то, как они меняются с ростом компании. Вторая часть о том, как с увеличением количества инженеров в команде попытаться сохранить скорость разработки. И третья часть — от том, почему Badoo живет на два офиса, и как при этом справиться с проблемой общения.
Читать полностью »

image

В Университете Иннополис студентов обучают профессора и научные сотрудники с опытом работы в ведущих ИТ-компаниях и университетах мира. Также вуз приглашает на гостевые лекции весьма необычных ИТ-специалистов. Мы уже писали о том, как своим опытом со студентами делился хакер Ares, знакомый с Эдвардом Сноуденом. На этот раз мы расскажем о профессоре Анджело Мессине, который работает профессором-практиком Института информационных систем и возглавляет магистерскую программу «Управление разработкой программного обеспечения» в нашем вузе. В интервью он делится воспоминаниями о службе в составе групп войск НАТО, объясняет, почему решил переехать в Иннополис обучать российских студентов и как в Европе армия взаимодействует с наукой.Читать полностью »

Сценарии как инструмент аналитика, и как они помогают работать с требованиями - 1

«Директор небольшой брокерской фирмы Юрий сидел в офисе, который он арендовал в модном коворкинге вместе со своими немногочисленными сотрудниками. Компания последнее время показывала очень хорошие результаты. Престижное экономическое образование позволило самостоятельно построить успешную компанию, а вот как обезопасить основной капитал – базу клиентов – от участившихся хакерских атак собственными силами Юрий не знал. Своим сотрудникам Юрий доверял, но они часто работали из дома, из кафе, да и местный администратор Илья не вызывал доверия, наверное из-за бороды и черной футболки.
Читать полностью »

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

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

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

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

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

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

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

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

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

Автор оригинальной идеи этой статьи — Джон Иннс, консультант в области гибких методологий IT-разработки. С первоисточником можно познакомиться здесь. Мы его немного доработали, много упростили, но теперь статью, хотя бы, можно читать :)

Делаем сплав гибкой разработки и User Experience (UX)

Итак, есть такая штука, как опыт пользовательского взаимодействия (тот самый UX, User Experience). В целом, UX — это впечатление пользователя от вашего продукта (например, сайта). Сюда относится внешний вид, удобство расположения кнопок, ссылок и других элементов.

Почему учитывать опыт взаимодействия — важно? Читать полностью »


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