Agile *

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

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

Вы находите буклетик, где очередная школа английского языка предлагает айтишнику "вспомнить всё" в одном из своих курсов. Вы внимательно изучаете программу курса (здесь, на пункте "произношение популярных айтишных слов", ваш речевой аппарат могут схватить судороги, а язык захочет вырваться наружу, шепелявя что-нибудь th-содержщее).

Но вот вы видите блок уроков, посвящённых идиомам. Идиомам. И-ди-о-мам. Кому они нужны, эти идиомы? Разве айтишники используют их в командном общении?

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

Давайте-ка вспомним что такое "идиома". А что такое идиома вообще? Идиома -- то набор слов, который имеет смысл в определенном языке, но не может быть дословно переведён без потери смысла на другой язык. Ну, например, в русском есть идиома "быть на седьмом небе". В английском языке тоже есть такая идиома, но звучать она будет по-другому -- to be on cloud nine.

Так уж случилось, что в интернациональных командах очень часто члены команды имеют классный английский (как нейтивы, так и не-нейтивы), а, значит, их речь наполнена всем: фразовыми глаголами, идиомами, сленгом и т.п.

Приветствую всех читателей Хабра!

Меня зовут Денис, RTE в компании «Автомакон». На данный момент работаю в направлении «Фулстек» на проекте «ВкусВилл».

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

Привет, друзья! Сегодня у меня важный день — я решила приступить к писательскому труду. Не обещаю стать активной, как многие тут, но, кажется, у меня есть, что сказать, особенно тем, кто только начинает свой путь в области управления проектами, будь то Project Manager, Scrum Master или просто руководитель, которому не все равно на свою команду, и кто хочет узнать что‑то новенькое о нематериальной мотивации.

Первая тема, моей статьи возможно нестандартная и казалось бы весьма недооценённая, назову ее так: Тет‑а-теты: Как общение с командой делает проекты крутыми?! В мире управления проектами одно из тайных оружий не всегда выходит за рамки обычного «Привет, как дела?». Это — теты, разговоры, которые поднимают общение в команде на новый уровень. Вам не кажется, что иногда общение в проекте — как танец на клавишах: непредсказуемо и иногда несуразно? Так вот, тет‑а-теты — это ваша тайная кнопка для оживления ваших проектных мелодий.

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

На связи Мария Болдырева — руководитель проектов в IT-компании Outlines Tech. Управляю командами 7 лет, среди которых 4 года — в IT. За это время повидала всякое: от стартапов до корпораций, и в статье делюсь своим опытом. 

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

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

Привет, Я Бохан Дмитрий — руководитель отдела инновационных проектов компании ПГК Диджитал. Сегодня поговорим про ретроспективу, зачем проводить ретро, а самое главное посмотрим с помощью каких игр, можно сделать ретро ярким и незабываемым.

Зачем проводить ретроспективы с командой? 

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

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

2. Вовлечение команды: с участие членов команды в процессе принятия решений  дает им новые возможности и увеличивает их чувство владения проектом.

3. Решение проблем: выявление проблем и препятствий своевременно не позволяет им расти и сорвать проект.

Инструменты для ретро

Подготовка и проведение эффективных ретроспектив требует некоторых важных инструментов и методов:

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

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть1, Часть2, Часть 3, Часть 4. Сегодня мы обсудим совмещение нескольких подходов для управления сквозным бэклогом команды.

Итак, проблема, которую мы будем решать — это отсутствие процесса работы с бэклогом и сквозной приоритизацией. Важно отметить, что инструменты, которыми я буду в основном оперировать, — это jira инсталляции server, плагин jira structure, jira kanban. Если реализация возможна на других инструментах, я буду в явном виде на них ссылаться. Но думаю, что в том или ином виде, подход можно переиспользовать и для других тикетных систем.

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

Это мой второй перевод и я позволю себе в этом предисловии пару предложений о том, зачем я потратил свое время на этот перевод:

Как живут IT-специалисты в сервисных подразделениях больших компаний, основной профиль которых напрямую не связан с IT? В этой статье, первой из серии — о том, как построена работа айтишников в Sminex, как мы применяем Agile-подход в повседневной работе, что у нас получается хорошо. Наша компания специализируется на строительстве дорогой недвижимости в центре Москвы — создаёт коллекцию домов вокруг Кремля в исторических районах города. Компания строит и проектирует более 460 тыс. кв. м элитной недвижимости.

Эта публикация вдохновлена одной из многочисленных презентаций о том, как планировать спринт в разработке, коих за свою жизнь я видел очень немало. И все они похожи одна на другую, как однояйцевые близнецы - всегда очень красивые рисунки и выверенный текст типа «тут у нас аналитика, вот разработка и тестирование, двухнедельный спринт, в конце спринта все задачи закрыты, руководство в восторге, заказчик счастлив». Я же хотел бы показать реальность такой, какая она есть.

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

Полезные борды и другие приёмы из личной практики.

Жизненный цикл (далее – ЖЦ) программного обеспечения (далее – ПО) состоит из ряда этапов, начинающихся стадией зарождения и заканчивающихся прекращением применения (рис. 1). Любая информационная система (далее – ИС) представляется совокупностью программных продуктов или ПО, тем самым определение жизненного цикла ПО и ИС тождественны. Вследствие того, что современные корпоративные информационные системы (далее – КИС) состоят из множества ИС, последнее применимо также и к КИС. 

Подарите 25 час в день и 8 день в неделю. Да еще одну неделечку к отпуску... Знакомо? Вот и я долгое время грустно смотрела в свой календарь и не понимала, куда все время уходит время и почему задачи закрываются в последний, самый горящий момент.

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

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

Итак, путь к личной эффективности начнем с небольшого аудита.

Сначала я анализирую, куда уходит моё время. Это даёт чёткое понимание, сколько времени у меня на самом деле есть и на что оно тратится. Такой аудит помогает выявить "воров времени" и переосмыслить приоритеты.

Менее важные задачи составляют около 65% общего списка. Хотя их вклад в достижение конечных целей минимален — примерно 15%, они несут в себе риск стать "ворами времени". Для эффективного управления временем критично научиться отличать эти задачи от ключевых и при необходимости делегировать их или же вообще исключить из списка приоритетов.

В команде продукта не проводят исследования и действуют «по ощущениям»? Не понятно как создавать продукты, которые соответствовали бы ожиданиям клиентов или превышали их? Как встроить исследования в регулярные процессы своими силами, не нанимая новых сотрудников и без большого бюджета?

В кейсе вы найдете ответы на все эти вопросы!

Пожалуй, нет более популярной темы для обсуждения, чем применение Agile в проектах SAP. Несмотря на то, что принципы гибкой разработки были сформулированы ещё в 2001 году [1], их использование в настоящее время становится как никогда востребованным. Связано это в первую очередь с тем, что последнее десятилетие знаменуется массовым использованием информационных технологий (далее – ИТ) в повседневной жизни: порталы государственные услуг, интернет-магазины, электронное правительство и многое другое. Вышесказанное требует как грамотной разработки программного обеспечения (далее – ПО), так и не менее искусного его внедрения. 

Всем привет! Меня зовут Дмитрий. Я работаю senior Agile‑коучем в ОТП Банке. Использую практики Канбан‑метода в своей работе с 2019 года и хочу поделиться с вами своим опытом. В статье используются данные, собранные при работе с сервисной IT‑платформой, состоящей из 8 команд (общая численностью около 70 человек).

Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь делать разработку эффективной. Иногда даже получается.

Вместо предисловия

Agile. Кругом Agile. Наверное не осталось людей, команд и организаций, которые работают не по Agile. Слово «SCRUM» прочно вошло в жизнь разработчика. Я уже и не помню, была ли разработка иной. А когда спрашиваешь, почему у вас в организации насаждается Agile, в ответ получаешь либо цитату из эпиграфа, либо, если человек более откровенен, слова "так все делают". Ну не может же быть, чтобы миллионы мух ошибались то, что делают все, было ошибочным?

Но, как известно, есть некоторые особенные люди, которые могут попытаться проверить, ошибаются ли мухи верно ли то, что делают все? Приятно, черт возьми, ощущать себя особенным!

Для начала попробуем подсчитать стоимость ритуалов SCRUM

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

- дейли митинг, он же стендап митинг. Вообще-то он должен занимать до 15 минут, но моя команда обычно хорошо если укладывается в 30 минут. Каждый день.

- планирование работ на будущий спринт. Тот самый процесс, где мы всей командой весело играем в карты. Обычно это занимает минимум 2 часа в спринт. Включает в себя декомпозицию задач из беклога, оценку и распределение. Да, в моей команде распределение проводится на планировании, нет такого, что на доске висят задачи, и сотрудники берут какую хотят.

Ни для кого не секрет, что ключевой задачей любого бизнес-продукта является прибыль. Но весь ли успех продукта зависит от бизнес-фич?