I Вступление

Будку надо переносить! Сезона не бывает, чтоб пару-тройку не шандарахнуло.
То с туалетом путают, то с пляжной кабинкой…
(х/ф Особенности национальной рыбалки)

Конец года, подведение итогов, заполнение анкет и прочая предпраздничная мишура ИТ функционеров. Мне уже в который раз попадается на глаза итоговые опросники ИТ фирм, призванные выявить тренды в подходах к разработке продуктов. И каждый раз возникает ощущение какого-то подвоха, когда отвечаешь на вопросы типа: «Вы все еще пользуетесь методом Waterfall (водопадная модель), или Вы все-таки (как и все передовое человечество) практикуете Agile (гибкие методологии)». Когда же начинаешь выяснять у автора сего опроса, а что он понимает под Agile, его разъяснения как-то не сильно ложатся в канву манифеста (Agile Manifesto). О многих принципах он реально задумываются впервые и эти самые принципы прямо-таки ставят его в тупик. Но после небольшого замешательства, в ход идет тяжелая артиллерия с железобетонным обоснованием своей позиции: «Мы же не по Водопаду работаем, значит по Agile».

Сам тезис «Гибкие методологии» настолько гуттаперчевый еще в своем звучании, что многие пытаются втиснуть в него все что угодно, а вернее то, что им наиболее выгодно. Постепенно это стало модной ширмой, которой можно прикрыть всякие свои недостатки и даже разгильдяйство, в процессе производства ИТ продуктов, и при этом, как-бы оставаться на гребне волны, в тренде. Мол не мы такие – а методика такая.

Давайте вместе, еще раз “ударим анализом” по теме Гибких методологий, попытаемся разложить основные артефакты и принципы по полочкам и отделить, тот сакральный смысл, который закладывали в это понятие изначально, от того, во что его превращают отдельные нерадивые популисты. Так же сравним подходы Agile с другими методиками для более точного понимания той грани, что их разделяет или наоборот – объединяет. Заодно попробуем выяснить, где использование принципов Agile наиболее целесообразно, а где не совсем уместно?

Что такое SAFe?

Что такое Agile многие знают. Еще большее количество людей, причастных к IT используют терминологию. Еще больше тех, кто слышал об Agile.

Далеко не все, кто уверенно использует термин Agile для общения, критики, для того; чтобы представить свою комманду или компанию в лучшем свете понимают, например, в чем отличие между SCRUM и Agile; и часто ставят между этими двумя разными понятиями знак равенства. Но вот не так давно в 2015 году появился еще и SAFe. Что это и зачем он нужен?

Приглашаем на Рождественский Scrum Meetup, который состоится 20 декабря на площадке Райффайзенбанка в Нагатино.

Мы в Промсвязьбанке активно переходим от вотерфол-канальных команд к эджайл-продуктовым. Где-то обошлось парой шишек, где-то уже можно менять грабли… но в результате мы накопили немало опыта, связанного c эджайл-трансформацией. В этом посте мы хотим поделиться опытом — вдруг вы откроете для себя что-нибудь новое.

Всем добрый день!

До конца года осталось уже почти всего ничего, но всё же несколько новинок в курсах у нас будет. Один из таких новый курсов — «Agile Delivery Manager», который создала Марина Арефьева. По традиции подготовили для вас открытые уроки и интересные материалы. Сегодня познакомимся о виденье, что же такое Delivert Manager и с чем его едят.

Поехали.

Рич Льюис (Rich Lewis) — лучший, с кем я когда-либо работал. Когда я только встретил его, он был бизнес аналитиком и скрам-мастером небольшой команды. Он справлялся со своей работой, но явно был способен на большее. Я предложил ему должность Delivery Manager в программе, которой занимался в то время.

О роли Delivery Manager мы говорим не часто. Конечно, это не часть “семьи” Agile, где доминирует терминология Scrum. Владелец Продукта; Скрам-мастер; Все остальные с ярлыком “Разработчик”. Вот, пожалуй, и все.

Тем не менее, название должности — Delivery Manager, существует. Например, в The Government Digital Service (GDS) в Великобритании и все большем количестве компаний в США.

Продолжаем про нюансы гибкой разработки (Agile), которые случаются на практике. Как понять, правильно ли внедрен Agile, какая практика годится для какой задачи и отрасли, кто в компании должен переводить работу на «Agile-рельсы»? Своим опытом с редакцией блога Mail.Ru Cloud Solutions продолжает делиться Agile-коуч ScrumTrek Василий Савунов.

В прошлый раз Василий рассказал, что такое Agile, какие он включает методологии и какие вокруг него сформировались стереотипы. Теперь поговорим о его внедрении.

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

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

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

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

This article in English: GTD Implementation via New Google Keep and Calendar Features

За последние годы Google Keep и Calendar значительно расширили свою функциональность, что дает возможность построить более удобную реализацию методологии GTD (Getting Things Done) на их основе. Ранее я уже публиковал материал с реализацией GTD на основе Google Calendar. Представленный теперь материал можно рассматривать как обновленную реализацию GTD на тех же принципах, но с использованием более современных средств.

В моем материале 2015 года в качестве базового элемента для всех пяти фаз управления рабочим процессом (Control) в системе GTD был выбран один и тот же сервис — Google Calendar. Теперь на различных фазах в качестве базовых элементов будут использоваться два разных сервиса — Calendar и Keep — в соответствии с приспособленностью их функционала для отдельных фаз.

• Calendar теперь будет использоваться в качестве базы для фазы обзора (Review-Reflect), а также для фазы выполнения (Do-Engage).
• Keep будет использоваться в качестве базы для фазы сбора (Collect-Capture), фазы обработки (Process-Clarify) и фазы организации (Organize).

Реализация GTD в Google Calendar (развернут список ближайших действий на неделю):


Pеализация GTD в Google Keep (категория ближайших действий):

Сегодня мы наблюдаем, как во всем мире постепенно отмирает waterfall-модель разработки. Ее не любят за тяжеловесность и плохую реакцию на изменения. Это напрямую влияет на актуальность продукта и увеличивает ТТМ (time-to-market), выливаясь в дополнительные затраты. Разработчики перестраиваются на рельсы agile, и мы здесь не исключение.

Методология agile изначально создавалась для маленьких команд, которые делают продукт под ключ в режиме end-to-end и сами отвечают за его качество. Но как быть, если разрабатываешь высококритичные банковские системы, над которыми трудятся десятки agile-команд? Как достичь той уверенности в продукте, которую дает долгое, исчерпывающее тестирование как в waterfall? В этом посте мы поделимся своим решением этого вопроса.

Методологии гибкой разработки (Agile) прижились и в IT, и в не-IT, обросли своими приметами, стереотипами, суевериями и мифологией. Редакция блога Mail.Ru Cloud Solutions решила поговорить об этой мифологии с Agile-коучем Василием Савуновым из ScrumTrek.

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

Что такое Agile?

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

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

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

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

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

«Всё — яд, всё — лекарство; то и другое определяет доза.»
Парацельс

Принято отсчитывать историю Agile от февраля 2001 года, когда появился на свет довольно странный документ — Agile Manifesto. По большому счёту текст документа скомпонован из философских очевидностей (например, «простота — искусство не делать лишней работы») и спорных утверждений (например, «лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды»). Но этот документ странен не столько своим содержанием (мало ли что может прийти в голову на лыжном курорте), сколько эпичностью последовавших изменений в отрасли разработки программного обеспечения. В кратчайшее время появилось множество методик, реализующих методологию «гибкой» разработки, которые торжественным маршем пошли по миру, захватывая умы Исполнителей и кошельки Заказчиков. Адептами этот движ преподносится как некая волшебная пилюля, решающая всё. Дошло до того, что благородному дону честному программисту уже стало неприличным признаться в причастности к разработке ПО по традиционной ориентации методологии. Попробуем же разобраться в причинах и следствиях явления, на примере Scrum-а, как наиболее распространённого проявления Agile.

Привет, Хабр! И снова на связи Алексей Приставко.

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

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

В этой статье я постараюсь ответить на следующие вопросы:

• Как методы и процессы разработки отражаются на эксплуатации?
• Что движет каждой стороной конфликта?
• В чем первопричина разногласий?

Добро пожаловать под кат!

13 ноября мы с компанией AgileVerse будем проводить теплый ламповый вечер с настольными играми. Вместо D&D, Манчкина или какой-нибудь другой классики вас будет ждать Scrum Values Game — новая игра, которая поможет врубиться в ценности скрам — фреймворка и связать их с обычными кейсами. (Да, и при этом не запороть реальные проекты — игра же!)



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

Привет, Хабр! Представляю вашему вниманию перевод статьи «Why I Don’t Use Story Points for Sprint Planning» автора Mike Cohn.

Как описано в «Agile Estimating and Planning», я большой поклонник story points для оценки бэклога продукта. Тем не менее, я также рекомендую оценивать бэклог спринта в часах, а не в story points. Почему это кажущееся противоречие? Ранее я писал о причинах. Я рекомендую использовать разные единицы измерения (points и часы) для различных бэклогов.

Новое место работы. Все собеседования позади. Первый рабочий день. Тебя проводят к рабочему месту. Там уже стоит готовый к работе ноутбук. Ты открываешь крышку. Все, ты готов к работе. Твоя первая задача. К тебе подходит человек, который должен ввести тебя в курс дела. Он объясняет тебе, что нужно сделать: баг с фиксом в 3 строчки кода. Попутно тебе помогают настроить рабочий комп. И вот ты уже приступаешь к задаче и понимаешь, что как-то все не так…

Во-первых, для сборки фронтенда у нормальных людей давно уже используется Webapck, на худой конец Gulp. Неужели они ничего не слышали про Docker?! Они вообще не умеют писать на Python!? Да и зачем здесь в принципе Python, и почему он еще 2й версии!? Вот дебилы! (Здесь может быть любой WTF на ваш вкус).

Мысли свои озвучиваешь вслух. Но про дебилов молчишь, конечно, все-таки культурный человек. Но на лице все написано. А вообще должны и сами понимать. И вроде все правильно. И все по делу. Но…

Глючные обновления указывают на более глубокую проблему


Windows 10 на презентации в Токио, июль 2015 года

Очевидно, обновление Windows от 10 октября 2018 года было не самым удачным. Быстро появились сообщения о потере файлов на компьютерах, а Microsoft приостановила распространение обновления. С тех пор баг исправили, сейчас идёт тестирование нового апдейта перед его повторным выпуском.

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