Давно хотел систематизировать свой взгляд на методологии разработки ПО, на взаимодействие менеджера и программиста (функционального тимлида и тимлида разработки), но всё не попадалась точка опоры, оттолкнувшись от которой, можно порассуждать. И вот эта точка опоры появилась. Коллега прислал ссылку на манифест (RU), который, как представляется, легко овладевает неокрепшими умами посредством своей категоричности и ненормативной лексики.
Должен признать, я понимаю, о чем так сумбурно говорят авторы.
От методологии SCRUM я отказался, как только стал тимлидом разработки. Поначалу, когда проект только начинался и я был разработчиком, ежедневные скрамы были в новинку и некоторым образом помогали в самоорганизации. Бывший тимлид проводил каждые две недели ретроспективы, на которых мы обсуждали плюсы и минусы (всё, как полагается). На скрамах я даже волновался, потому что озвучивал конкретные сроки, в которые планирую уложиться с текущей задачей. И ещё больше волновался, если не укладываюсь.
По мере погружения в проект и расширения компетенций, стало так: смотришь на часы и думаешь: «Опять скрам, надо что-то говорить». Было видно, что коллеги думают аналогично. В начале рабочего дня, когда голова ещё свежа и чиста, как утренняя роса, мне меньше всего хотелось отвлекаться на разговоры и потом снова вникать в код. Ретроспективы обычно проводились во второй половине дня и представляли собой свободное обсуждение совместно пережитого, без принятия каких-либо решений. Аналогично: сначала они создавали видимость сплочения коллектива, но потом стали для меня просто поводом размяться и расслабить глаза.
Став скрам-мастером, я всё чаще думал: зачем эта говорильня, когда потратить время можно более продуктивно? Более того — я узнал о практиках, при которых утренний scrum длится полчаса и сопровождается рисованием на флипчарте.
Что там каждое утро можно рисовать? Для чего? Я не понимаю. Видимо, аналогичными вопросами задавались и авторы "манифеста".
Будучи премного благодарным бывшему тимлиду за то, что он внедрил вообще хоть какую-то методологию разработки, которая в своё время очень помогла, я также благодарен ему за то, что могу сейчас чувствовать эту разницу — между наличием методологии и её отсутствием. Став тимлидом разработки, я перестал проводить скрамы и ретроспективы. Это не мешает мне контролировать весь процесс разработки и в любой момент знать, чем занимаются коллеги, есть ли у них проблемы.
Если говорить о взаимодействии разработчиков с менеджерами, то эффективность, на мой взгляд, достигается при совокупности некоторых условий. Первое, как ни банально, принятие факта, что «мы — команда». Восприятие разработчиком менеджера как заказчика, равно как восприятие менеджером разработчика как исполнителя указаний — ошибочны. Второе: «каждый занимается своим делом». Менеджер не должен уметь программировать, он должен понимать, что хочет бизнес, правильно распределять приоритеты и оценивать сроки, равно как разработчик не должен общаться с заказчиком. Третье — «минимум слов, максимум дела». Без пояснений.
Да, я согласен с авторами в том, что нужно соблюдать баланс между производством и администрированием. Но не менее важно проявлять уважение к коллегам и контролировать эмоции.
Автор: aspanin
