Agile *

Думаю, ни для кого не секрет, что Scrum сегодня – одна из самых популярных Agile-методологий. В сети можно найти много позитивных отзывов от людей, которые его попробовали. Но очевидно, что положительных результатов удается добиться не всем, поэтому есть и немалое количество критических статей. Вот, например, недавно тут же – на Хабре – был опубликован перевод подобной статьи  «Почему оценка задач сломала Agile».

У меня есть хороший опыт использования этого самого Scrum`а и оценки задач в нем, поэтому возникла мысль написать разбор приведенных тезисов и ответить на критику (что-то  в стиле «Антипаттерны Scrum»). Но в итоге, я решил, что будет честнее (по крайней мере для моей первой публикации), если я начну с позитива, и сначала попытаюсь сам разъяснить главное на мой взгляд заблуждение в статье – что же такое Story Points, и что такое оценка в Scrum.

При этом я не хочу писать новую инструкцию. Если вам нужны формальное описание и детали, то можете обратиться к первоисточникам, например к книге Джеффа Сазерленда «Scrum. Революционный метод управления проектами» (МИФ, 2015) – там все подробно описано с обоснованиями и прочим. Я же, в свою очередь, хочу предложить более короткий путь: «с использованием местных идиоматических выражений».

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

Scrum - популярный в командах разработки фреймворк. Но так ли он важен и нужен в действительности?

В статье в формате "вредных советов" приведены порочные практики, которые можно встретить в Scrum-командах.

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

Привет! Меня зовут Евгения Воропаева. Я занимаюсь тестированием в PIMS-команде СберМаркета, мы разрабатываем внутреннюю систему для отдела контента и производства. Проект существует уже 2,5 года и за это время PIMS рос и развивался, приходили и уходили люди, менялись подходы к работе, внедрялись новые практики. Методом проб и ошибок мы выстроили процессы в команде тестирования, которые считаем оптимальными. Хочу поделиться результатом, к которому мы пришли и надеюсь, наш опыт будет вам полезен.

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

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

Сразу будем делать? Или сначала проверим, а кто‑то вообще его купит?

Я уверен, что у статей‑списков есть огромный потенциал для проверки гипотез о спросе.

Привет всем, кто интересуется Канбан‑методом, и кто хочет познакомиться поближе с одним из его инструментов — S.T.A.T.I.K.

Задумка этой статьи появилась тогда, когда в очередной раз ко мне кто‑то подошел с вопросом: «Мы собираемся делать СТАТИК, где про это можно почитать?»

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

Привет, Хабр! На этапе выбора темы статьи было много идей: написать про DevOps или про платформы, а может про продуктовые команды или про практики SRE? Но пришли к выводу, что нет ничего интереснее, чем реальная увлекательная история трансформации. Мы, команды платформы разработки MOEX и экосистемы Финуслуги.ру, в лице Карапета Манасяна, Александра Барыкова, Антона Квашёнкина и Юлии Лутковской, расскажем практически про весь путь изменений и про их подводные камни. Важно отметить, что в статье затрагивается довольно много тем, местами даже будут блоки со скриптами 😊. Поехалиии!

Каждому проектному менеджеру – от junior до senior, известен скоуп методологий управления проектами. Но многие работодатели не понимают, кто такой менеджер проектов, чем он должен заниматься и какие методологии работают для конкретных задач. Как не выбрать то – не знаю что и не попасть туда – не знаю куда? Давайте разбираться вместе.
Меня зовут Лана Демченко, я администратор проектов направления медицинских ИТ-продуктов в компании «БАРС Груп». Также имею опыт работы в продажах и в административном управлении.

Хочу поделиться своим опытом в том, как я бесплатно получил сертифицированное обучение по основам проектного менеджмента от Google на Coursera. Описываемые действия, в моем конкретном случае, помогли мне сэкономить около €300 на всех частях этого курса. Для меня - это ощутимые деньги и я рад, что вообще есть подобная возможность.

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

Эмпирические выводов по прошествии 5 месяцев профильной работы менеджером проектов в разработке веб-приложений.

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

Предваряю свой рассказ дисклеймером: опытным менеджерам или аналитикам — всем, кто напрямую взаимодействует с заказчиками в бизнесе, — этот материал может показаться крайне бесполезным. А вот начинающим управленцам — сильно наоборот.

Всем привет! Мы - отдел бизнес-поддержки (БП) в Social Discovery Group. В этой статье расскажем, как мы повторили шестой подвиг Геракла, очистив доску от 1500 тикетов, которые накопились за 4 года. 1500 задач - это больно. Тикеты кочевали из спринта в спринт, заказчики ежедневно запрашивали статус по задачам, а мы испытывали стресс от переработок и от того, что не можем дать апдейты. Мы поняли, что нужно менять процессы в отделе и применили подход STATIK, который навсегда избавил нас от бесконечной очереди задач. 

Привет всем читателям, желающим грамотно выстраивать самые многозадачные бэклоги. Меня зовут Фёдор Гвоздев, я основатель интернет-магазина корейской косметики HolySkin. Работаю над развитием этого проекта уже 8 лет и не раз сталкивался с трудностями приоритизации. В этой статье я постараюсь поделиться своим опытом и представить самые «рабочие» модели, которые не раз выручали нас в работе.

Осенью я был на митапе, посвящённом scrum'у. И услышал там интересный тезис: в слаженной скрам-команде роль тимлида/техлида минимальна, потому что все участники команды в той или иной степени являются носителями знаний и прекрасно самоорганизовываются благодаря скраму.

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

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

Привет! Меня зовут Карина Суворова, в «Северстали» я занимаюсь автоматизацией пользовательских процессов. Как часто вам приходят письма и встречи с задачами, которые надо выполнить в определённые сроки? Мне много. А моим коллегам, особенно тем, чей рабочий день состоит из таких «почтовых задач», ещё больше.

Чтобы ничего не забыть, нужен удобный инструмент управления, с категоризацией и возможностью анализа загрузки, повторяемости и фактически затраченного времени. И он есть — Jira.

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

Чтобы избавиться от этого разрыва, мы разработали прекрасное решение, которое доступно всем и не требует подготовки для поддержки. Работает оно с Outlook. Нужны только Jira для размещения и структурированного хранения задач и Visual Basic for Applications (VBA) для их создания.  

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

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

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

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

Отличное практическое пособие по agile-управлению проектами для всех и каждого!

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

Agile относится к любому процессу, который соответствует концепциям Agile Manifesto (манифест). В 2001 году 17 разработчиков программного обеспечения встретились, чтобы обсудить простые и эффективные методы разработки. Они опубликовали Манифест Agile Software Development, в котором рассказали о том, как они нашли "лучшие способы разработки программного обеспечения, применяя их самостоятельно и помогая делать это другим".

В отличие от управления проектами по водопадной модели, которая является строго последовательной: вы не начинаете разработку, пока не проведены исследования, и не приступаете к разработке, пока дизайн не завершен; в agile дизайнеры, разработчики и бизнесмены работают одновременно и параллельно.