Agile, Scrum, разработка ПО Archives – Страница 12 из 31

Технический долг: как не стать жертвой невидимого врага

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

Технический долг и беклог

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

Три визуализации, которыми я объясняю Agile

Хорошая визуализация помогает объяснять достаточно сложные вещи. Вместо большого количества слов достаточно одной картинки. У большинства консультантов есть свои любимые визуальные метафоры. Михаэль Вильямс в своей статье рассказывает о визуальных метафорах, которые он использует для объяснения принципиально важных моментов в организации работы по Agile. Когда я учился в школе, я сделал открытие. Я обнаружил, что я посредственно запоминаю числа, даты и формулы, но при этом фантастически легко запоминаю изображения и истории. Если я нашел способ изобразить что-то визуально, есть хороший шанс, что я запомню это навсегда. Если нет, то увы… То, что появилось как подспорье в учебе, быстро стало моим…

Есть ли польза от оценок трудозатрат разработчиков для самих разработчиков?

Мы знаем, что заказчикам и заинтересованным сторонам проекта нужны оценки по срокам реализации задач. На их основании они строят планы, расставляют приоритеты и планируют даты поставки разрабатываемых продуктов. А что для разработчиков? Для них отдача совсем не очевидна. Да и в целом может показаться, что и пользы-то никакой нет, ведь оценки используются зачастую “против” разработчиков, поскольку интерпретируются и воспринимаются стейкхолдерами именно как обещания. Вполне естественно, что разработчикам без особого удовольствия дают оценки, ведь они могут повлечь неприятности. Однако, оценки могут принести однозначную пользу командам разработки – фактически, со временем они могут повысить статус команд разработки среди всех заинтересованных сторон и…

Кто тут крайний?

Забудем на минуту про единорогов, бирюзовые компании, холакратию и прочие мифические концепции. Они, конечно, где-то есть, но не очень рядом. Представим себе традиционную организацию, имеющую ИТ-департамент, устроенный, как водится, в виде иерархии. Ничего необычного. Часть этой иерархии – подразделение, где трудятся аналитики. Поймаем одного из них в коридоре и спросим: “Подскажи, дружище, на твой взгляд, чтобы всё в разработке ПО стало быстрее и качественнее, что нужно сделать?”. Во многих знакомых мне компаниях ответ будет примерно таким: “Известно что – разработчиков заменить на нормальных. Наши-то и бизнес не понимают, и код пишут так себе, а учиться и слушать никого не хотят…”….

Олег Скрынник, 4 октября 2020, последний комментарий 28 октября 2020

Семь распространённых мифов о DevOps

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

Разрешение конфликтов в Agile-командах

Большинство людей предпочло бы избегать конфликтов. Как специалисты по проектам, мы знаем, что это неизбежно, и мы также знаем, что несогласие может быть конструктивным. Но при этом мы не любим конфликты, и большинство из нас надеется, что кто-то другой возьмёт на себя их разрешение. Что ж, с гибкими командами это может быть сложно, потому что команда должна быть самоорганизованной, а значит, никто не должен вмешиваться и исправлять что-то за нас. Что с этим делать? Возможно, вы не склонны доверять статьям, в которых обсуждается управление конфликтами. Я уверен, что их авторы действуют из лучших побуждений, но говорить о стандартных моделях управления…

Как бизнес-аналитику встроиться в гибкую среду?

Есть ли роль бизнес-аналитика в гибкой среде? Я уже довольно давно работаю бизнес-аналитиком, и этот вопрос возникает постоянно. Бизнес-аналитики зачастую считают, что они должны оправдывать свою роль в гибкой разработке. Тот факт, что такой вопрос всё время задают, проистекает из руководства по Scrum. Scrum Guide определяет три роли в команде: команду разработчиков, Scrum -мастера и владельца продукта. Легко заметить, что здесь не упоминается о роли гибкого бизнес-аналитика. Нельзя сказать, что мы единственные, кто остался в стороне – также не определены роли для архитекторов решений, тестировщиков, группы обеспечения качества, менеджера развёртывания, дизайнера пользовательского интерфейса или технических писателей. Мы все каким-то образом…

Бэклог! – Как много в этом слове …

Команды, работающие над развитием различных продуктов, имеют одну общую цель: обеспечить максимальную скорость изменения своего продукта для реализации возникающих потребностей пользователей / заказчиков. Вопрос: В каких условиях команда может достигнуть требуемых показателей? Ответ: При одновременном достижении двух условий: Команда, как черный ящик, устроена внутри корректно: умеет работать с потоком обрабатываемых объектов (намеренно не указываю каких), пропускная способность отдельных этапов обработки сбалансирована. Достижение такого состояния – предмет отдельной целенаправленной работы, детализировать далее не будем, предполагаем далее, что оно достигнуто. Команда может управлять входом поступающих объектов: объекты должны быть замкнутыми (в математическом смысле :): иметь строгие границы) так, чтобы команда могла их…

Может ли быть слишком много прозрачности в работе Agile-команд?

Прозрачность часто называют одним из трёх столпов Agile, наряду со способностью к проверке и адаптации. Но может ли команде быть нанесён вред от излишней прозрачности? Майк Кон (Mike Kohn), один из соавторов и основателей Scrum и Scrum Alliance, считает, что это возможно, и предлагает свой подход по снижению возможного урона. Для начала давайте определим, предлагает Майк, прозрачность как отражение того, как работает команда. Измеримая часть на самом базовом уровне может быть представлена следующими метриками: скорость работы отработанные часы количество story points на одного сотрудника команды диаграммы выгорания количество исправленных дефектов за один спринт и проч. Некоторые из них, возможно, стоит…

5 спорных моментов, убранных из Scrum

Сам по себе фреймворк Scrum уже давно перестал быть инновацией. Появившись задолго до подписания Agile-манифеста, Scrum сегодня неразрывно связан с миром гибких подходов. Основой фреймворка уже довольно давно является “Руководство по Scrum” (Scrum Guide). С момента своего появления этот документ довольно сильно изменился. В своей статье голландский специалист Вилем-Ян Агелинг рассказывает о пяти спорных моментах, выпавших из руководства по Scrum за эти годы. Если вы перешли на Scrum пять или более лет назад, то ваше понимание Scrum отличается от того, которое существует сегодня. Есть много вещей, которые когда-то определялись как Scrum, даже упоминались в руководстве по Scrum, но в какой-то…

Портал №1 по управлению цифровымии информационными технологиями

Agile, Scrum, разработка ПО

Портал №1 по управлению цифровыми
и информационными технологиями