У меня достаточно большой стаж разработки, но начиная с 2001 года я перешел на руководящие позиции. В основном в должностях тимлида и проджект менеджера, но последние годы в качестве руководителя компании. Поэтому методологии разработки – это то, с чем я близко соприкасаюсь. Кроме того, я потратил очень много времени и сил, чтобы выработать собственное представление о том, как надо строить процесс разработки. Я спикер большого количества конференций по проджект менеджменту и, помимо всего прочего, еще и сертифицированный Scrum Master.
По хорошему, по каждой из методологий SCRUM, Kanban стоит читать целый тренинг, тема очень обширна. Но даже если вы пройдете такие тренинги, яснее вам не станет. Почему?
Сейчас мы имеем большое количеству теорий по управлению командами, которые в руках одних людей работают, а у других – не работают. Все дело в человеческом факторе. Есть прирожденные руководители, которые на интуитивном уровне знают, как руководить людьми, а полученные дополнительные знания и методологии им помогают. Но есть те, кто не склонен руководить людьми: человек слишком не уверен в себе или, наоборот, слишком авторитарен и хочет продавить всех под себя. В руках у таких руководителей даже самые хорошие методологии могут не работать.
С чего все начиналось?
В начале не было никаких особых методологий, просто было задание, программисты садились и делали. Первыми заказчиками были военные, а как работают военные? Все делалось строго по регламенту, поэтапно. Такая методология получила название «Водопад». Подобная модель разработки хорошо подходит именно для военных проектов, когда есть одно ТЗ, нет изменений и делается задача до победного конца.
В коммерческой разработке все работает иначе. С каждого этапа может потребоваться вернуться на предыдущий, корректировать ТЗ, изменять правила, переписывать код, менять структуру и пр. Да, это неудобно, но и отойти от этого не получится, ибо бизнес меняется слишком быстро.
Гибкие методологии разработки: Agile
Рынок диктует условия бизнесу, бизнес меняется и это отражается на условиях разработки. Таким образом возникло огромное количество гибких методик разработки под общим названием Agile. SCRUM, Kanban также относятся к Agile разработке. Данные методологии могут использоваться не только в программировании, но и в других сферах. Например, Kanban был изобретен в корпорации Toyota и отлично адаптирован именно к промышленному производству.
Методологии не являются взаимоисключающими. Вы можете одновременно использовать большую часть из них вместе. Например, SCRUM, Lean и Kanban прекрасно соединяются и не мешают друг другу.
Людьми руководить сложно, их невозможно загнать в одну модель и заставить функционировать одинаково. У каждого члена команды есть свое представление, в какое время лучше работать, в коллективе есть отношения друг с другом, что также влияет на эффективность работы. PM должен учитывать этот аспект, а вот ни одна методология вам этого не учтет.
Что же дают методологии? Фактически, каждая из них дает вам опорные точки. Дает возможность понимать, какой из вариантов принятых вами решений, лучший и по каким параметрам. Сегодня есть огромное количество теорий по управлению персоналом. Написаны миллионы книг и они не противоречат друг другу, а дополняют.
Методология Lean
Это методология выхода на рынок. Она говорит, что для того чтобы выйти на рынок, не обязательно иметь полностью законченный продукт. Потому что вы будете делать его три года, потом вынесите на рынок, а он не зайдет. Вы впустую потратили время и деньги. Опрашивать заранее целевую аудиторию тоже нет смысла. Только то, за что пользователь платит, то и будет лучшим вариантом, а на опросах можно много разного сказать. Lean говорит, что вы должны сделать минимальную версию продукта и смотреть, как он зайдет. Но Lean вообще ничего не говорит об управлении персоналом.
Методология Kanban
Суть Канбана – распределять задачи, которые ставятся внутри команды, по этапам разработки и перемещать их по этим этапам. Канбан доски могут делиться на любое количество этапов, самое примитивное деление: 1) То что в планах 2) То, над чем работаем 3) Готово.
SCRUM
Методология SCRUM говорит, что задачи нужно делать не потоком, а итерациями. Т.е. отбирать какое-то количество задач, которые в финале создадут какой-то инкремент – дополнение функционала к вашему продукту. И вот такими итерациями вы движетесь к цели. Это отличная методология для ИТ сферы – заказчик видит, что у вас постоянное наращивание функционала, он стабильный и постоянно работает. Таким образом вы не потеряете слишком много времени, если рынок резко изменится.
Еще есть методология Extreme Programming, но она достаточно тяжелая, поэтому в чистом виде не используется. Все предложенные решения эффективны, но выкручены на максимум. Например, все знают, что наиболее эффективно программисты работают парами, по методологии Extreme Programming предполагается, что весь код пишется в паре. Код, покрытый тестами, работает лучше и надежнее, по Extreme Programming код должен быть покрыт тестами на 100%. И так далее. В реальном мире это не встречается.
Естественно, каждую методологию я очень сильно упрощаю, показываю только основную суть системы.
