У кого спринт не работает

Scrum — реальный опыт работы по методологии

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

Для организации процесса работ над проектом мы решили выбрать популярную методологию Scrum. Отчасти это дань моде, отчасти большое количество публикаций в сети Интернет на тему «Scrum сделал за нас все!».

Какие роли есть в Scrum

С чего обычно начинается разработка программного обеспечения? С идеи: «Как было бы замечательно, если бы у меня было некое ПО, которое делало бы примерно вот это. Было бы просто супер!» Человека, который в команде будет представлять эту идею, называют Product Owner (PO) или Владелец продукта. Product Owner – это тот, кто видит цель продукта или кому кажется, что он видит цель продукта, но важно то, что он может ее сформулировать и начать процесс движения к ее достижению. Цель он формирует в виде списка своих пожеланий (хотелок). Этот список называется Product Backlog Items (PBI). Он постоянно модифицируется в зависимости ситуации на рынке или от разрастающегося аппетита Product Owner’a.

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

Что такое спринт и зачем он нужен

ProductOwner сформулировал свою цель в виде некого пункта B, который нужно достичь, начав движение с пункта A. Но пункт B – это не точка, в которую можно попасть, просто нарисовав прямую линию между ней и пунктом А. На самом деле пункт B это окрестность точки, и радиус ее может варьироваться.

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

Как формируется список задач на спринт

В команде спринт длится 2 недели. За неделю ничего не успевается, за месяц все забывается. Поэтому 2 недели для нас самый оптимальный вариант. Первый день спринта уходит на планирование. На ранних этапах на планирование уходило даже 2 дня. Планирование – это процесс, при котором команда берет из списка требований наиболее приоритетные и разбивает на задачи, которые позволяют достичь результата. Каждая задача оценивается в часах. Желательно, чтобы задача не занимала времени больше, чем 4 часа. Если участник команды говорит, что сделает задачу за 5 дней, значит, он понятия не имеет, что нужно сделать.
Общее количество часов в спринте на каждого человека рассчитывается из того, что спринт длится 2 недели или 10 рабочих дней. Это 80 часов минус один день на планирование. Итого 72 часа. Но это идеальные часы. Это значит, что человек ни на что не отвлекается, не ест, не пьет, с места не встает, а только работает и не устает. Во время планирования задача оцениваются в идеальных часах. Но набирается для человека не 72 часа, а 72 часа, умноженные на некий коэффициент, который называется производительностью команды. Обычно это 0.5. Удивительно, но это какое-то магическое число, именно при нем весь спринт сдается успешно. Кто-то из великих сказал: «Возьмите время, которые назвал вам разработчик, умножьте его на два и еще немного прибавьте и получите срок, за который вам программист выдаст результат». И это действительно так.
В Scrum есть несколько рекомендаций в отношении того, как исполнителю оценивать время на задачу. Например, играть в покер. Но мы этим не грешим. Что бы там не говорили, но если какой-то модуль начал делать кто-то один, то он его и будет продолжать наращивать из спринта в спринт. И только он может оценить, сколько ему нужно времени на выполнение задачи. Единственные, кто ему может помешать завысить сроки, это его совесть (помните про самоорганизацию) и ScrumMaster.

Как проверить, что требование ProductOwner’а выполнено

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

Главное требование – тесты должны быть очень подробными.

Что происходит во время спринта

Начинается процесс исполнения спринта. Главная его цель – добиться, чтобы тесты, предъявляемые к требованиям, к концу спринта выполнялись.
Для сплоченного движения команды к цели Scrum предлагает делать ежедневные митинги. Митинг – это когда каждый, стоя у доски с маркером, вычеркивает то, что он сделал вчера и пишет то, что он собирается сделать сегодня.

Это очень мощная практика. Благодаря ей каждый знает, куда движется проект в целом. К тому же когда человек, рассказывает, что он будет делать сегодня, то он автоматически координирует свои действия с другими участниками. Другие участники могут тут же предложить лучшие решения задачи. А еще написанная на доске задача, а по сути — это обещание всем своим коллегам, очень хорошо мотивирует самого исполнителя. Единственное, ScrumMaster не должен забывать объявлять, что начался митинг.
Митинги проводить желательно стоя и длительностью не более 15 минут. Мы начинаем митинги в 9 утра.

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

Наступает долгожданный конец спринта, обычно это пятница в 16:00, и команда сдает спринт Product Owner’у и всем-всем, кто заинтересован в продукте. Каждый отчитывается по задачам, которые выполнял и рассказывает о том, каких успехов достиг, а также объясняет причины, по которым не удалось достичь цели. Главное правило — никогда не переносите срок сдачи спринта.
Иногда после сдачи спринта делается анализ того, почему что-то происходит или не происходит, и что нужно предпринять, чтобы исправить ситуацию.
А в понедельник все повторяется сначала.

Накопленный опыт

Мы для себя выработали несколько правил, несоблюдение которых приводило к провалу спринта:
• Спринт надо планировать детально, не жалея на это сил. Если что-то из требований непонятно, то надо прояснять требование. Если это не удается сделать, то не надо брать задачу в спринт, а требование отправлять на доработку.
• Ни при каких условиях не брать дополнительные задачи, которые идут вне спринта. А если все-таки «навязали», то согласовать с Product Owner’ом, что будут удалены из спринта другие задачи.
• Количество человек в команде не должно превышать 5-6 человек. Когда наша команда выросла до 16 человек, митинг начал затягиваться на 2 часа. Ввели фиксированное время выступления для каждого и стояли с секундомером. Но тогда человек не успевал донести свою мысль, и митинг превращался в формальность. Поэтому мы просто разделились. Сначала поделились на клиентщиков и ядерщиков, а потом начали делиться по задачам. Т.е. каждая команда делает свою фичу, и в этой подкоманде есть как клиентщики, так и ядерщики. Этот подход используется до сих пор, и для нас он наиболее эффективен.

Вывод

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

Кто мы?

Команда, в которой я работаю, называется «Юниклауд Лабс». Это дружный коллектив интересных людей, реально болеющих за свое дело.

Вариков Андрей VAndrey
Технический директор ООО «Юниклауд Лабс»

Источник

Работа с неудачными спринтами и сроками

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

Это выглядит великолепно с точки зрения разработчика, однако, допустим, у нас есть компания-разработчик программного обеспечения » Scrum-Addicts LLC «, разрабатывающая что-то для серьезных клиентов (» Money-Bags Corporation «):

1. Менеджеры Scrum-Addicts предлагают создать программное обеспечение для Money-Bags
2. Они согласовывают список функций, а Money-Bags просит указать дату доставки.
3. Менеджеры Scrum-Addicts консультируются со своей командой Scrum, и команда говорит, что для выполнения всех функций потребуется 3 недельных спринта
4. Менеджер Scrum-Addicts добавляет 1 неделю, чтобы быть в безопасности, обещает отправить программное обеспечение через 1 месяц и подписывает контракт с Money-Bags
5. После 4 спринтов (срок поставки) команда Scrum может предоставить только 80% функций (из-за неопытности в новой системе, необходимости исправления критических ошибок в предыдущих функциях в производственной среде и т. Д.)
6. Как предполагает Scrum, на данный момент продукт потенциально может быть отправлен, но Money-Bags требуется 100% функций, как указано в контракте. Поэтому они нарушают договор и ничего не платят.
7. Scrum-Addicts находится на грани банкротства, потому что они не получили денег от Money-Bags, а инвесторы были разочарованы результатами и не хотят больше помогать компании.

Очевидно, что ни одна софтверная компания не хочет быть в шкуре Scrum-Addicts. Что я не понимаю в Agile и Scrum, так это то, как они предлагают командам решать вопросы планирования и сроков, чтобы избежать ситуации, описанной выше. Итак, подведу итог, у меня есть 2 вопроса:

Кто виноват?

1. Менеджеры, потому что это их работа, чтобы сделать правильное планирование
2. Команда, потому что они сделали больше, чем могли
3. Кто-то еще

Что нужно сделать?

1. Менеджеры должны сдвинуть крайний срок в 2 раза (или в 3 раза) позже, чем исходная оценка команды.
2. Следует побуждать членов команды выполнять всю работу, которую они выполняли, несмотря ни на что (назначая штрафы за неудачные спринты).
3. Команда должна отказаться от Scrum, потому что это не соответствует политике крайнего срока компании
4. Мы все должны отказаться от разработки программного обеспечения и присоединиться к монастырю
5. .

Я вижу несколько фундаментальных проблем управления в вашем примере:

если менеджер Scrum-Addicts подписывает контракт с «жестким сроком», но добавляет запас прочности в 33% в ситуации, когда «задействована новая система», это довольно безрассудно.

доступность предоставления как минимум x% функций через один месяц могла бы использоваться для согласования контракта, когда клиенты платят деньги хотя бы частично, когда он получает только 80% функций в установленный срок. Договор «все или ничего» — это то, от чего не выиграет ни поставщик программного обеспечения, ни покупатель — это означает не только 0 денег для поставщика, но и 0 функций для клиента. А методология разработки «все или ничего», такая как «Водопад», позволит вам писать такие контракты, а гибкий подход открывает дополнительные возможности.

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

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

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

Тот факт, что Scrum-Addicts LLC договорились о заключении договора, а не о сотрудничестве с клиентом, заставляет меня усомниться в их гибкости.

Ясно одно: ловкость должна приниматься КАЖДЫМ. Ловкость не только для разработчиков. Менеджеры и клиенты также должны принять ценности Agile Manifesto. Если клиенты не принимают гибкость и все еще требуют жестких контрактов и минимального сотрудничества, то либо не используйте гибкость, либо найдите лучших клиентов.

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

Менеджеры, юридический отдел, бухгалтеры — выбирайте сами .

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

Клиенты хотят иметь свой пирог и есть его — они с радостью принимают водопад, мини-водопад, ловкий, ла-ла-ланд, если они получают продукт X за $ Y к дате Z.

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

ИТ-проекты имеют дело с неизвестными ; некоторые из этих неизвестных даже неизвестны . Что это обозначает?

Возьмите, например, игрушечный мост для вашей модели железной дороги. Есть все известные вам параметры:

Вы знаете, насколько велика долина

Вы знаете материал гор, их высоту, устойчивость и т. Д.

Вы знаете, сколько материала вам нужно

Вы знаете из более ранних «проектов», сколько времени у вас ушло на создание подобных вещей

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

Сделайте пример еще дальше:

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

Скажем, у вас нет информации о модели ландшафта

Информация о ландшафте состоит из двух гор, которые кажутся не слишком большими

Последовательность горы между камнем и желе

Общая стоимость составляет максимум 10 $

На рабочем месте совершенно темно и нет шансов на свет: у вас есть только коробка из 8 спичек

Срок исполнения 3 часа

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

Каждая ИТ-компания должна знать это. Им приходится иметь дело с проектным риском.

1) Есть несколько способов минимизировать (финансовый) риск: сделка может включать в себя то, что клиент платит за каждый рабочий прирост. Таким образом, после получения приращения 1 необходимо оплатить частичную ставку. Пока Scrum-Addicts LLC поставляет, существует минимальный финансовый риск. Чем более детализированы цели спринта , тем ниже общий риск каждого спринта. Это означает, что если корпорация Money-Bags получила 80% контракта, они должны как минимум заплатить 80% стоимости контракта. Если они отказались платить после неудачного спринта, риск не так высок, как отказ платить 100%.

2) Scrum-Addicts LLC имеет проблемы со своими разработчиками

Менеджеры Scrum-Addicts консультируются со своей командой Scrum, и команда говорит, что для выполнения всех функций потребуется 3 недельных спринта. Менеджер Scrum-Addicts добавляет 1 неделю, чтобы быть в безопасности, обещает отправить программное обеспечение через 1 месяц и подписывает контракт с мешками денег

Это говорит о том, что а) разработчики не разбираются в схватках или б) они неправильно разбираются в схватках. Чем дольше команды работают со скрамом, тем лучше их оценки. Если команды делают оценки, а менеджер добавляет «буфер» как «безопасность», менеджер, кажется, знает лучше, чем команда, что является плохим признаком . Если у вас есть опытная команда, вам не нужен «менеджерский буфер», команда включила его в оценку. Идея в том, что чем больше спринтов работало вместе, тем больше команда знает свои сильные и слабые стороны и имеет некоторые метрики для реалистичных оценок. Конечно, есть, как уже упоминалось, неизвестные неизвестныекоторые, как правило, затрудняют оценку; или хотя бы неточным. Но в конечном итоге оценки должны становиться все лучше и лучше.

Кто виноват?

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

Даже если руководство совершенно глупо, команда должна была выступить против такого проекта. Хороший менеджер должен знать риски; но хороший разработчик должен указывать на риски. И самое главное: команда должна сообщить рано, если что-то не получается.

Что нужно сделать?

Сейчас: возьмите денежные мешки в суд

На будущее: не заключать такие контракты

Скрам не виноват в провале управления. Scrum был разработан на основе опыта многих неудачных ИТ-проектов. Это не может предотвратить неудачу и не может вылечить некомпетентность команд или руководства. Основная идея:

структурировать способы общения (кто с кем разговаривает, когда о чем)

поощрять неудачу отчетности разработчика рано

разделять задачи на задачи и подзадачи

структурировать время и возможности (кто работает, когда над чем)

распределить задачи по временным интервалам

сделать непредсказуемое немного более предсказуемым (планирование покера)

или в целом: минимизировать риск.

Скрам — это инструмент, как молоток. Является ли это хорошим инструментом, зависит от ваших знаний, как его использовать. Но иногда отвертка подходит лучше. Тебе решать.

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

Лучший способ посмотреть на это: «Что вызвало задержку?». Был ли это недостаток опыта в технологии? Критические ошибки, которые не были обнаружены при тестировании / QA? Отсутствие тестирования / QA? Слишком оптимистично оценивать? Не принимая во внимание не очень оптимистичные оценки команды? Кто-нибудь попал под автобус? Какой бы ни была причина, следующий вопрос — «Как мы можем быть уверены, что это больше не повторится?». В некоторых (надеюсь, редких) случаях ответом может быть «избавиться от таких-то», но если вы начнете с «Мне нужно наказать того, кто несет ответственность», вы вряд ли увидите большинство случаев. где это не правильное решение.

В рамках проекта вы уже утонули. Срок пришел и ушел, вы предупредили клиента, как только стало очевидно, что он собирается проскочить (потому что вы это сделали, верно? Если нет, это часть проблемы), и теперь это нужно обрабатывать, как бы оно ни было прописано. в договоре (это на самом деле прописано в договоре, верно?). Вообще говоря, это должно включать переговоры с клиентом о том, как вы собираетесь доставить недостающее. Многим людям нравится думать о контракте как о чем-то, что нельзя изменить, но сталкивается либо с: а) отказом от контракта и отсутствием того, что вы купили, б) предъявлением иска компании за нарушение контракта и потерей большого количества денег в суде, и в) переговоры о том, как получить свой продукт с наименьшим количеством возможных проблем, большинство компаний выбирают в.

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

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

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

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

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

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

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

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

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

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

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

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

То, как вы «наказываете» такое поведение, ограничивает объем работы, которую те, кто не закончил, могут выполнить в следующем спринте. Шансы поработать над классными вещами исчезают. Награда за хорошую работу — больше работы.

Это выглядит великолепно с точки зрения разработчика, однако, допустим, у нас есть компания-разработчик программного обеспечения «Scrum-Addicts LLC», разрабатывающая что-то для серьезных клиентов («Money-Bags Corporation»):

Менеджеры Scrum-Addicts предлагают создать программное обеспечение для Money-Bags. Они согласовывают список функций, и Money-Bags просит предоставить дату отгрузки. Менеджеры Scrum-Addicts консультируются со своей командой Scrum, и команда говорит, что это займет 3 недели. -длинные спринты для выполнения всех функций Менеджер Scrum-Addicts добавляет 1 неделю для обеспечения безопасности, обещает отправить программное обеспечение в течение 1 месяца и подписывает контракт с Money-Bags После 4 спринтов (крайний срок доставки) команда Scrum может предоставить только 80% функций (из-за неопытности с новой системой, необходимости исправления критических ошибок в предыдущих функциях в производственной среде и т. д.). Как предполагает Scrum, на данный момент продукт потенциально может быть отправлен, но Money-Bags требуется 100% функций, как указано в договоре. Поэтому они нарушают договор и ничего не платят.

Scrum-Addicts находится на грани банкротства, потому что они не получили денег от Money-Bags, а инвесторы были разочарованы результатами и не хотят больше помогать компании.

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

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

Подумайте, ПОЧЕМУ МБ хочет забрать свой мяч и пойти домой. МБ не требовал, чтобы работа была сделана в течение месяца с самого начала. SA обещал 100% критических функций в течение одного месяца и не поставил. SA устанавливает срок не МБ. SA даже произвольно добавил неделю к крайнему сроку. Так почему же это срок?

Иногда, конкурируя за работу, компании-разработчики программного обеспечения поддаются искушению выпендриться и пообещать луну. Профессионалы тщательно устанавливают, нужна ли вообще луна. Что является наиболее важной потребностью в MoneyBags? 100% функций или функционирующий продукт через месяц? Они даже знают, что действительно важно? Есть ли какое-то предстоящее событие, устанавливающее жесткие сроки?

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

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

Итак, подведу итог, у меня есть 2 вопроса:

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

Любой мог остановить эту пародию до того, как у нас будет месяц.

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

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

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

Менеджеры должны сдвинуть крайний срок в 2 раза (или в 3 раза) позже, чем исходная оценка команды.

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

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

Следует побуждать членов команды выполнять всю работу, которую они выполняли, несмотря ни на что (назначая штрафы за неудачные спринты).

Члены команды должны быть поощрены. Не удалось, совершено или иным образом. Вместо того чтобы строить какие-либо искусственные последствия, такие как наказания или даже бонусы (кнут и пряник), исследования показали, что люди, занимающиеся творческой работой, такой как программирование, лучше всего реагируют, если им предоставляются три вещи: Автономия, Мастерство и Цель.

Даниэль Пинк говорит об этом TED . Речь идет о не гибкой мотивации, но я легко увидел, как сопоставить эти точки с гибкой:

Автономия — я хочу руководить собственной жизнью — позвольте мне выбрать работу из отставания.
Мастерство — я хочу стать лучше в чем-то важном — Отзывы клиентов.
Цель — я хочу быть частью чего-то большего, чем я — Совместная команда.

Команда должна отказаться от Скрама, потому что это не соответствует политике крайнего срока компании. Скрам может уложиться в срок более точно, чем водопад. Учитывая крайний срок схватки можно встретить его. Он может соответствовать только 1 из 47 функций в зависимости от времени, возможностей и навыков, но может соответствовать.

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

Мы все должны отказаться от разработки программного обеспечения и присоединиться к монастырю

Точно так же, как если бы меня заперли в комнате подальше от реальной жизни, это заставило бы меня писать МЕНЬШИЙ код.

Я отредактировал этот ответ до размера. Если вам интересно читать историю редактирования.

Источник