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

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

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

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

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

Олег Скрынник, 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, но в какой-то…

Почему стоит меньше рассуждать об Agile и больше о потоке

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

DevOps и “смерть” разработчиков. Что-то пошло не так

Разработка уже умерла давным-давно и была заменена DevOps. Или, по крайней мере, так должно было случиться после появления DevOps. Знакомая мантра? Бернард Броуд (Bernard Brode) в своей заметке на портале DevOps.com рассказывает, почему это не так. На самом деле у разработчиков всё просто отлично. Например, прямо сейчас на крупнейшем в мире сайте по поиску работы Monster.com около 150 000 вакансий для разработчиков. И для сравнения лишь около 16 000 позиций для специалистов DevOps. Похоже, что революция, в ходе которой разработчики должны были бы быть заменены инженерами DevOps, не случилась. “Смерть” разработчиков Угасание позиции разработчика предсказано было уже давно. Фактически, с…

Agile-методы не подходят для устаревшего лидерства

Две группы лидеров Не так давно я разговаривала с потенциальным клиентом, давайте назовём его Стивом, который был заинтересован во внедрении гибких практик управления. Стив полагал, что он уже очень хорошо осведомлён об Agile. Он хотел, чтобы его организация «стала гибкой», ожидая более быструю поставку продукта, лучшую предсказуемость и лучшие показатели. Все это веские причины, по которым организации хотят стать гибкими. Но когда я спросила его, что он будет делать с улучшением показателей, он дал мне повод задуматься. Ответ Стива: «Мы хотим посмотреть, насколько хорошо работают команды, получаем ли мы от них то, за что им платят. Мы не можем позволить…

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

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

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