И еще один пинок мяча в те же ворота, что и прошлой статье. Все таки, меня удивляет вот такое отношение к Scrum (взять отсюда):
Scrum creates self organized teams. They organize themselves, they organize their quality. They organize their tools. They organize their engineering practices (TDD, pair programming). Why? Because they are responsible for delivering. No one else is.
Господи, ну какая-же фигня. Объясните почему вдруг у них появляется супер-пупер ответственность за результат.
Раньше команда писала код, тестировала, делала документацию. И теперь это делает. Раньше ей нужно было делать это качественно, теперь тоже. Ну ладно, пусть команда становится поближе к рулю в том, чтобы определить, что значит качественно.
Но вот только не надо мне рассказывать, что из плохо организованной, немотивированной команды Scrum сделает сплоченный коллектив, и все как один с флагами будут responsible for delivering.
Еще раз повторю мысль из предыдущей статьи. Scrum — это методика управления проектами. Все остальное в нем не большые добавки и приятности. Но это никак не методика повышения ответственности команды.
Сижу вот на работе лабаю презентацию Scrum’а. Где-то когда я ее сделал до половины и увидел, что выходит она мягко говоря корявая, решил заглянуть в интернет.
Блин… Это же ужас. Нет, это не ужас, это ужас-ужас. Все презентации сделаны так, как будто они сделаны для фильма. Знаете, когда в фильме тренер выступает перед командой (футбольно или баскетбольной) и под маршевую музыку вещает а-ля «вы команда, вы можете — общайтесь, слейтесь в единое и вы их порвете». И вот команда с запузыренными мозгами выбегает на поле и действительно рвет всех на своем пути.
Не знаю, уже кому приносят удовольствие такие презентации. Может конечно высший менеджмент может немножко возбудиться на такое дело, представляя, что все фирма — это команда американского футбола и как они под его руководством побеждают в мировом чемпионате. Но всех остальных должно мощно тошнить от таких вещей.
Ладно, черт с этим первым типом презентаций, есть еще второй тип , которые подробненько рассказывают как Scrum работает. То есть походово рассказывают о Backlog’е, Sprint’е, ежедневных митинга, игре в покер и о каждом новом слове, которые придумали и засунули в Scrum. Ну? И те, кто делал эти презентации действительно считают, что вот если не рассказать про игру в покер или ежедневный митинг или про все роли в Scrum, то все… никто его не будет пользовать. И вот только за этот самый покер его полюбят и сразу приймут.
В общем, в печку такие презентации.
Scrum впервую очередь предназначен для управления(project management). Соответственно первая презентация должна показывать проблемы текущего метода управления (причем конкретно тыкать носом — вот то говно, в которые вступаем каждые три дня) и рассказывать о Scrum’е ровно столько чтобы показать, как он решает эти проблемы.
Все остальные вещи, типа кто такие свиньи и курицы в Scrum, что команда обязательно должна суперактивно общаться и что баги принято называть дефектами… э… можно опустить и не вспоминать вообще.
В куче статей, я писал, мол, нужны процессы — нужны процессы.
Пришло таки время написать о чем же я писал все это время.
В самом простом виде, я бы сказал, что когда ты прочищаешь мозги на одну и ту же тему три раза Васе, два раза Пети. А потом тебе надоедает прочищать мозги всем им по отдельности и ты пишешь документ, рассылаешь всем и говоришь: «Делать надо так как написано в этому документе и теперь не отнекивайтесь, что вам об этом никто не говорил и нету четкого описания как делать». Так вот, записанная последовательность, того чего делать и чего не делать и есть процессы.
Конечно, процесс может быть таки и не записан. Но пока он не записан, найдется, таки Коля, который все сделает наоборот и потом искренне будет удивляться, почему ему устроили темную.
Дальше больше. Для каждой компании есть свой оптимальный размер процессов. Когда вы делаете софт для космического корабля, то любой commit должен быть просмотрен кучей людей, для него должно быть куча разнообразных тестов, он должен быть правильным по куче стандартов. То бишь, там тома с описаниями их процессов. И наоборот, для конторы из одного человека, двух-трех процессов (а-ля, весь код в SVN, все баги в bugtracker) должно хватать. Ну и естественно, если компания выбирает неправильный уровень, какое количество процессов ей нужно, то либо в ней все будет делаться на коленке (и по ходу разваливаться), либо в ней что-бы пукнуть, нужно будет подписать пять обходных листов.
Ну и естественно, процессы бывают разные. Например связанные с наймом и увольнением — в которых записано вещи типа создание и удаление account’ов и т.п. Есть процессы для разработки — как branch’ить код, каков жизненный цикл ошибок, откуда приходят задачи и куда посылать того, кто их принес.
Сегодня, у меня солянка сборная. На повестке дня три темы:
— организация совещаний
— соотношение менеджеров и исполнителей
— американский миф о команде
Итак по поводу совещаний. Я малехо удивлен, что фактически не в одной организации не проводятся нормально совещания, хотя в штатах, даже на простейших курсах, которые я проходит (Business communication для людей у которых английский — второй язык) рассказано как их разумно вести.
Частенько, особенно крупные и серьезные совещания, похожи на борьбу без правил — смешиваются в кучу кони, люди, все что-то пытаются сказать, мысль куда-то постоянно кочует, одно и тоже пережевывают по семь раз, общение разбивается на какие-то подгруппы. В целом твориться полная кутерьма.
А теперь быстренько по пунктам, что нужно для толкового совещания:
а) Длительность митинга должна быть обозначена заранее.
б) Вопросы, которые обсуждаются на митинге должны быть определенны заранее. А также нужно определить, желаемый тип результатов — решение, список идей, мнений или что-то другое.
Кстати, оба этих пункта озвучиваются и до митинга и повторяются в самом начале митинга.
в)Должен быть координатор совещания.
Это человек, который следит за тем, чтобы всем давали высказаться и не перебивали, возвращал обсуждения в запланированное русло и главное, если обсуждение вопроса затягивается, останавливал обсуждения и принимал решение о вынесение обсуждения деталей на отдельное совещание. Плюс, чаще всего, такой человек еще и ведет записки — сгенерированные идеи, принятые решения, возникшие дополнительные вопросы.
в) Должен быть человек, который имеет право принимать решения. Особенно, это важно если совещание собрано именно для принятия решений, а не для генерации идей. Я, вообще, очень сильно настаиваю на то, чтобы в компании было достаточно четкое разделение прав, ответственностей и полномочий. Так вот, должен быть человек, который может авторитарно сказать — мы идем путем A, а не путем Б.
г) В конце митинга, проходится еще раз по плану и по выписанным решениям, идеям и действиям, которые надо сделать после митинга.
Усе… Этого достаточно, чтобы совещания не были местом спячки и разгребания накопившейся непрочитанной почты, а местом где собираются, чтобы делать что-то полезное.
Слава богу, что в IT на территории exUSSR пока не сильно прижился этот американский стандарт.
Второе, что я хотел сказать — это соотношение менеджмента и исполнителей. Кстати, оказалось я об этом уже говорил тут. Хотя со мной и не согласились, но я считаю, что у чистого менеджера не должно быть больше чем 7 прямых подчиненных, но и меньше чем 4-5 тоже не должно быть. Как только вы обнаруживаете, что у вас 4 программиста, 3 тестировщика, 1 project manager и 2 product manager, 1 director, 1 CEO, 1 CFO, 1 CTO и т.п., то значит в королевстве датском, не все в порядка, так как общее соотношение по фирме выходит один исполнитель к одному менеджеру. Чаще всего этим болеют молодые компании, которым ну оооочень хочется, выглядеть большими и серьезными. Но, чаще всего, это проходит, как только становится видно что деньги утекают с какой-то сумасшедшей скоростью.
И третье — американский миф о команде. В нескольких книгах читал, да и в жизни видел, как здесь любят идею — собери хорошую команду, а хорошая команда тебе решит любые проблемы. Так вот… фигня это. Не совсем конечно фигня, но достаточно сильно. Ясно, что с хорошей командой легче решать все проблемы, чем с плохой. Однако, во первых команда — только часть всего, есть еще деньги, есть процессы, есть заказчики, есть идея, есть продукт или услуга построенные на этой идее, есть контакты, есть удача и т.п. И абсолютно не стоит надеяться, что одной хорошей командой удастся заткнуть все дыры.
