Agile теория против практики.

Октябрь 7th, 2009

В прошлой статье Andrey Yasinetskiy сказал, что мой манифест работодателя противоречит Agile. Я так взял, взвесил agile практики, которые знаю, почесал в голове, отписал, что они не противоречат. А потом я полез и прочел Agile software development статью в wiki. и обнаружил, что большинство практик на самом деле противоречат первому же пукнту Agile манифеста.

Самый первый пункт манифеста — «Individuals and interactions over processes and tools«. Блин, да половина agile дисциплин основана именно на следовании процессов. Test driver development, continuous integration, code refactoring, iterative development — это же все процессы. Причем, если взять какие-нибудь уже готовые методики (а-ля того же SCRUM) то эти процессы там уже четко прописаны, описаны, роли, действия, артифакты и т.п. Да, естественно в каждой из них есть «individuals and interactions», но как только individual решать забить на процессы, которые им не нравятся — а-ля перестанут код класть в source control, остановят систему генерящую билды и перестанут делать итеративную разработку, вот тут как раз и придет пипец их попыткам работать Agile.

Кстати, аналогично насчет послднего пункта Agile манифеста «Responding to change over following a plan«. Это не значит, что надо нафиг забить на план. Это значит, что план должен изменяться в зависимости от внешних событий.

В целом, можете в меня хоть помидорами кидать, но Agile Manifesto в чистом виде — это радужные мечты богемы IT мира. Для всего же остального мира, Agile практика (которая таки требует процессов и изменчивого плана) кроет как бык овцу Agile теорию.


Манифест работодателя.

Октябрь 6th, 2009

Решил написать манифест работодателя, который будут давать всем людям в случае если они собираются на меня работать.

Правило N.0. В тот момент, когда вы начинаете работать со мной вы либо принимаете правила, которые я озвучиваю и мы сотрудничаем, либо отвергаете их и мы не сотрудничаем.

Самый простой и лучший метод быстро закончить со мной сотрудничество не выполнять правила обговоренные заранее.

Если вы знаете, что какие-то правила вам не подходят, то озвучивайте наперед, тем самым экономя свое и мое время и нервы.

Правило N.1. Если вы работаете со мной, то вы делаете то, что мне нужно, а не то что вам хочется.

Если мне нужен разработчик исправлять баги, то таки надо исправлять баги, а не изучать новый очень интересный язык и экспериментировать с ним в проекте(не дав мне об этом знать).

Правило N.2. Отчетность всегда является самой критичной и важной задачей.

Я должен быть в курсе того, что происходит. Отчетность должна быть краткой и четкой (не обязательно писать Войну и Мир по поводу каждого бага).

И если я НЕ знаю, что работа сделана, то я подразумеваю, что она НЕ сделана.

Кстати, как небольшое уточнение. Отчетность может быть в разном виде — личное общение, электронная почта, какие-нибудь системы для отчетности. Главное — она должна быть.

Правило N.3. Если вы freelancer, это не обозначает, что вы free работать по времени когда вам хочется и сколько вам хочется.

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

Правило N.4. Во всем, что относится работы, я не терплю лжи или специального искажения информации.

То есть, не должно быть отчетов, что все готово на 95%, когда оно готово на 20% (при том, что работник на самом деле это знает наперед).

Правило N.5. Работа должна делаться.

Никаких размазываний работы и создания видимости, что дело делается. У каждой задачи есть четкие цели, которые должны достигаться.

А теперь добрая часть.

Я всегда оплачиваю работу полностью и в срок.

Даже если работа НЕ качественная, я оплачиваю ее (правда больше не сотрудничаю).

Оплату провожу своевременно, без задержек (хотя увы пару прецедентов мало зависящих от меня были).

Я всегда готов идти на уступки

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

Я всегда заинтересован продолжать сотрудничество с хорошо работающими людьми.

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

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




Эффективная система разработки.

Сентябрь 30th, 2009

Товарищ по оружию avl проводит семинары о построении эффективной системы разработки.

Вырезка из его блога: «В ходе тренинга с 5 по 11 октября мы последовательно будем строить эффективную систему, позволяющую избежать наиболее частых ошибок при разработке ПО и решать требуемые задачи наиболее эффективно.»

И дополнительная информация находится тут.

Freencaler’ы — засранцы?

Сентябрь 27th, 2009

В ответ на статью Станивлава Малкина, о том, что все русскоговорящие заказчики чаще всего засранцы пишу ответную статью, о том,  почему большинство удаленных русскоговорящих (да и не только) freelancer’ов тоже засранцы. 🙂 (2Станислав — шутка само собой).

На самом деле у меня есть всего две вещи, которые хочется сказать, но которые меня (как русскоговорящего заказчика) просто выводят из себя. Причем это не то, что произошло один раз
или с одним человека, а вполне таки систематическое действие большинства freelancer’ов.

а) «Исчезания».

Работал уже с приличными количеством freelancer’ов (количество подбирается к десятку) и фактически все считают нормальной ситуацией исчезнуть на недельку, без предупреждения и отвечания на любые внешние прерывания (а-ля телефоны и почта). После чего, появиться, причем зачастую делая вид, что собственно говоря ничего и не произошло.

Дорогие товарищи freelancer’ы, обращаюсь к вам как представитель класса заказчиков. Это самый лучший метод потерять нас, даже если в остальное время вы супер-пупер потрясающе
исполнительные.

Одна мысль заказчика, что эта неделя исчезания могла произойти в какой-то важный момент автоматически ставит крест на всех остальных положительных пунктах.

Кстати, проблема само собой не само исчезание, а то что о нем не оповещается. Таким образом заказчик остается без возможности принимать решения на основе полной информации о ситуации.

б) Не делание того, что говорилось раньше.

Одна из идей длительной и плодотворной работы freelancer’а с заказчиком — это «притирание» с обоих сторон. Когда заказчик вам говорит — после того как вы исправили баг — пишите мне об этом, то лучше всего это и делать, так как он это делает редко просто так. Зачастую же выходит, что freelancer делает только то, что он считает полезным или нужным делать. Мы даже не говорим о каких-то технических решениях, где freelancer может быть прав, а заказчик не прав. Мы говорим о том, чтобы заказчику было удобно и хотелось с вами дальше работать. Как вы считаете, если он вам дал 5-10 простых правил — после каждого бага мне письмо, исходники присылать раз в неделю и т.п, то нормально ли забывать это в 80% случаев после несколько разового упоминания?

И снова дорогие товарищи freelancer’ы. Это второй по порядку самый лучший метод поставить крест на остальных ваших плюсах. Действительно, нефиг заказчику выпендриваться, пусть сам беспокоится о том, что я должен делать и постоянно мне об этом напоминает. Это правильный подход к жизни.