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

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

    В частности, стратегическое и тактическое проектное планирование, фокусирующееся на эффекте (читай: решении проблем и реализации возможностей), в последние годы находит всё большее распространение в ИТ сфере под эгидой техники «Карт влияния» (Impact mapping). Техника заключается в построении ментальных карт (mind maps), отражающих взаимосвязи между целями организации, вовлечёнными (прямо и косвенно) в достижение этих целей людьми, необходимыми изменениями в их поведении и конкретными программно-аппаратно-административными-… мерами/инструментами, необходимыми для воплощения этих изменений в жизнь.

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

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

    Если вдруг будете в апреле в Минске, приходите на Analyst Days, я буду рассказывать там на примере конкретного открытого проекта о применении этой техники в рамках комплексного подхода. А после можем пообщаться.
  • Практическая холакратия. Нарезаем круги и готовим роли
    0
    Тогда это действительно не Скрам, хотя вы явно нигде и не писали, что Разработка работает по нему. Скрам приносит максимум пользы там, где есть высокий уровень неопределённости – большая зависимость от реакции пользователей, жёсткая конкуренция, сложная динамичная предметная область или технологические зависимости. Каждая поставленная фича в этом случае позволяет получать новые важные знания о том, как развивать продукт дальше, в том числе саму эту фичу. Если фича задерживается (а при описанной модели это практически неизбежно), знания приходят позже и продукт, соответственно, развивается хуже.

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

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

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

    Не могли бы вы так же подробно, как и обо всём остальном, рассказать о процессах в Разработке: как проходят планирования, ежедневные встречи, обзоры и ретроспективы у обозначенных команд? Есть ли там всё-таки Скрам или его нет, потому что не нужен?
  • Практическая холакратия. Нарезаем круги и готовим роли
    0
    Василий, спасибо Вам и всей Кнопочной команде за эту прекрасную статью. Очень вдохновляет!

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

    Я всё-таки надеюсь, что это полное внедрение рано или поздно произойдёт, и у нас появится возможность прочесть об этом такой же замечательный материал. Успехов! +)
  • Нефункциональные требования к программному обеспечению. Часть 1
    0
    В том то и дело, что, ввиду перечисленных обстоятельств, есть немалая вероятность того, что в ближайшие годы нынешнее третье издание будет оставаться одной из самых авторитетных и рекомендуемых книг по бизнес-анализу. А это чревато распространением всяких «резервов проекта» в довольно широких масштабах, чего лично мне очень не хотелось бы.

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

    Я бы с большим удовольствием и не меньшим пристрастием вычитал двадцатую главу +) Только уже осенью.
  • Нефункциональные требования к программному обеспечению. Часть 1
    0
    Специально уточнил этот вопрос у организаторов сообщества. Переводы на сто процентов легитимны, поскольку делались с личного согласия авторов на безвозмездной основе. «Те, кто просят деньги, сразу пишут об этом на своих сайтах». Авторами переведённых книг являются граждане Швеции, ведущие активисты гибкой разработки Хенрик Книберг и Маттиас Скарин.

    Даже если с переводами Вигерса могут возникнуть какие-то юридические проволочки, всегда остаётся возможность выслать издательству список найденных ошибок и параллельно постараться его максимально распространить в Сети. Пусть их учтут в следующем издании, а те, кто приобретёт нынешнее, будет проинформирован.
  • Нефункциональные требования к программному обеспечению. Часть 1
    +2
    Это не самый удачный перевод в первую очередь из-за того, что бэклог некорректно называть журналом. Термин «журнал» в техническом и околотехническом мире обладает устойчивой психологической инерцией — «документ с записями о событиях в хронологическом порядке». Бэклог же представляет собой приоритезированный список элементов не привязанный к какой-либо хронологии.

    На мой взгляд, самый простой вариант термина это «список [название элементов]»: «список нереализованных компонентов продукта», «список компонентов для реализации в спринте». Или сокращённо: «список компонентов продукта», «список компонентов спринта». Если команда использует истории, то соответственно: «список историй продукта», «список историй спринта».

    Что касается политики издательства в отношении переводов и редактуры, это ещё один веский довод взяться за такую работу силами сообщества. К примеру, у Agile Ukraine есть замечательная инициатива Agile Translations. Думаю, в сообществе русскоязычных аналитиков не меньше людей, у которых достаточно компетенции и желания заниматься такой полезной и интересной деятельностью. Осталось их организовать +)
  • Нефункциональные требования к программному обеспечению. Часть 1
    0
    Я, конечно понимаю, что для «классических требований» термин «backlog» не ключевой, но бездумная копипаста «резерва проекта» с Википедии дискредитирует это издание гораздо сильнее, чем опечатка в посвящении и всякие «повелители сайта» по тексту.

    Если бы переводчик потрудился заглянуть в те же «Пользовательские истории», то нашёл бы там «Журнал запросов на выполнение работ» – не первоклассный перевод, конечно, но хотя бы отражающий общую суть. Примечательно, что «Вильямс» открыто указывает переводчика А. Г. Гузикевича, тогда как у «Русской редакций» ничего подобного я не нашёл.

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

    1 — «если уже есть дизайн всех готовых компонент», скетча действительно будет достаточно. Спецификация не нужна +)) Именно это я и пытаюсь объяснить. Простенькое наглядное подспорье для объяснения и спецификация – это разные вещи. Нужно искать для первого более подходящее название, потому что психологическая инерция слова «спецификация» неиллюзорно вводит в заблужение. Точно так же, как подробное описание задачи кажется исчерпывающим, хотя это не так. Такие «мелочи» зачастую имеют решающее значение. И в гибкой разработке об этом знают.

    2 — какую часть продукта составляют сложные проблемы, над которыми нужно думать по 2 месяца? Какая часть пользователей готова ждать 2 месяца, прежде чем кто-то что-то «родит»? А может у них уже есть идеи? Я не говорил, что большее число однотипных участников может позволить решить проблему быстрее. Я говорю о том, что регулярные поставки за счёт со-трудничества с клиентами дают больше эффекта, чем долгие решения даже самых крутых гуру, основанные на предположениях. В одном UX решении тысячи их. Я это знаю на собственном опыте. Поэтому лучше следовать пути открытий, чем пути сумрачного гения.

    3 — действительно, от людей и процесса. И, если вся команда 2 месяца работает над UX решением, это действительно круто. Но что-то мне подсказывает, что в реальности происходит иначе. Разработчики отвлекаются на код – дизайнерами лабаются громоздкие (с точки зрения реализации) решения, управляющий отвлекается на клиентов – начинаются украшательства от разработчиков. Дело не в принуждении, а именно что в процессе. Я вижу основную ценность гибкого процесса в правильном управлением вниманием. Никто не хочет лажать, просто мы крайне неудачно отвлекаемся. Это можно решить вне спринтов. И это хорошая задача. Но спринты делают своё дело, хотим мы того или нет.
  • Визуальные спецификации
    0
    Если не возражаете, продолжим выращивать гриб Истины +)

    1 — в своём примере я специально сделал акцент на сложности. Осознанное BDD не применяется там, где её нет. Время, затрачиваемое на проработку деталей при высокой сложности поведения системы, более чем оправдано для её дальнейшей поддержки и развития. Детальное описание сложного поведения системы (к примеру, ценообразования при продаже товара в крупном интернет-магазине) в виде сценариев и богатого пользовательского интерфейса (с большим количеством оригинальных элементов) в виде макетов высокой детализации я склонен называть спецификацией. Если вместо них попытаться использовать ЕЯ и скетчи, то суммарное время, которое придётся потратить на объяснение и итерации, существенно превысит время, затрачиваемое на разработку спецификации. Если это условие не выполняется, объяснить задачу можно в непосредственной беседе и спецификация не нужна. Если беседа в данном случае заменяется документом, это не делает получаемый документ спецификацией.

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

    3 — реализацией элегантного решения для выбранных важных кейсов и является процесс достижения цели спринта. При этом ключевым фактором является полное вовлечение всей команды, тогда как при долгом проектировании взаимодействия ограниченным составом теряется из вида то ценность, то реализуемость компонентов. В результате разработчиков принуждают создавать программных монстров на грани используемых технологий, которые в итоге не дотягивают до необходимых нефункциональных параметров, и весь эффект продуманности деталей смазывается проблемами с быстродействием и надёжностью. Или, того хуже, дорогущий компонент оказывается маловостребованным.
  • Визуальные спецификации
    0
    Хорошо, давайте возьмём пример прямо из Википедии. Предположим, нам необходимо построить мост через реку. Причём не обычный мост, а что-нибудь типа Аламильо. Скажем, к Олимпиаде нужно создать настоящий шедевр инженерного искусства.

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

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

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

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

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

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

    У меня есть подозрения, что если дизайнер в полной мере будет понимать сущность итеративного процесса и примет его для себя, он сможет в него вписаться и создавать дизайн приложения эволюционно. Тогда можно добиться уже самой настоящей гибкости в управлении продуктом, разрезая до конца все слои пирога. Только следите себе за ситуацией и развивайте систему в нужную сторону.
  • Визуальные спецификации
    +3
    Истина, как плесень – зарождается в спорах.


    Спасибо за прекрасную спорную статью! И да будет этот комментарий мицелием могучего гриба!

    А источник спор заключается в сущности самого понятия спецификации – «набора параметров, которым удовлетворяет (должен удовлетворять) некоторый технический объект». И эти параметры должны быть достаточно точными для того, чтобы данный объект можно было воплотить в жизнь и проверить его на жизне-способность. На сегодняшний день в разработке пользовательских приложений есть лишь 2 артефакта, которые могут претендовать на такую роль: BDD сценарии и дизайн экранов системы. На основе сценариев пишутся тесты и реализация, на основе дизайнов делается вёрстка (в широком смысле этого слова). И то, и другое становится непосредственной частью системы. Всё остальное я склонен называть когнитивным сахаром, целью которого действительно является «донесение идей в максимально понятной и полной форме». Проще говоря: спецификация доносит не идеи, а конкретные характеристики продукта. Идеи же доносятся фасилитируемым общением. И эти понятия нельзя смешивать.

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

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

    Мы делали стори мэпы и карты переходов в Prezi и остались очень довольны. Масштабирование – это сила! Обнаруживается очень много неявных историй и начинают проклёвываться первые интерфейсные решения. Дальше дело за проектированием интерфейсов: сначала на бумаге/магнитной доске, потом в Balsamiq для общего обсуждения и согласования, затем в Axure для более тонких вещей, над которыми ломают голову и управляющий продукта, и дизайнеры, и разработчики.

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

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


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

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

    Подытожим:

    • Спецификация = BDD сценарии + дизайн
    • Спецификация != донесение идей
    • Донесение идей = общение + (шаблон бизнес-модели + карты эффектов + карты историй + карты переходов + прототипы интерфейса)
    • Дизайн желателен, но не обязателен для начала разработки


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

    P. P. S. Не так давно меня попросили высказаться по более общему вопросу документирования проектов. Я накидал заметку в Фейсбуке. Думаю, её прочтение раскроет мою позицию гораздо полнее. Надеюсь, обещанный там (и много ещё где) слайдкаст всё-таки появится в этом-следующем месяце. Он призван стать той самой «визуальной (даже аудио-визуальной) спецификацией» ко всему, что здесь написано +)
  • Создание продукта: НАЧАЛО
    0
    Надеюсь, к концу текущего года мне будет что рассказать и по этом поводу +)
  • Создание продукта: НАЧАЛО
    0
    Игры делают по ещё более гениально-простой «методике» +)
  • Создание продукта: НАЧАЛО
    0
    Денис, если говорить о нашей компании, то из публичных проектов мы в похожем ключе открывали мобильную версию сайта ведущего молдавского сотового оператора, сейчас так работаем над B2B порталом молдавских ИТК компаний и порталом Почты Молдовы. С апреля начинаем работу над крупным собственным продуктом.

    В наших масштабах подход работает прекрасно.
  • Создание продукта: НАЧАЛО
    0
    Спасибо за прекрасную статью! Отличное продолжение статьи Алексея. Лично для меня очень важно было связать воедино всё то, к чему мы так или иначе приходили за время работы по гибким подходам.
  • Больше, чем plain vanilla scrum. Общепринятые практики работы с требованиями
    0
    Артём Сердюк придумал отличную альтернативу шаблону бизнес-модели Остервальдера — более интуитивный и наглядный канвас в виде воздушного шара. Думаю, скоро Артём представит его широкой общественности.

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

    Надеюсь, со временем применение данного инструмента тоже станет общепринятой техникой для скрам-команд. По крайней мере, я буду прикладывать к этому все необходимые усилия.
  • 8 Параметров социальной жизни команды: как измерить неизмеримое
    0
    Вы, видимо, не поняли, что речь идёт о скрам-команде. Это не рыночный сброд. Это союз умных людей, мотивированных профессионалов, которым нужно лишь «создать условия, обеспечить поддержку и полностью довериться» (5-ый принцип).

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

    Нет натянутых улыбок, нет жеманства. Сегодня к нам вернулся коллега из Штатов и сразу попал на оценивание сложного модуля. Мы вышли измотанные из переговорной через 3 часа, но он искренне признался, что давно так здорово не проводил время, потому что был среди своих и занимался любимым делом. У американцев он просто засыпал, участвуя в аналогичных мероприятиях.

    Если не верите, попробуйте сами. Эмпирический процесс расставит всё на свои места.
  • 8 Параметров социальной жизни команды: как измерить неизмеримое
    0
    Людям нравится быть счастливыми и делать счастливыми других. Перечисленное нравится людишкам.
  • 8 Параметров социальной жизни команды: как измерить неизмеримое
    +1
    А мы последовали совету Хенрика и стали мелко штрафовать опоздавших, а на «вырученные средства» приобретать приятные, и, как правило, сладкие, мелочи.

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

    Один и тот же социальный механизм (подражание) может приводить к кардинально противоположным эффектам. Главное — удачно подобрать точку приложения ))
  • 8 Параметров социальной жизни команды: как измерить неизмеримое
    0
    А я так и вижу, как узко Вы мыслите.
  • 8 Параметров социальной жизни команды: как измерить неизмеримое
    0
    Архиполезно, спасибо!
  • 5 Идей для Владельцев продукта: как усилить мотивацию команды через работу над Видением
    0
    Стрессовые условия существуют вне нашего желания, это данность большинства проектов. Фокус аналогично снижается вне нашей воли, это данность человеческих существ. Пост о том, что требуется от PO, чтобы фокус всегда был на приемлемом уровне: максимально понятно представлять команде продукт, внимательно относиться к каждому её участнику, вести живой диалог с конечными пользователями, ставить релевантные цели спринта, обращать внимание на внешние факторы, влияющие на сроки разработки.

    И всё это — абсолютно правильно, как с точки зрения теории подхода, так и той практики, которую мне посчастливилось иметь. Единственно соглашусь, что некоторые формулировки вышли не очень удачными. Уверен, что на следующей итерации выйдет куда складней +)
  • 5 Идей для Владельцев продукта: как усилить мотивацию команды через работу над Видением
    0
    Ни о регулярности, ни о тяговой силе речи не идёт. Речь идёт о помощи (фасилитаторстве) команде в ситуациях, когда снижается фокус. Проще говоря, всё это о том, как помогать людям бороться с ленью и быть всегда в тонусе. Каждый этого хочет, но не всем это даётся легко. Вот для тех, кому сложно мотивировать себя самостоятельно, и нужен фасилитатор с набором подобных техник.
  • 155 лет со дня рождения Константина Циолковского
    0
    Тем не менее, починили! ;-)
  • 155 лет со дня рождения Константина Циолковского
    +1
  • 155 лет со дня рождения Константина Циолковского
    0
    Даа, эпичный гуглофэйл :-) Действительно, 155.

    Меня ещё вчера насторожило:

    В сентябре 2007 года к 150-летию со дня рождения К. Э. Циолковского в Боровске был открыт новый памятник на месте ранее разрушенного.


    Но в голову не пришло, что могли так ошибиться. Может, отписать им? )
  • 155 лет со дня рождения Константина Циолковского
    +1
    C вооот таким кейс-стади!
  • 155 лет со дня рождения Константина Циолковского
    0
    На интерактивное извинение напрашиваются ;-)
  • 155 лет со дня рождения Константина Циолковского
    +2
    Кстати, некоторые из приведённых чертежей вспоминаю ещё из «Городов на орбите» Ф. Ю. Зигеля. Книга, которая совершенно случайно попала в руки, но оставила неизгладимый след в моём мировосприятии. При всём обилии всевозможных медиаматериалов сегодня не хватает таких изданий. Вспомнилось из недавнего Пелевина:

    Я родился уже после того, как последняя битва за душу человечества была проиграна. Но я слышал её эхо и видел её прощальные зарницы. Я листал пыльные советские учебники, возвещавшие, что Советский Союз сделал человека свободным и позволил ему шагнуть в космос. Конечно, даже в детстве мне было понятно, что это враньё — но в нём присутствовала и правда, которую было так же трудно отделить от лжи, как раковые метастазы от здоровой плоти.
  • 155 лет со дня рождения Константина Циолковского
    0
    У пана Стани́слава был куда эффектнее, но то скорее попытка реабилитации за пропущенный юбилей. Сегодняшний мне тоже очень нравится, солидно. Однако лучшим подарком для Константина Эдуардовича будет очередной уверенный шаг из колыбели. Всё в наших руках.
  • 155 лет со дня рождения Константина Циолковского
    +4
  • Мой взгляд на Scrum
    +1
    То есть Вы писали как раз о том, что многие люди неверно понимают назначение Скрама и слишком многого от него ждут. Что же, могу только подтвердить сей печальный факт. Но движение растёт, а вместе с ним и общий уровень компетентности.

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

    Сейчас, внедряя Скрам, я делаю на их решение основной акцент, пропагандируя такие практики, как применение гибких баз знаний (live wiki), кроссфункциональность (наши программисты с радостью обсуждают с дизайнерами вопросы UX, а менеджеры заливают релизы на боевой сервер), привлечение разработчиков на самых ранних проектных этапах (вплоть до этапа подписания контракта; на прошлой неделе провели общий предпроектный воркшоп по результатам обследования одного из объектов автоматизации, получили отличные результаты) и т.д. Это выходит за рамки Скрама, но превосходно с ним сочетается.

    Большую часть из вышеперечисленного я склонен называть, как пальчиковые батарейки — AAA (Advanced Agile Analysis). Надеюсь, в ближайшие месяцы созрею на серьёзную статью по этому поводу.
  • Мой взгляд на Scrum
    0
    1. Скрам и не должен ничего говорить по этому поводу, вы его явно с чем-то путаете.
    2. Правильное развитие качеств команды обеспечивается за счёт ретроспектив. Здесь я соглашусь с Хенриком Книбергом, что это вторая по значимости (после планирования спринта) церемония Скрама. А то и первая. Здесь наибольшего проявления достигает самая важная из трёх составляющих управления эмпирическим процессом — адаптация (почитайте про модель Такмана, к примеру).
    3. Способов множество, вы вольны выбирать любой. Я уверен в том, что Скрам настолько хорошо «протестирован», что, как писал тот же Хенрик, «работает прямо из коробки». Дальше его можно совершенствовать до момента, когда вы выйдите на уровень Ри и вообще забудете, что работаете по Скраму.

    Я искренне не понимаю, почемы вы ждёте от правил игры в шахматы описания тактики игры гроссмейстера. И самое главное: «Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices». Приветы от Хенрика: Scrum and XP, Scrum and Canban.
  • Мой взгляд на Scrum
    +2
    Individuals and interactions over processes and tools (Manifesto for Agile Software Development).


    Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done (Principles behind the Agile Manifesto).


    Как пошутил Кен Швабер в своём знаменитом выступлении (Scrum et al, 5.09.2006): «Вы вполне можете научить работать по Скраму кучку идиотов… и получать в конце каждой итерации дерьмо» (вольный перевод).

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

    1) Люди не мотивированы — вы получите дерьмо.
    2) Люди не талантливы — в конце первой итерации вы получите дерьмо. Но если они мотивированы настолько, что готовы совершенствоваться, есть все шансы получить годный продукт на одной из последующих итераций.
    3) Людям не нужна инфраструктура — вам не нужен Скрам у вас собралась команда суперменов, способных читать мысли и в мгновение декомпозировать до нужного уровня сложные абстрактные системы. Или у вас настолько простой продукт, что вам действительно не нужен Скрам. «Scrum is a framework for developing and sustaining complex products» (Scrum Guide, стр. 3).

    Таким образом:

    1) Правильные вещи делают мотивированные люди.
    2) Вещи правильно делают талантливые люди.
    3) Быстро делать вещи вышеперечисленным людям помогает Скрам — за счёт вымеренной годами непрерывной практики минимальной формальной инфраструктуры (в первую очередь — фиксированных временных рамок — timeboxes).

    Как мне показалось, Ваш взгляд на Скрам либо слишком узок, либо недостаточно компетентен. И в том, и в ином случае советую, как минимум, более вдумчиво перечитать Манифест и Руководство. Да и в видео Кен довольно прозрачно отвечает на все перечисленные в статье «проблемы».
  • Украинские студенты создали перчатки, переводящие язык жестов в речь
    0
    Как мне кажется, жестовые языки гораздо более семантически ёмкие. Они нарративно ограничены, зато должны давать гораздо более чёткие фразы для синтеза, чем переводчик ЕЯ–ЕЯ.
  • Украинские студенты создали перчатки, переводящие язык жестов в речь
    0
    Вы видели альтернативный ролик об очках Гугл, снятый в России? Помните, там момент, когда у парня что-то спрашивают, он повторяет очкам вопрос несколько раз, а те не реагируют. В результате выходит конфуз.

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

    Кроме того, такие перчатки могут стать очень многофункциональным устройством ввода для тех же самых очков. И тут вам снова пригодится ЖЯ. По-моему, здорово.
  • Украинские студенты создали перчатки, переводящие язык жестов в речь
    0
    Выходит, можно хоть свой жестовый язык придумать и настроить систему таким образом, чтобы она воспроизводила его на языке собеседника. Таким образом, оказавшись в чуждой языковой среде, можно хотя бы вопросы и просьбы «произносить», что часто уже немаловажно.

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

    На сегодняшний день всё это, конечно, ещё фантастика. Но идея перчаток мне раньше ни в голову не приходила, ни на глаза не попадалась. Весьма впечатлён.
  • Украинские студенты создали перчатки, переводящие язык жестов в речь
    0
    С другой стороны, это ведь язык ввода. Теоретически, изъясняться можно на любом из жестовых языков, звуковая расшифровка же будет на том языке, который укажет пользователь.
  • Украинские студенты создали перчатки, переводящие язык жестов в речь
    +1
    Не знал. Жаль.