Рубрика «scrum» - 14

Среди ваших знакомых наверняка есть люди, которые попробовали Scrum и решили отказаться. Возможно вы сами были в такой ситуации. Я обучался скраму у Джима Коплина, внутреннего тренера Microsoft, в Швеции. Работал в нескольких компаниях, в которых всё было по скраму. А так же в тех, где использовали классические методологии разработки. В этой статье я расскажу свои наблюдения и постараюсь раскрыть тайну скрама, почему же многим он так и не даётся. Читайте под катом.
Читать полностью »

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

В настоящее время, Scrum является одной из наиболее популярных методологий разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].

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

Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии :)

Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)

imageЧитать полностью »

Тема, о которой буду говорить, крайне неоднозначная. Предвижу нехилый холивар по этому поводу, если, конечно, статья заинтересует кого-то. Прежде, чем перейти непосредственно к чтению, взгляните ещё раз на заголовок и на его последнее слово. И не нужно говорить, что я не прав. Я и сам знаю, что многие со мной не согласятся. Да и цели у меня такой нет. Итак…
Читать полностью »

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

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

Хорошо, есть методология, которая выдумана командой программистов «для себя», но которую, по нашему мнению, будет интересно попробовать и другим. Внутри команды воссоздаётся небольшая экономическая модель рыночных отношений, а приоритеты регулируются при помощи курса внутрикомандной валюты. Читать полностью »

Гибкое управление проектами и продуктами

Думаю многие на Хабрахабр знакомы с блогом Бориса Вольфсона. Нам посчастливилось посотрудничать с Борисом и сделать замечательную книгу — Гибкое управление проектами и продуктами.

Книга доступна в печатном и электронном виде — PDF и EPUB. При покупке «живой» книги вы также получаете электронные версии (бонус действует только после подтверждения оплаты). А также в течение недели на нашем сайте действует скидка 20% на раздел книг — Карьера в IT-индустрии. Код купона — 2c4590fd98eca723.
Читать полностью »

Перевод статьи «Dependency Management in a Large Agile Environment».

Краткий обзор

Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.

1 Введение

В октябре 2006 года начался грандиозный переход отдела разработки (R&D) salesforce.com от модели водопада к гибким методологиям, основанных на Scrum. На тот момент прошло 10 месяцев с предыдущего мажорного релиза, а дата выпуска нового переносилась уже пять раз. Многих расстраивало, что продукт выпускается редко и с серьёзными опозданиями. Мы не стали дожидаться завершения релиза, реорганизовали существующие команды в Scrum-команды и с помощью процессов Scrum выпустили релиз в феврале 2007 года. С тех пор, используя наш новый гибкий подход, мы выпустили уже пять мажорных релизов (длительностью в 3-4 месяца) нашего набора SaaS приложений и платформы Force.com. Каждый из них состоялся точно в запланированный день.

Во время реорганизации мы следовали рекомендациям Scrum для отдельных команд, но не обращали особого внимания на взаимодействие между командами. Формируя команды, мы стремились минимизировать зависимости между ними, однако код не изменился в одночасье, так что сохранилось немало взаимосвязей. Довольно скоро мы внедрили Scrum-of-Scrum meetings. Эти встречи помогали обсуждать проблемы и состояние дел, но одних только собраний было недостаточно. Работая над последними пятью релизами, мы опробовали и отшлифовали дополнительные подходы, улучшающие взаимодействие команд. Далее в статье мы расскажем о некоторых трудностях с управлением зависимостями и о том, как мы преодолели эти проблемы.
Читать полностью »

Вместо введения

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

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

Для удобства сделал субтитры к видео, чтобы смотреть его было проще. Замечу лишь, что это не профессиональная видео лекция и лектор нигде эту методологию не читает специально. Дина Насырова (Тим Лидер из Fujitsu) пришла к нам в знак уважения, чтобы помочь наладить процесс работы коллектива и заодно поделилась своим собственным богатым опытом. Встреча прошла год назад — с тех пор много воды утекло. Но спустя время до сих пор вспоминаю ее, так как информация представленная в ней мне очень сильно пригодилась.
image
Читать полностью »

Привет!

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

Disclaimer: Статья не претендует на полноту или истину в последней инстанции. Автор тоже ни на что не претендует, а просто делится своими наблюдениями, как есть.
Читать полностью »

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

Нелицеприятный тест вашего Agile
Когда-то мне доводилось участвовать в попытках внедрения Agile в команде, разрабатывающей ПО. В регулярных дискуссиях, стараясь, чтобы это внедрение не превратилось в карго-культ, я снова и снова цитировал пост в блоге Элизабет Хендриксон. Ему уже больше трёх лет, но мне он нравится, и я бы хотел представить вашему вниманию (и вашей борьбе с карго-культом) перевод этого поста.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js