Agile *

Но есть же Scrum?!

Не поймите меня неправильно. Я обожаю Scrum. Я уже много лет использую Scrum везде, где он действительно работает. Но давайте посмотрим правде в глаза – фраза из Scrum Guide “Scrum is easy to understand, hard to master” [1] – очень точно отражает суть [Примечание: по-русски “легок для понимания, сложен для освоения”. Почему-то в официальном русском переводе цинично ограничили максимой “Scrum - прост”]. И это объясняет, почему так много команд легко впадает в ересь “Зомби-Скрама”.

Из-за этой сложности для понимания, командам обязательно нужен хороший тренер, обладающий здоровым эмпирическим подходом и способный помочь запустить процесс, по-настоящему основанный на практическом опыте. Механическое исполнение предписанных ритуалов не способно дать жизнеспособного процесса. Но много ли таких тренеров? Это легко узнать просто взяв просто цифры с сайта scrum.org [2]. Более чем 300 000 сертифицировано как PSM I. Если русскоязычный цикл статей зайдет аудитории Habr, я обязательно расскажу о том, что на деле значат все эти сертификации, но давайте пока просто примем, что любой человек способный прочитать и понять слова в Scrum Guide, легко сдаст PSM I. Теперь посмотрим на сертификации, которые требуют понимания и практического опыта. Для сдачи PSM II уже надо продемонстрировать умение применять Scrum на практике, и сдали его уже всего лишь чуть больше 8 000 человек. И всего лишь чуть больше 800 сдали экзамен, который действительно подтверждает глубокое понимание Scrum - PSM III. Не больше 10 000 человек на миллионы команд по всему миру.

Проблему усугубляет то, что поток информации об Agile как минимум на треть состоит из мнений людей имеющих мало практического опыта разработки настоящих продуктов. Множество авторов больше пожинают плоды стремления людей ко всему модному и популярному. В результате, кто-то пытается преодолеть сложность аджилизации, прибегая к более жестко регламентированным фреймворкам типа SAFe. По моему глубокому убеждению, применение SAFe это большой шаг назад, к дедуктивным (классическим, предсказательным) способам управления проектом, но, по крайней мере, он обеспечивает командам хоть сколько-нибудь ясный путь к реализации Agile. Команды теряют столь ценимую Scrum свободу, но, с другой стороны, недостаток опыта и не позволил бы им воспользоваться этой свободой в полной мере.

По прогнозам Gartner, исследовательской консалтинговой компании, специализирующейся на рынках ИТ, к концу 2024 года, 75% организаций перейдут от пилотных проектов к внедрению ИИ. Для того, чтобы внедрять инновации в мире пост-COVID, лидерам в области данных и аналитики потребуются постоянно увеличивающиеся скорость и масштаб анализа с точки зрения обработки информации и доступности, чтобы добиться успеха перед лицом беспрецедентных рыночных изменений.

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

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

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

ИИ в стране тестирования ПО

Искусственный интеллект (Artificial intelligence) определенно набирает обороты и внедряется в самых разных отраслях. ИИ помогает системам выполнять задачи, которые традиционно требуют человеческого интеллекта. В компьютер может поступать огромное количество наборов данных, в которые затем добавляют логику и шаблоны, чтобы проанализировав, сделать соответствующие выводы. Контроль качества и тестирование необходимы для установления действительного соединения между похожими парами входа и выхода.

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

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

Когда тестировщики инициируют и поощряют диалог, это может пролить свет на более мелкие детали элементов незавершенных задач (бэклога), что позволит инженерам прицельнее сосредоточить свои усилия. Хорошо сформулированные вопросы результируют в полезных дискуссиях и ответах. Когда тестировщики четко излагают свою стратегию, разработчики могут помочь обеспечить тестируемость кода, а также могут написать более прицельные модульные и интеграционные тесты. Все эти меры способствуют получению хорошо протестированного кода.

В этой статье описаны 10 примеров ситуаций, когда хорошо развитые коммуникативные навыки тестировщиков могут стать решающим фактором.

Шон Престридж – старший инженер по применению (FAE), руководитель группы FAE американского подразделения IAR Systems – в статье «Move fast and break things? Not so fast in embedded», рассказывает о специфике разработки программного обеспечения для встраиваемых систем, уделяя особое внимание вопросам качества кода и тестирования.

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

"Мы выбираем, нас выбирают
Как это часто не совпадает"
(с) песня из к/ф «Большая перемена»

Всем привет! С вами рубрика Agile Shorts и сегодня мы с вами поговорим о "Предназначении".

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

Поэтому я не хотел писать еще одну статью с описанием техники Red-Green-Refactor. Мне хотелось взглянуть на TDD немного глубже и описать, как и почему TDD влияет на поведение человека.

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

Тема методологий и процессов разработки, как правило, не особо интересна разработчикам. Абсолютно нормально услышать: “Должен быть менеджер, который этим занимается.” Как мне кажется, большинство разработчиков попросту не видят достаточно ценности в том, чтобы понимать процессы компании. Однако, по моему опыту, это крайне важный компонент, который позволяет программистам становиться сильнее именно с технической точки зрения, а также двигаться по карьерной лестнице вверх. Эту связь я и попытаюсь показать.

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

Если интересно, как мы учились работать с техническим долгом, то добро пожаловать под кат.

Итак вы захотели оценить положение дел в команде. Оказались только что назначенным лидом или выдохнули после первого сданного проекта, который сделали не только собственными руками. Прежде чем бросаться за новый проект, задумались:

Теперь продукт работы, как тимлида  –  больше не только код, не количество закрытых задач в срок и даже не изящность или скорость решений.

Привет, Хабр! Представляю вашему вниманию перевод статьи "The agile swarm: How to design shareable work for software project teams" автора Stephen Frein.

^{Фото: Flickr}

Успешные аджайл-команды склонны ограничивать незавершённую работу (НЗП, незавершённое производство). Предпочитают ли они Скрам, Канбан-метод, или какую-либо другую аджайл-методологию, эти команды особенно выделяют над всем остальным быструю разработку полезной функциональности.

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

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

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

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

Я и мои коллеги по работе для внутренних сотрудников компании, в которой я работаю, периодически готовим небольшие статьи, где разбираем различные кейсы по гибким подходам, включая и кейсы использования Канбан-метода для совершенствования и управления процессами. Такие статьи мы называем Agile-shorts. И я подумал, "А почему бы не открывать свои статьи и для более широкой аудитории?" И, вот, сегодня я публикую первую свою статью из этой серии.

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

Выбор методологии разработки новых программных продуктов зависит от ряда следующих факторов: новизна и новаторство концепции; понимание клиента, что он хочет; понимание поставщика программных продуктов, что хочет клиент. Парадокс заключается в том, что и тот и другой ошибаются с самого начала на этапе формирования идеи. Для того чтобы идея была подтверждена в виде MVP и в дальнейшем развивалась в виде продукта, необходимо выбрать подход и механизмы, направленные на быстрое получение обратной связи от клиента.

В этой статье мы поделимся опытом запуска стартапа в компании — системном интеграторе ОТР2000 с точки зрения выбора и внедрения гибкого подхода к разработке протестированных и
работоспособных программных продуктов.

Всем салют. Эксперт OTUS Андрей Романов приглашает всех желающих на свой бесплатный демо-урок по теме: «Командообразование в удаленных и распределенных командах».

А мы в свою очередь традиционно делимся с вами полезным переводом

Случалось ли вам работать над проектом, где участвует более сотни человек, несколько компаний, с учетом 10 часовых поясов, разных менталитетов и языков? Хотим поделиться своим опытом планирования работ в проекте, который управляется по методологии SAFe в условиях вынужденной удаленной работы.