Agile *

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

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

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



В Альфа-Банке у нас для этого есть Альфа-Мобайл и Альфа Бизнес-Мобайл.

Меня зовут Илья Царев, я Head of iOS, и сегодня я расскажу вам, как у нас устроен процесс разработки мобильных приложений.

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

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

На чистом скраме, без всех этих принципов, можно ускориться в 1.5-2 раза, такие примеры есть. Хотя, их достаточно мало. И это парадокс.

Помните публикацию про гибкий суррогат? Я там долго рассуждал о том, что на обложке книги по скраму написано, что она про ускорение работы в 4 раза. Бери и делай, как написано, и получай шикарное ускорение.

Но этого не происходит. Почему?

Я в своей практике ответ нашел, приглашаю и вас ознакомиться. Если хотите 4X.

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

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

Agile development is especially useful for mobile app development. The agile methodology provides our clients with a continuous feedback loop. Sourcebits mobile app design and development clients see milestones every 2-3 weeks. They aren’t left to wait until the very end of the project. Agile development for mobile apps means clients provide feedback every step of the way to ensure the success of the project. – Joe Chen, CTO, Sourcebits

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

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

На высшую истину и полное раскрытие темы не претендуем, спорить ни с кем не собираемся, мы этот путь прошли. Хотите – тоже проходите.

Если согласны – под кат.

«Додо Пицца» развивается в США. В середине 2016 года мы открыли доставку в Оксфорде и быстро поняли, что предпочтения клиентов в США и России отличаются. Американцы — индивидуалисты. Они привыкли, что можно собрать пиццу из любых ингредиентов: пусть даже бекон с шоколадным соусом. Поэтому нам надо было сделать такой функционал для американских Додо. Мы назвали проект «Своя пицца».

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

Чтобы разобраться, мы использовали сторимэп. Этот инструмент помог спланировать работу и запустить «Свою пиццу» за 2,5 месяца. В статье рассказываем, как применяем сторимэп.

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

Сегодня посмотрим на не так сильно распространенный, но более близкий к нам, программистам и разным ИТшникам, пример.

Конкретно вам НЕ стоит читать дальше, если вы МОЖЕТЕ в течение 5 минут ответить на вопрос: насколько изменилась скорость, или эффективность вашей работы за последние полгода?

Если вы ответили на этот вопрос цифрой, и цифра эта не равна нулю, то публикация не для вас.

Для 1Сников вместо нуля может быть Неопределено, для js'ников — undefined.

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



Дисклеймер: Каждая организация уникальна — от внутренней структуры, и до того, как она общается с внешним миром. Так что я не считаю ни один воркфлоу (или бизнес-процесс, как любят говорить на русском) универсальным решением. Пост не претендует на полноту и исключительность, он скорее о том, что подобный подход работает у нас в SkuVault, в текущей конфигурации команды, и демонстрирует положительные результаты. Наша специфика — это 50 человек, 16 из которых оторваны от другой части 10-часовой разницей во времени.

Недавно мне посчастливилось начать работу с одной относительно немаленькой компанией (~100 человек), где, как выразился наниматель, “по-отдельности все хорошие специалисты, а вместе работать не получается”. Ну, думаю, я как раз специализируюсь на создании команд, дай, думаю, помогу чем смогу. Пообщались на собеседовании на тему общего понимания цели компании, об условиях, в которых возможна успешная совместная работа, о максимальном использовании компетенций сотрудников и о вовлечении в общее дело. Казалось бы, мысли у нас с нанимателем сходятся, но сам держу ухо востро — знаю о негативной репутации компании у потенциальных соискателей в городе. Ну что же, тем интереснее будет задача!

25 декабря приглашаем вас на митап Рождественский Agile в Райффайзенбанке. Под звуки Jingle Bells и в предновогоднем настроении поговорим о том, сколько нужно программистов, чтобы оценить фичу, какие подводные камни в трансформации и как аджайл помогает в работе в самых разных отраслях — от киберспорта до миграции сервисов. Эти и многие другие вопросы обсудим вместе с Mail.Ru Group, Unusual Consepts и Riot Games.

Под катом подробности.

7 команд и ни одного менеджера – думаете, такое возможно? Мы построили процесс, в котором показываем на каждом демо по 1-2 фичи от команды, проводим ретро команд, ретро релизов и при этом получаем реальное удовольствие от работы. Хотите организовать свою работу так же? Тогда добро пожаловать под кат.



Мы, компания Renga Software, занимаемся разработкой программных продуктов для проектирования зданий и сооружений в соответствии с технологией информационного моделирования (BIM). Идем спринтами, выпускаем релизы каждые 3-4 месяца. Пользователей системы с каждой неделей становится всё больше. Продукт совсем молодой, поэтому бэклог переполнен важными, а главное, интересными задачами. Но как в короткие сроки разработать продукт, который будет использоваться для проектирования жилых домов, детских садов, больниц и театров?

Привет! Меня зовут Стас, я Product Owner команды «Welcome Aboard». Мы делаем удобный продукт для соискателей, желающих устроиться работать в Альфа-Банк.

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

Сейчас мы сосредоточились на электронной анкете соискателя. В ней более 50-ти полей, она разделена на 6 шагов и работает на любом устройстве.



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

Поход

Главный герой (Эл) ведет в поход школьников — класс своего сына. Задача — дойти до Чертова ущелья засветло, переночевать там и, на следующий день, вернуться обратно. Детишки выстраиваются в шеренгу по одному и отправляются в путь. Первым идет Эл, остальные — как придется. Строй растягивается и главному герою приходится перебраться в конец чтобы никто не потерялся. Тогда главный герой перестает видеть голову строя, что тоже его беспокоит. Он пытается сообразить как так получается и первое что видит главный герой — толстый мальчик, которому идти тяжелее чем другим. После небольшого привала и перепалки ребятишек из-за задержки, они снова отправляются в путь и поведение толстячка изменяется — теперь он не отстает от впереди идущего т.к., вероятно, ему стало стыдно, что он задерживает всех. Теперь при накоплении отставания от впереди идущего, он переходит на бег. Теперь толстячок тратит сил больше чем другие — надолго ли его хватит?

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

В пятницу, 15 декабря в офисе Туту.ру пройдет очередной Agile Kitchen. Темой встречи станет практика и теория масштабирования Agile. Своими кейсами и опытом поделятся эксперты из Сбербанка, ScrumTrek, EPAM и других компаний. Вас ждут интереснейшие доклады и ставший уже привычным игровой трек.

У нас в Wrike есть традиция делиться с командой мыслями о книгах, которые прочитали. Мы давно думали, что было бы неплохо распространить эту инициативу и на наш блог на Хабрахабре, и вот подвернулся хороший случай — книга Фредерика Брукса «Мифический человеко-месяц».

Книгу можно назвать скорее классикой фольклора разработки, нежели реальным руководством по построению рабочего процесса. В ней отражены проблемы, с которыми Брукс столкнулся при организации работы над созданием операционной системы OS/360, и его подходы к их решению. Результат был далек от идеала, на что сам Брукс и указывает. Его целью было не научить как правильно, но поднять проблемы, требующие решения. Любопытно разобраться, что изменилось в разработке с 1960-х годов.


Фото из архива IBM

Julie Zhuo, директор по продуктовому дизайну в Facebook, однажды выступала на «TNW Europe», и рассказывала о фрэймворке, который используется в Facebook, чтобы сфокусироваться на разработке продукта.

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

Этот список не идеальный и не полный. Если бы была какая-то пошаговая инструкция (Шаг 1: Идея. Шаг 2: ??? Шаг 3: Профит!), тогда я бы потратила на неё хорошие деньги, а потом похлопала нас по спинам и смотрела бы, как новые потрясающие продукты цветут вокруг нас, словно цветочные поля в мае.

Путешествие завершено на 1%. Давайте продолжим идти дальше и обучаться.

Фрейминг

1. Продукт успешен, потому что решает проблемы за людей. Это звучит очень просто, но это самая важная вещь, которую нужно понимать в создании хороших продуктов.
2. Первым шагом в создании чего-то нового является понимание того, какую проблему ты хочешь решить и для кого. Это должно быть предельно ясно до того, как вы начнете думать над решением.
3. Третий вопрос, который вы должны себе задать: «Почему именно эту проблему стоит решать?»
4. Если аудитория, для которой вы создаете, узко определена (и вы её часть), то вы можете положиться на свою интуицию, чтобы принимать решения по продукту. Если же нет, то стоит полагаться на исследования и данные.
5. Если вы — основатель стартапа, будет легче начать с решения проблем узкой аудитории, а затем расширяться к общей аудитории после того, как вы заручитесь изначальной поддержкой.
6. Проблема, которую вы пытаетесь решить, должна быть поняла за пару предложений и резонировать с кем-либо из вашей целевой аудитории. Если этого не происходит, то считайте это тревожным признаком.

Долгое нахождение в зоне комфорта ведёт к проблемам

Однажды, когда держала в руках карты для planning-poker с 5 ценностями SCRUM, я поняла, что отдельные ценности в нашей команде «проседают». Хотя в команде мы исповедуем именно их.

1. Иногда мы перестаем слышать заказчика, не достаточно погружаемся в задачу и не стараемся решить проблему заказчика на глубоком уровне. Это происходит по причине того, что мы достаточно долго работаем в зоне своей ответственности. И фокус нашего внимания постепенно сужается до круга наших непосредственных задач. На проблемы окружающих людей мы просто перестаём обращать внимание.
2. В силу проблемы, обозначенной пунктом выше, члены команды иногда могут позволить себе резко ответить коллегам, если те чего-то долго не могут понять. Такое отношение не стимулирует к открытости, в следующий раз человек лучше потратит несколько лишних часов, чем снова обратится за помощью.
3. Долгая работа в одной и той же зоне ответственности приводит к шаблонности мышления. Иногда мы решаем задачи по «накатанному» пути из-за боязни выйти из зоны комфорта, столкнуться с чем-то новым и даже банальной лени глубже исследовать вопрос.
4. Отдельные члены команды недостаточно открыты шарингу знаний из-за интровертности характера.

Всем привет! Тема Agile вечна, вот и в нашем офисе не так давно прошла ScrumTrek’овская кухня. На этот раз обсуждали работу с требованиями, искали новые подходы к разработке и решали, как найти ценность для продукта.

На встрече было 10 докладов от спикеров из М.Видео, ScrumTrek, ZeptoLab, Альфа-Банка, Сбербанка, Citigroup, EPAM, Renault Digital и Look At Media. Программа была насыщенная, так что не проходите мимо, наверняка найдёте что-то для себя интересное. Комментарии приветствуются!

Для особо нетерпеливых есть лайфхак: последней строкой я добавлю ссылку на все видео разом. Не благодарите.

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

Обычно, говоря про Scrum, люди говорят только про разработку софта, но сегодня Кодабра расскажет кое-что необычное, мы поведаем вам свой опыт использования гибкой методологии для «разработки» самого настоящего оффлайн-мероприятия с живыми людьми вместо кода, площадками вместо серверов и самой требовательной аудиторией – детьми. Это рассказ про необычный подход к организации крупнейшего в России фестиваля цифровых технологий для детей и подростков – Digital Fest 2017.