1 post tagged

Scrum

Книга “Scrum”

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

  • К следующему проекту, названному “Страж” (Sentinel), ФБР приступило сразу, в 2005 году. Программа обязательно начнет работать. В данном случае все будет иначе: в Бюро примут необходимые меры, проведут надлежащие бюджетные процедуры и организуют правильные средства контроли. Цена вопроса? Сущий пустяк – 451 миллион долларов. И система “Страж” будет полностью работоспособной в 2009 году.
    Что на этот раз могло пойти не так? Ответ появился в марте 2010 года. Компания Lockheed Martin, подрядчик, которого наняли для разработки новой системы, опаздывала на год, осуществив лишь половину проекта и потратив 405 миллионов. Для завершения программы, по оценкам независимых экспертов, ей потребовалось бы еще от шести до возьми лет, а налогоплательщикам пришлось бы раскошелиться дополнительно на 350 миллионов долларов минимум.
  • При управлении проектами традиционно требуется наличие двух вещей – подконтрольность и предсказуемость. Такой подход неминуемо приводит к возникновению огромного количества документации, таблиц и диаграмм, в точности как получилось с компанией Lockheed. Месяцы труда тратятся на то, чтобы предусмотреть все до мельчайших деталей, не допустить ни одного сбоя, не перерасходовать финансовые средства и продвигаться согласно графику.
    К великому сожалению, подобный сценарий, даже самый радужный, на самом деле никогда не воплощается в жизнь. Попытки загнать творческую деятельность человека в разноцветные графики и таблицы бессмысленны и обречены на провал. Это не имеет никакого отношения ни к работе людей, ни к выполнению проекта, а тем более к тому, как вызревают и осуществляются идеи и как совершаются великие дела.
  • В основе методологии Scrum лежит простая идея. Когда бы ни был запущен проект, вам ничто не мешает регулярно проверять ход работ и последовательно выяснять: справляетесь ли вы с заданием; в нужном ли направлении движетесь; создаете ли именно то, что на самом деле хочет получить заказчик. Вам также ничто не мешает постоянно поднимать следующие вопросы: есть ли способы усовершенствовать методы разработки и выполнять работу наиболее качественно и быстро; существуют ли факторы, препятствующие вашим задачам.
  • Планировать полезно. Слепо следовать плану – глупо. Невероятно заманчиво, когда работа, которую предстоит выполнить по крупному проекту, детально изображена графически на бесчисленных диаграммах и представлена на всеобщее обозрение. Но как только этот превосходно отточенный план сталкивается с реальность, он сразу рассыпается в прах.
  • На исправление ошибки, обнаруженной в день, когда она была сделана, уходил час. Спустя три недели требовалось уже двадцать четыре часа. В принципе не имело значения, была ли ошибка крупной или мелкой, сложной или простой, – в любом случае, если к ней возвращались через три недели, времени требовалось в 24 раза больше. Делай все как следует с первого раза. Если допустили ошибку, исправлять ее нужно немедленно. Если не сделать сразу, то придется дорого платить за свою ошибку.
  • Как получается, что меньше работая, успеваешь делать больше? На первый взгляд в этом нет логики. Люди, трудясь из последних сил, начинают совершать ошибки, которые, как мы уже знаем, иногда труднее и дольше исправлять, чем все сделать правильно с первого раза. Уставшие сотрудники становятся рассеянными и склонны отвлекать окружающих. Кончается тем, что они принимают неверные решения.
  • Когда у нас не остается энергетически резервов, мы склонны действовать опрометчиво. Этот феномен окрестили “истощение эго”. Идея заключается в том, что принятие любого решения требует от вас энергетических затрат. Это странный вид истощения – вы не чувствуете физического утомления, но ваша способность принимать взвешенные решения снижается. Что на самом деле меняется, так это наш самоконтроль – наша способность быть дисциплинированными, вдумчивыми и просчитывать последствия.
  • Многозадачность отупляет. Если делать одновременно несколько дел, получится и медленно, и плохо. Не поступайте так. Если вы считаете, что вас это не касается, то вы ошибаетесь – это относится и к вам.
  • Сделанное наполовину – не сделано. Наполовину собранна машина отбирает большое количество ваших ресурсов, которые могли бы быть использованы для создания ценности и экономии средств. Все, что не закончено, стоит денег и энергии, не принося никакой практической пользы.
  • Делайте все правильно с первого раза. Совершив ошибку, исправляйте ее сразу. Отложите все дела и займитесь ею.
  • Если слишком усердно трудиться, работы становится больше. Если работать сверхурочно – это не значит, что успеешь больше. Слишком усердный труд приводит к усталости, которая в свою очередь приводит к браку в работе, и его приходится сразу устранять.
  • Без героизма. Если для выполнения работы вам нужен герой – у вас проблема. Героическая усилие следует рассматривать как признак ошибки при планировании.
  • У Николы Дурамбе (Salesforce) есть верный способ проверки, не сбилась ли команда с нужного пути. Она может неожиданно спросить, скажем, у сетевого инженера, из какой он группы. Если специалист, отвечая, называет программный продукт, над которым они в данный момент работают, а не свою специальность, то она одобрительно кивает.
  • Командная динамика хорошо функционирует только в малочисленных группах. Классический вариант – семь человек, плюс или минус еще двое. По статистическим данным, если в группе более девяти человек, скорость работы действительно падает. Дополнительные исполнители заставляют группу работать медленней.
  • Если вам нужно вычислить, как виляет размер группы, нужно взять число людей в ней и умножить его на это число минус один и разделить на два. Коммуникационные каналы = n(n-1)/2. Например, если в группе пять человек, то у вас десять каналов. Шесть человек – пятнадцать каналов. Семь человек – двадцать один канал. Десять человек – сорок пять каналов. Наш мозг не в состоянии успевать за таким количеством людей. Мы не можем уследить, че занимается каждый человек и теряем скорость.
  • Сколько раз ваша группа, сталкиваясь с проблемой, сразу начинает искать виноватого? Готов спорить, что любой из вас был на подобных собраниях. И наверняка любой из вас раз-другой оказывался на месте человека, на кого взваливали вину за ошибки. И опять я готов спорить, что когда вы осуждаете другого, вы быстро находите подтверждения его персональной вины, но когда упрекают вас, вы гораздо лучше видите внешние факторы, приведшие к проблемам, и можете объяснить причины своего поведения. Когда вы ведете речь о себе – вы совершенно правы. Но когда вы обсуждаете чужие поступки, вы совершаете одну из самых распространенных и самых пагубных ошибок, присущих человек. Фундаментальную ошибку атрибуции.
  • Заблуждаются все. Каждый из нас считает, будто только он умеет объективно реагировать на ситуацию, в то время как поведение остальных лишь мотивировано их персональными особенностями. Забавный побочный эффект заключается в том, что когда нас просят описать черты характера собственные и наших друзей, мы всегда отображаем себя куда более банальными. Мы не находим в себе тех ярких особенностей, которые признаем за своими знакомыми.
  • Люди стремятся обвинять других людей, но никак не систему. Так проще. Фундаментальная ошибка атрибуции обращается к нашему чувству несправедливости. Если мы можем обвинить другого, мы ограждаем себя от возможности сделать то же самое.
  • Информационный каскад возникает, когда для человека удобнее всего, понаблюдав за действиями своих предшественников, повторить их поведение вне зависимости от имеющейся у него информации.
    На примере передачи стать в журнал: Редактор первого журнала статью вернул. Тогда автор шлет ее во второй журнал. Его редактор, узнав о первом отказе, скорее всего, тоже откажет. А если есть еще и третий журнал и его редактор узнает о первых двух отказах, вероятность того, что он отклонит ее, еще выше. Человек склонен считать, что мнения других людей более верные, чем его, даже если эти суждения противоречат его собственной оценке.
  • Обвинять глупо. Не ищите дурных людей, ищите вредные системы – системы, которые стимулируют ненадлежащее поведение и вознаграждают за плохую работу.
  • Побеждать малым количеством. Малочисленные команды работают быстрее, чем многочисленные. Правило номер один – семь усастников плюс-минус два.
  • Что ты делал вчера, чтобы помочь команде завершить спринт?
    Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?
    Какие препятствия встают на пути команды?
  • Спринты имеют определенную продолжительность. Вы не можете сначала сделать недельный спринт, а потом трехнедельный. Нужно быто последовательными. Ваша цель – установить рабочий ритм. Еще один важнейший аспект спринта: как только команда утверждает список требований, задачи из этого списка “блокируются”. Если вмешиваться и отвлекать команду, ее работа существенно замедлится.
  • Потребности разных персонажей, как правило, совсем разные. Представьте себе такой случай, когда ситуация меняется на противоположную. Предположим, вы произносите: “Мне нужна машина, чтобы ездить на работу”. А теперь начните предложение так: “Как жителю пригорода, постоянно ездящему в центр на работу…” Или ровно наоборот: “Как фермеру Южной Дакоты с ее плохими дорогами…” В результате вы получите два совершенно разных представления об идеальном автомобиле.
  • Чтобы наращивать нужный темп, прежде надо свести на нет все потери.
  • Только тот, кто непосредственно выполняет проект, знает, сколько он требует времени и сил. Какая-нибудь группа хороша в разработке одного вида продукта, но совершенно несостоятельна в работе над другим. Наверняка в каждой группе можно найти специалистов, способных совершать чудеса в какой-то конкретной сфере. Наверное, есть группы, где кто-то с чем-то не справляется. Как мы уже не раз говорили, все команды уникальны и неповторимы. У каждой свой темп и ритм работы. Подгонять их под общий шаблон – верный путь в пропасть.
  • Первое, о чем стоит задуматься, когда вы размышляете о смысле своего задания, – это действующее лицо. Покупатель, невеста, читатель, служащий – тот, для кого вы будете выполнять данную задачу, чьими глазами вам придется смотреть на мир, когда приступите к созданию новой вещи, принятию конкретного решения, разработке программы.
    Затем надо обратить внимание на то, что мы хотим сделать в первую очередь. Обычно это лишь часть работы, с которой мы начинаем наш процесс и на которой всегда можем его остановить.
    Наконец, нужно подумать о мотивах. Почему выбранный нами персонаж хочет эту вещь? Как она будет ему служить, чем будет радовать его как потребителя? Определенно, этот момент может оказаться ключевым. Личная заинтересованность придает колорит всему.
  • Есть довольно быстрый и точный способ сбора оценок. Он называется “покер планирования”. Каждому участнику дается колода карт с числами Фибоначчи. Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, что мы говорим об оценках, а не жестких планах. И оценках небольших фрагментов проекта. Если расхождение получается более чем на три карты, тогда те, кто положил карты с самым большим и самым маленьким значением, объясняют, почему они так считают. Затем проводится еще один раунд покера планирования.
  • Это путешествие, а не пункт назначения. Истинное счастье можно найти в пути, а не в его завершении. Мы обычно награждаем только за результаты, но что больше всего нужно укреплять в людях – их стремление к величию.
  • Владелец продукта должен быть всегда доступен для команды, поскольку в любой момент может потребоваться его объяснение, почему то или иное задание нужно делать в первую очередь. Не имея возможности связаться с ним, команда может принять неверное решение. Кстати, это одна из причин, почему я редко рекомендую на роль владельца продукта руководящих работников, например CEO компаний, – у них просто нет столько времени посвящать себя нуждам команды.
  • Нет смысла искать плохих людей, ищете плохие системы. Давайте зададим вопрос, который мог бы изменить положение вещей: “Что стимулирует в людях плохое поведение?” Весьма сомнительно, что кто-то в вашингтонских политических кругах серьезно считает себя дурным человеком. Готов спорить, большинство их исполнены самых благих намерений. Все дело в системе, которая подвела их и заодно нас.

Goodreads

 No comments    231   6 mon   Books   Scrum   Синопсис