Agile *

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

Зачем менять то, что работает? Действительно, поговорка гласит: «Не трогай матчасть и она тебя не подведет». «Есть у нас Redmine и мы им пользуемся. Так зачем же нам менять его на YouTrack, да еще и за деньги?» — резонный вопрос, задаваемый коллегами. Вопрос известен и ответ на него очевиден: незачем. Но давайте взглянем на проблему с другой стороны.

Проблема создания качественного пользовательского интерфейса (UX-интерфейса) действительно существует. Конкретно — она проявляется, когда компания-разработчик использует гибкие методологи. Собственно причина того есть совокупность двух моментов:

• Итеративность работы программистов. В Agile разработчики предпочитают создавать проект «по частям», отдельными итерациями. И таким же образом «передавать» получающийся продукт заказчику.
• «Целостность» работы дизайнеров. UX-дизайнеры предпочитают продумывать и разрабатывать концепцию целиком. Соответственно, по готовности цельной концепции — они передают ее в разработку. Такой подход заставляет дизайнеров выбиваться из общего ритма, что порождает проблемы с распределением рабочего времени.

Намечается два пути: оставить дизайнеров в покое или попытаться вовлечь их в Agile (притом стараясь никого не покалечить). В первом случае придется жертвовать темпом, во втором — качеством конечного продукта. Или есть третий путь?

Сначала пример с большой красной машиной

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

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

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

Парное программирование является одной из практик XP. Эта практика воплощает экстремальную (преувеличенную) идею Code Review. Если ревью позволяет улучшить качество кода, то давайте делать его постоянно, во время рефакторинга и написания нового кода.

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

За годы участия в разработке ПО, я вывел для себя 3 правила, пересечение которых дает нужный результат: Делать правильные вещи правильно и быстро. Любопытно взглянуть, как Scrum нам помогает достигать эти цели?

Моя статья будет представлять собой больше набор историй из жизни и некоторые выводы из них. Основная проблема, которая меня сейчас волнует: как сделать так, чтобы довольны были и заказчики, и разработчики, и прибыль была и карма цела. Конкретного окончательного рецепта у меня нет, есть несколько отрицательных примеров и намеченные цели, которыми хочется поделиться.
Я занимаюсь разработкой с 2003 года (в основном web-приложения), до этого 4 года преподавала в ОмГУ основы программирования для 1-го курса математического факультета. На данный момент у меня пошел 3-й год в роли совладельца собственной небольшой аутсорсинговой компании. Рассказывать буду исключительно о своем опыте по двум причинам: я успела побывать в трех различных типах компаний, которые могу сравнить, и считаю, что пересказ чьего-то опыта не дает полной картины.

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

Когда-то я был тестировщиком. Помню, как в те далекие времена порой был крайне недоволен программистами:

Эти вечные сомнительные доводы «это не баг, это фича» или «если это и баг, то незначительный, пусть остается».

Да как же остается, если система колом встает!?

Потом я стал программистом. И всё изменилось – меня начали жутко бесить эти бесконечные возвраты на доработку:

То им это не нравится, то тут не работает! Да нафига было вообще в этом окне контекстное меню вызывать и вставлять нечитабельные символы!? Как они вообще до этого додумались!? Бред же, в боевом режиме так ни один пользователь не сделает!

Не буду править, пусть остается!

В общем, классика – вражда программистов и тестировщиков.

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

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



Понять последних можно, ведь большинство статей и agile-евангелистов говорят, примерно следующее: «Делайте так, как говорит методология, и ваш проект попадёт в рай. Если нарушите хотя бы одну из практик, то Agile покарает вас»