Agile *

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

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

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

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

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

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

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

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

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

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

Иногда заказчики писали свои цели в официальных документах к проекту. Иногда мне казалось, что я и так понимаю цели заказчика — они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.

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

Везде ли применимо проектное планирование

Любую деятельность компании или отдельного человека можно разделить на два состояния:

1. Я делаю (сделаю) что-то сейчас;
2. Я буду это делать в будущем.

Первое состояние очень популярно в торгово-закупочной деятельности:

• купить прямо сейчас;
• заказать прямо сейчас;
• позвонить прямо сейчас.

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

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

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

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

Перевод статьи «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. Эти встречи помогали обсуждать проблемы и состояние дел, но одних только собраний было недостаточно. Работая над последними пятью релизами, мы опробовали и отшлифовали дополнительные подходы, улучшающие взаимодействие команд. Далее в статье мы расскажем о некоторых трудностях с управлением зависимостями и о том, как мы преодолели эти проблемы.

Сегодня моя цель – коротко рассказать о подходах data-informed продуктового менеджмента, который я исповедую и попытаться заинтересовать вас в использовании его базовых инструментов в ваших продуктах.

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

Для себя я сформулировала, что измерения успешности продукта состоит из трех блоков:

— счастье пользователей;
— успешность (качественная и количественная) итераций и релизов;
— счастье команды.

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

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

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

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

Привет Хабр!

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

Под катом вас ждет небольшое путешествие в противоположную точку зрения.

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

Добрый день!

Одним из моих профессиональных интересов, как координатора команды тестировщиков, являются методологии разработки программного обеспечения. В настоящее время все большую популярность приобретают так называемые Agile-методологии, в особенности Scrum и Kanban. На «раcпиаренных» терминах играют недобросовестные «тренеры», семинары и сертификации («сертифицированный Scrum-мастер», «сертифицированный Product owner» и т.д.) растут как на дрожжах.

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

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

Вы руководитель нового проекта заказной разработки. Вам принесли договор, неизвестно кем и как заключенный, дали контакты заказчика и дальше вы предоставлены сами себе. Изучив функциональный объем проекта, вы понимаете, что в данном случае было бы правильно применить Agile. Но в договоре уже прописаны четкие фазы в соответствии с каскадной моделью разработки (waterfall) со сроками, результатами и фиксированной ценой по каждому этапу. Что делать в этой ситуации?

На www.edx.org в рамках курса Software as a Service опубликована интересная лекция технического руководителя (engineering manager) Дэнни Бурка (DANNY BURKES) о том, как устроена их работа в Pivotal Labs. Выдержками из этой лекции, переведенными на русский язык, хочу с вами поделиться.

Лекция построена следующим образом. Сначала рассказывается о философии разработки ПО в Pivotal Labs. Затем даны более конкретные рекомендации для разработчиков и менеджеров проектов. В конце рассказывается о практике найма людей в их организацию.

Если хотите почитать про содержание Agile Camp и marshmallow challenge, симуляцию Scrum, Business Model Canvas и персон, добро пожаловать под кат.

КДПВ

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

В статье описаны:

1. Manifesto for Agile Software Development
2. Agile Manifesto — IBM version
3. MoreAgile Manifesto
4. Agile Manifesto 2.1
5. Manifesto for Half-Arsed Agile Software Development
6. Declaration of Interdependence
7. Programming, Motherfucker
8. Software Craftsmanship Мanifesto
9. DevOps Manifesto

Слово «команда» очень часто используется в сегодняшнем деловом мире. Наверняка, каждый не раз в своей работе сталкивался с тем, что руководитель говорит: «Мы же одна команда!» Или: «Где ваш командный дух?» Или: «Мы должны быть одной командой!»

В лучшем случае сотрудники закивают головами. А на самом деле, разойдясь по своим рабочим местам, подумают: «А что это было? О какой команде идет речь? Зачем нам это? У нас и так все нормально…»