Как стать автором
Поиск
Написать публикацию
Обновить
19.65

Agile *

Гибкая методология разработки

Сначала показывать
Порог рейтинга
Уровень сложности

О’Жаль: Что не так с гибкими методологиями

Время на прочтение6 мин
Количество просмотров10K
Используя термин Agile, люди часто имеют в виду не что-то конкретное, но то что они правы. Например, не написал тесты — не Agile, не провел митинг с командой — не Agile, не заполнил тайм-трекинг — опять не Agile. Тому, что каждый трактует термин Agile по-своему, есть объективные причины, связанные с его происхождением.


Читать дальше →

Конференция AgileDays 22 и 23 марта 2018

Время на прочтение2 мин
Количество просмотров2.1K
22 и 23 марта в Москве в Центре Международной Торговли состоится конференция AgileDays’18. В этом году она проводится 12-й раз. В очередной раз докажем, что наша конференция самая крутая по тематике Agile в России и Восточной Европе!

На AgileDays будет почти 100 докладов, воркшопов и дискуссий, интересных как экспертам, так и новичкам в области Agile. Мы ожидаем более 1200 участников — менеджеров проектов и руководителям компаний, скрам-мастеров и владельцев продуктов, разработчиков и аналитиков.

Этот вводный текст мы пишем почти каждый год. А теперь о том, что новенького ожидается в этом году.
Читать дальше →

Райффайзенбанк начинает второй набор в Java-школу

Время на прочтение3 мин
Количество просмотров11K
Скрам, смузи, эджайл, блокчейн, биг дата, «в каком отделении карту оформляли, туда и идите». Ну, в общем, все мы слышали, что сейчас в тренде в банковской сфере.

Где можно в это втянуться и набрать критическую массу знаний молодому разработчику? В Java-школе Райффайзенбанка: здесь быстро всему научат, расскажут, покажут, да ещё и заплатят.

Что из себя представляет наша Java-школа? Это трехмесячная оплачиваемая стажировка в одном из крупнейших банков России для студентов последних курсов бакалавриата и магистров. В короткие сроки вы научитесь работать в команде по методологии SCRUM, получите/отточите свои навыки в Enterprise девелопменте, повысите ораторские способности, споткнетесь обо все подводные камни командной работы над одним проектом с применением систем контроля версий и поспорите с командой, что же лучше, GIT или Subversion.


Далее — рассказ очевидца. Из первых, так сказать, рук.
Читать дальше →

Управление проектами по разработке программного обеспечения. Проблемы и пути решения

Время на прочтение15 мин
Количество просмотров29K

Воронка методологий В 2001 году, когда ещё не было Хабра и существенной доли его современных читателей, когда вотерфолл был всемогущим, а об эджайле ещё только-только начинали говорить, я немного поисследовал тему методологий разработки и их отличий друг от друга. В результате появилась статья, которая была опубликована на дружественных мне веб-сайтах. На статью даже ссылались некоторые уважаемые учебные заведения при подготовке курсов по основам менеджмента программных проектов. Поскольку дружественные веб-сайты были не про IT, то и статья со временем с них исчезла. Дабы не допустить её полного исчезновения с просторов рунета, позволю себе опубликовать её на Хабре и предлагаю всем желающим совершить небольшой экскурс в прошлое. Да, многие вещи сейчас кажутся наивными, но ряд выводов всё ещё более чем актуален.

Читать дальше →

Немного о ретроспективе

Время на прочтение6 мин
Количество просмотров12K
Для команды разработки важно регулярно проводить ретроспективу, чтобы постоянно совершенствоваться. Но какой она должна быть?

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

  • на ретро тратили по 2 часа и сильно выматывались
  • обсуждения периодически уходили в затяжные бесполезные споры
  • некоторые мелкие проблемы не успевали решить и постоянно переносили на следующее ретро
  • отдельным членам команды надоедали ретроспективы из-за однообразия

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

Прошлой весной я сходил на Okademy от ScrumTrek. Это обширный курс, включающий в себя много полезного для скрам-мастера, но для меня самым полезным оказалась часть о том, как эффективнее проводить ретроспективы. Хочу рассказать, как это нам помогло.

image
Читать дальше →

Отчет с прошедшего Рождественского Agile MeetUp'a

Время на прочтение1 мин
Количество просмотров3.6K
В конце декабря на площадке Райффайзенбанка состоялся Рождественский Agile MeetUp. В предновогоднем настроении участники поговорили о том, сколько нужно программистов, чтобы оценить фичу, развеяли мифы об Agile и трансформации, и, конечно, затронули больную тему дедлайнов. О том, как это было, читайте под катом.


Внедрение Scrum'a технарем: реальный опыт, подводные камни, tips&tricks

Время на прочтение8 мин
Количество просмотров19K
В последние годы внедрение agile-методологий в разработку ПО стало целой индустрией: по этой теме выпускается специальная литература, собираются тематические конференции, устраиваются тренинги. На рынке труда возникли совершенно новые профессии, такие как agile-коуч или скрам-мастер. Появились целые компании, которые специализируются на внедрении гибких методологий в других компаниях.

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

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

В таких условиях у разработчика есть два пути: продолжать терпеть или брать инициативу в свои руки.

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

#Ускорение4X. Кастомизация целей команды

Время на прочтение8 мин
Количество просмотров3.3K
Генеральные цели перехода на #Ускорение4X мы обсудили. Теперь нужно сделать еще более важную штуку — учесть цели каждого участника команды. Мы же ускоряемся сами для себя, а не для начальника.

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

Итак, зачем кастомизировать цели? Вроде нормально они звучат — ускориться, научиться работать на форсаже, научиться переводить на форсаж.

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

Такое сплошь и рядом есть во всех компаниях, от всех собственников и менеджеров. Что они там обычно говорят? Давайте увеличим продажи вдвое! Наша цель — войти в список Forbes! Мы хотим через 5 лет выйти на IPO! Наша цель — 5 новых продуктов через год! Ну и т.д. Еще там непонятные миссии добавляются,ценности сейчас модно стало писать, и подобную ересь.

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

#Ускорение4X. Генеральные цели

Время на прочтение6 мин
Количество просмотров2.5K
Все, вступления закончились, начинаем изучать практические приемы, из которых состоит #Ускорение4X.

Если вы — тот человек, который берется за внедрение #Ускорения4X в команде, то первый шаг придется сделать вам.

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

Я постараюсь объяснить цели, и дам пример согласования — его можно использовать в качестве подсказки. А можно не использовать, главное — результат. Но разговаривать с людьми придется вам. Не лишним будет всем дать ссылку на эту публикацию — если переживаете за свое красноречие.
Читать дальше →

Agile коммуникация в распределенных командах, не пересекающихся по рабочему времени

Время на прочтение6 мин
Количество просмотров9.1K
Главный вопрос этого поста: какие же изменения претерпевает agile коммуникация (и скрам, в частности), натягиваясь на распределенные команды?

Для этого, давайте сначала классифицируем коммуникацию:

  1. стратегические митинги (планирование / ретроспектива)
  2. ежедневную синхронизацию (в том числе daily standups)
  3. прояснение рабочих вопросов

image

Давайте добавим еще одно измерение! Если попробуем наложить вышеприведенную классификацию на географию, то появляются дополнительные срезы для вышепреведенного:
Читать дальше →

#Ускорение4X. Принцип № 0/3. Системное подчинение

Время на прочтение8 мин
Количество просмотров3.9K
Напомню, что мы изучаем практику #Ускорение4X.

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

Не знаю, как вы, а я наблюдаю за проектами изменений лет 10. Кроме наших любимых ИТ-проектов (которые ведь тоже — изменения), много приходилось и видеть, и делать самому обычных, организационных изменений.

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

Но еще важнее другой, побочный итог — мы убедились, что методика_такая-то — фуфло. Потому что не работает.

Так часто бывает, например, с внедрением принципов agile, или конкретно методики скрам. Так будет и с методикой #Ускорение4X, если действовать с той же ключевой ошибкой — главной ошибкой внедрения изменений в нашей стране.

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

Что лучше – 1 команда мобильной разработки или 15?

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

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

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



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

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

#Ускорение4X. Принцип № 0/2. Скрам-мастер

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

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

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

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

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

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

Ближайшие события

Как мы достигли идиллии, работая без менеджеров. Часть 2. Тайная комната

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

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


Читать дальше →

Гибкая методология для мобильной разработки

Время на прочтение5 мин
Количество просмотров14K
image

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
Читать дальше →

#Ускорение4X. Принцип № 0/1. Изменяемая среда

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

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

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

Если согласны – под кат.
Читать дальше →

Как сторимэп помогает не завязнуть в разработке нового продукта на годы

Время на прочтение5 мин
Количество просмотров27K

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


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


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

Читать дальше →

Гибкий суррогат

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

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

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

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

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

Анатомия распределенной команды — процесс подготовки требований

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

image

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

Scrum внедрили, agile — забыли

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

image
Читать дальше →