От SCRUM к LEAN

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

 


Немного истории

Корни Scrum на самом деле выходит за рамки Agile эпохи.

Корни Scrum на самом деле выходит за рамки Agile эпохи. Первое упоминание об этой технике могут быть найдены в 1986 году Hirotaka Takeuchi и Ikujiro Nonaka, для коммерческой разработки продукта. Первый официальный документа, определяющего Scrum, написанные Джефф Сазерленд и Кен Schwaber, был представлен в 1995 году.

Scrum популярность выросла вскоре после 2001 года публикации Agile Manifesto , а также книги Agile разработки программного обеспечения с Scrum , в соавторстве с Кеном Schwaber и Майк Бидл.


Несколько фактов

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

Существует нет, и никогда не будет, список "Scrum Best Practices", потому что козыри команды и проекта контексте всех других соображений. - Майк Кон

Роли

Все начинается с свиньи и курицы. Курица просит свинья, если он заинтересован в совместном открытии ресторана. Курица говорит, что они могли бы назвать это ", ветчиной и яйца". Свинья отвечает: "Нет, спасибо.Я бы быть совершены, но вы только участвовать! "

Это Scrum! Он определяет конкретный набор ролей, которые делятся на две группы:

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

Это, как мы начали

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

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

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

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

Этот человек взял на себя роль Master Scrum.

Scrum Master

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

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

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


Введение термина "Спринт"

Лично у нас нет никаких проблем с 5:57 релизы месяца, но изначально я не мог себе представить такого частого графика выпуска. Я думал, что это было слишком быстро, и не предоставит нам время, необходимое для интеграции и отладки нашей продукции. Но потом, наша Scrum Master представила нас термин, спринт.

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

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

Если я правильно помню, первое значительное изменение в процессе нашего развития пришли путем введения планирования спринта.

Sprint планирования

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

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

Product Owner

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

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

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

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

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

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


Планирование совет

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

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

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

Так, что на этом форуме?

Колонны для процесса развития

Существуют четыре основные колонки:

  • Отставание выпуска - Где все истории находятся в текущей версии. Да, продукт готов к выпуску после каждого спринта, но это не обязательно означает, что мы на самом деле освободить его. Мы обычно имеют пятидневный спринт.
  • Sprint Отставание - Когда мы планируем, мы ведем переговоры, что продукт владелец хочет завершить в спринте. Как мы решаем, что мы можем и не может выполнить? По оценке сложности каждая история (см. ниже - Оценка истории). Конечным результатом является набор историй переехал из выпуска отставание до отставание спринте. Команда сосредоточена на окончание этих историй в ближайшие недели.
  • Рабочая On - Это одна простая. Когда члены команды принимают историю, они добавляют его в этот столбец, чтобы показать всем, что они работают. Это предназначено для сотрудников управления, а для общения с членами команды. Каждый человек должен всегда знать, что их товарищи по команде работаем. На изображении выше, маленький закладки застрял на заметки содержат имена моих членов команды.
  • Готово - завершить все дела! Да, это где завершил историй идти. Тем не менее, важно определить, "что сделано". В конце идеальное спринт, все истории и ошибок с отставанием спринте должен содержаться в этой колонке.

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

Определение урон

Что сделано? Когда вы можете с уверенностью сказать, что история завершена? Как вы знаете?

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

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

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

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


Заполнение совета

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

User Stories

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

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

Примером такой рассказ может звучать что-то вроде: "Как пользователь, я хочу поделиться папку с моими товарищами по команде."

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

Вы можете думать про себя: "Почему переговоры?Разве это не на самом деле лучше для одного человека, чтобы решить, что делать и когда? " Не совсем. Эти две роли будет зависеть от просмотра одного человека из системы или проекта. Два человека, с другой стороны, имеют больше шансов обеспечить более объективный путь для команды, обеспечивая конечную цель (лучше ценного программного обеспечения) достигается.

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

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

Ошибки, ошибки, ошибки

Отслеживание ошибок невероятно важно.

Мы также список ошибок на борту. Вы видите эти красные стикеры? Те ошибки, которые мы должны исправить в следующей версии.

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

Я не знаю других команд, которые накапливаются ошибки в течение трех спринтов, и тратят каждый четвертый спринте их устранению. Другие разделить спринт в 25/75 для ошибок / историй. Кроме того, другие команды могут работать по истории утра, и ошибки, после обеда, она просто зависит от компании.

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

Задачи или Sub-Stories

Задачи записываются как простые предложения с точки зрения разработчика.

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

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

Мы используем голубой заметки для задач, на наш борт. Посмотрите в последней колонке ("Готово", колонка), и вы найдете наши задачи в рамках закрепленных пользователь история. Это отдельная история, был взломан около четырех задач.

Технические задачи

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

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

Техническое отставание

Для молодой команды с небольшим опытом работы с Agile и Scrum, это полезно, чтобы выделить эти задачи с мини-отставания.

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

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


Big Challenge: оценка

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

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

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

История очки

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

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

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

  • Используйте Fobinacci Numbers - 1,2,3,5,8 (и, может быть, 13, но 13-размера история пахнет слишком большой для меня).
  • Используйте Полномочия 2 - 1,2,4,8 (и, может быть, 16, но это число следует избегать).

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

Семафоры

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

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

Естественно, что каждый цвет имеет свое значение.

  • Зеленый означает легкая задача, которая может быть завершена в следующем спринте.
  • Желтый относится к более трудной задачей - тот, который требует больше усилий от нескольких членов команды. Он также имеет высокие шансы завершить в следующем спринте.
  • Красные метки приписываются к историям, которые являются чрезвычайно сложным и не может быть закончена в одном спринте. Там должно быть практически нет таких историй, но если вы усыновить одного спринта недели, пять дней на короткое время.

T-Shirt Размеры

Номера могут быть уродливыми, чтобы вы, цвета слишком художественно. Это время для футболки размеров! Этот метод предлагает отказаться от сравнения историю сложности с момента завершения. Проще говоря, вместо цифр, можно использовать как размеры S, M, L, XL, XXL для ваших рассказов.

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


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


Измерение скорости развития

Итак, вы хотите узнать, насколько хорошо вы выполняете в текущем спринте? Часто используемым методом является Burndown графике:

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

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

Есть никаких наполовину сделано историй. Если история будет сделано, то сделано. Если это не полное, то он не рассчитывал на Burndown графике.

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

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

Когда это происходит, вы регулируете. В течение следующего спринта, взять четыре очка. Вот так?

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

Проблема Что вы будете делать после того, как вы закончили то, что вы планируете? Еще одна история? Как вы положить, что на графике? Вы не можете перерисовывать исходной линии.

При работе с Burndown графики, рекомендуется всегда делать средний показатель за последние 3-5 графиков, для того, чтобы указать расположение точек на предстоящий спринт. Конечно, в самом начале, у вас нет такой информации, так что вы не будете так точны, как в будущем. Это нормально.

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

Velocity?

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

Agile методологий и методов целевой поддерживать постоянный темп. Доставка быстрая сейчас, и доставить быстрее позже. Как они это делают? Scrum является одним из элементов головоломки. Другой важной части включают методы, которые программисты могут использовать, чтобы сделать свой код и процесс развития лучше. Например, XP (Extreme Programming), парное программирование, TDD (Test Driven Development), и т.д. Все это, вместе, может сделать команда действительно здорово.

Таким образом, мы измерить эту скорость, но то, что мы на самом деле с ним делать?

Совет: Измерение скорости для лучшего предсказания, а не для оценки команды или ее членов.

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


Всегда оглядываться назад и улучшение

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

Эти встречи, как правило, называют Ретроспективы. Они предлагают рамки, чтобы выделить то, что было хорошо, а что пошло не так. Вот несколько примеров из моей собственной ретроспективы.

Bad Things

  • Члены команды боролись слишком много
  • Член команды X или Y не был совместным, когда парное программирование
  • Мы потеряли слишком много времени с небольшой вещи, как X или Y
  • Мы не сопряжение программы все время
  • Мы не писать тесты для модуля М

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

Good Things

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

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


Я хочу посмотреть, что вы сделали это Sprint

Демо для показа заинтересованные стороны (и владелец продукта) ход реализации проекта.

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

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

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

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

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

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


Тем не менее, нам нужно больше Руководства

В ходе этих встреч, каждый член команды должен ответить на три вопроса.

Это был момент, когда наша Scrum Master предложил сделать встречи каждый день. Да! Каждый день, каждое утро, в точном час!

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

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

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

В ходе этих встреч, каждый член команды должен ответить на три вопроса:

  • Что вы делали вчера? - Короткий ответ ожидается - максимум 2-3 предложения.
  • Что ты собираешься делать сегодня? - То же типа короткий ответ, что-то вроде: «Я буду работать на эту историю сегодня».
  • Существуют ли какие-либо проблемы с вашим процессом? Если да, то какие? Могут ли они быть быстро решена? Это должно быть ответом выделяя проблемы и решения, если оно известно. Нет детального обсуждения должны быть приняты, в то время как эта встреча продолжается. Scrum Master должен принять к сведению проблемы, и работать в направлении ее решения вместе с командой, после того, как заседание закрывается.

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

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

Большинство наших проектов написана на PHP. В какой-то момент мы должны были взаимодействовать наш проект с VMWare. Мы рассмотрели официальные библиотеки для VMWare API, и выяснили, есть Java и Perl версии. Там также неофициальный вариант Ruby. Мы были уверены, что мы могли бы использовать одну из них, и просто сделать некоторые exec() вызывается из PHP, чтобы захватывать вывод в виде строки. Как мы и думали, анализ оттуда должна быть кусок пирога.

Оказалось, что это было почти невозможно. Ни одна библиотека API работала достаточно, как мы ожидали. Некоторые были заброшены или неполным, и у них было почти невозможно разобрать выходов. В конце концов, мы были вынуждены сделать то, что никто никогда не делал: реализация VMWare API библиотеки в PHP. К сожалению, не было никакой другой приемлемый способ сделать это.

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

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


Заключение

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

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

Тэги :

0 Комментариев

    Нет результатов.

Оставьте комментарий

Мы не опубликуем ваш email

Scroll To Top