Agile *

Шаги по разработке большой компьютерной программы для доставки заказчику

Иллюстрация выше — из статьи д-ра Уинстона Ройса «Управление разработкой больших программных систем» 1970 года. Считается, что это первое в программной инженерии описание модели водопада. Диаграммы д-ра Ройса разошлись по сотням учебников и статей. Но часто забывают тот факт, что изобретатель водопада сразу написал: «Эта конкретная реализация рискованна и влечёт за собой неудачу».

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

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

Есть множество готовых проверенных временем фреймворков для организации рабочего процесса, в которых хорошо описаны методы и принципы. Если собираем машину, используем Kanban, готовим пирог — Lean, разрабатываем сайт на заказ — PMBoK. Важно учитывать, что каждый проект уникален и нуждается в адаптации подходов, но в целом для вашего случая скорее всего уже есть достаточно полезных решений. Выстраивая процессы для себя, взял всего понемногу.

Было

Работал в стартапе. Один продукт, одна небольшая команда, нет жестких ограничений по срокам. Использовали Scrum и Kanban в чистом виде, если можно так выразиться. Записывали задачи в Trello и перетаскивали по 4 доскам: идеи, надо сделать, в работе, готово. Для обсуждения хода работы созванивались каждый день, а раз в неделю планировали задачи на следующий спринт. Все как у людей.

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

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

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

Почему же не стыкуются отзывы реальных разработчиков с декларируемыми целями Agile?

Практически каждый человек, который сталкивался с разработкой ПО знает что такое оценка задач в Story Points (SP), тем не менее периодически мне доводится рассказывать коллегам из других отделов или новичкам в команде, которые ни разу не сталкивались с таким подходом, зачем мы используем SP и почему это удобно для команды и эффективно для компании.

Цель этого текста – рассказать, что такое SP, как их использовать для оценки задач и почему эта методика получила такое широкое распространение.

И снова здравствуйте. В преддверии старта курса «DevOps практики и инструменты» делимся с вами переводом еще одного интересного материала.

---

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

В agile-командах часто возникает спор, насколько детально должна быть проработана User Story, прежде чем ее следует передавать разработчикам.

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

Рассмотрим Agile-подход к решению этой проблемы.

Не соглашайся ни за что
Ни с кем и никогда,
А кто с тобой согласен, тех
Трусливыми зови.
За это все тебя начнут
Любить и уважать.
И всюду будет у тебя
Полным полно друзей.
Григорий Остер.

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

для оптимального понимания данной статьи лучше начать знакомство с Части 1 вот тут

Движение от животного к человеку

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

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

Каждый проект требует жертвы. Главное, чтобы не слишком большой. Команда Mail.Ru Cloud Solutions перевела статью Алекса Стейвли про минусы технического долга и его способность уничтожить даже самый успешный проект. Предупреждение автора: в этой статье не так много практики, как хотелось бы, но она может натолкнуть на размышления.

Проектировщики самолёта отвечают на вопрос о его безопасности:
— Ничто не вечно, но современные авиалайнеры невероятно устойчивы, а самолёт — самый безопасный транспорт в мире.
Инженеры-строители отвечают о безопасности лифтов:
— Лифты защищены множеством отказоустойчивых механизмов. Их практически невозможно уронить в свободное падение.
Программисты отвечают на вопрос об электронном голосовании:
— Это просто ужасно.
— Серьёзно?
— Абсолютно. Не доверяйте программам для электронного голосования и не верьте никому, кто уверяет в их надёжности.
— Почему?
— Не совсем знаю, как это выразить, но вся наша область плоха в том, что мы делаем, и если вы будете полагаться на нас, то все умрут.
— Говорят, что надёжность гарантируется технологией под названием «блокчейн».
— А-а-а-а-а!!! Что бы они ни говорили, не прикасайтесь к этому! Закопайте поглубже. Не забудьте перчатки!
Источник: XKCD, лицензия Creative Commons 2.5

Глюк мобильного приложения для подсчёта голосов на прошлой неделе добавил хаоса на Съезде фракций Демократической партии в Айове. Через несколько часов после открытия собраний по всему штату стало ясно: что-то пошло не так. Результаты неизвестны до сих пор. Появились сообщения с описанием технических проблем и недоразумений. Демократическая партия Айовы опубликовала заявление, в котором отрицает слухи о кибератаке, но подтверждает технические проблемы с мобильным приложением.

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

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

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

TL;DR
Я считаю, что ключ к нормальному переходу на аджайл — это квалифицированный заказчик. То есть собственник/директор/лидер, который понимает, зачем вообще ему нужен аджайл, знает разницу фреймворков, оценивает ресурсы и сроки, готов к кризисам и не надеется на «золотую пулю».

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

Слёрм Аджайл — наша попытка готовить заказчиков и участников.

Приглашаем на митап Scrum Community 11 февраля! Поговорим про командную ответственность: как часто вы поднимаете эту тему? Бывает ли такое, что вы как скрам-мастер, продукт-оунер или менеджер думаете, что ответственность и осознанный подход к её принятию решают большинство вопросов?

Приходите искать ответы вместе! UPD: регистрация быстро закрылась, так как формат рассчитан на небольшое количество участников. Будем рады видеть вас на других митапах!

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

Предположим, вы небольшой производитель круп. Вы отгрузили товар в торговую сеть, но деньги получите в среднем через 60 дней после отгрузки. Многим компаниям ждать столько не под силу: ту же зарплату сотрудникам нужно платить уже сейчас. Одно из решений — факторинг. После заключения договора факторинга вы можете получить финансирование любой поставки. Достаточно после отгрузки товара отправить фактору подтверждающие документы (счета-фактуры, накладные, акты). Фактор верифицирует поставку у вашего покупателя и перечисляет вам деньги за товар, за вычетом собственной комиссии.

В сделке участвуют покупатель, поставщик и фактор, которые подписывают множество бумаг, уведомлений. Раньше взаимодействие с клиентом собиралось как паззл из разных кусочков: например, подписание договоров происходило при помощи сторонних операторов электронного документооборота, верификация поставок — пересылкой по e-mail excel-файлов, а в личном кабинете на сайте фактора поставщик мог посмотреть лишь статистику по сделкам. Было неудобно, трудоемко – и нам, и клиенту. Надо было собрать всё это в одну систему.

В 1951 году в Нью-Йорке начались клинические испытания изониазида — противотуберкулёзного препарата. В итоге выяснилось, что изониазид — это первый синтетический антидепрессант. Coca-Cola была придумана в Атланте, штат Джорджия, в 1886 году, как средство от расстройства желудка, а заодно нервной системы. Сейчас это один из самых популярных газированных напитков без каких-либо значимых медицинских свойств. В 1818 году Уильям Кабитт создал крутящееся колесо, предназначенное для наказания осуждённых — заключённые должны были ежедневно проходить 3 352,8 метра по движущейся лестнице. В итоге это стало прообразом беговой дорожки в каждом спортивном центре. Учёные из английской компании Pfizer попытались создать цитрат силденафила для лечения коронарных заболеваний сердца — ну, что такое «синенькие таблеточки», наверное, знает уже весь мир.

Иногда изобретение обретает новую жизнь. И создатели удивлённо смотрят, во что превратилось их детище.

Почему мы уверены, что DevOps или SRE могут жить только в среде IT — возможно эта философия спасёт тысячи жизней в медицине катастроф, в скорой помощи, авиации, космонавтике или разработке лекарств и вакцин?

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

Введение

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

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

В больших командах от 20 сотрудников есть такая проблема – беспорядок в задачах. Сроки срываются, работа тормозится. Поэтому на рынке есть множество систем управления задачами, которые так или иначе эту проблему решают.



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

Что же такое система управления задачами? Какие функции позволяют навести порядок в задачах?

Мы долго думали. И после 3-недельного брейншторма, общения с клиентами и опросов выделили 5 критериев. По этим критериям и сделали данный обзор.

Критерии и обзор 5 систем управления задачами, в том числе нашей собственной – ниже.

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

Может ли «красный» лидер быть эффективным? (Спойлер: Да, если он не красный).

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

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

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

Лидер идеального «красного» государства может смело сказать — «государство это я», а в идеальном «синем» государстве совсем нет лидера — жизнь там течет как известном романе Франца Кафки «Процесс». (с) KonkovVladimir

Именно эти законы системы становятся преградой на пути внедрения любых проектов повышения эффективности бизнеса и вовлечённости персонала.

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

Метрики, KPI, SLA, DoD, OKR — численных показателей производительности и эффективности команд существует много, но часто их недостаточно, чтобы понять, как на самом деле обстоят дела в команде. Довольны ли люди тем, что они делают, гордятся ли своим продуктом, хотят ли идти в офис?

Squad Health Check — модель оценки здоровья команды, придуманная в Spotify, и сегодня расскажем, как мы в Яндекс.Деньгах измеряем наше здоровье и что из этого вышло.