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

«Директор небольшой брокерской фирмы Юрий сидел в офисе, который он арендовал в модном коворкинге вместе со своими немногочисленными сотрудниками. Компания последнее время показывала очень хорошие результаты. Престижное экономическое образование позволило самостоятельно построить успешную компанию, а вот как обезопасить основной капитал – базу клиентов – от участившихся хакерских атак собственными силами Юрий не знал. Своим сотрудникам Юрий доверял, но они часто работали из дома, из кафе, да и местный администратор Илья не вызывал доверия, наверное из-за бороды и черной футболки.

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

Когда я прочитал: «Agile is much more than just Scrum» — в описании сертификационного курса Certified Agile Professional компании ScrumTrek, то первое, о чем я подумал: почему ScrumTrek, тогда уж нужно было назваться AgileTrek? После прохождения этого обучения я вернулся к этому утверждению с более серьезным настроем. Так что же я вынес с тренинга? Записи, раздаточный материал и сертификат Certified ICAgile Professional? А как же понимание, что такое Agile? В чем заключается концепция Agile-подхода? Что такое Agile mindset?

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

Привет, Мегамозг.



14 и 15 марта в Москве в Центре Международной Торговли состоится конференция AgileDays’16. В этом году у нас юбилей — AgileDays проводится 10-й год подряд и в 10-й раз мы докажем, что это самая крутая Agile-конференция России и Европы.

Для вас будут работать более 70 экспертов и докладчиков! Мы ожидаем более 1000 участников.

В этом году в программе, кроме традиционных сессий по управлению процессами по Agile, разработке продукта и customer development, инженерным практикам и практикам тестирования, будут 3 новых направления:

• Холакратия и другие способы избавиться от иерархий
• Agile в гос. организациях: практики заключения контрактов и выстраивания agile-разработки.
• Привлечение удержание сотрудников и построение карьеры.

Вступление

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

Разработчикам не нравятся технологии в компании и хочется что-то сделать на новом, крутом, современно языке и… И? ИИИ? Копнем историю. Полезно вспомнить, как все начиналось. Математика оказалась нужна людям далеко не из любопытства: государственная экспансия, строительство, военные технологии, бизнес — они одними из первых испытали глубокую жажду в быстрых и правильных вычислениях. Квадратные и кубические уравнения научились правильно решать лишь тогда, когда они оказались нужны… купцам и артиллеристам. Синусы и косинусы тоже придумали не из-за большого ума — с их помощью стало возможным строить… нормальные дома, которые не падают :-)

А логарифмы… там вообще интереснейшая история. Они оказались купцам (а за ним морякам и пиратам) и военным настолько нужны, что некоторые математики средневековья жизнь потратили лишь на составление их таблиц! Посмотрим в глаза героям — Джон Непер:

В брендинговой компании стояла задача разработать конкурентные преимущества. Во время брейнсторминга была озвучена интересная идея: наладить круглосуточное производство продукта. О ней и хочется рассказать поподробней.

Работа в несколько смен — идея не новая. В IT мире работа в 2-3 смены идет в call-центрах. Часто техподдержка осуществляется в других часовых поясах, о качестве которой часто шутят в сериалах. Новостные агентства тоже работают по такому принципу.
Так, например, IT crowd подшучивает над французским саппортом.

А South Park издевается над поддержкой Oculus Rift, предположительно расположенной где-то в Индии.

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

Украинский программист Андрей Рысин, который с 2004-го года работает в американской компании SAS, занимающейся разработкой программного обеспечения в сфере бизнес-аналитики, в 12-ти-миллионном онлайн-сообществе GitHub для разработчиков со всего мира выложил Большой электронный словарь украинского языка (БЭСУЯ).

Недавно мы в MakeRight.ru с удовольствием прочитали книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда. О чем она? В двух словах — о том, как организовать слаженную командную работу.
Начав внедрять элементы скрама на практике, мы пришли к выводу, что идеи книги действительно работают.

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

Это восторг!
Исследование, которое поражает от начала до конца. Вы можете быть в чем-то не согласны или, наоборот, согласитесь во всем, но в любом случае это надо прочитать.

Это те вопросы, которые волнуют многих людей долгое время. Можно ли так организовать компанию, чтобы все сотрудники были счастливы на работе? Можно ли избавиться от стереотипного мышления, что работа от слова раб? Как избавится от бесконечной бюрократии, которая пожирает компании, стоит им вырасти до 50+ человек?

Lego Serious Play или, сокращённо, LSP — это необычный и пока еще не очень распространённый метод игрового моделирования (или – фасилитации). Не запутано начали? Тогда продолжим и, обещаем – ничего сложного в этом нет.

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

Теперь вернёмся к тому, с чего начали – Lego Serious Play.

Ниже немного формализма и бюрократии к материалам о проведении ретроспектив, типа Fun Retrospectives. Материал информационный, в стиле — «у нас так» :)

Что такое ретроспектива

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

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

Недавно ко мне попала книга «Scrum. Революционный метод управления проектами», и сегодня я хочу порекомендовать её вам.

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

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

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

Два с половиной года назад, когда мы с командой (точнее её тогда еще не было) начинали разрабатывать наш продукт, мы не задумывались о методологиях, процессах и прочих, казавшихся нам тогда не нужными, бюрократических вопросах. Время шло, продуктов становилось больше, команда росла. Постепенно, все начали понимать, что образовывается некий хаос, который все сложнее контролировать, а главное, который серьезно ограничивает наши возможности. На самом деле, незаметно для нас ситуация приближалась к критической.

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

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

• «Удобный хостинг»: Предустановка панели управления и дозаказ лицензий на лету
• Как работает API нашего IaaS-провайдера
• Как мы разработали свой DNS-менеджер

Сегодня мы решили переключиться на необычную тему — исправление недоработок. Для этого мы нашли профильный материал эксперта.

При работе над пользовательскими историями (user story) очень легко допустить оплошность. Если не выявить ошибку до начала разработки, желаемого результата можно не получить вовсе. В голове аналитика детали проекта просты и понятны, но на практике не всегда могут быть адекватно выражены в виде user story.

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

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

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

Для кого:

• Инженеров: архитекторов.
• Техменеджеров: тимлидов и техлидов.
• Менеджеров: проектных менеджеров и продуктовых менеджеров

Опыт на старте:

• Желателен опыт промышленной разработки от 2 лет.
• Обязательны навыки проектирования в объеме курса «Agile Mindset в проектировании систем», особенно для участия в продвинутом тренинге: «Agile Mindset в проектировании решений».

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