Agile scrum разница: «В чем состоят отличия Scrum и Agile?» – Яндекс.Кью

Agile и Scrum на практике: вопросы скрам-мастеру | GeekBrains

Что такое Agile, как проводят скрам-собрания в российских и международных компаниях, кто такой Scrum master и какие функции выполняет.

https://d2xzmw6cctk25h.cloudfront.net/post/1957/og_image/116cd6af043c0da9c731ff7ad9026dda.png

К чему готовиться, когда приходишь в команду, где применяют Agile. Кому нужен Scrum, в чем его сила и когда он мешает. 

Слова Agile и Scrum прочно вошли в жизнь разработчиков за рубежом и в России. Мнения о гибких правилах разработки в профессиональном сообществе расходятся. Сегодня мы обсудим эту тему с человеком, который работает по принципам Agile уже более 10 лет и успел получить опыт проведения скрамов в российской и международной компаниях. Мой собеседник — Владимир Морозов — преподаватель факультета Android-разработки в GU, он нам расскажет про функции Scrum мастера и какую роль он играет в команде.

— Владимир, какие курсы вы сейчас ведете в GeekUniversity и GeekBrains?

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

— В каких компаниях и командах вы занимались разработкой и практиковали Agile и Scrum?

— Я не любитель часто менять работу: в 2007 году пришел в компанию, которая разрабатывала ПО для ритейловых сетей. В этой компании мало кто знал про Agile, и когда команда столкнулась с проблемами, мы стали анализировать ситуацию и искать решение. В итоге пришли к необходимости использовать Scrum. Сейчас работаю в DXC Technology — тоже по скраму. 

Уточню, что Scrum — это не методология и не технология, а фреймворк, как утверждают авторы скрам-гайда Ken Schwaber и Jeff Sutherland. На русский язык тяжело перевести, что такое фреймворк, поэтому говорят «методология». На самом деле это контейнер с правилами, который каждая компания и команда заполняет своими процессами. Я бы сказал, что скрам — это набор правил и рекомендаций. 

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

Разработка программного обеспечения — штука сложная: тяжело прогнозировать сроки выполнения задач, синхронизировать задачи между разработчиками, расставлять приоритеты. Скрам помогает решать эти проблемы и организовывать работу так, чтобы ваша команда развивалась непрерывно.

— В чем ключевые особенности взаимодействия в командах, применяющих Agile?

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

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

— Чем еще занимается скрам-мастер?

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

— Чем на практике отличается применение методологии Agile в разных компаниях (российских и зарубежных) и командах? Какие факторы влияют на эти различия?

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

— По вашему опыту, когда Scrum работает лучше всего и какие у него противопоказания?

— Скрам отлично работает, когда сотрудники самомотивированы, ответственны. А еще, когда не до конца понятно, что делать, и вы постоянно ищете, как улучшить процессы разработки ПО. 

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

— Когда в феврале этого года в блоге вышла небольшая статья про Agile, у одного читателя возник вопрос: есть ли в Scrum место «причесыванию кода» — рефакторингу и «выпиливанию костылей»? Или в погоне за новыми запросами пользователя трудно найти на это время?

— Интересно, что в твиттере недавно появилось на эту тему сообщение от автора принципов SOLID, Роберта Мартина, или Дядюшки Боба, как зовут его в сообществе. Он посоветовал при оценке задачи закладывать в нее рефакторинг и написание тестов. Считаю этот совет очень разумным и полезным. 

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

— У себя в профиле вы указали, что в программировании, помимо прочего, вам важна тестируемость кода. Что вы под этим подразумеваете?

— К сожалению, начинающие разработчики, да и не только они, часто пренебрегают написанием автотестов. Как проверить код? Только тестированием. Это можно сделать вручную либо написать автотест — кусок кода для проверки другого кода. 

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

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

— Работаю по Scrum в компании DXC Technology. Почитайте, чем она занимается. Не уверен, что это компания топовая, но международная — точно. 

Как связана архитектура с Agile? Я не понимаю. Это как сравнивать зеленое с круглым. 

Если в ранних версиях руководства по скраму говорилось, что работающий код лучше документации, это не значит, что документация не нужна. В последней редакции гайда таких фраз уже нет. Разработка документации ведется в рамках отдельных задач и/или Definition of done, то есть определения законченности задачи.

— Есть ли в Agile механизм защиты продукта от перегрузки лишними функциями из-из «хотелок» пользователей? Или это за рамками подхода?

— За рамками. За этим следит владелец продукта: он ведет backlog (список задач) и расставляет приоритеты. Любая «хотелка» должна быть проанализирована.

— В каких ситуациях уместно так называемое экстремальное программирование (XP)? Был ли у вас такой опыт?

— Мы работаем по этим методикам. Фактически Scrum — часть экстремального программирования. Добавим сюда парное программирование, непрерывную интеграцию и разработку через тестирование — получим XP. 

Если заказчик недоступен, в скраме его замещает владелец продукта. Мне кажется, чем больше элементов экстремального программирования вы применяете, тем качественнее продукт. XP — это работа без стрессов, а не наоборот. 🙂

К примеру, подход test-first означает, что сначала мы пишем тест, он падает, затем пишем код под этот тест, и тест в результате «зеленый», то есть показывает, что код написан верно. Теперь мы точно знаем, что тест работает с новым кодом, сам код не содержит дефектов — следовательно, нет багов у пользователя и он не треплет нам нервы.

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

Еще один принцип XP — частые итерации и общение с клиентами. Это нам дает скрам. У нас нет строгой точки релиза, когда перед поставкой продукта все разработчики трудятся в мыле днем и ночью. Поставка может быть итогом каждого спринта. А непрерывная интеграция обеспечивает работоспособность проекта постоянно.

— Как выглядит спринт в команде Android-разработчиков? Что чаще всего идет не так и что при этом может сделать мастер?

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

В каждой команде — свои проблемы. Это может быть внутренняя коммуникация, назойливое руководство или еще что-то. С подобными препятствиями помогает бороться скрам-мастер. К слову, сейчас наша команда работает на Java, C#, Golang, Python и Angular (TypeScript).

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

— Что касается веба, — да. Фронтенд — часть, которую видит пользователь, а значит, американский разработчик лучше напишет и оформит текст для американской аудитории, поскольку и языком владеет на уровне носителя, и клиента знает.

У меня не настолько большой опыт работы с зарубежными Android-разработчиками, чтобы говорить о подобных нюансах. Но сейчас наша команда пишет микросервисы на C# — это тоже можно считать бэкендом 🙂

— Насколько понимаю, Аgile ориентирован на опытных специалистов, которые умеют брать на себя ответственность. Когда в команду приходит Junior, которого предстоит многому научить, он еще не полностью вовлечен в проект. Что, кроме собственного желания сотрудника, влияет на скорость вовлечения? Как этому способствует скрам?

— Обучать таких людей — одна из обязанностей scrum-мастера. Чтобы скорее вовлечься, нужно просто начать работать в команде.

— Насколько обременительно быть скрам-мастером: какую часть рабочего времени приходится выделять на организационные моменты? Насколько это сочетается с другими задачами ведущего разработчика?

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

Наша команда создана недавно, и в ней уже подобрались сеньоры, но все равно разработчики и автотестеровщики из других команд приходят за советом, а иногда даже просят посмотреть code review. Однако эта работа никак не связана с задачами скрам-мастера.

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

Scrum и Agile для чайников

Автор Елена Трускова На чтение 8 мин. Просмотров 17.5k. Опубликовано 10.05.2017

Комментарий Котиков

Для начала. Scrum и Agile — в чем разница? Если коротко, Agile — это философия, семейство гибких подходов к разработке ПО. Scrum — один из таких подходов. У него есть братик — Kanban. Он тоже подход, используемый в Agile.

Елена Трускова рассказывает:

На этой неделе я прошла двухдневный тренинг по Agile/Scrum (произносится «эджайл» и «скрам»). По гибким методологиям разработки программного обеспечения написано много заумной и не очень литературы, многое я читала. Но только после двухдневного погружения в тему у меня наконец собралось базовое понимание предмета, из которого я пишу эту заметку.

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

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

Принципы скрама можно применить совершенно ко всему: например, к работе над творческим продуктом. Это, конечно, не «канонический эджайл», скрам-евангелисты будут скрежетать зубами, зато ваши процессы будут двигаться бодрее. Шашечки или ехать?

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

Эджайл

(англ.agile —«проворный, шустрый, сообразительный»)

Концепция гибкости:

Подставьте свой вид деятельности вместо слова «разработка» — и эти принципы станут близкими и понятными.

«Работающий продукт — основной показатель прогресса», «простота как искусство минимизации лишней работы» и «люди и взаимодействие важнее процессов и инструментов» — правда, звучит разумно?

Книжку «Открывая организации будущего» Фредерика Лалу я читала совсем недавно. Вполне бодрый подход ко всем отраслям на свете

Скрам

(англ. scrum — толкотня в борьбе за мячик в регби)

Тут стоит напомнить, что это моя личная и субъективная точка зрения на скрам. Здесь я размышляю о применимости элементов скрама как в творческих проектах, далеких от IT, так и в индивидуальной работе (скажем, над блогом). Много точных деталей для этого придется упустить; я стараюсь сохранить простоту текста и не перекормить читателя терминологией.

Жесткость скрама заключается в структуре. Есть некий набор подходов, работающих вместе лучше, чем по отдельности. Вытащить что-нибудь и заиспользовать вам, я надеюсь, никто не запретит.

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

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

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

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

Команда в скраме

Стандартный размер скрам-команды — 7 плюс-минус 2 человека. То есть от пяти до девяти. Бывает скрам-масштабирование: можно из 25 команд состроить систему работы над гигантской задачей. Но основная единица скрама — команда.

В каждой команде есть:

• участники (в случае IT — разработчики, кто эти семь человек у вас — решите сами)
• продакт оунер (product owner, владелец продукта). Его роль: понимать рынок и пользователя, формулировать задачи на языке бизнеса и пользователей, держать в голове осознание того, в каком направлении должны развиваться ценность и польза, придумывать и отбирать задачи для развития продукта. Что-то вроде руководителя продукта (не команды).
• скрам мастер (scrum master, скрам-евангелист). Его роль: следить за процессом, наблюдать за внутренней жизнью команды, мотивировать людей, устранять препятствия. Что-то вроде тренера.
  Вокруг команды есть пользователи и стейк-холеры (stakeholders, заказчики). К этим людям продакт оунер ходит советоваться.

Устройство спринт

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

У продакт оунера есть список идей от бизнеса для осчастливливания пользователей. Он называется «продакт бэклог» (product backlog, список продуктовых идей). В нем идеи отсортированы по важности и значимости.

В каждом спринте есть спринт бэклог (sprint backlog, список задач на спринт) — отсортированный список идей, которые команда решила сделать за ближайший спринт. Смысл скрама в том, что команда сама оценивает сложность каждой задачи и решает, какие задачи войдут в очередной спринт.

Задача в спринте имеет известный команде вес (известно, сколько времени на неё уйдет), к ней прикреплен исполнитель, она является понятной и важной. Если неизвестно, сколько времени уйдет на задачу, нужно её разбить на более мелкие части.

В начале своей жизни команда всегда плохо планирует. Это объективная реальность. Но она ведет статистику того, что ей удается сделать за спринт, и со временем планирует всё точнее. Ей помогает итоговая встреча спринта — ретроспектива. На ней можно обсудить слабые моменты уходящего спринта и придумать способы делать по-другому.

Обычно в спринт влезает 5 плюс-минус 2 идеи. Если идеи слишком большие, команда их дробит так, чтобы в каждом спринте можно было что-нибудь маленькое, да показать.

В скраме идеи называются юзер-сториз (user stories, истории про пользователей) и формулируются так: «Я как (роль?) хочу (что?) для того, чтобы (зачем?)». Таким образом команда видит не только функциональность, но и смысл её создания, причем для конкретной роли: пользователь, заказчик, покупатель.

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

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

Структура спринта

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

Каждый день есть стендап-митинг (stand up meeting, совещание стоя) на 15 минут. Делать его стоя важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу и чесать ухо. Можно использовать какой-то предмет, чтобы говорил в один момент времени только один участник, и передавать его по кругу.

Каждый участник стендапа по очереди отвечает на три вопроса:

• что я сделал вчера
• что я сделаю сегодня
• что меня тормозит

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

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

В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта, спринт-ревью (sprint review, обзор спринта) с пересмотром продакт-беклога и разговорами о том, ЧТО мы делаем, а также ретроспектива (retro) — что мы делали не самым лучшим образом весь спринт и хотим улучшить далее — о том, КАК мы это делаем.

«Если бы у меня было восемь часов для того, чтобы срубить дерево, я бы шесть часов потратил на заточку топора». (приписывается лесорубу и президенту Аврааму Линкольну)

Подпишитесь на рассылку новостей. Никакого спама!

Email*

Подписаться

Как использовать Agile и Scrum для управления проектами — руководства на Skillbox

запись вебинара

 1ч. 40 мин.

статья

 10 мин.

Экономия времени

 1ч. 30 мин.

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

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

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

Плюсы методологии:

• Нет нужды составлять длинное ТЗ — вместо этого формируется гибкий список задач на основе желаний клиента.
• Бюджет гибкий — если деньги закончились, заказчик все равно получит работающий проект, пусть и с меньшим количеством функций.
• Меньше бюрократии — нет нужды согласовывать сразу всю документацию по проекту, достаточно получить одобрение руководителя по одному вопросу. Разработка других задач в это время не прекращается.

Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.

Scrum — это метод управления проектами, он входит в философию Agile. Ключевое отличие от классической, водопадной схемы создания ПО заметно сразу — для начала разработки не нужно техническое задание.

Минус водопадной схемы — процессы идут друг за другом. Это замедляет разработку

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

Удобно вести бэклог задач в Trello или Excel.

Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.

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

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

Как это работает? Команда забирает из бэклога часть задач. Каждая разбивается на максимально мелкие тикеты. Теперь нужно оценить время на задачу, и вот здесь проявляется особенность Scrum.

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

Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.

Так выглядит бэклог со спринтами.

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

В идеальном мире на ключевые роли в scrum-команде назначаются люди, выращенные на проекте. Такой человек будет знать процессы изнутри, лучше ориентироваться в оценках и понятнее ставить задачи.

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

Член команды разработки, отвечающий за выполнение ежедневных процедур и за соблюдение интересов команды. Этот человек фиксирует дедлайны и начало спринта, добавляет оценки, отчитывается перед заинтересованными лицами об этапах проекта. Растите scrum-мастера внутри команды.

Команда разработки

Люди, которые непосредственно создают и тестируют код. 

К разработчикам есть несколько требований:

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

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

Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.

Так выглядит диаграмма сгорания в реальных проектах.

Контролируйте работу команды с помощью двух scrum-показателей:

• Focus Factor — коэффициент, который показывает, сколько задача должна была выполняться по плану, а сколько вышло в итоге. Так оценивается «концентрация» команды над проектом.
• Velocity — производительность. Поможет спрогнозировать количество задач, которые команда сможет взять в следующем спринте — в зависимости от количества готовых тикетов в прошлом. Velocity = Focus Factor * Оценка новых задач.

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

В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:

• Что сделано вчера?
• Что будет сделано сегодня?
• Какие есть проблемы и препятствия для выполнения задач?

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

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

Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.

На следующей ретроспективе обсудите идеи из плана, отсортируйте их по категориям «плохо» и «хорошо». Повторите процесс — получается ретроспектива на ретроспективу.

Попробуйте такой шаблон для ретроспективы.

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

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

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

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

Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:

• Trello — подходит для маленьких проектов, быстро и удобно.
• Scrumban — есть разные доски, вложенные задачи и подзадачи. Удобно для средних и маленьких проектов.
• Jira — есть версионность, удобно для больших и долгих задач. Поддерживает массу типов разработки. Попробуйте, она вам понравится.

• Научиться вести бэклог и расставлять приоритеты.
• Проводить спринты.
• Формировать стабильную и постоянную команду, решать трудности, растить внутри группы scrum-мастера.
• Контролировать работу с помощью диаграммы сгорания проекта.
• Организовать работу — каждый день интересоваться делами команды, проводить ретроспективу и закладывать время на тикет с запасом.
• После каждого спринта демонстрировать проект.
• Изучить инструменты и найти самый удобный.

Теперь вы знаете основы Agile и Scrum и можете начать внедрять их в реальные проекты. Но для эффективной работы с командой этого мало — нужно уметь делать это осмысленно, знать тонкости методологий и не теряться в сложных моментах. Всему этому учат на курсе Skillbox. Одновременно с обучением сможете использовать полученные навыки в работе.

Курс «Руководитель digital-проектов»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

• Живая обратная связь с преподавателями
• Неограниченный доступ к материалам курса
• Стажировка в компаниях-партнёрах
• Дипломный проект от реального заказчика
• Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Сравнение Agile, Scrum, Kanban в качестве эффективных методов управления проектами

Вопросы, рассмотренные в материале:

• Какие существуют популярные системы управления проектами
• В чем преимущества и недостатки классического метода управления
• В чем плюсы и минусы Agile, Scrum, Kanban
• В чем различия между Agile, Scrum, Kanban

Определение терминов управления проектами: Agile, Scrum, Kanban

В проектном управлении существует множество методов, призванных удовлетворить любые потребности управленцев, в том числе уже упомянутые Agile, Scrum, Kanban. Если вы не запускаете космический спутник и лишены столь объемных ресурсов, вы сможете выбрать инструмент, который будет для вас самым подходящим. Нужно понять, какой из факторов играет ключевую роль в вашем случае: дедлайны, ресурсы, соблюдение процесса, ряд других характеристик. Далее вы будете отталкиваться от этого показателя при выборе одного из методов управления, созданных на основе Agile.

Нужно составить представление о некоторых терминах, перед тем как заняться сравнением Agile, Scrum, Kanban как самых популярных из существующих подходов к проектному менеджменту.

Базовые термины проектного управления:

1. Agile: гибкий итеративно-инкрементальный метод проектного менеджмента с динамическим формулированием требований, выполнение которого ведется за счет непрерывного взаимодействия рабочих групп. В последние входят специалисты разных профилей. Если проводить сравнение Agile с другими методами, становится ясно, что его идеи стали основой для множества методик, например, Scrum, Kanban.
2. Критический путь: непрерывный цикл действий, требующий самого продолжительного срока на его осуществление.
3. Событийная цепочка процессов (EPC-диаграмма): диаграмма, в которой отображается ход проектов в соответствии с доступностью ресурсов.
4. Резерв времени: промежуток времени, на который можно задержать старт работ, не влияя на срок сдачи проекта. У критического пути такого резерва нет.
5. Веха (контрольная точка, milestone): ключевое событие, которое на диаграмме Гантта выглядит как задача, не имеющая продолжительности. Вехой может считаться конец этапа.
6. Менеджер проекта (руководитель проекта, project manager, PM): управленец группы проекта, он отвечает за планирование, реализацию, закрытие проекта.
7. Ресурсы: это время, оборудование, материалы, специалисты, пр. – то есть все составляющие, без которых успешная работа не представляется возможной.
8. Содержание проекта (Scope): описание всех работ, запланированных на время осуществления проекта.
9. Спринт (Sprint): итерация (рабочий цикл) в Scrum, на которую дается неделя – месяц. За него создается рабочая версия продукта/его элемент, который можно передать заказчику.
10. «Классическое» или «традиционное» проектное управление: самый распространенный вариант управления проектами, в основе которого лежит «водопадный» (Waterfall)/каскадный цикл, где задача последовательно движется по фазам.

Далее рассмотрим ряд подходов к проектному управлению. Начнем с классического вида – Agile, после чего перейдем к сравнению Scrum и Kanban.

Топ-3 статей, которые будут полезны каждому руководителю:

Немного о классическом проектном управлении

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

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

5 этапов традиционного менеджмента:

Этап 1. Инициация. На совещаниях, собраниях все участники устанавливают требования к проекту. Именно на этом этапе составляется представление о результате работы.

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

Этап 3. Разработка. Во многих случаях этот этап представляет собой часть планирования. Разработка сама по себе обычно свойственна технологической области, так как позволяет выбрать конфигурацию проекта/продукта, способы его создания. Так, если речь идет о сфере информационных технологий, то выбирают язык программирования.

Этап 4. Реализация и тестирование. Осуществляется основная работа по проекту – написание кода, строительство, пр. Для этого используются составленные ранее планы, работа сверяется с выбранными метриками. Во второй части фазы продукт тестируется – проводится сравнение результата с требованиями заказчика и представлением группы на первом этапе. Это позволяет исправить недочеты.

Этап 5. Мониторинг и завершение проекта. На этом шаге можно просто передать результат трудов заказчику либо вести длительное взаимодействие с клиентами по улучшению проекта – все зависит от самого проекта. Если он ведется в сфере клиентского сервиса и ПО, допускается поддержка результатов.

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

Поскольку такое проектное управление привязано ко времени исполнения задач, проекты осуществляются с использованием инструментов календарно-сетевого планирования. Обычно в ход идет знаменитая диаграмма Гантта, для ее построения и заполнения могут использоваться простые средства, такие как «Excel» и «Smartsheet», или более серьезные программы «Microsoft Project» и «Primavera».

Преимущества и недостатки классического метода управления

1. Сильные стороны классического проектного менеджмента.


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


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

2. Слабые стороны классического проектного менеджмента.


Главная слабая черта этого подхода – невозможность реагировать на изменения. Руководство «Toyota», создавшей Lean и Kanban, часто критикуют за разработку софта для своей компании на основе этого недостаточно гибкого метода.

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

Альтернативные методы управления: сравнение Agile, Scrum, Kanban

1. Agile.

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

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

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

Agile стал популярен не так давно, однако сама идея итеративной разработки существует уже долгие годы. Современное название семейство гибких методологий получило в 2001 году, после публикации Манифеста Agile («Agile Manifesto») – он зафиксировал базовые ценности и принципы гибкой разработки ПО. Основными в этом подходе стали командная работа, адаптация, готовность к изменениям.

В чистом виде Agile является не методом управления проектами, а набором идей и принципов их реализации. Все они послужили базой для создания гибких методов или фреймворков (frameworks), таких как Scrum, Kanban, Crystal, пр. Хотя сравнение последних позволяет заметить серьезные отличия между ними, подход к работе остается общим.

Сильные стороны Agile:

Специалисты в сфере проектного управления ценят Agile за адаптивность, то есть этот метод подстраивается под любые условия, процессы фирмы. Именно этим свойством объясняется количество систем в семействе Agile.

При работе с Agile нельзя забывать о его основном правиле: «Реакция на перемены важнее следования плану». Быстрая, безболезненная реакция на изменения приводит к тому, что лидеры рынка все чаще делают выбор в пользу более гибких процессов. В отличие от классического подхода, Agile может использоваться для проектов, не имеющих четкого завершения, допустим, для запуска сервиса или блога.

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

Слабые стороны Agile:

По сравнению со Scrum, Kanban, Agile – это не методология или стандарт. Как мы говорили, Agile– это система принципов и ценностей. Поэтому основная сложность работы с Agile в том, что каждая команда должна сама составить систему управления на основе имеющегося набора правил. Если проводить сравнение Agile с Scrum, Kanban, то при работе с ними этого не требуется. Поясним, что данный процесс сложен, на него затрачивается немало времени, кроме того, он требует изменений всей организации от процедур и до базовых ценностей. Не каждая компания способна справиться с такой задачей.

Работая с Agile, лидер должен проявить знания и упорство, а также от него потребуются серьезные административные ресурсы, вложения. Радует тот факт, что сегодня есть готовые наборы практик, которые упрощают Agile-трансформацию организации. В их число входят Scrum, Kanban и целый ряд других: Crystal, LeSS, SAFe, Nexus.

2. Scrum.

Гибкий фреймворк, появившийся в 1986 году. Считается, что он наиболее структурированный по сравнению со всеми остальными продуктами семейства Agile. Здесь элементы водопадного метода совмещены с гибким подходом к управлению проектами, образуя баланс гибкости и структурированности.

В соответствии с принципами Agile, Scrum делит проект на части, которые заказчик может сразу использовать для получения ценности – они называются заделами продуктов (product backlog). Хотя «задел продукта» является достаточно точным переводом английского термина и используется в профессиональной литературе, на практике его обычно заменяют словом «беклог».

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

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

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

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

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

Структура Scrum состоит из 5 основных встреч:

• Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»): в классическом подходе есть похожий этап, но там он называется этапом планирования. В первый день спринта команда обсуждает, что уже сделано в рамках проекта, что еще нужно предпринять, принимается решение о следующем шаге. Отдельная роль отводится владельцу продукта – в Scrum он устанавливает приоритетные задачи. На первом шаге в Scrum определяют, что получит заказчик после итерации, поэтому данная встреча влияет на ее эффективность.
• Планирование спринта: владелец сделал свое дело, поэтому сразу после первой встречи команде нужно понять, как она будет идти к цели, что именно будет делать во время итерации. Выбор специалистов среди технологий планирования и оценки ограничивается только одним правилом: инструменты не могут противоречить идеям Scrum.
• Ежедневные летучки: каждый день, желательно в одно время, команда выделяет четверть часа на то, чтобы обсудить статус задач, состояние проекта. В это время не говорят о вопросах и разногласиях, такие темы прорабатываются лично со Scrum-мастером. Летучка нужна только для обмена информацией, тогда каждый специалист будет в курсе текущего состояния проекта.
• Подведение итогов спринта: теперь проводится адаптация продукта. Команде нужно представить свое детище всем заинтересованным лицам, ведь только так можно понять, выдерживает ли результат ее работы сравнение с ожиданиями участников, поставленными целями.
• Ретроспектива спринта: проходит после подведения итогов, но до планирования нового рабочего цикла. На этом этапе важно понять, насколько четко шла работа, какие были проблемы на разных ее этапах. Команда проводит сравнение, чтобы новый спринт оказался более продуктивным.

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

Сильные стороны Scrum:

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

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

Как говорят члены команды «Netflix», главное достоинство Scrum состоит в том, что он позволяет «быстро ошибаться». По сравнению с другими подходами к управлению, Scrum не требует долго и с большими затратами готовить крупный релиз – поставки каждые две недели имеют небольшой размер, их легко отслеживать и, при необходимости, оперативно исправлять.

Слабые стороны Scrum:

Scrum, по сравнению с другими методами из семейства Agile и вне его, выдвигает серьезные требования к команде проекта: она должна быть маленькой (5–9 человек), а у каждого члена команды должно быть более одной компетенции, необходимой в процессе выполнения проекта. Так, разработчику ПО нужны знания в тестировании и бизнес-аналитике. Подобный подход позволяет всем участникам быть задействованными на разных этапах проекта, подменять друг друга при необходимости.

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

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

3. Kanban.

Это детище инженера компании «Toyota» Тайичи Оно (Taiichi Ono), которое увидело свет в 1953 году. При сравнении Kanban с другими методами заметна его схожесть со схемой производства – в нее попадает кусочек металла, а выходит полноценная деталь. Инкремент продукта передается с этапа на этап, а в конце мы получаем готовый к поставке элемент.

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

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

Kanban требует установить этапы потока операций (workflow). Здесь их изображают в виде столб

Agile и Scrum для работы в Digital агентстве | Блог

Наверное вы уже что-то слышали об Agile.  Может даже пытались применять у себя в проектах. Ну или хотя бы ради интереса посмотрели парочку видео на ютубе. Однако так и не поняли как сделать работу над проектом проще и эффективнее?

Это Андрей и он тоже не понял.

У Андрея своя Web-студия. Он работает 24/7, прикладывает колоссальные усилия, но студию уже 2 года как прогресс покинул. Мелкие проекты тянутся полгода, оплата поступает не всегда вовремя, у коллектива не горят глаза. Андрей твердо решил что так продолжаться не может. 

Давайте, поможем Андрею и его команде разобраться в терминах и войти в прекрасный мир Agile методологии.

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

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

В документ вошли 4 идеи:

● Люди и взаимодействие важнее процессов и инструментов;

● Работающий продукт важнее исчерпывающей документации;

● Сотрудничество с заказчиком важнее согласования условий контракта;

● Готовность к изменениям важнее следования первоначальному плану.

«Да, нашли тут дурака! Документаций нам не надо, контракта мы не придерживаемся, на инструменты наплевать! Так и создается из визитки интернет магазин с бюджетом в 5 тысяч. Знаем, плавали» — разочарованно подумал Андрей. 

Наш герой, как и многие, изначально понимает Agile манифест некорректно, полностью откидывая правую часть предложения. Однако это неправильное восприятие сути.

«Мы признаем ценность того, что находится справа, но для нас более ценно то, что слева. Это не взаимоисключающие вещи, просто акцент делается на людях, взаимодействиях, сотрудничестве и работающем продукте» — объясняет Agile манифест.

Тут Андрей понимает, что по сути, Agile это своего рода философия, которую ему нужно не внедрить, а лишь принять.

И правда, Agile это лишь система ценностей, на основе которой развивается целый комплекс практик по управлению проектами.

Окей, с теорией разобрались, но что же Андрей получает на практике?

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

– Слишком сложно! — опять пробурчит Андрей.

– Минимизирует риски! — ответим мы.

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

«Хорошо, я допускаю, что это может сработать, но мне нужна конкретная методика по управлению проектами» — резонно замечает Андрей.

Давайте расскажем ему об одной из самых распространенных  методик Agile.

Scrum

В центре SCRUM находится команда, у каждого есть четкая роль. Условно, команда делится на 3 вида ролей:

1. Product Owner (владелец продукта) — человек, понимающий каким продукт должен получится на выходе. Он собирает и приоритезирует требования. Общается с клиентом или клиентами. Рассказывает о ним команде. Вот кстати интересный факт: Product owner это не всегда клиент. Это запросто может быть человек в команде разработки.

2. SCRUM Мастер — это “сердце команды”, задача этой роли в том, чтобы создать для команды максимально комфортные условия работы, мотивировать и помогать. Роли мастера и владельца продукта ни в коем случае не должны пересекаться.

3.  Непосредственно команда, которая выполняет проект: дизайнер, Front-end, Back-end.

“А кто головой отвечать будет??!” — восклицает Андрей.

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

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

Как пользоваться Scrum

1. Формирование бэклога

Это список требований (задач), которые нужны для реализации проекта, включает в себя как технические, так и функциональные требования. Product Owner отвечает за бэклог, наполняет его и расставляет приоритеты. Именно такой подход к делу решает одну из основных задач Андрея, ведь часто для его команды все задачи одинаково приоритетны, что приводит за собой “застой” в разработке проекта.

Задачи в бэклоге обычно формируются на языке пользователя и включают в себя все требования заказчика.

2. Спринт планирование

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

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

To Do — задачи, которые нужно сделать;

WIP — задачи в процессе выполнения;

Done — выполненные задачи;

Изначально каждую пользовательскую задачу следует разбить на подзадачи и распределить по сотрудникам. Планирование спринта определяет чем Андрей и его команда будут заниматься в ближайшее.

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

Когда задачи на неделю спланированы, посчитаны и распределены — они переносятся в колонку To DO и блокируются. Это значит, что в течении рабочей недели команда работает по заранее согласованному плану.

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

Для визуализации задач удобнее всего использовать дополнительные программы. Андрею вот  приглянулся WEEEK.

3.  Ежедневные Скрам-встречи — митапы

Они просто должны быть. Каждый день. Но не более 15 минут. Поэтому их часто проводят стоя на ногах, чтобы не задержаться на удобном диване невзначай.

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

За время собрания успеваем перенести сделанные задачи в колонку Done , а те, которые планируются на сегодня из To Do перемещаем в WIP.

Вывод: задача команды за один спринта все задачи из колонки To Do перенести в колонку Done. Если не все задачи успели дойти до этой колонки, то задачи переносятся на следующий спринт, а на следующем планировании проводится корректировка рабочих часов на задачи.

– Ох, ну зачем каждое утро, то? – недоволен Андрей.

– Чтобы понимать, где находимся –  отвечаем мы.

4. Ретроспективы. 

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

5. Демонстрация и релиз

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

Так, спустя  4 недели Андрей уже имеет “осязаемую” часть, а может даже и весь продукт. Может показать его клиенту и обсудить возможные правки, собрать новые требования, и даже получить процент оплаты 🙂

Что делать Андрею и его команде дальше?

С собранными требованиями после демонстрации вернуться к этапу бэклога и повторить цикл. Профит.

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

Что еще нужно знать?

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

Он четко объясняет правила, которые необходимо соблюдать, чтобы все работало. Но гибок в том, что для каждой команды и проекта Scrum будет разный. У кого-то между спринтами будет регулярный полуспринт на правки. У кого-то будут релизы каждую неделю. У кого-то спринты по 2 недели. А у кого-то дополнительная строка под внеплановые задачи. Никто не знает как удобно работать вам и вашей команде. Нужно пробовать, тестировать и внедрять.

Scrum чек-лист 

1.   Собираем команду, распределяем роли.

2.   Формируем бэклог, разбиваем его на части по приоритету.

3.   Одному спринту отводим определенный объем задач.Оформляем и наполняем колонки To Do.

4.   Каждое утро проводим митап, по его результатам переносим задачи в нужную колонку.

5.   В конце спринта проводим ретроспективы.

6.   Общаемся с клиентом, показываем что сделали, собираем новые требования, правки.

7. После нескольких спринтов, проводим релиз, заливаем готовую часть продукта или функцию.

8.   Колесо Сансары дало оборот.

Начнем? 

__________

Текст: Анастасия Евдокимова

Где Agile ужасен, особенно Scrum / Хабр

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

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

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

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

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

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

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

Хорошо известно, что творческие люди теряют креативность, если их просят объясниться во время работы. То же и с программным обеспечением. Программистам часто приходится работать в условиях односторонней прозрачности. Эти системы Agile часто неправильно применяются и требуют унизительной прозрачности работы, несмотря на отсутствие взаимности. Вместо того, чтобы работать над фактическими долгосрочными проектами, которыми человек мог бы увлечься, они низведены до работы над атомизированными, функциональными «пользовательскими историями» и часто запрещают работать над улучшениями, которые не связаны с краткосрочными, непосредственными потребностями бизнеса (часто спускаемыми сверху). Этот неправильный, но распространённый вариант Agile исключает понятие собственности и расценивает программистов как взаимозаменяемые, одинаковые компоненты.

Scrum — худший вариант, с глупостью двухнедельных «итераций». Это вызывает ненужное беспокойство о микрофлуктуациях производительности человека. Нет абсолютно никаких доказательств, что такой подход действительно ускоряет или улучшает разработку в долгосрочной перспективе. Он просто заставляет людей нервничать. Многие в бизнесе думают, что это хороший подход, потому что работа «идёт быстрее». Я в IT-индустрии уже десять лет, как менеджер и как рабочая пчела. Это неправда.

1. Бизнес-ориентированная разработка.

Agile часто подают в сравнении с «водопадом». Что такое водопад?

Подход Waterfall действительно ужасен. В нём «работа катится вниз», где каждый уровень организационной иерархии выбирает то, что он считает «интересным материалом», и передаёт дальше. Проекты определяются руководителями, архитектура проектируется архитекторами, личные сроки устанавливаются менеджерами среднего звена, реализация выполняется рабочими лошадками верхнего уровня (программистами), а затем операции и тестирование передаются лошадкам нижнего уровня. Это крайне нефункциональная схема. Когда люди чувствуют, что все важные решения уже приняты, у них нет мотивации работать как можно лучше.

Водопад воспроизводит социальную модель дисфункциональной организации с определённой иерархией. В свою очередь, Agile довольно часто реплицирует социальную модель дисфункциональной организации без чётко определённой иерархии.

У меня смешанные мнения о названиях должностей вроде «старший» и «директор», и тому подобное. Они имеют значение, и я сам, вероятно, не приму должность ниже уровня директора, но я ненавижу их значение. Если вы посмотрите на Scrum, он специально лишает прав старших, самых способных инженеров, потому что здесь они обязаны придерживаться установленных процессов (работа только над созданными задачами, 5-10 часов в неделю на планёрках). Эти процессы спроектированы для людей, которые начали программировать месяц назад.

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

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

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

Но у вас «бизнес-компания», это нормально. Тогда не нанимайте инженеров в штат, если вам нужен талант. Вы можете получить лучших людей в качестве консультантов (начиная с $200 в час и резко поднимаясь с этого уровня), но не в качестве штатных сотрудников «бизнес-компании». Хорошие инженеры хотят работать в фирмах, управляемых инженерами, где они будут участвовать в планировании работы без необходимости оправдываться перед «скрам-мастерами», «владельцами продукта» и несколькими уровнями менеджеров-гуманитариев.

В конечном счёте, Agile (как практикуется) и Waterfall — формы бизнес-ориентированной разработки, и поэтому ни одна из них не подходит для разработки качественного ПО или мотивации сотрудников.

2. Подчинённое положение молодых.

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

Проблема с двухнедельными итерациями Agile (или «спринтами») и пользовательскими историями заключается в том, что нет стратегии выхода. Там нет варианта «Нам не придётся больше это делать, когда мы достигнем [X]». Предполагается, что эта система навсегда: ориентированные на бизнес митинги никогда не исчезнут. Архитектура, НИОКР и развитие продуктов уходят из работы программиста, потому что не вписываются в атомизированные «истории пользователей» и двухнедельные спринты.

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

Однажды я работал в компании, где менеджер по продуктам сказал, что разница между старшим инженером и младшим инженером — в способности давать более точные оценки по срокам. Ну, вообще-то нет. И это даже оскорбительно. Я ненавижу оценки, потому что они генерируют политики и на самом деле не делают работу быстрее или лучше (на самом деле, обычно наоборот).

Самое худшее в оценках — что они стимулируют выполнение работы, которую можно оценить. Это заставляет программистов отдавать предпочтение простым вещам низкого уровня, которые на самом деле не нужны бизнесу (даже если неуклюжие менеджеры среднего звена думают иначе), но это «безопасно». Всё, что на самом деле стóит делать, имеет ненулевой шанс неудачи и слишком много неизвестных параметров для разумной оценки сроков. Концентрация Agile на краткосрочной ценности для бизнеса в конечном итоге отталкивает людей от работы, которая действительно нужна компании, ради управления репутацией каждого программиста в режиме реального времени.

Такая культура наталкивает на мысль, что программирование — это ребячество, от которого нужно избавиться к 35 годам. Я не согласен с таким мнением. На самом деле, я думаю, что это вредная мысль. Мне 30 с небольшим, и я чувствую, что только начинаю хорошо программировать. Преследование старших программистов только потому что они достаточно опытны, чтобы знать, что этот гибкий/scrum-процесс не имеет ничего общего с информатикой и что он не добавляет ценности — это ужасная идея.

3. Слишком краткосрочный подход, что глупо и опасно.

Agile предназначен для второстепенных консалтинговых фирм, у которых нет достаточного кредита доверия, чтобы вести переговоры с клиентами на равных, и которые сталкиваются с жёсткими сроками, а каждый клиентский проект является экзистенциальным риском. Он для «маргинальных» аутсайдеров. Но вот проблема: Scrum часто развёртывают в крупных компаниях и финансируемых стартапах. Но люди идут в такие компании, потому что не хотят быть аутсайдерами. Они хотят безопасности. Вот почему они работают в этих компаниях, а не создают свои собственные. Никто не хочет быть позади, если в этом нет значительной личной выгоды. Agile в корпорации означает боль и риск без вознаграждения.

Когда каждый клиентский проект несёт экзистенциальный или серьёзный репутационный риск, Agile может оказаться подходящим решением, поскольку фокус на краткосрочных итерациях полезен, когда компания находится под угрозой и может исчезнуть в долгосрочной перспективе. Агрессивное управление проектами имеет смысл в чрезвычайной ситуации. Это не имеет смысла как постоянная договоренность; по крайней мере, не для талантливых программистов, у которых есть менее стрессовые и более приятные варианты.

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

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

4. Он не имеет никакого отношения к построению карьеры.

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

В чрезвычайной ситуации, будь то консультация, стремящаяся успокоить важного клиента или корпоративная «военная комната», мысли о резюме могут подождать. Мало кто откажется от пары недель неприятной или иной работы, не имеющей отношения к развитию карьеры, если это действительно важно для компании. Важность работы здесь приоритет. Если вы можете сказать «Я сидел в штабе и по 20 минут в день общался с гендиректором», это оправдывает выполнение тупой работы.

Но если нет чрезвычайной ситуации, программисты ожидают, что их карьерный рост будет воспринят серьёзно. Иначе они уйдут. «Я был в команде Scrum» означает, что вы груша для битья. Одно дело сделать тупую работу, потому что гендиректор признал, что неприятная задача добавит миллионы долларов стоимости (и он вознаградит её соответствующим образом). Но если вам просто назначили «пользовательские истории» и тикеты Jira — значит, вас рассматривают как лузера.

5. Цель определить низкие показатели, но при этом неприемлемо высок уровень ложноположительных результатов.

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

В дебатах о гражданских свободах часто упоминается распространённая ошибка: аргумент «нечего скрывать». Некоторые любят утверждать, что вторжение в частную жизнь, скажем, правоохранительными органами, не является проблемой, потому что они сами не преступники. Эти люди упускают несколько ключевых вещей. Например, что законы меняются. Спросите любого, кто был евреем в Центральной Европе в 1930-х годах. Даже для респектабельных людей состояние слежки — это состояние тревоги.

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

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

Agile и особенно Scrum уязвимы для ошибки «нечего скрывать». Если ты не «плохой работник», ты ведь не против ежедневных планёрок, верно? Единственные люди, кто будет возражать против ежедневных отчётов о своей работе с точки зрения краткосрочной стоимости бизнеса — это «бездельники», которые хотят украсть деньги у компании, верно? Ну, нет. Очевидно, нет.

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

Часто от внедрения Agile/Scrum страдают лучшие сотрудники, потому что R&D эффективно устраняется. Одержимость краткосрочными «итерациями» или спринтами означает невозможность опробовать нечто новое, рискованное.

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

6. Пьяный эффект.

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

С точки зрения менеджера, который не знает, как работает программное обеспечение, это может показаться приемлемым компромиссом: несколько «примадонн» уровня 7+ покинут корабль под парусом Дивного Нового Scrum, зато 3-ки и 4-ки станут вполне приемлемыми 5-ками. Проблема в том, что разница между программистами 7 и 5 существенно больше, чем между 5 и 3. Если вы потеряете своих лучших людей и своих лидеров (которые необязательно находятся на руководящих ролях), то небольшое повышение уровня некомпетентных, для которых предназначен Scrum, не приносит пользы.

Scrum и Agile играют в то, что я называю предвзятостью к смене статуса. По сути, многие люди судят о своих успехах или неудачах не объективно, а исходя из субъективных изменений в статусе. Убедить программиста уровня 5 согласиться на зарплату программиста уровня 3 в стартапе (в обмен на долю в стартапе) психологически расценивается не как потеря денег, а как серьёзная прибавка в статусе.

Agile/Scrum и культура дискриминации по возрасту в целом касаются получения наиболее впечатляющей статусной прибыли, а не фактической экономической прибыли. Её можно достичь, как правило, путём найма людей, которые принесут наибольшую ценность (даже если вы предлагаете на 50% выше рыночной ставки, потому что лучшие программисты стоят в 10-30 раз больше их рыночной ставки).

Люди, которые меньше всего осведомлены о том, какой социальный статус они «должны» иметь — это молодёжь. Вы найдете 22-летнего программиста уровня 6, который думает, что у него уровень 3 и который согласится на Scrum, но 50-летний уровень 9, вероятно, знает, что у него 9 и может неохотно принять условия уровня 8,5, но точно не опустится до 3 или даже 6. Поиск статусной прибыли, конечно, бесполезен. Эти пункты ничего не значат. Вы выигрываете в бизнесе на разнице в доходах и расходах, а не на разнице в бессмысленных пунктах статуса. Может быть, существует целая индустрия в привлечении инженеров 5-го уровня, расценивая (и оплачивая) их как 4, но в нынешних рыночных условиях гораздо выгоднее нанять 8 и относиться к нему как к 8.

7. Нечестная реклама.

Здесь я сосредоточусь на Scrum. Некоторые утверждают, что Scrum является «экстремистским вариантом Agile», а другие — что это самый далёкий вариант от истинного Agile. (Возможно, здесь проявляется одна из проблем: мы не можем договориться о том, что является и не является Agile).

Решениям вроде Scrum есть своё место: очень ограниченное, временное. Нечестно говорить, что оно работает везде и на постоянной основе.

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

У этой команды не будет чёткого менеджера, поэтому вы выберете лидера (например, “Scrum Master”) и дадите ему полномочия. Вы не хотите, чтобы он был официальным «менеджером людей» (так как он должен быть максимально беспристрастным). Поскольку кризис носит краткосрочный характер, карьерные цели отдельных лиц могут быть приостановлены. Это считается «спринтом», потому что люди должны работать так быстро, как могут, чтобы решить проблему, и потому, что им будет разрешено вернуться к своей обычной работе, как только спринт закончится. Кроме того, в такой чрезвычайной ситуации вам нужно дать понять, что никто не оценивается индивидуально. Основное внимание уделяется миссии и только миссии.

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

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

Таким образом, Scrum признаёт идею, что иногда власть нужно делегировать «экстренным» руководителям: они будут делать всё, что считают необходимым, чтобы выполнить работу, оставив споры на потом. Всё нормально. Иногда всё должно быть именно так.

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

Честолюбивому демагогу (скрам-мастер?) легче проявить себя в схватке с драконами, чем избежать их появления. Проблема с агрессивным настаиванием Scrum на бизнес-ориентированной инженерии заключается в том, что она делает ценностями («сотрудничество с клиентами») привлечение и убийство драконов (известных как «требования»), когда может быть более разумным не выманивать тех из своих пещер.

Agile и Scrum прославляют чрезвычайные ситуации. Это их главная проблема. Некая версия того, что индустрия видеоигр называет «шоу-тайм». Это не позволяет устойчиво работать. Агрессивный акцент на индивидуальной производительности, отсутствие заботы о карьерных целях людей при распределении работы и мандат, в соответствии с которым люди работают только на заявленный высший приоритет — всё это даёт большую пользу в краткосрочной чрезвычайной ситуации, но становится токсичным и деморализующим в долгосрочной перспективе. Люди стерпят краткосрочную потерю автономии, но только если впереди будет чёткая точка, когда они её вернут.

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

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

Этой культуре подчинённого положения молодых, низкой автономности и агрессивного управления пришло время уйти. Это не просто плохие идеи. Здесь более серьёзная опасность, потому что выросло поколение инженеров-программистов, которые поглощают их, не зная ничего лучшего. Есть слишком много молодых программистов, обречённых на посредственность из-за уверенности в том, что бизнес-ориентированная разработка и «пользовательские истории» — так всегда всё работало. Такое следует предотвратить: от этого зависит будущее нашей индустрии. Agile, по крайней мере, а такой извращённой реализации, как всё, что я видел, — полная ерунда, которая не имеет никакого отношения к программированию и, конечно же, не имеет никакого отношения к информатике. Бизнес-ориентированная разработка в целом — тупик. Её следует бросить обратно в грязь, из которой она вышла.

в чем разница и что выбрать? / Блог компании Hygger / Хабр

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

Две популярные Agile-методологии

Scrum и Kanban — представители методологий Agile-семейства. Обе считаются гибкими и итеративными. Перед тем, как разобраться в разнице между ними, вспомним кратко о том, что их объединяет.

Более 17 лет назад лидеры IT-разработки сформулировали манифест Agile. Главное, что можем выделить из манифеста:

• Люди и взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования первоначальному плану.

Можно смело согласиться со всеми аргументами, ведь действительно:

• Люди важнее инструментов, потому что несколько человек, объединенных вместе и «заряженных» на одну общую цель могут иметь больший потенциал и прийти в итоге к бОльшему результату.
• MVP-подход в разработке: выпускаем минимально-жизнеспособную версию продукта на рынок ASAP. Все «свистелочки» оставляем на потом.
• Слово «заказчик» очень просится поменять на «пользователь». Требования к проекту надо собирать не у заказчика, а у пользователей будущего продукта. Об этом детально написано у Карла Вигерса и Джоя Битти.

Зачастую в последнее время проект — это стартап. В контексте стартапов приходит на ум «customer development» (оригинальную методику замечательно описал Стив Бланк).

По сути, во время customer development мы проверяем наши гипотезы до начала разработки даже прототипа. Наши цели – убедиться в том, что:

— проблемы, решением которых мы занимаемся, существует в жизни пользователя.

— эти проблемы существенные.

— пользователь будет за них платить

— есть рынок, и это не проблема одного человека.

— есть каналы привлечения пользователей (например Facebook Ads, или Googl Adwords), и мы сможем найти такую стоимость привлечения пользователей, которая будет давать нам прибыль (CAC < LTV).

• Пункт про гибкость нужен тогда, когда ваш UX или менеджер проекта меняет требование в задаче, и программист говорит: «У вас там семь пятниц на неделе». Вот в этой точке пространства и времени вы ссылаетесь на пункт про гибкость. А вообще, нужно “копнуть” глубже. Для чего нужна готовность к изменениям? Для того, чтобы уметь реагировать на обратную связь. Вы запустили фичу в продакшн, собрали статистику поведения пользователей, убедились в том, что надо менять какие-то параметры фичи и отправили ее на допроектирование. И вот у вас уже на проде улучшенная версия функции. Чтобы все это сделать, нужно быть готовым к изменениям (это про Agile) и способность эти изменения улавливать (это про аналитику и данные).

Это основные идеи манифеста, но есть еще знаменитые 12 принципов, которые говорят сами за себя. Так что, глубоко «копать» в них не будем, а лучше вернемся к основному вопросу отличия Scrum от Kanban.

В чем разница между Scrum и Kanban?

Основу Scrum составляют короткие итерации или спринты, как правило, 2-3-х недельные. Перед началом спринта команда сама формирует список фич на итерацию, далее запускается спринт.

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

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

Вот вы заказываете в Москве на Кутузовском новую Toyota Camry на «максималке», и для вас уже делают зеркала в козырьке (вы выбрали «максималку» как раз из-за зеркал в козырьке). Важный момент тут — мы можем менять приоритеты в любой момент. Мы очень быстро можем переключать станок в другой режим.

Основная разница между Scrum и Канбан — в длине итераций. В Scrum итерации — 2 недели, в Kanban задачи программисту можно «подсовывать» хоть каждый день.

Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Вчера вы залили на прод новую фичу, а сегодня получили данные с передовой и узнали, что вот эта штука не работает так, как было задумано — люди не нажимают кнопку «купить». Вы «даете по шапке» UX, он дает вам новые требования. Вы поднимаете наверх очереди эту задачу, программист берет эту задачу «сверху», выполняет ее и, к вечеру fix уже на проде, конверсия в платежи выросли на 12%. Это победа.

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт. Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.

В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.

Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей. Например, у вас есть колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для задачи будет равен deployed-developing, то есть сколько времени прошло от момента, когда задачу начали делать до момента пока она попала в deployed.

Итак, в Scrum наша цель — закончить спринт, в Kanban — задачу.

Scrum — это автобус, который останавливается лишь на определенных остановках, где люди выходят группами. А Kanban — это маршрутка: захотел пассажир выйти, попросил водителя и вышел там, где ему нужно.

Что интересного в Kanban позволяет удачно использовать его и в спринтах? Рассмотрим на примере инструмента для управления проектами Hygger.io.

WIP

Во-первых, это WIP (Work in progress). Мы ставим ограничение на число задач, которые может одновременно делать один сотрудник. Выполнять несколько задач одновременно могли только Наполеон и Цезарь. Мы знаем, как они закончили. Поэтому мы бережем своих людей и спасаем от выгорания: они делают только одну задачу в единицу времени.

А если серьезно, то переключение «с задачи на задачу» у программиста в среднем занимает 15 минут. Пока сделаешь чай, пока полистаешь Habr, прочитаешь требования к новой задаче, вспомнишь где ты остановился и найдешь место в коде. Каждое переключение — это выход из потока, а войти в поток не всегда получается — могут мешать внешние раздражители. Поэтому все строго: одна задача на сотрудника. Как мы это контролируем? Вот здесь должно быть понятно:

Когда мы впервые внедряли Kanban, WIP лимиты сразу же показали узкие места в нашем процессе: в колонке Testing скапливалась большая очередь задач  —  наш тестировщик не справлялся с проверкой задач. Задачи очень долго находились в очереди. В итоге, программисты успевали подзабыть задачи, которые им переоткрывал тестировщик спустя неделю или две. Раз забыли, значит надо смотреть код и вспоминать, о чем там шла речь, снова погружаться в детали. Это все издержки, которые понижали наш КПД. Тогда мы подключили на проект еще одного QA и проблема была решена.

Swimlanes

Во-вторых, это Swimlanes. Представьте себе, что у вас «лег» сайт. Как это часто бывает — в рабочее время. Вы делегируете задачу вашему лиду или devops – «Поднять сайт сию же минуту». А он сейчас делает другую задачу и планирует ее закончить завтра после обеда. Что делать? Бежать к нему и умолять переключиться на блокера? Можно, но так вы скоро получите прозвище «черный лебедь». Поэтому мы используем Swimlanes.

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

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

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

Sub-columns

У вас есть колонка Программирование, а за ней – Тестирование. Когда программист закончил задачу, он ее переносит в Тестирование. И получается, что тестировщик как-бы начал тестировать задачу. Но, на самом деле, тестировщик проверяет другую. Да и вообще, вы поставили ограничение WIP на число задач и после того, как программист перенес задачу на тест, у QA нарушен этот лимит. Стало две задачи.

Допустим, программист не будет переносить задачу на Тестирование и оставит ее в Программировании. Но как ему брать следующую задачу, если у него есть WIP лимит, который он не может нарушить. В таком случае, на помощь приходят Sub-columns. Например, для колонки Программирование делаем под-колонки In progress и Done. И когда программист заканчивает задачу, он переносит ее в Done. Когда тестировщик освободится, он возьмет новую задачу из под-колонки Done колонки Программирование и перенесет ее в свою колонку Тестирование.

Заключение

Подводя итоги, хочу отметить, что Scrum — гибкая методика разработки, а Kanban — еще более. Всему свое время и место. Если это разработка нового продукта, то на старте разработки и до релиза лучше использовать Scrum, так как он делает разработку более контролируемой по срокам. Также в Scrum много коммуникаций в команде: ребята обсуждают весь бэклог спринта перед стартом, задают вопросы авторам задачи (UX, продакт-менеджерам, бизнес-аналитикам), оценивают задачи сообща с помощью Planning poker. Scrum помогает детально погрузить команду в суть продукта.

А после релиза продукта начинается совсем другая жизнь: начинает идти обратная связь от пользователей продукта, нужно быстро на нее реагировать. Вы начинаете работать над HADI циклами — вам нужно постоянно проверять различные гипотезы, где на гипотезу может банально влиять цвет кнопки. Вы начинаете измерять и оптимизировать метрики продукта, например, Pirate Metrics (AARRR) и так далее. Все увеличивает ваш цикл разработки, вы начинаете делать много маленьких задач в непредсказуемой последовательности. И для этого как раз идеально подходит Kanban.

Какую бы из Agile-методологий вы не выбрали, вы можете качественно реализовать ее с помощью платформы для управления проектами Hygger.io.

А на чем вы остановили свой выбор: Scrum и Kanban? Делитесь своими примерами и наблюдениями в комментариях!

основных различий между Agile и Scrum (вы должны знать)

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

Гибкий

Agile-менеджмент представляет собой различные методологии разработки программного обеспечения, на которые повлияла итеративная и инкрементная разработка, включая экстремальное программирование (XP), Rational Unified Process (RUP), Scrum и другие.Гибкий процесс или методы создают среду, в которой происходит постоянная эволюция требований и эволюция в результате сотрудничества между самоорганизующимися кросс-функциональными командами. Гибкие методологии способствуют дисциплинированному подходу к управлению проектами, который поощряет набор передовых методов, позволяя быстро предоставлять высококачественное программное обеспечение и улучшая бизнес-подход, который согласовывает разработку с потребностями клиентов. Методологии Agile отличаются от традиционной водопадной методологии, где все требования изначально анализируются и документируются до начала разработки.В Agile-подходе требования подобны фактическому прогрессу в разработке программного обеспечения на каждой итерации. Такой подход обеспечивает гибкость при адаптации к изменениям требований и приоритетов бизнеса.

Также известный как Манифест для гибкой разработки программного обеспечения, Agile-манифест — это формальная декларация 4 ключевых ценностей и 12 принципов, поддерживающих итеративный подход к разработке программного обеспечения. Методология гибкой разработки позволяет оценивать направление проекта на протяжении всего жизненного цикла разработки.Это достигается за счет регулярных итераций, и когда переоценка выполняется на каждой итерации, это значительно сокращает затраты и время на разработку. Agile помогает компаниям создавать правильный продукт. Преимущества Agile:

Для клиентов

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

В интересах продавцов

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

Качество

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

Видимость

Методология

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

Контроль затрат

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

Управление рисками

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

Скрам

С другой стороны,

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

Простота

Разработка в Scrum осуществляется спринтами, которые длится 1, 2 и 3 недели. Команда Scrum состоит из:

1. Владелец продукта: Основная обязанность владельца продукта — максимизировать ценность продукта и работу команды разработчиков.В дополнительные обязанности входит управление каталогом товаров.
2. Scrum Master: Команда разработчиков состоит из самоорганизующихся профессионалов, которые в конце каждого спринта превращают каталог продуктов в приращение продукта.

Команда разработчиков

3. : Скрам-мастера следят за тем, чтобы команда Скрама соблюдала теорию Скрама и ее правила.

Гибкость

В традиционной каскадной модели, когда бизнес-требования и технические требования задокументированы и детализированы, это приводит к бесконечной документации.Скрам использует пользовательские истории для описания функций, которые необходимо разработать. Инструмент под названием Pivotal Tracker используется для хранения этих пользовательских историй в бэклоге. Если необходимо внести изменения или возникает необходимость добавить в пользовательские истории, в этом случае команда может внести изменения уже в следующем спринте. Это позволяет бизнесу изменить свое мнение, а команде разработчиков быть достаточно гибкой, чтобы приспособиться к этим изменениям. Способность приспосабливаться к изменениям — мощный атрибут методологии Scrum.

Коммуникация и сотрудничество

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

1. Владелец продукта, Скрам-мастер и команда разработчиков ежедневно тесно сотрудничают.
2. Проводятся встречи по планированию спринтов, что позволяет команде разработчиков организовать свою работу на основе знаний, полученных из бизнес-приоритетов.
3. Проведение ежедневных схваток, на которых команда разработчиков может отчитаться о проделанной работе, ее будущих перспективах и решить проблемы, если таковые имеются.
4. Проведение обзоров спринтов позволяет членам команды оценивать свою прежнюю работу, рекомендуя лучшие практики для каждого спринта.

Подробнее о различиях Agile и scum

,

Agile Vs Scrum: узнайте разницу

• Home

• Testing

  • • Back
    • Agile Testing
    • BugZilla
    • Cucumber
    • Database Testing

    9000 J4 9000 9000 J4000 Тестирование базы данных

    9000

    • Назад
    • JUnit
    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • Quality Center (ALM4000 RPI)

    9000

    • Управление тестированием
    • TestLink

• SAP

  • • Назад
    • ABAP
    • APO
    • Начинающий
    • Basis
    • BODS
    • BI
    • BPC
    • CO
    • Назад
    • CRM
    • Crystal Reports
    • QMO

    Заработная плата

    • Назад
    • PI / PO
    • PP
    • SD
    • SAPUI5
    • Безопасность
    • Менеджер решений
    • Successfactors
    • Учебники SAP
  • 8

  Apache

  • AngularJS
  • ASP.Net
  • C
  • C #
  • C ++
  • CodeIgniter
  • СУБД
  • JavaScript
  • Назад
  • Java
  • JSP
  • Kotlin
  • Linux
  • Linux
  • Kotlin
  • Linux

  js

  • Perl
  • Назад
  • PHP
  • PL / SQL
  • PostgreSQL
  • Python
  • ReactJS
  • Ruby & Rails
  • Scala
  • SQL

  000

  0004 SQL

  • UML
  • VB.Net
  • VBScript
  • Веб-службы
  • WPF