Вместо того, чтобы представить За последние 3 года работы мне довелось поработать на самых разных должностях: исследователем, разработчиком и руководителем проекта.
Существуют разные стили управления: западный (когда в коллективе предоставляется большая свобода и многое строится на доверии, уважении, личной организованности личности) и восточный (когда каждое промедление карается, сроки строго фиксированы, железная дисциплина команда находится в авангарде и если человек не достигает поставленных целей – происходит расставание).
Менеджер проекта должен совмещать эти два элемента: яблоко и палку, подпускать к вам людей, чтобы разработчики вам доверяли, но и сохранять субординацию, поскольку отношения есть отношения, и нацеленность на результат должна быть всегда.
Но гораздо важнее: как вы двигаетесь к своей цели, как вы организуете свой рабочий процесс.
В этой статье я хотел бы поделиться с уважаемой публикой одной из наших непрофессиональных видеолекций, которую мы сняли для себя.
Думаю, в каждой команде наступает момент, когда что-то может пойти не совсем так, как хотелось бы.
Я хочу внести некоторые изменения, и лучше начать с себя.
Как говорится, если хочешь изменить мир, то начинать следует в первую очередь с себя и своего ближайшего окружения.
Для удобства я сделал к видео субтитры, чтобы было удобнее смотреть.
Отмечу лишь, что это не профессиональная видеолекция и лектор специально нигде не преподает эту методику.
Дина Насырова (Тим Лидер из Fujitsu) пришла к нам в знак уважения, чтобы помочь улучшить процесс работы команды, а заодно поделилась собственным богатым опытом.
Встреча состоялась год назад – с тех пор утекло много воды.
Но спустя некоторое время я все еще ее вспоминаю, потому что информация, изложенная в ней, мне очень пригодилась.
Полная стенограмма видеолекции (субтитры)
Дина: Откуда все это взялось? Посидели, попили чаю и узнали, что нужен менеджер проекта.Теги: #scrum #scrum #agile #лидер команды #управление проектами #методология #управление проектами #управление командой #управление стартапами #agileВерно? Команда: Да! Дина: Поэтому я спросил: «А ведь оно тебе точно нужно, даЭ» И я пообещал приехать и прочитать лекцию.
Как я вижу, что такое Scrum и как можно развиваться без начальника.
Кто-нибудь из вас знает, что такое Scrum? Команда: Я читаю.
Виктор дал ссылку.
Записки с передовой Дина: Итак, короче, я здесь тоже разместил ссылку на эту книгу.
С моей точки зрения, это одна из лучших подобных книг, без лишних подобных вступлений — зачем этот Скрам, бла-бла-бла.
Вы просто берете его, как инструмент, да, и применяете.
Вот почему она мне нравится.
На основе этого я сделал эту небольшую презентацию.
Я сам, конечно, тоже читал Генри Книберга и только эту книгу.
Этой книги действительно достаточно, чтобы вы начали.
Зачем разработка без начальника, правда? Потому что — по сути, такое понимание, как тимлид или руководитель проекта или кто-то в такой роли, стоящий наверху, — да, а с такой палкой — нет. И это (показывает) делает это мотивацией, да.
Представляете, какая будет мотивация? Я покажу вам на картинке (рисует).
Такой сотрудник — осел.
Похоже на осла, да? Как его можно мотивировать? Вот так можно добавить немного моркови.
Побежит ли он вперед? Он, наверное, побежит, да? Есть еще один способ мотивации.
Такой волшебный удар.
Побежит ли он вперед? Он побежит. Есть и другой вид мотивации, когда такая морковка мотивирует его изнутри.
Оно горит внутри человека.
С моей точки зрения, самая правильная мотивация.
Но я отвлекся, на самом деле речь вообще не об этом.
Дело в том, что если программисты достаточно зрелые, команда сформировалась, то эта штука сверху с палкой нужна как вариант, по сути.
И сейчас я вам расскажу, как можно распределить ответственность внутри команды так, чтобы разработка шла максимально быстро и, соответственно, все были довольны.
Итак, Роберт Челдини рассказывает о том, кто такой скрам-мастер и просто о команде.
Кстати, сколько вас там сейчас? Команда: Нас.
Ну 9. И 5 из них программисты.
Дина: 5-6 программистов.
Это, в принципе, команда — самый идеальный вариант Scrum. Потому что 4 как-то непонятно, да.
4 человека всегда могут договориться.
И никакой методологии не нужно.
А 10 это уже много.
Потому что я знаю это по себе.
Вы больше не видите человека, который находится рядом.
Ты не обращаешь внимания.
Вам нужно записать все, до последней буквы, как вы будете развиваться.
Почему - возьмет ровно столько и скажет - смотри - вот заказчик.
Будет ли это работать так? Это то, что вам нужно, верно? Заказчик скажет, ну, наверное, это то, что мне нужно, и вы садитесь это разрабатывать.
Приходите к вам в помещение и проектируйте.
Через шесть месяцев вернитесь и скажите «да».
Мы работали, разрабатывали и тестировали.
Заказчик говорит — ну это конечно круто, но мне это, наверное, не очень-то и нужно.
В этом больше нет необходимости.
А ты говоришь: ну, смотри.
Мы с вами согласились? Вот о чем мы договорились – вот что мы сделали.
Это модель водопада.
Сначала собираются требования.
Тогда вам придется их одобрить.
Ребята, как ваш английский? Должен ли я перевести? Требования - согласование с заказчиком.
Дальше значит разработка, потом тестирование и все — на этом разработка заканчивается.
В то же время, что произошло с заказчиком за эти полгода? Может быть, у него вообще все изменилось – вас это совершенно не касается? Заплатил, дал хороший аванс - нормально.
Есть такая вещь, как Scrum, верно? Почему он? Мне кажется, в вашем случае это оптимальная модель.
Потому что это итеративная разработка.
Это всё херня (показывает), да? Это происходит много, много, много, много раз в течение жизни и развития.
Почему – потому что на самом деле все может измениться – особенно для тебя.
Да, заказчик почесал репу, пришел и сказал — блин, я нашел такую классную штуку.
Давайте реализуем это.
Оцените это здесь.
И Scrum именно для таких команд и для таких быстро развивающихся и меняющихся проектов.
Когда заказчик в принципе может играть с ценой проекта.
Да? То есть он может понять.
сейчас я вам лучше покажу.
Начнем, да.
С чего начинается Скрам? Scrum начинается с создания журнала невыполненных работ по продукту.
По сути, это список требований заказчика.
Вы усаживаете его перед собой и говорите – давай скажем ему, что тебе нужно.
Конечно, в этой книге сказано по-другому, но с моей точки зрения требования должны выглядеть именно так.
Пользователь что-то делает, а система как-то реагирует. То есть пользователь входит в систему и вводит пароль для входа.
Система его аутентифицирует или говорит, что логин-пароль неверный.
Это похоже на пользовательскую историю.
И оно должно быть сформулировано именно с точки зрения заказчика — это бизнес-история, не должно быть так, что подключиться к базе данных и использовать такой храм — это не правильно — это про бизнес-желания, с классическим продуктом.
Он лукаво улыбается – громко кричал, что он в команде, а на самом деле (показывает на руководителя проекта).
История пользователя.
После этого эти пользовательские истории записываются.
Для каждого из них необходимо сделать стандартный идентификатор.
У каждого из них должно быть имя, именно в таком виде, что пользователь заходит, а система как-то реагирует. Важность, первоначальная оценка - первоначальная оценка, скажем так, да.
То есть примерно сколько времени это может занять, очень приблизительно.
Как продемонстрировать.
Пользователь заходит, авторизуется и видит результат и всякие разные заметки.
И это будет выглядеть примерно так.
Я взял это из книги.
Вот это мне не очень нравится (рисует).
Но это тоже лучше, чем никак.
Да, это то, что мы делаем, чтобы воссоздать.
Мы сидим перед собой владельца продукта и записываем каждый список пожеланий.
Затем мы все садимся вместе.
Мы делаем приблизительную оценку нашей проблемы, а затем просим его указать на важность.
Важность от 50 до 150, каждая задача: какая самая важная, какая не самая важная.
Зачем – чтобы выдрать только самое важное.
То есть сначала делаем только самое важное.
А потом все остальное, не важное, и тогда его можно и вовсе выбросить.
Ясно? Есть вопросы? Итак, у нас есть отставание по продукту.
Мы потратили несколько дней и все соки от заказчика сохранились.
То, что он сделал с нами, было для того, чтобы указать на важность.
Что мы делаем дальше? Стоит рассказать вам о первом спринте.
Но я хочу поговорить о, знаете о чем? Где должна сидеть команда, как она должна сидеть – как вы думаете? Значит, она может сидеть где угодно? Должны ли они быть рассажены по отделам? Надо посадить всех вместе, убить себя, но посадить всех вместе.
То есть люди должны видеть друг друга.
Скрам-мастер в принципе может вообще не прийти на встречу.
Команда : Можно вопрос - работаю ли я удаленно.
Дина: Ну, с этим тоже можно работать.
Кстати, в книге есть такой случай.
Ну понятно, что идеального мира не существует. А вообще было бы здорово, чтобы все увидели друг друга.
Просто у меня был и есть опыт – я вижу, как формируются команды.
То есть первая стадия – это совершенно разные люди.
Мы собираем их вместе, и они начинают шутить.
Пройдёт полгода – поедят и пойдут вместе.
Здесь начинается команда.
Это влияет и влияет, к сожалению, нужно понимать, что да - хочешь работать удаленно, хочешь работать из дома.
Команда: Да-нет, дело не в этом.
Я живу в другом городе.
По-другому это не работает. Дина: С этим можно жить, я говорю об идеальном случае, это не смертельно.
Где должен сидеть владелец продукта? Команда: На возвышенности наблюдайте за всеми.
Дина: На самом деле ему приходится работать с командой каждый день.
Оно должно быть в шаговой доступности.
Но не там.
То есть у него не должно быть возможности прийти и сказать – что ты здесь делаешь? Этого не должно случиться.
Он где-то рядом.
Но это не значит, что он и команда сидят на одном месте.
Так.
Мы создали наш портфель продуктов.
Вот наши задачи.
То есть, например, занимает 50 важности (часов, да?).
Но это не часы — а пользовательская история.
Что такое пользовательская история? Точнее, сюжетная точка.
Когда вы начинаете оценивать невыполненную работу по продукту, вы собираетесь вместе и определяете, сколько времени потребуется, чтобы реализовать это в идеальном мире.
В идеальном мире это как только ты приехал в 8 утра, ушел вечером в 6 часов, и все это время: ты не пошел есть, ты не пошел пить чай, ты не ходил общаться - ты просто работал.
Это называется Story Point и цена эта штука такая.
Это, скажем, 30, это 10. Это очень важно, это не очень важно.
И так далее.
Теперь нам нужно создать так называемый журнал отставания спринта.
Это то, что вы возьмете на первой итерации.
Помните, что мы занимаемся итеративной разработкой.
Одна итерация — это один спринт. Вы можете варьировать продолжительность спринта, то есть спринт может длиться неделю.
Это может быть месяц, три месяца – это в основном зависит от команды.
Вот чем хорош длинный спринт – как вы думаете? Команда: Вы можете замутить что-то большое.
Дина: Почему он плохой? Команда: Этот большой может быть слишком кривым.
Дина: Потому что мы могли не понимать, чего хочет от нас заказчик.
Мы делали это целый месяц, но оказалось, что это неправильно.
Ну и правильно – вам нужно найти максимально удобное для себя положение.
Бывает и так, что человек не поработал за 2 недели — вот он только взялся и спринт окончен.
Что делать? Команда: Можно ли сохранить задачу, если он ее не выполнил? Пусть это продолжается.
Но посмотрите, да.
Для чего вообще нужен Scrum? Дина: Именно для этого после каждой итерации.
Там была какая-то стройка.
Какая-то новая функция? Что можно показать.
А то, что не было выполнено, считается неработающим.
Команда: Но всякое может случиться.
Человек, например, заболел или просто не успел.
Что делать? Наверняка такие случаи бывали? Дина: Есть такие случаи.
Иногда люди тоже меняются.
Но.
Мы говорим о том, что в конце нам нужно что-то показать владельцу продукта.
Хорошо, мы покажем это немного меньше.
Никто не умрет. Другой вопрос, что у нас будет некоторая статистика того, что мы обычно выполняли за 1 спринт. 1 спринт, например, у нас занял — например, 280 часов.
Думали, что сделаем за 200. Допустим, сделали за 160. А в следующий раз захотели за 180 - но сделали снова за 160. В следующий раз планируем за 160. У нас есть история.
И это также дает нам возможность вполне серьезно планировать, гораздо серьезнее, чем в водопадной модели.
Но примерно зная.
Это 160, да.
Делим 160 на 200. И получаем определенный коэффициент фокусировки.
Это процент, вот как мы поступим.
Затем мы умножаем на эту цифру в Бэклоге Спринта.
И узнаём, что закончим через пару лет. Добавьте нас разработчиков - примерно так.
Итак, Sprint Backlog и мы берем эту историю и эту историю (показывает).
Для нас это как начало формирования Бэклога Спринта.
Мы делаем это на специальном планерке, который проводится в начале каждого спринта.
Это называется планированием.
Мы все собираемся вместе, смотрим, какие приоритеты.
И мы берем на себя эту задачу.
Как вы думаете, как следует называть владельца продукта? Он уже все сюда выложил.
Мне позвонить? Мы еще ничего не показываем? На самом деле у меня была возможность попробовать оба пути.
У нас был Product Owner, которого с нами вообще не было, и он сказал — ладно, я приеду на демо — что вы от меня хотите, это уже слишком.
Был один человек, который был с нами.
Тот, кто действительно был с нами - мы попросили его прийти на этот митинг и на этом митинге эти вещи пересматриваются (показывает).
То есть отставания очень приблизительные.
И здесь их можно пересмотреть.
Вот, например, 50, а на самом деле 60. И когда он это увидел.
И он сказал: ребята, мы с этим не договорились – почему так.
И вы начинаете объяснять здесь, здесь.
А он сидит и думает. Может быть, тогда это не сейчас.
И он забирает, например, вот эту вещь.
Вниз (показывает).
Так что же нам еще делать? При этом же планировании мы определяем цель самого спринта.
То есть, когда мы берем эти вещи, дело на самом деле очень сложное.
Для меня, пожалуй, самое сложное было.
Потому что вы выдираете все эти пользовательские истории.
Они могут быть не очень связаны друг с другом.
еще должна быть цель.
А ведь именно это и есть главная цель спринта.
Команда: Как разделить цели на маленькие? Дина: Я скажу вам сейчас.
Чуть позже, ладно.
После того, как мы определили цель, нам нужна цель, длина спринта, так как все это мы покажем через 2 недели, через 3 недели.
Затем нужно определить время ежедневной встречи.
У вас обычно есть ежедневные встречи? Команда: Планерки проводятся раз в неделю.
Но они не технические.
Дина: Что такое ежедневная встреча? На самом деле сейчас да, у меня очень мало развития — у меня есть сервис.
Тем не менее, мы проводим ежедневные митинги.
Я просто не знаю, как вам это объяснить - но это работает. Люди собираются.
Самое лучшее, что происходит, это то, что люди начинают вариться в собственном соку.
Каждый из них очень быстро отвечает на несколько вопросов.
Что ты сделал? Чем ты планируешь заняться? А какие у тебя проблемы? А с проблемами может быть очень феерично.
Когда человек варится в собственном соку, он может столкнуться с проблемой, когда кто-то в команде знает, как ее решить.
А потом оказывается, что вопрос адресован коллективу — все время кто-то поднимает руку и говорит — послушайте, это очень просто.
И все крутится, серьезно, гораздо быстрее.
А эффект в том, что люди просто не варятся в собственном соку.
И я часто видел, как половина команды после этого митинга собиралась и так оживленно жестикулировала.
Как это должно быть на самом деле.
Это очень важный фактор.
Я просто настоятельно рекомендую смотреть друг на друга каждый день.
И ответьте на эти вопросы.
Это действительно помогает. И кроме того, программисты любят посидеть.
И ни с кем не общаться.
Если у вас есть новые, вы почувствуете, насколько быстрее он войдет, ведь он каждый день смотрит вам в глаза, а не сидит там.
Когда лучше проводить митинг: утром, вечером или в обед? Кому как Команда: Есть ли смысл обсуждать там какие-то проблемы? А что, если ты весь день ничего не сможешь там делать? А вечером ты скажешь – я весь день просидел.
Ты можешь сделать что-нибудь завтра.
Дина: Мы сейчас объясним.
Многие говорят, что нужно делать утром.
Но мы делаем это во время обеда.
Есть и недостатки: людям очень трудно вспомнить, что они делали вчера.
Команда: Ну, как утром.
Например, прийти на работу на час раньше.
И митинг на прочистку мозгов.
Дина: Мы лично приходили, причем лучше в обед, хотя в книге написано, что утром.
Так как мои люди приходят в обед. Команда: Утро на самом деле — время расширяемое.
Наш график также немного изменчив.
Дина: У меня нет желания заставлять их приходить в восемь.
За что? Если, например, он приходит и мучается как фигня 4 часа.
Лучше сделаю это в 12. Есть понятие опоздания, оно самое характерное.
Но есть люди, которые опаздывают к 12. Как вы думаете, что я делаю? Чтобы люди не опаздывали? Что можно сделать, чтобы люди не опаздывали? Команда: Лишите его бонуса.
Тенденция, однако.
Покажи мне морковку.
Помните подход сзади? Для особых случаев или поставьте баночку Дина: По сути, в книгах представлен подход, при котором делают общую копилку, и опоздавший человек приходит и молча кладет туда деньги.
А в конце недели напиваются за собранные деньги.
У нас это не работает. Он спокойно вносит деньги, на следующий день снова опаздывает, на следующий день снова опаздывает. Не знаю, тебе это не поможет. Лично я купил свиные уши.
И тебе придется ходить с этими ушами целый день.
2 раза было достаточно.
Здесь мы фактически сформировали отставание.
Знаете ли вы, что эти карты предназначены для покера? (показывает).
То есть после того, как мы собрали задачи.
Нам необходимо их переоценить – ведь здесь мы могли допустить ошибку.
Что мы делаем, так это то, что команда собирается так же, как и вы.
Представьте, что у каждого из вас есть колода карт. Мы сделаем правителей, кто чем занимается.
И каждый молча выкладывает карту.
А я, например, смотрю — один выложил сто.
Еще час постил - а у меня вопрос в честь чего? Почему один? Ну, например, я знаю, как это сделать, потому что уже это сделал.
Есть приготовления.
Я спрашиваю - почему 100? Я не знал, как это сделать.
Тогда мы просим кого-нибудь, кто знает, объяснить.
И делаем еще один раунд – все снова выкладывают свои карты.
Во второй раз обычно те же цифры.
Но я беру больше - ну, на всякий случай.
Вот так происходит планирование — бэклог спринта.
Еще одна вещь, которую можно сделать.
Обычно пользовательские истории довольно поверхностны.
Поэтому в книге сказано, что они тоже так делают. Приходим к выводу, что эти истории разбиты на небольшие задачи.
То есть есть, например, админка, или в базе 3 таблицы.
Это дело истории.
Это истории для программистов.
Что делать? И это маленькие задачи.
Команда: А кто устанавливает этот самый вес? Билет и сама история вообще? Сколько времени? Дина: Итак, вы сидите и делаете это сами.
Вокруг никого.
Есть только скрам-мастер, но он не босс.
Он может даже прийти извне.
Это только поможет вам наладить процесс.
Он больше не имеет никаких функций.
Если кто-то, например, устраивает диверсию, он идентифицирует этого человека.
Например, кто-то сидит и разговаривает — и я не знаю, как это все устроено.
Такая звезда.
Он просто с ним разговаривает – зачем ты это делаешь? В принципе нет начальника Команда: Оказывается, это будет работать, если только все люди будут мотивированы.
Дина: Ну а что значит мотивированный? Команда: Ну я имею в виду, что кто-то приходит на работу просто посидеть, ну там же - планктон.
Дина: Scrum не терпит таких людей, я говорю, что все это будет сразу видно.
Работа сразу же прекратится.
Ну, если, например, вчера он сказал, что сделал 3 таблицы, то он сказал позавчера.
Сегодня он говорит это снова.
Нам нужно включить мозги и подумать, тот ли он человек.
Что он здесь делает? Столы? На самом деле это такие маленькие желтые бумажки (показывает).
Это сломанные задачи.
Задачи могут брать на себя совершенно разные люди.
Команда: Это все еще не ясно.
Кто разбивает задачи на задачи.
Сами программисты разбивают задачи на задачи? А еще и сами оценивают, то есть если неправильно разбивают? Ни тот директор, никто? Дина: И кого кроме Вас меня тоже интересует этот вопрос? Откуда технический директор знает, что находится внутри разработки? Кто кроме вас знает, что внутри разработки? Технический директор показал, что находится снаружи.
Я говорю владелец продукта.
Если вы знаете, что вам нужно выполнить эту задачу, вы ее нормально оцените.
Команда: Споры приветствуются? Да, вас много.
Все ли складывается на основе нескольких карт? А что, если окажется, что вы сказали, что сделаете это быстро, а в итоге нарвались на какой-то косяк? Дина: И это то, что происходит всегда.
Я рассказал тебе о трюке.
То есть всегда получается, что мы говорим 160 сторипоинтов.
И мы никогда не делаем первый спринт больше 80. Хорошая цифра, когда мы взяли 160 и сделали 120, это вообще здорово.
Люди всегда ценят больше.
Он всегда думает, что он лучше Команда: И не все подводные камни не всегда легко увидеть Дина: И я имею в виду то же самое – ну, всякое может случиться.
Утром сидишь и думаешь не о том.
Тут жена закричала.
Это тоже случается.
От этого никуда не деться.
Собственно, двинемся дальше или у вас есть еще вопросы? Команда: Я не совсем понимаю.
Ну, кто-то считает. Что одну задачу можно разделить на 2 подзадачи, другую — на 5? Кто прав? Дина: Обсуждаем.
Там приветствуются споры? Скрам-мастер, почему? чтобы немного вас сориентировать.
Он не будет участвовать в споре.
Но если он видит, что спор не по теме, значит, кто-то выражает свои амбиции.
Тогда в этом случае он прекратит этот спор Команда: То есть он еще вроде бы руководит процессом — и говорит, что мы будем делать 5 подзадач, в этом смысл? Дина: Он управляет процессами.
Если у вас грамотный Скрам-мастер, он никогда не скажет — давайте сделаем 5. Нет, он просто, ну, посмотрит, что говорят люди, и решит, что нужно сделать, или проведет голосование, или он Сделаю что-нибудь по-другому, или он заговорит как-нибудь.
Сам он этого не скажет 5. За результат он ответственности не несет. Он отвечает, что ваш процесс идет хорошо.
Все.
Команда: Нет, но он это не сам придумал, он сказал это исходя из мнений Дина: Это решается процессом.
Если вы уже говорите 2 часа, он вас остановит. Но он все равно не будет решать за тебя Команда: по типу как управление людьми и процессами Дина: В этом и заключается ценность, что есть человек, который будет решать за вас, какую задачу вам следует выполнить, сколько времени это займет и когда вы ее сделаете – такого человека просто нет. То есть это своего рода коллективный разум.
Но на самом деле он есть.
Он призывает вас серьезно собраться и взять на себя ответственность.
Не каждая команда к этому готова.
Но поскольку вы уже давно работаете вместе, он у вас уже должен быть.
То есть ответственность полностью лежит на вас.
Никто за вас этого не сделает, никто вам этого не говорил.
Вы все это вынесли сами и несете ответственность за результат. Команда: Извините, но можно еще вопрос: вы сказали, что сначала сказали, что сделали оценку 10 или 100, и владелец продукта должен Подождать, пока оценки выровняются, или он сможет выбирать? Дина: нет, оценки надо выровнять.
Еще в моей практике было, что если спор продолжается слишком долго, если один человек говорит 5 часов, другой говорит 100. Личные амбиции.
Я говорю – кто возьмет? То есть если возьмете, то оставим на 5 часов.
Это нехорошо делать, так как задачи должны формироваться по другому принципу.
Но если идти совсем некуда, то оставим так.
Теперь, когда мы создали бэклог продукта.
У нас есть куча задач, они оцениваются, мы знаем, что делать, а потом делаем что-то вроде этого.
Есть такая сетка (рисует) и все это сюда приклеивается и дальше все происходит. То есть план платы готов, и надо начинать, как спринт, надо начинать что-то делать.
Здесь есть очень важная вещь – мы распределяем все эти задачи.
Но мы не даем людям все задачи сразу.
Смотрим вверху самые важные задачи.
Ниже не очень важно.
Здесь есть задача, которую мы можем взять на себя.
Если у нас останется время, скорее всего, нет. Здесь куча заданий (показывает).
И каждый должен знать, что сначала нужно взяться за задачу, имеющую наивысший приоритет? Команда: Берут ли люди на себя задачи? Дина: Да, это трюк.
Каждый человек имеет право взять на себя задачу.
На самом деле, когда я это прочитал, это был самый страшный момент. Что, если кто-то скажет, что я не буду этого делать? И какая-то задача будет просто висеть там.
Что делать? На самом деле, за все это время такого не произошло ни разу.
Я не знаю, что я буду делать? Я, пожалуй, позвоню ребятам: где вы, команда? Почему это происходит? Разве мы не несем ответственности за результат? На самом деле этого никогда не происходило.
Видимо, когда сформировалась команда и есть ответственность за результат, есть понимание, что кто-то должен делать.
Здесь есть еще одна такая особенность.
По спринту 5 или 6. Если команда достаточно большая, то становится понятно, что один человек постоянно делает одно и то же, потому что хорошо знает, как это все работает изнутри.
То есть он начал делать админку, и там тоже ковыряется.
Он начал обращаться с какой-то большой просьбой.
А рядом куча мелких запросов.
Вот он все это и делает – потому что я знаю, как сделать это быстрее, да.
Вот тут и нужно, если есть умный Скрам-мастер — он скажет нет, вы этим не занимаетесь, потому что он послезавтра заболеет, и никто не знает, что он делал внутри.
Было бы лучше, если бы это заняло больше времени, но каждый попробует немного.
То есть здесь у скарм-мастера есть право вето.
Почему бы вам этого не сделать – с объяснениями, конечно.
Команда: Извините, можно вопрос? Мне кажется, что этот этап нам не подходит для нашего проекта.
Потому что, например, у нас одни занимаются аудиоядром, другие - видеоядром, и тянуть их нет смысла - так как это очень разные области, у них есть своя специфика.
Дина: На самом деле панацеи не существует. Даже с водопадом, как бы я ни любил водопад, правда? Команда: Я не говорю о водопаде, я говорю о том, чтобы не менять людей из-за задач.
Например, он делает произведение, делает его успешно, тогда пусть делает. Заменить его пока некому, но с другой стороны - Он быстро делает качественную работу, почему бы и нет? Дина: Но, возможно, на самом деле это будет не Scrum. Команда: Но я просто говорю, может быть, какой-то гибрид нам подошёл бы больше хотя бы на первое время? Дина: Я тоже так думаю.
Вы видите сами.
Я говорю, что нет панацеи, нет серебряной пули, всегда нужно что-то менять.
Возьмите что-нибудь и незаметно адаптируйте под себя.
Вот если вы считаете, что людей менять незачем, то это ваше решение.
Команда: Мне просто кажется, что у вас Scrum. В общем, все это из Java-разработки.
Но не такие проекты.
У нас гетерогенный проект, грубо говоря.
А должно быть так: есть сайт, допустим, вы делаете базу данных.
А создавать сайты и базы данных может любой человек.
Это просто заказная разработка сделать сайт, например, магазина.
Люди делают это, и этот Scrum идеален.
Наши разработки в области исследований и разработок являются прорывными.
Мы не совсем.
Дина: Но Scrum – это еще и исследования и разработки.
Команда: Я говорю о совершенно разных областях аудио и видео.
В общем, совершенно разные направления.
Человек может работать в аудио 10 лет. У него там диплом.
И он ни слова не понимает в видео.
Если так поменять через неделю.
Это будет просто какая-то каша.
И общий вектор роста будет нулевым.
Что касается аудио, вот задача.
Он также может быть далеко не монолитом.
Нет-нет, я не говорю глобально, может просто не стоит навязывать им глобально, задачами поменьше.
Я согласен с этим, если на аудио работают два человека.
Могут, даже если дублируют друг друга.
Но переключать их на видео не нужно, так как не будет смысла.
Оказывается, это Scrum Limited. Мы не делаем все это ради Scrum, не так ли? Но мне это интересно, чтобы можно было это применить, и чтобы это было не так просто слушать и всё.
Дина: Это можно сделать на доске, но мы сделали все это в Scrum Works. Есть такая вещь.
А еще есть Джайра.
В джайре мне показалось не так уж и комфортно.
Потому что Джайра ведь не об этом.
И поскольку он есть у Jayra, вы запускаете эту штуку, которая превращает Jayra в Scrum-доску.
Но Scrum Works мне понравился больше.
Но это на самом деле дело вкуса.
В принципе, все это можно сделать на доске.
Ты тупо берешь наклейки и приклеиваешь их на доску.
Лучше это сделать на доске, потому что вы можете это увидеть.
Тем не менее, Scrum Works необходимо открыть.
Это лень, да.
Спринт окончен.
Что мы делаем дальше? Мы показываем заказчику и всем, кто интересуется этим делом, что мы сделали.
Требуется заказчик, требуется владелец продукта.
Мы покажем ему все это.
В общем, хорошо пригласить на демо кого-то со стороны.
Потому что сразу такая дрожь - что же мы покажем.
Людей это очень воодушевляет, и мы можем показать, что это не позор.
После того, как демонстрация закончится, нужно устроить еще один магический розыгрыш.
Это называется ретроспективой и длится около 1,5 часов.
То есть мы все собираемся вместе и смотрим на свои текстуры фокуса.
Сколько очков вы набрали? Мы смотрим на наше отставание и говорим о том, что можно было сделать по-другому.
Что можно было сделать лучше, где мы накосячили, что мы накосячили, почему так произошло? И вот это, пожалуй, самое важное из всех митингов.
Как это произошло.
Такая ретроспектива Я тоже хотел тебе сказать, я не знаю, как ты.
Но когда мы начинаем проект Всегда есть техническая задача, которую сложно документировать в виде пользовательской истории.
Это такие вещи, как расширение окружающей среды, проведение некоторых исследований.
Как это будет работать? Как объяснить владельцу этот продукт? Но он кажется умным.
Он, наверное, поймет. Лично у меня были с этим проблемы.
Я лично пришел к выводу, что мой первый спринт всегда технический, мне просто нужно принять это как должное и объяснить и понять, что происходит, попробовать пару вариантов.
И всегда есть технические задачи, в которых вы всегда должны объяснить своему Product Owner, что есть техническое задание и мы его сюда вставляем, что без тестирования жить нельзя.
Мы сейчас сидим и разбираемся с тестированием, а это потребует очень много сюжетных очков.
Ну собственно тестирование.
Есть ли у вас неавтоматизированное тестирование? Не модульные тесты? Что делать с тестированием — есть несколько подходов.
Вы можете проводить тестирование в рамках спринта.
То есть задача выполнена.
Вы отдаете его тестировщику.
И он тестирует. А пока тестировать нечего — сидит и пишет кейсы задач.
Мы попробовали это, и это не сработало.
Что мы сделали? То есть некоторые разработчики, они тянут до последнего дня всё, почти всё.
И потом все это валится на тестер мертвым грузом, да? Извините, что мне делать? Вот итерации и что у нас получилось, не знаю, подойдет это вам все или нет? Разрабатываем, а тестер еще что-то делает? Он у нас вообще не работает. Отдаем ему эту сборку и начинаем следующую.
При этом какую-то часть этой сборки мы закрашиваем как баги.
То есть мы знаем, что в сюжетной точке будет исправлена ошибка.
Они обязательно приедут, она еще тестирует, выкатывает баги, мы их сразу исправляем, собственно так мы и жили.
По-другому и не могло случиться.
Может, можно как-нибудь это сделать? Команда: Сколько процентов вы ставите на ошибки? Дина: Сначала больше, потом меньше Команда: 30-20 процентов? Дина: Сначала еще ближе к 40, а потом качество увеличивается и становится ниже Команда: Могу ли я задать еще вопрос? Просить? Что делать, если человек уходит в отпуск на месяц и исчезает из этой системы? Дина: То есть есть среднее количество стори-пойнтов, которое делает один человек за один спринт, и мы его вычитаем — получается криво, конечно, но хоть как-то.
То есть мы взяли
-
Плагин Atomic — Помощник При Заполнении Форм
19 Oct, 24 -
Пишем Наш Первый Драйвер Для Windows
19 Oct, 24 -
Вы Верите В Популярность Windows 7?
19 Oct, 24
