Agile *

Привет, Хабр! Сегодня мы расскажем о том, как разные команды в JetBrains “готовят” Agile и работают с Agile досками.

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

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

Что самое важное в организации команды? Может построить планы?

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

Что делают успешные команды и чего не делают разваливающиеся за неделю? Что важнее — назначить на каждую задачу исполнителя или проставлять дедлайны, а может самое важное ставить приоритеты? Есть ли действие, которое значительно увеличивает срок жизни проекта?



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

23 мая в питерском офисе Wrike прошла встреча для scrum-мастеров и project-менеджеров. Мы поговорили о реальном применении скрама в IT-разработке, инструментах scrum-мастера, взамоотношении компонентных команд с бизнесом, о целеполагании в условиях разработки по Agile и многом другом. Спешим поделиться видеозаписями докладов.

Узнаете себя? А может, другие из-за вас чувствуют себя так?

Групповой чат похож на непрекращающееся совещание со случайными участниками и без повестки дня. Так считает Джейсон Фрайд, знаменитый сооснователь компании 37signals, автор бестселлеров Getting Real и Rework. Мы в Alconost перевели для вас его статью с анализом плюсов и минусов групповых чатов. Небольшой спойлер: минусов оказалось в несколько раз больше.

Половина успеха в управлении проектами — постановка целей, и это не самая простая половина. Мы в Wrike в свое время основательно озаботились выбором оптимального подхода к целеполаганию на уровне всей компании и отдельных команд, и в итоге остановились на OKR. Изначально концепция Objectives & Key Results (цели и ключевые результаты) зародилась в Intel, но действительно популярной ее сделал Джон Доерр из Google.

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

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

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

Муха дрозофила. Источник

Оставим в стороне книги и маркетинговые изысканя про agile-методологии и встретимся 23 мая в питерском офисе Wrike поговорить о реальном применении скрама в IT-разработке. Участники поделятся как успешными, так и не сработавшими практиками, обсудим, как проходят скрам-ивенты в различных компаниях, какие техники и инструменты применяются. Встреча будет интересна для практикующих scrum-мастеров и сочувствующих. Помимо докладов, планируется дискуссия по темам митапа в неформальной обстановке.

Название этой статьи частично позаимствовано из одного популярного спектакля и кинофильма. «Дальше не придумали, импровизируй» – после этой фразы в фильме звучит нецензурная реакция человека, который понял, что импровизировать придется именно ему. В этой ситуации когда-нибудь оказывался или окажется каждый профессионал, работающий в сфере информационной безопасности. Это тот самый момент, когда ты встал у руля ИБ в организации нового для тебя профиля, когда в структуре компании происходят изменения уровня слияний и поглощений, или когда внезапно в 8 вечера пятницы начинают раздаваться звонки с сообщениями о неработающих банкоматах… Именно тогда в голове начинает звучать этот голос, дающий единственно верное направление дальнейших действий.

Имеющие дело со сложными ИТ проектами руководители подтвердят, что разделение задач на более мелкие и управляемые части делает рабочий процесс намного проще. В этой статье расскажу о процессе, который поможет структурировать каждый этап проекта и учитывать все поставленные задачи. Речь идет об иерархической структуре работ WBS (Work Breakdown Structure).

В качестве предисловия

Ты сидишь перед монитором, разбираешь утреннюю почту, и вдруг воздух вокруг начинает дрожать.

— Что происходит?!

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

— Где я? Что это за место?

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

— Приветствую, %UserName%, ты в оплоте магов! Мы знаем, что ты способен пользоваться Источником Силы. Я расскажу тебе о нем. Источник содержит пять Сил — Земля, Воздух, Вода, Огонь и Дух. Земля олицетворяет устойчивость, Воздух — свободу, Вода — изменение, Огонь — мощь, Дух — дисциплину. В большинстве случаев для выполнения необходимого действия вполне достаточно какой-либо одной части из пяти. Так потоки Огня позволяют зажечь свечу и контролировать горение пламени. Но более сложные задачи требуют плетения потоков из большего числа Сил. Для примера, тому, кто захотел бы воздействовать на погоду, потребовалось бы сплести одновременно потоки Воздуха, Воды и Духа. Но для того, чтобы начать обучение, тебе придётся пройти испытание...

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

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

Одна из очень известных компаний, которая была примером успешного применения Scrum в 1997 году, обратилась за помощью в Danube Technologies, Inc. в 2009 году, потому что «рынок» показал, что они оказались менее гибкими, чем конкуренты. Начинания по внедрению Scrum, которые начались 1997 году, по-видимому, не могли выдержать десятилетие сосуществования с проблемами, присущими крупным предприятиям. К сожалению, большинство попыток внедрить Scrum в крупных организациях не приводит к долговременным преобразованиям. Препятствия для внедрения Scrum обычно также мешают достижению успеха в бизнесе в целом, а устоявшиеся организации обычно неохотно избавляются от них.

Препятствие #1: Наивный менеджмент ресурсов

В Руководстве PMBOK написано:

«зачастую возникает необходимость увеличения бюджета, чтобы добавить дополнительные ресурсы для выполнения того же объема работ в более сжатые сроки»

В отношении программного обеспечения, Фред Брукс (в книге «Мифический человеко-месяц») дает утверждение, которое противоречит предыдущему:

«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»

Чтобы разрешить этот парадокс, давайте рассмотрим определение «ресурса».

Наряду с развитием механических систем автомобиля инженеры постояно стремились добавить что-то в электроную начинку, сделать машину безопаснее, управляемее и умнее. Сегодня для этого есть все предпосылки: ИТ-отрасль развивается огромными темпами, автопроизводители готовы сотрудничать и вести перспективные разработки, корпорации вкладываются в развитие автотранспорта. Между тем, «ум» автомобилей развивался поступательно, на протяжении более полувека. Всё это время он принимал разные формы и уходил в разные концепции: от безопасности до развлечений. Современый виток эволюции зашёл так далеко, что уже непонятно, софт определяет железо или железо — софт. А значит, пора написать об автомобилях на Гиктаймс

О чем?

Как менеджер я заинтересовался бережливым производством и после прочтения книги “Lean Thinking” решил перенести своё видение из сферы заводского производства в IT индустрию.

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

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

Автор рассказал, как избежать максимального количества недоразумений, связанных с использованием историй в разработке программного обеспечения по методологиям Agile и Lean.

Agile — это мода, тренд, слово, которое мелькает везде и повсюду (уступая, кажется, только коучингу).

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

Рассказываем о том, что Agile это не свод правил, высеченный в камне, а советы, которые команды могут применять. Или нет. Учимся мудро подходить к организации рабочего процесса. И использовать на практике только те принципы, что близки вам (ну и заказчику!).

Предисловие переводчика: Недавно я рассказал о том, как реализовать процедуру планирования выпуска релизов по продуктам с помощью семейства продуктов Atlassian и дал ссылки на статьи как сделать тоже самое в Team Foundation Server и Redmine.

А что делать если компания не дозрела купить JIRA, TFS или Redmine, как обойтись только Excel-ем?

И эта статья о том как это сделать.

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

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

На просторах интернета огромное количество информации по управлению проектами в IT-сфере и намного меньше информации о практике применения проектного подхода к разработке продуктов в машиностроении.

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

Сегодня я хочу поделиться двухлетним опытом проведения игры getKanban в Туту.ру. В целом, игровые механики мы используем довольно активно: играем в getKanban, Playing Lean, Lego Serious Game и т. д. Но getKanban, по нашему мнению, наиболее цельная и качественная игра. Для нас эта игра уже стала традицией и привычным инструментом обучения и коммуникации. Возможно, кто-то из читателей возьмет наш опыт на вооружение.

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

Важно!

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