XP practices
Alexander
Я кратко пройдусь по ключевым практикам и постараюсь описать то, с
итогом, заработало это или нет.. в одном из проектов, над которыми я
работал.. Итак,
1. Stand-up meetings.
Чисто социальная практика и одна и фундаментальных, как в разработке
софта, так и повседневной жизни.. Что бы чего то добиться с компанией
людей, нужно постоянно делиться информацией, принимать решения и
действовать.. Оказывается, совсем не все так думают. Не знаю, в чем
искать проблемы, но стэнд-ап митинги выглядили, нечто вроде картины
"допрос пленного красноармейца".. В большей степени, мне приходилось
говорить одному, получая ответы "Да", "Нет".. в редком исключении что-
то больше.. Я замечал, что люди чувствуют себя не уютно, каждодневные
встречи просто начинают вызывать раздражение, и не понимание того,
зачем все это надо.. Хотя, каждый раз, я старался донести идею этих
встреч, и призывал к инициативности.. В итоге, я сократил встечи до 2-
х в неделю, потом до одной.. Сейчас общий митинг организовываю только
в "экстренном" случае. Люди, которые были в команде, небыли настроенны
на общение, они не привыкли к этому, и данное нововведение их
абсолютно не радовало. Сейчас, в 99% случаев беседую с каждым
идвидуально, и при необходимости сам доношу человеку информацию
переданную кем-то другим, выступая в роли ретранслятора.. Вместо того,
чтобы это один раз услышали все на общем, каждодневном митинге.
Итог: провал.
2. Peer review
По моему мнению одна из самых ценных практик. Не сомненно пир ревью
должны выполнятся.. Что произошло в моем случае. Лично я предполагал,
что пир ревью должны быть знакомы все девелоперы уровня MED, знать его
цели и использование.. Это не так.. На самых ранних этапах, я сам
выступал в роли инициатора процесса пир ревью (фреймворк, который
используется в комании для issue tracking имеет специальную
функциональсть для этого). Не раз объясняя то, что работа девелопера
без проведенного ревью и исправления дефектов не может считаться
завершенной.. Пир ревью в общем случае делались не охотно, либо не
приносили большой пользы.. На каком-то этапе, мне уже было сложно
прослеживать работу каждого из разработчиков, поэтому я просил, чтобы
инициаторами пир ревью были сами же разработчики (как это и должно
быть).. Человек практикующий ХР, сам прекрасно знает - "я не могу быть
уверен в том, что мой кусок работы закончен, пока его не посмотрит кто
нибудь другой".. Позже, к приближающимся дедлайнам, пир ревью просто
скипались.. Понимая то, что все равно они не несут практической
пользы, я воспринял это так как есть..
Итог: почти провал
3. Unit testing & Refactoring
Начальный опыт разработчиков по юнит тестированию варьировался от 0 до
отрицательных значений.. Т.е. либо про него не знали вообще, либо
имели негативный опыт. Один из членов команды утверждал, что занимался
юнит тестированием веб приложений, и у него об этом крайне не приятные
впечатления. Конечно, тестирование GUI сложный процесс, и как мне
кажется, редко приносящий действительный результат.. Человек
занимающийся бизнес логикой, с юнит тестами не работал.. Поэтому,
крайне тяжело было внушить что, что TDD (test driven development) это
не про то "что написанно в книжках", а то что реально работает и
приносит результат.. Радует то, что мне удалось переубедить, показав
как это можно и нужно делать пояснив правило: write test first (не
поверите, как было приятно, когда этот человек зашел и сказал "блин..
такой дефект сейчас с помощью юнит теста нашел.. так был его никогда
не обнаружил"). Однако, имея мало опыта с юнит тестированием
разработчик так проектирует свои классы и методы, что они сложно
поддавались тестированию вообще.. Тут есть моя вина в том, что из-за я
не заметил эту проблему с самого начала (т.к. почти не заглядывал в
код) и на этапе дизайна, эта важная деталь мною была пропущенна.. В
результате этого сейчас образовалась большое количество кода, либо
вообще без тестов, либо из-за проблем проектирования, не поддающаяся
юнит тестированию.
Отмечу также свою вину в том, что при планировании на юнит
тестирование, отводилось неадекватное количество еффорта.. что в
некторых случаях провоцировало пропуск юнит теста.
Refactoring, как неотемлемый процесс, также стал под угрозой.. Не имея
должного покрытия тестами, рефакторинг превращается в процедуру
переливания из пустого в порожнее, причем без контрольную.. К
сожалению, большинство тоже очень плохо понимает, что рефакторинг
кода, который не покрыт тестами это 100% внесение еще одной ошибки.
Итог: почти провал
4. Continues Interation
Радует, что большинство людей понимает для чего нужен Cruise Control,
и зачем нужны каждодневные сборки. Но не все понимают того, что это
должна быть не только компиляция, которая ничего не говорит о
состоянии продукта, а и запуск тестов, снятие метрик и т.д.
Итог: почти успех
5. Collective code ownership.
Я пытался подчеркнуть то, что кодом владеет вся команда, т.е. она в
равной степени несет за него отвественность, и все в равной степени
могут его изменять. Детская психика взрослых разработчиков, к
сожалению, совсем не походит к ХР.. Ко мне подбегает девелопер, со
слезами на глазах, что без спроса, "его" код был изменен, он там
ничего теперь не понимает и тот человек все сломал.. и просто, "шеф
все пропало!".. я знаю ситуацию, и знаю для чего это менялось..
Объяснение принципов Collective code ownership не приносят ни какого
успеха.. Не возможно (по крайней мере мне) человеку сказать в
"дружище, ты %№#-ню написал, твой товарищь ее исправил", появляются
обиды, со всеми вытекающими последствиями.. В итоге эти разработчики
начинают считать, что прожект менеджер ущемляет их права..
Итог: провал
6. Iterations and planning.
Даже не знаю, какая из компаний сейчас не использует итеративной
модели. Итерации и планирование релизов были сделаны, все было
нормально.. Но.. есть одно но)..
О планировании.. Что предполагает ХР - частый пересмотр планов,
переоценка, коррекция и уточнение.. Причем, эти планы краткосрочные
(по крайней мере не длительные). Идея основывается на том, что весь
ход проекта очень тяжело предсказать.. Подход несомненно верный.. Но
что происходит в жизни?
Я просмотрел здесь статью, о том "Как уговорить заказчика перейди на
SRUM", прошу прощения, и я возможно не прав, но.. как я понял, люди
которые это писали никогда никого не уговоривали, а если они работают
сейчас с использованием этих практик, то потому что, топ менежджмент
этой компании сами хорошо знают эти практики и имеют большой опыт,
соотвественно заключают с заказчиками правильные контракты.. и прожект
менеджера в дальнейшем эти вопросы не беспокоят..
Я не могу вдаваться в подробности, поэтому скажу очень кратко.. Помимо
всяких проектных вещей, одна из самых главных есть контракт (между
компанией и заказчиком). Так вот, контракт может быть составлен таким
образом и с такими обещаниями, которые противоречат практике
пересмотров и коррекции планов, в ходе выполнения проекта.. Поэтому
один из уроков, которые я вынес, при переходе на новый проект,
требовать предоставить тебе контракт, чтобы полностью быть
осведомленным о тех рамках в которых ты находишься.
Тут понятна сторона компании, есть заказчик с которым она хочет
работать.. Заказчик почти ничего не знает о IT, но понимает, что он
хочет получить.. Причем, как человек не знающий о рисках производства
ПО хочет иметь четкие даты, когда проект будет сделан.. присутсвие в
контракте фразы - "полный график выполнения проектных работ будет
пересматриваться ежемесячно, с поправкой промежуточных и финальной
даты поставки и бюджета проекта" отпугнет любого желающего подписать
данный контракт.
Итог: использовалась, но плохо ложилась в контрактные условия
Хотелось бы написать еще.. но думаю, пока хватит..
Сделаю маленькое резюме.. Я прекрасно понимаю, что может быть мои
способности донести информацию до людей не идеальны.. может быть, я
некоторых вопросах был не настойчив.. и допускал ошибки.. я это совсем
не отрицаю..
Но сейчас имею четкий вывод для себя: "ХР, или другая гибкая методика,
не создает процесс, направленный на создание продукта, а люди которые
работают над продуктом, создают себе этот процесс руководствуясь
определенными правилами".
Не заработает никакая методика, если она не поддерживается группой
людей. Не получиться взрослому человеку, рассказать что и как надо
делать (потому что в глубине души он прячет улыбку, мол начитался
умных книжек, теперь свои мысли навязывает).. Не получится, заставить
человека говорить на митингах, если он не умеет или не хочет общаться
с людьми. Не получиться человека заставить просить другого
разработчика посмотреть его код, если он считает, что ошибка найденная
у него это какой-то укор.. Не получиться заставить человека писать
юнит тесты, если сам он не понимает того, что не может быть уверен в
коде, для которого, юнит теста нету.. Для ХР нужна команда (не группа
людей, а именно команда) которые очень хорошо знакомы с целями каждой
из практик и умеют ими пользоваться (в таком случае, даже новый
человек в нее вольется без проблем и сам быстро обучится).. Для ХР
нужна определенная культура, которая с большинстве случаев отсутсвует.
Люди в команде, должны уважительно относиться друг к другу и считать
проектный успех, как свой личный и неудачу, как свою личную.. такая
команда способна на многое.. и какую методологию тут использовать,
вопрос второстепенный..
Благодарю за внимание,
С уважением
Alexey Krivitsky
не спеши ставит крест. не вышло пока, получиться позже.
советы:
посади всех в одну комнату, и расставьте мебель так, чтоб общение
стало свободным и делалось не когда менеджер приказал, а по
необходимости.
когда двое общаются, соседи должны слышать краем уха, чтоб быть в курсе.
купить flip chart или что-то в этом роде, как активатор информации - к
примеру туда можно вешать список багов на неделю, график соотношения
открытых-закрытых багов. что-угодно, что интересно всем в настоящий
момент.
поставить это штуку в таком месте, чтоб возле неё можно было общаться
хотя б втроем.
вешайте задачи в виде sticky-notes (побольше 15x8 см чтоб было видно издалека).
на плакат с разделениями: new | in dev | in testing | done | closed
проводите митинги возле этой штуки, заменив "доклады" на просто то,
что каждый по очереди перемещает свои задачи в зависимости от
прогресса.
будь примером на своих задачах.
но не бери на себя инициативу делать что-то за кого-то.
когда есть необходимость поделиться инфой больше, чем с 1 человеком.
говори громко и всем.
народ в итоге любит быть информированным.
используйте wiki для обмена инфой.
пейте вместе пиво. много.
делая вышеописанное в любых комбинациях рано или поздно дасть
ожидаемый результат. не поможет - меняй команду через полгода.
> 2. Peer review
> По моему мнению одна из самых ценных практик. Не сомненно пир ревью
> должны выполнятся.. Что произошло в моем случае. Лично я предполагал,
> что пир ревью должны быть знакомы все девелоперы уровня MED, знать его
> цели и использование.. Это не так.. На самых ранних этапах, я сам
> выступал в роли инициатора процесса пир ревью (фреймворк, который
> используется в комании для issue tracking имеет специальную
> функциональсть для этого). Не раз объясняя то, что работа девелопера
> без проведенного ревью и исправления дефектов не может считаться
> завершенной.. Пир ревью в общем случае делались не охотно, либо не
> приносили большой пользы.. На каком-то этапе, мне уже было сложно
> прослеживать работу каждого из разработчиков, поэтому я просил, чтобы
> инициаторами пир ревью были сами же разработчики (как это и должно
> быть).. Человек практикующий ХР, сам прекрасно знает - "я не могу быть
> уверен в том, что мой кусок работы закончен, пока его не посмотрит кто
> нибудь другой".. Позже, к приближающимся дедлайнам, пир ревью просто
> скипались.. Понимая то, что все равно они не несут практической
> пользы, я воспринял это так как есть..
>
> Итог: почти провал
проблема скорее в отсутствии code ownership
лечится.
не ассайнь задачи на программистов. вместо этого дай им выбирать то,
что нравится из общего пула. и лучше это делать на общем митинге.
объясни, что важно, что все были знакомы со всеми частями системы.
и чтоб люди не боялись брать задачи из "неизвестных" им мест в системы.
если у вас есть "эксперты" по тем или иным частям системы, проси их
помогать народу, который берет задачи по их частям.
говори слова "мы команда, наш код, общие задачи" как можно чащи и вслух.
исправляй, когда кто-то говорит "мой код, мои задачи" и проч.
сложные задачи делайте в паре. буть примером. посиди с каждым по
очереди по 2-3 дня. узнаешь о людях очень многое.
введи правило писать тест на каждый баг ДО починки.
введи тесты в критерий "done"
веди статистику кол-ва тестов понедельно, вешай это на ваш
"информационный активатор".
не сдавайся !
> 4. Continues Integration
> Радует, что большинство людей понимает для чего нужен Cruise Control,
> и зачем нужны каждодневные сборки. Но не все понимают того, что это
> должна быть не только компиляция, которая ничего не говорит о
> состоянии продукта, а и запуск тестов, снятие метрик и т.д.
>
> Итог: почти успех
поднимается за 3-5 дней на любом проекте на java или .net вместе с тестами.
считай, что билд failed если упал хотя бы один тест.
когда билд падает - кричи, и говори, что это самая важная задача в любое время.
принимай задачи на сборке от CruiseControl - никогда на локальной машине.
> 5. Collective code ownership.
> Я пытался подчеркнуть то, что кодом владеет вся команда, т.е. она в
> равной степени несет за него отвественность, и все в равной степени
> могут его изменять. Детская психика взрослых разработчиков, к
> сожалению, совсем не походит к ХР.. Ко мне подбегает девелопер, со
> слезами на глазах, что без спроса, "его" код был изменен, он там
> ничего теперь не понимает и тот человек все сломал.. и просто, "шеф
> все пропало!".. я знаю ситуацию, и знаю для чего это менялось..
> Объяснение принципов Collective code ownership не приносят ни какого
> успеха.. Не возможно (по крайней мере мне) человеку сказать в
> "дружище, ты %№#-ню написал, твой товарищь ее исправил", появляются
> обиды, со всеми вытекающими последствиями.. В итоге эти разработчики
> начинают считать, что прожект менеджер ущемляет их права..
>
> Итог: провал
см выше.
> 6. Iterations and planning.
> Даже не знаю, какая из компаний сейчас не использует итеративной
> модели. Итерации и планирование релизов были сделаны, все было
> нормально.. Но.. есть одно но)..
>
> О планировании.. Что предполагает ХР - частый пересмотр планов,
> переоценка, коррекция и уточнение.. Причем, эти планы краткосрочные
> (по крайней мере не длительные). Идея основывается на том, что весь
> ход проекта очень тяжело предсказать.. Подход несомненно верный.. Но
> что происходит в жизни?
>
> Я просмотрел здесь статью, о том "Как уговорить заказчика перейди на
> SRUM", прошу прощения, и я возможно не прав, но.. как я понял, люди
> которые это писали никогда никого не уговоривали, а если они работают
> сейчас с использованием этих практик, то потому что, топ менежджмент
> этой компании сами хорошо знают эти практики и имеют большой опыт,
> соотвественно заключают с заказчиками правильные контракты.. и прожект
> менеджера в дальнейшем эти вопросы не беспокоят..
я перевел 2 проекта на scrum
один раз ушло 9 месяцев.
второй - 3.
> Я не могу вдаваться в подробности, поэтому скажу очень кратко.. Помимо
> всяких проектных вещей, одна из самых главных есть контракт (между
> компанией и заказчиком). Так вот, контракт может быть составлен таким
> образом и с такими обещаниями, которые противоречат практике
> пересмотров и коррекции планов, в ходе выполнения проекта.. Поэтому
> один из уроков, которые я вынес, при переходе на новый проект,
> требовать предоставить тебе контракт, чтобы полностью быть
> осведомленным о тех рамках в которых ты находишься.
>
> Тут понятна сторона компании, есть заказчик с которым она хочет
> работать.. Заказчик почти ничего не знает о IT, но понимает, что он
> хочет получить.. Причем, как человек не знающий о рисках производства
> ПО хочет иметь четкие даты, когда проект будет сделан.. присутсвие в
> контракте фразы - "полный график выполнения проектных работ будет
> пересматриваться ежемесячно, с поправкой промежуточных и финальной
> даты поставки и бюджета проекта" отпугнет любого желающего подписать
> данный контракт.
>
> Итог: использовалась, но плохо ложилась в контрактные условия
не верю, что нет выхода.
и что тебе до контракта? ты его не подписывал (!)
начни с демонстраций софта каждую одну-две недели.
привлека заказчиков по полной.
требуй недельных планов.
не заметишь, как уже будет полный agile
почти все успешные команды набирались по одному.
командами они становились уже по ходу
вывод - команды строятся и это реально.
* No matter the circumstances you can always improve.
* You can always start improving with yourself.
* You can always start improving today.
(c) Kent Beck, "Extreme Programming Explained: Embrace Change"
попробуй с сегодняшнего дня говорить вместо "не получиться" -
"тяжело, но реально, попробуем-ка это: ...."
отличный пост, саша. пиши ещё :)
лё
Alexey Krivitsky
вот хорошая статья по поводу причин противостояния предложениям,
с парой толковых советов (на англ):
http://www.dhemery.com/articles/resistance_as_a_resource.html
у меня была (и пока что есть ещё остаточные явления)
похожая ситуация: любые мои предложения воспринимались "в штыки".
и дело тут не в квалификации команды, и не вкачестве даваемых советов,
а в эмоциональной окраске.
надеюсь поможет
удачи!
Vasiliy Keretsman
> > всяких проектных вещей, одна из самых главных есть контракт (между
> > компанией и заказчиком). Так вот, контракт может быть составлен таким
> > образом и с такими обещаниями, которые противоречат практике
> > пересмотров и коррекции планов, в ходе выполнения проекта..
> >
> > Итог: использовалась, но плохо ложилась в контрактные условия
>
> не верю, что нет выхода.
> и что тебе до контракта? ты его не подписывал (!)
Леша,
Мне немного Сашина ситуация знакома.
Я не согласен, что при внедрении Agile не надо брать во внимание
текущее состояние дел. Контракт очень сильно "цепляет" процесс
разработки в таких условиях.
Это особенно характерно для небольших компаний, которые не могут себе
позволить перебирать клиентами. Параллельно ведется разработка
нескольких проектов. Количество ресурсов ограничено, поэтому всякими
методами стараются выжать по максимуму из того, что имеется.
С клиентом договариваются менеджеры, которые не всегда понимают, что
такое разработка ПО. Чтобы "захватить" клиента даются не реальные
обещания. С клиентом обговаривается вся функциональность,
устанавливаются сроки с потолка, это все прописывается в контракте, а
разработчики ставятся в итоге перед фактом. Часто вносятся изменения в
требования, когда разработка началась.
Цель, с точки зрения менеджера(начальства), не создать хороший
продукт, а успеть в обещанные сроки, чтобы получить оплату от клиента.
Качество мало интересует. Получится хорошо - отлично, нет - ну ничего
страшного. Как мне когда-то популярно объяснили - баги можно фиксить и
после релиза и клиент за это еще будет платить в рамках поддержки :).
Если в таких условиях пробовать что-то менять только снизу, то именно
контракты и станут на пути (косвенно конечно), так как в них заложен
"процесс" (время и деньги).
Внедренние любого agile процесса предусматривает изменения на всех
фронтах - разработка, менеджмент, продажи и т.д.
Если скроки не реальные, в контракте четко прописано что проект должен
быть готов через 2 месяца и если еще есть какие-то штрафные санкции,
то как в таких уловиях можно внедрить например тот же XP?
Убрать TDD, парное программирование, peer review, планирование (за
тебя его уже и так сделали) - и что получим на выходе? :)
Вася.