Agile *

Джефф Сазерленд (Jeff Sutherland), военный летчик (совершивший более 100 боевых вылетов во Вьетнаме), cоавтор Agile-манифеста и CEO Scrum.



Здравствуйте!
Сегодня я хочу поговорить о жизни, свободе и поиске счастья — о Великой Американской мечте, которая зачастую так и остается неисполненной. Как сказал поэт Роберт Бёрнс: «Даже самые тщательно выстроенные планы идут крахом и у мышей, и у людей», что не может не вызывать неудобств и психологического дискомфорта, вместо ожидаемого удовлетворения.

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

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

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

И такой человек нашёлся — это Надежда Юринова, директор по маркетингу в компании Bookmate. Надежда, как многие из нас, долго время работа в Москве, но в какой-то момент собственной жизни решила переехать в Берлин не меняя место работы.

О работе на новом месте, удалённом от старого на, примерно, 1800 километров мы и пообщались.

Спойлер: в конце публикации всех дочитавших ждёт небольшой сюрприз.

Первый вопрос – достаточно простой: почему ты начала работать удаленно?

Так получилось потому, что я хотела пожить в другом городе, и им стал Берлин. Я не ожидала, что мою роль можно полноценно исполнять вне офиса. Потому что директор по маркетингу – это не только стратег, но и team lead, который подбирает самых лучших ребят, объединяет их друг с другом, запускает процессы, чтобы они вместе системно работали и время от времени что-то им подкидывает и где-то их контролирует. Конечно же, это проще делать, когда ты с ними находишься рядом.

1-13 февраля 2001 года семнадцать человек собрались на горнолыжном курорте The Lodge At Snowbird на горном хребте Уосатч (штат Юта, США), чтобы поговорить, покататься на лыжах, расслабиться, попытаться найти общий язык, и, конечно же, поесть. То, что родилось в ходе этой встречи, назвали Agile Manifesto. Были собраны представители, придерживающиеся различных методологий разработки: экстремального программирования, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, другие симпатизирующие идее необходимости в альтернативной системе управления документацией и тяжеловесы мира разработки софта.



Пожалуй, сложно было бы найти сбор организационных анархистов крупнее этого. То, что получилось в результате встречи, было символично названо манифестом о гибкой разработке программного обеспечения, а именно Agile Manifesto, и подписано всеми участниками встречи. Единственное сомнение было связано с термином agile в названии и исходило от Мартина Фаулера, который выразил беспокойство, что большинство американцев не знают, как правильно произносить это слово.

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

Все началось с того, что в начале 2016 года меня пригласили работать в небольшой украинский Банк в качестве архитектора информационных систем (ИС). И одной из задач, которая перешла мне от прошлой команды, была задача организации работы ИТ службы в соответствии с сервисно-ресурсной модели. Да, задача безусловно не относится к архитектуре ИС, но послужила для меня своеобразным вызовом.

Факторы, повлиявшие на успех выполнения задачи:

• Поддержка руководства (уровень правления Банка);
• Желание модернизировать ИТ службу (как со стороны бизнес пользователей, так и со стороны работников ИТ службы);
• Личный опыт работы в данной модели управления на предыдущих местах работы.

Словом
Мы все больны гандболом
Мы все больны гандболом
И за гандбол умрем…

Сплин.

Agile методологии (для удобства назову ее гибкой) набирают обороты, отвоевывая все большие территории у Waterfall. Гибкость, как основа всего сущего, проникает во все новые сферы: управление проектами (ведущие стандарты постепенно вставляют соответствующие принципы в свои управленческие подходы — PRINCE2 Agile, например) и отрасли (государственную, например).

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

Дмитрий Лобасев (lobasev.ru)

Давайте погрузимся в механику гибких процессов и вместе подумаем, как сделать так, что вот, приходите вы, например, с конференции и как менеджер говорите: «Так, ребята, всем Kanban с понедельника!» или «Всем Scrum!». А ребята смотрят на вас – ну, а какой у них выбор? Сказали Scrum, значит, Scrum… Идут, что-то делают, пытаются сделать Scrum, делают какие-то ритуалы, приплясывают возле доски по утрам, ходят, что-то еще делают. Но что-то не работает.

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

Вот как было задумано:



Ну, и получается на выходе:

Асхат Уразбаев (ScrumTrek)

Прежде, чем начнем говорить, как это все выглядит изнутри, с какими проблемами мы сталкиваемся, когда тренируем команду, вопрос: те, кто работает по Agile, что для вас значит, что Agile команда является Agile командой? Как вы это определяете?

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

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

Раньше для автоматизации технических процессов в финансовом отделе мы использовали такую структуру.

Является ли Agile аналогичным Lean? Когда люди говорят “Agile”, подразумевают ли они на самом деле Scrum? Или люди все еще используют разные типы Agile и почему?

Получая много вопросов в прошлом, я решил расставить все точки над “и”.

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



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

На этой неделе мы постарались системно рассмотреть, кто, зачем и как проектирует UX. Сегодня мы решили продолжить эту тему в свете редизайна нашего сервиса Печкин-mail.

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

Этот материал будет полезен в первую очередь тем, кто много занимался программированием и вдруг внезапно стал вынужден заниматься управлением проектами и людьми. С год назад я рассказал про наказания на конференции, а солнышки из Битрикса сделали текстовую версию для #habr. К сожалению, потеряв в точности, четкости и правильности акцентов. За год материала добавилось. В конце — чеклист для ленивых :)

Итак. Если вы не садист или моральный урод, а ваши сотрудники — не мазохисты, то сомневаюсь, что кому-то из вас наказания доставляют удовольствие. Мне — нет.

Структура публикации

• Немного о том – почему так?
• Схема работы команд разработки под которую делается настройка
• Настройка XML-ек
• Сохранение XML-ек
• Настройка TFS через интерфейс

Использовалась TFS 2015, однако многое справедливо и для более ранних версий.

В минском офисе Wargaming регулярно проходят встречи, на которых сотрудники компании делятся опытом и обсуждают насущные вопросы, волнующие разработчиков, менеджеров, дизайнеров, продюсеров, художников – словом, всех тех, кто работает в IT и геймдеве. Эти митапы мы называем WG Talk и проводим в закрытом формате, только для сотрудников компании.
Но есть темы и знания, которыми нельзя не поделиться с широкой аудиторией. Поэтому мы организуем Open WG Talk.

Сегодня мы хотим поделиться с вами видеозаписями выступлений последнего Open WG Talk, темой которого стало продуктовое управление и внедрение новых процессов. Под катом вы найдете доклады Сергея Бережного, директора разработки Wargaming, и Ярополка Раша, руководителя медиасервисов Wargaming.



Приятного просмотра!

Здравствуйте, уважаемые читатели.

Сегодня мы хотели бы поговорить с вами о важном аспекте гибкого управления проектами, но не о чистом Agile, а о планировании проекта и итераций. Речь пойдет о жанре «Пользовательских историй», которым посвящена очень успешная на Западе книга Джеффа Паттона с предисловием Мартина Фаулера:



В статье, текст которой вас ждет под катом, мы перевели «User Story Mapping» как «визуализация функционала». Вариант взят из очень интересной книги Бориса Вольфсона "Гибкое управление проектами и продуктами", также выходившей в нашем издательстве.

Итак, автор статьи прочитал труд Паттона и решил, что так должен поступить каждый. Насколько убедительные примеры он привел — судить вам.

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

Эта статья — выражение моей личной боли. Кнопочные решения портят мне жизнь, я трачу время на споры и обоснования.

Когда мы общаемся с коллегами, заказчиками или пользователями, я использую фразу «кнопочное мышление». Что я имею ввиду под этим термином? Текущая статья — развернутый ответ на этот вопрос.

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

Для тех, кто любит смотреть, а не читать, есть видео и слайды.

Когда у нас надёжно заработала непрерывная интеграция на Jenkins и устоялись процессы выпуска релизов продукта, возникла мысль: а почему бы не перенять передовой опыт и не поставить в офисе свой электронный излучатель информации (information radiator): большой красивый экран, на котором автоматически отображаются происходящие с проектом процессы?



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

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

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

Даже относительно крупным компаниям приходится перестраиваться. «[В последнее время] заказчики выводят на конкурсы любые независимые этапы, по окончании которых можно получить завершенные бизнес-результаты (оптимизация части инфраструктуры в ключевых регионах, рост быстродействия критичных для бизнеса приложений, таких как «1С»)», – рассуждает директор департамента ИТ-аутсорсинга ALP Group Дмитрий Бессольцев.

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