На самом деле, вот еще буквально полгода назад я думал что Scrum в команде, которая делает SharePoint, не очень актуален. Я считал, что из-за особенностей разработки под SharePoint, из-за того что мы фактически пишем кучу слабосвязанных плагинов, а не цельный продукт - командная разработка привносит больше вреда, чем пользы: это происходит из-за оверхеда на общение и организационные процедуры, которые вроде как никому особо и не нужны, т.к. каждый занят своим модулем и в чужие дела не лезет.
Как вы уже наверное догадались, я ошибался. Причем, сильно ошибался...
Итак, что же дает Scrum, что дает командная разработка и почему это применимо к SharePoint?
Во-первых, я на самом деле не уверен, что созданные независимо модули могут магическим образом объединятся в удобный и цельный продукт. Нет, чудес на свете не бывает. Либо вы делаете модули отдельно, и потом получаете неказистую и неконкурентную штуковину, которую практически невозможно продать на современном рынке, либо вы уже изначально пишете цельный продукт - и тогда вещи начинают выглядеть совершенно иначе.
Во-вторых, общение в команде, постоянные митинги и стэндапы - сначала это конечно непривычно и напрягает, ведь сроки поджимают и все такое, но если грамотно построить эти встречи, для каждой встречи ввести расписание, и не заставлять присутствовать тогда когда человека не касается обсуждение - это действительно начинает работать!
Встречи и обсуждения - это прежде всего, общение. И когда люди общаются, это само по себе уже благотворно влияет на атмосферу в коллективе: команда становится более дружной, угрюмые одиночки вдруг оказываются неплохими ребятами ну и всё такое. Человек существо социальное все-таки, даже разработчик :)
Ну и конечно, деловое общение на разнообразных Scrum-собраниях - это обмен опытом, обмен идеями (brainstorming), активное отслеживание рисков и проблем, взаимопомощь. Всё это сильно повышает эффективность и очень быстро окупается.
С точки же зрения бизнеса, Scrum прежде всего дает предсказуемость. Реально работающую оценку трудозатрат, которая подтверждается из спринта в спринт. Вспомните, ведь любой проект начинается с вопроса: "За сколько ты сможешь это сделать?". И правильная оценка - безусловный залог стабильной прибыли и довольных клиентов.
Кстати, кто работал с оценками по SharePoint-проектам, те знают и понимают, что хороший estimation в SharePoint - это очень сложно. Влезли в стандартный функционал - задача решается за полдня. Не влезли - попали на месяц трудозатрат. И тем не менее, planning poker из спринта в спринт срабатывает, и это даже для SharePoint, и это даже несмотря на то, что наш Scrum на самом деле весьма далек от идеального Scrum'а. Как? Точно не знаю. Но работает :)
В общем, на самом деле я лично очень доволен, и надеюсь наш отдел будет продолжать развиваться в том же духе :)
>>> Я считал, что из-за особенностей разработки под SharePoint, из-за того что мы фактически пишем кучу слабосвязанных плагинов, а не цельный продукт...
ОтветитьУдалитьВ паре sp проектов, в которых приходилось принимать участие, разработка была построена от построения portal & site definitions и далее уже вниз по иерархии - мастера, списки, колонки, типы, документы и прочее...и вообщем-то это вносило некую ясность понимания, как решение выглядит и давало ощущение полноты решения. Соответственно, выделялись отдельные библиотеки для построения UI и бизнесс-логики, используемые на разных слоях.
К чему я это? Просто к тому, что вообщем-то есть конечно особенности разработки именно под шарепоинт, но они не настолько значимы, чтобы не применять различные технологии разработки такие как scrum. Важно, чтобы процесс В ПРИНЦИПЕ был построен и были нормальные здоровые отношения в команде.
Что касается митингов - вот уж действительно важно, чтобы не дергать людей, которые отношения к теме митинга не имеют :) тогда это зло и для программиста, и для проекта в целом.
Ну под шарепойнт можно как угодно писать. При этом сам шарепойнт можно даже особо не использовать :)
УдалитьА про митинги - просто реальный опыт, буквально вот не очень давно стали придерживаться принципов:
1. На каждый митинг - строгая агенда. Люди всегда знают, что митинг займет именно столько-то времени, и по агенде могут определить, какие части митинга им интересны, какие нет.
2. Агенда должна выполняться всегда, вне зависимости от того что например обсуждение какого-то пункта затянулось. Регламент, и всё тут. А затянувшееся обсуждение откладываем и переносим в следующий митинг.
3. В агенде прописаны обязательные участники, для остальных участие необязательно.
Эти правила, к слову, вводились под впечатлением от книжки Deadline (автор Tom Demarko) - очень рекомендую, если еще не читал!
И в общем сейчас я вижу, что такой подход дает просто охрененные результаты. Причем де факто, митингов стало с тех пор больше, причем больше раза в два. Но они проходят намного более эффективно и главное, народ гораздо лучше стал к ним относиться. Не просто люди стоят и маются, а реальное обсуждение происходит, брэйнсторминг, предложения и т.д. - и это здорово.
Андрей, спасибо за пост. Хотелось бы ещё знать ТТХ вашей команды (кол-во разработчиков, аналитиков и прочее).
ОтветитьУдалитьВиталий, хороший вопрос :)
УдалитьК сожалению, мы еще далеки от идеала, и я бы не сказал, что у нас настоящие идеальные cross-functional teams - но как минимум, мы к этому очень стремимся.
В нашей команде в настоящий момент 5 человек, включая меня.
Я занимаюсь разработкой, но также много занимаюсь составлением спецификаций на новые модули, т.е. аналитикой. Я же провожу планирования и играю ключевую роль на согласованиях с Product Owner.
Четверо ребят - разработчики.
Один из разработчиков является также "пожарником" - т.е. он участвует в команде с низким коэффициентом (вроде 0,3), и значительную часть времени тратит на закрытие разных срочных багов, запросов клиентов и т.п., чтобы не сбивать таймфрейм остальным ребятам.
Также, у нас есть выделенный отдел тестирования, и 2 тестировщика работают в основном только на нужды нашей команды, хотя иногда и переключаются на задачи других команд. Я думаю, в некотором роде они также являются членами команды.
Плюс, весь процесс курируется руководителем отдела - он организует и нередко проводит значительную часть собраний (включая стэндапы), занимается всякими организационными вопросами, участвует в согласованиях с Product Owner и т.д.
Для решения архитектурных проблем консультируемся с нашим архитектором - он работает в другой команде. Также, есть у нас и дизайнер, она не прикреплена ни к одной из команд.
Наконец, в течение месяца обещают технического писателя, что должно повысить качество документированности продукта - с этим пока плоховато, и вот на последней ретроспективе документацию очень многие упоминали и очень много времени было уделено обсуждению как с ней быть.
На текущий момент ситуация вот такая, но в целом стремимся к тому, чтобы нарабатывать постоянный состав команд и формировать cross-functional teams.
Спасибо за ответ. Описанная команда, я думаю, встречается в 90% случаев, и то, что архитекторы, аналитики и тестировщики удовлетворяют нужды нескольких проектов - это абсолютно нормально, т.к. одним проектов их на 100% не загрузить.
УдалитьСогласен что функциональное разделение не совпадать с составом команд - например, тестировщикам нужно заниматься настройкой виртуалок, тестовых окружений и т.п. - в случае SharePoint это лучше делать централизованно, т.е. отдел тестирования имеет право быть.
УдалитьНо с другой стороны, выделенный тестировщик, *привязанный* к команде - это очень здорово и чем его загрузить - я уверен, у любой команды найдется. Как я упоминал выше, в нашем случае двое ребят работают на 80% на нужды нашей команды, причем они работают на том же Task Dashboard, участвуют почти во всех собраниях, проектированиях, обсуждениях, стэндапах, ретроспективах и т.п. Более того, тестирование идет постоянно, 1 задачу сделали - её сразу же проверяют. Задачи специально формулируются таким образом, чтобы их можно было проверить и в формулировку задачи включается план тестирования и план демонстрации.
Далее, аналитик. Разработка спецификаций и задач для product backlog'а, исследования по этим задачам, согласования с Product Owner - всё это производится, в нашем случае, в рамках спринта. Например вот на предыдущем спринте у нас было запланировано проведение 1го общего обсуждения командой (brainstorm), двух согласований с Product Owner и 1 оценки трудозатрат. Это фигурировало в качестве отдельных задач, и точно также на стэндапах эти задачи участвовали в общем обсуждении.
Работы по проектированию, дизайну, созданию и согласованию спецификаций - идут, опять же, постоянно и на самом деле иногда их делаю не я а кто-то еще.
Всё это я к чему: вся идея cross-functional-teams состоит в том, чтобы не было незаменимых членов команды и чтобы не было абсолютных, "слепых", авторитетов. Когда идет архитектурное обсуждение, участвуют все. На этот час, пока идет собрание, все становятся архитекторами, и собственно наличие отдельного архитектора совершенно необязательно. С точки зрения Scrum "архитекторов" вообще не бывает, как и аналитиков и т.п. Все делают всё.
Конечно, очень желательно иметь неких "лидеров направлений", или "авторитетных консультантов" - но это неофициальные роли, здесь как раз вступает в силу штука под названием Scrum Leadership. Т.е. команда сама внутри себя решает, кого слушать, а кого нет. Если команда приходит к выводу, что знаний и умений членов команды недостаточно (выяснить это - одна из задач ретроспектив), команда может выделить время и запланировать на следующий спринт например задачу по изучению архитектурных аспектов, чтобы кто-то провел исследование и потом провел доклад по результатам.
Вот в общем, как-то так я это понимаю, и именно к этому мы стараемся по-тихоньку идти, конечно придерживаясь прежде всего здравого смысла.