Agile *

Привет Хабр!

В процессе чтения статьи от 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

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

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

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

Менеджер, как человек, который не должен лезть в технические детали, при виде прошедшего Continuous Integration билда, может однозначно сказать, хороший он или плохой. Зеленый — хороший, красный — плохой. Очень простой индикатор, да и не только для менеджеров, но и для всей команды в целом. Девелоперы на эту ситуацию смотрят немного иначе.

Представьте, что у вас что-то заболело (не дай бог, конечно). Вы идете к врачу и тут есть две возможности:

• «Резать к чертовой матери!»
• Вы идете сдавать анализы и после этого узнаете, что просто съели что-то не то

Лично мне и моим коллегам нравится второй вариант, именно поэтому, когда нас просят внедрить «эти ваши аджайлы», мы проводим аудит. Но мы не такие, как PricewaterhouseCoopers — мы лучше, мы неформальные и мы даем ценные результаты. Как именно — читайте под катом!

Я очень ленив, чтобы серьезно заниматься риск-менеджментом. Всегда считал это полной чушью, созданной неудачниками для отмазок в стиле: «А! Мы же говорили, что у вас ничего не получится!» Вон из моего проекта!

Кроме того — мы применяем аджайл. Мелкие итерации. И наши риски, и риски клиентов — ничтожно малы! А еще у нас есть типовые и четко очерченные в договорных отношениях этапы (не путать с agile-итерациями ;). Каждый раз, когда мы сталкиваемся с неопределенностью — мы разбиваем задачу на несколько мелких этапов и наши риски снижаются. Это же просто! Да? А теперь плохая новость:

Снижая риски добавлением этапов, мы снижаем рентабельность* всего проекта.

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

Итак, у нас есть абсолютно типовые этапы:

Ниже несколько, во многом очевидных, тезисов, которые могут помочь новичкам в Scrum

Немного о проекте и о командах.

Описанный проект — первый, на котором мы решили применить Scrum в полной мере.
До этого работали по итерациям, но без Stand-up митингов, Ретроспектив и Демок.

Работы над проектом ведут две команды.

Команда 1 создает систему документооборота, в которой будут готовиться данные для некого приложения, которое разрабатывает Команда 2.

Из-за этого в определенных итерациях мы пересекаемся и сильно зависим друг от друга

Итак.

Думаю, что большинство тех, кто внедрял у себя в командах тот или иной инструмент (особенно, если он родом из страны с другой ментальностью) согласиться, что внедрение не всегда проходит гладко. Однажды один академик мне сказал: «Ну а как ты хотел? Внедрение — это по определению вторжение чужеродного объекта в тело. Должно быть оСВОЕние. Делание своим!». С тех пор, для меня осознание того, что инструмент работает не совсем так, как задумывалось — является лучшим признаком освоения. Команда или сотрудник модернизировали по своему и начали использовать. И еще лучше, когда команда берет два разных инструмента и сама комбинирует их. Так произошло и в этот раз.

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

Приветствую, хабровчане!

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

Технология CRUD-матрицы — это хороший инструмент для каждого члена Agile-команды на протяжении всего жизненного цикла продукта. CRUD-матрица позволяет наладить адекватный диалог с клиентом и выявить дублирование функционала, а также устранить противоречивость модели. Что касается оценки времени, то в этом моменте CRUD-матрица значительно уступает такому инструменту, как “planning poker”, который позволяет провести адекватную оценку с учетом объективных причин.

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

С чего все начиналось

Scrum — достаточно простая методология. Работать же по скраму не так и просто. Точно так же происходит со многими инструментами, например с покером для планирования. Практика сама по себе вполне понятная, но продуктивно её использовать в течении длительного времени затруднительно.
В этой статье я расскажу про технику, которая упрощает процесс оценок в работе скрам команды.
Итак, в чём же сложность?
Как вы знаете, story points — это относительные оценки объёма работы в истории. Нет способа оценить одну единственную историю в story points, вы всегда сравниваете историю с другими историями через story points. Покер может хорошо сработать в начале проекта, когда команды оценивает много историй в течении короткого промежутка времени.
Но позже, во время регулярной переоценки существующих историй и оценок новых историй становится значительно труднее, потому что калибровка одного story point забывается: «что такое один story point», «что-то я не уверен, что эта история действительно в 3 раза больше нашего золотого эталона», «эти две истории размером 5 не выглядят одинаковыми в размере, с моей точки зрения». Знакомые проблемы?

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