Agile *

Залп скосил 50 офицеров и 760 рядовых. Французы дрогнули, запаниковали и — обратились в бегство. «Тут дела наши пошли не вполне хорошо», — описывает этот момент битвы официальная французская депеша.

Келли Дж. Порох. От алхимии до артиллерии.

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

Пытаясь как-то спасти положение, активисты Scrum вспоминают, что Scrum — это же еще и framework. Объявляется новая стратегия: “Мы не только Scrum, мы еще и Agile! Мы используем best practices, берем из Scrum только самое лучшее, то, что подходит конкретно для нашей ситуации, а все остальное лишнее и необязательно”. А раз так — “Мы — молодцы и все делаем правильно”.

Дэниэль Д. Гэлорат — президент и исполнительный директор Galorath Incorporated и главный разработчик SEER-SEM, программного продукта по алгоритмическому управлению проектами.

Он считается экспертом в области оценки программного обеспечения и автор книги «Программное обеспечение, оценка и риск-менеджмент» («Software Sizing, Estimation, and Risk Management»).

«Книга помогает определить лучший способ инвестировать в улучшение производительности программного обеспечения.»
— Берри Боэм, автор спиральной модели и COCOMO

Сегодня день рождения одного из отцов-основателей Agile-манифеста — Алистера Коберна. Предлагаю вашему вниманию перевод его выступления на TED про командную разработку.



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

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

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

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

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



Эту картинку не стоит воспринимать буквально. Она рассчитана на то, чтобы показать главные преимущества гибкой разработки над каскадной моделью, а именно по отношению к минимально жизнеспособному продукту (MVP).

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

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

Дурацкая задача – когда ожидаемая от реализации польза не оправдывает количества необходимых ресурсов, но Заказчик настаивает на необходимости её выполнения.

О

• управлении потоком задач на разработку,
  Как избавится от «дурацких» задач?
• управлении расходами на разработку,
  Как определить и выбрать самые выгодные задачи?
• распределении ограниченных ресурсов.
  Как сделать так, чтобы все Заказчики были довольны, а количество ресурсов при этом осталось тем же?

Это вводная статья по теме «Систематизация бизнеса». Общая информация.

В последующих статьях, если данная тема вызовет интерес у резидентов Хабры — будут практические разборы и опыт, коих, за последние 3,5 года накопилось достаточно.

Добавил вступление по совету одного из резидентов, для уточнения, благодарю.

Итак, «продукт» создан, есть какой-то маркетинг и первые сотрудники. Суммы «капают» на расчетный счет, пора расти дальше! И в этот момент, как рефлекс собаки Павлова, у 90% предпринимателей в голове возникает вопрос:

«А почему бы не внедрить CRM систему?»

Пошел процесс… Поиск вариантов… Подрядчики… Amo, 1С или Битрикс 24…

А ведь интуиция сидит на плече и подсказывает: «Мужик. Что-то не так. Как-то все очень туманно в этой автоматизации.»

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



Результат? CRM работает на 30% от своих возможностей, управление «не интуитивно», на все нужны инструкции, многие моменты не совпадают с практикой, сотрудники саботируют.

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера


Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Эпиграф. «Критика не принимается вообще, принимается только альтернативное построение. Если оно будет лучше, чем моё, тогда я приму его как более правильное».

Статья написана под впечатлением статьи Мотивация каратистов: как перестать беспокоиться о неэффективных сотрудниках?.

В статье приводится альтернативное мнение о том как можно построить систему бонусов. Частично методика опробована на своей шкуре и показала свою высокую эффективность в прикладной области (не разработка ПО).


^{картинка для привлечения внимания}

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



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

Наша команда работает in-house в Москве и Воронеже и удалено по разным городам России. Эта мотивация применима для всех, кто работает в компании full-time, в независимости от местонахождения. Отдельно хочу отметить высокую эффективность в случае работы с удаленными сотрудниками.

На текущий момент, в компании работает больше 10 разработчиков. У нас 10 купонных сервисов, 2 мобильных приложения, агрегатор kupon.ru, ERP-система, рассыльщик, который рассылает более 8 миллионов писем в день, и, совместный проект, аналитический сервис gtmix.ru. Каждый разработчик участвует в 2 и более проектах. Работает it-отдел по SCRUM в Trello. Ежедневные митинги разделены по проектам и проходят в точно назначенное время.

Эффективность разработчика измеряется в баллах. Для удобства сбора результатов, мы используем плагин для trello: Scrum for Trello. Балл формируется из коэффициента скорости команды и времени, затраченного на задачу. Есть простая, наглядная табличка:


Из практического опыта, оптимальный коэффициент скорости команды составляет 1,6. Чтобы вы понимали, это 5 часов работы сотрудника в день или 1 балл. 1 человек/час — это время потраченное на написание кода и обмозгование задачи. Время затраченное на чтение книг, кофе, чай и тому подобное не считается.

Джефф Сазерленд (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% на всякий случай (все равно не хватает). И отжимание «заведомо раздутых сроков», чтобы исполнитель пообещал чего-то более приемлемого. И невнятные бормотания вместо конкретных цифр.



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