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 покарает вас»

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

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

В прошлый раз я рассказал о том, как, на мой взгляд, должны выглядеть карты процессов для пользовательской истории, задачи, бага (UserStory, Task, Bug). В этот раз я хочу рассказать, как все это настроить в Visual Studio.  Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.

После установки TFS Power Tools, в VS должен появиться новый пункт в меню Tools.



На скриншоте уже показано, что необходимо сделать для того, чтобы начать редактировать элементы задач. Tools > Process Editor > Work Item Types > Open WIT from Server. Такой выбор позволит сразу получить изменения на сервере. В целом все пункты последнего меню говорят сами за себя и с минимальными экспериментами можно получить представление об их действии.

Я хочу рассказать о том, как можно расширить стандартный процесс (workflow) для некоторых элементов в TFS 2010 (про 2011 будет позже) при выборе шаблона Agile для проекта. Так же интересно услышать мнение хабрасообщества по поводу донастройки шаблонов, кто как настраивает workfolw. Расскажите, как это делаете вы, очень интересно.

Стандартные настройки проекта out-of-box на мой взгляд достаточно бедны и не обеспечивают должной прозрачности, если необходимо отслеживать/контролировать работу над проектом распределенной команды, либо когда управляющий (менеджер или еще какой-нито начальник) желает видеть как идут дела с задачами. Стандартные настройки не позволяют, на мой взгляд, уверенно говорить о текущем состоянии задач.

Обычная рабочая доска (task board) имеет больше состояний, нежели базовые настройки типичных артефактов управления проектом из которых строится процесс Agile: UserStory, Task, Bug. Мне кажется это базовые вещи, которые стоит рассмотреть и дополнительно настроить, что собственно я и сделал для себя и команды.  В рассказе ниже я затрону только настройку процесса перехода состояний, не затрагивая свойства элементов. Т.е. никаких кастомизаций внешнего вида и свойств не будет.

Прежде чем двигаться дальше, расскажу, какие инструменты вам понадобятся. Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.

Продолжаем разговор о степени погружения в Agile начатый здесь.
Логичным продолжением предыдущей статьи будет рассмотрение Agile Evaluation Framework (сокращенно Agile:EF). Если говорить кратко, то это фреймворк детальной оценки глубины внедрения (или степени освоения) определенных практик. Ключевым словом тут является «детальный» и «фреймворк».

Существует несколько метрик, позволяющих определить глубину погружения в Agile практики вашей команды. Первым методом измерения, который мы рассмотрим, будет Shodan Adherence Metrics – Метрика соответствия уровню «Шодан» (Шодан – первый дан – первая мастерская степень в японских боевых искусствах).

Автор оригинальной идеи этой статьи — Джон Иннс, консультант в области гибких методологий IT-разработки. С первоисточником можно познакомиться здесь. Мы его немного доработали, много упростили, но теперь статью, хотя бы, можно читать :)



Итак, есть такая штука, как опыт пользовательского взаимодействия (тот самый UX, User Experience). В целом, UX — это впечатление пользователя от вашего продукта (например, сайта). Сюда относится внешний вид, удобство расположения кнопок, ссылок и других элементов.

Почему учитывать опыт взаимодействия — важно?

Давайте познакомимся с новыми инструментами планирования, появившимися в TFS 11 Beta, которые можно использовать в разработке Windows, Web, мобильных, облачных и кросс-платформенных приложений.



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

План захвата темы:
• Описание требований (Backlog)
• Планирование итерации
• Планирование работ
• Загруженность исполнителей

Как менеджер проектов в своё время я попытался интегрировать различные Agile/SCRUM методики в свою повседневную жизнь. Ведь она тоже в каком то смысле является долгосрочным и довольно динамичным проектом.

Неоднократно пробовал использовать популярные GTD инструменты, но в итоге именно Google календарь ввиду своей наглядности и привязке ко времени — оказался наиболее эффективным. Получается такой вот Self SCRUM Board с итерациями и планерками :)

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

Теперь хочу подробно разобрать пример построения контрольной карты Шухарта на основе реальных данных. В качестве реальных данных я взял историческую информацию о завершенных личных задачах. Эта информация у меня есть благодаря адаптации под себя модели личной эффективности Дэвида Аллена Getting Things (про это у меня тоже есть старый слайдкаст в трех частях: Часть 1, Часть 2, Часть 3 + Excel-табличка с макросами для анализа задач из Outlook ).

Постановка задачи выглядит так. У меня имеется распределение среднего числа завершенных задач в зависимости от дня недели (ниже на графике) и нужно ответить на вопрос: «есть ли что-то особенное в понедельниках или это всего лишь погрешность системы?»



Ответим на этот вопрос при помощи контрольной карты Шухарта – основного инструмента статистического управления процессами.

Не могу не опубликовать размышления от Тани Васильевой по поводу предстоящей 5-6 марта CSM сертификации в Петербурге. Не поспоришь!

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