Вместо введения
За последние 3 года работы мне довелось работать в самых различных ипостасях: исследователем, разработчиком и руководителем проектов. Есть различные стили управления: западный (когда предоставляется большая свобода в коллективе и многое построено на доверии, уважении, личной организованности отдельного индивидуума) и восточный (когда штрафуется каждое опоздание, жестко фиксируются сроки, во главе угла стоит железная дисциплина коллектива и если человек не справился с поставленными целями — наступает расставание ). Руководитель проекта должен сочетать в себе два этих элемента: яблоко и кнут, подпускать людей к себе, чтобы разработчики Вам доверяли, но и соблюдать субординацию, так как отношение-отношениями, а нацеленность на результат должна быть всегда.
Но куда важнее: как Вы двигаетесь к поставленной цели, как организуете свой рабочий процесс… В этой статье хотелось бы поделиться с достопочтенной публикой одной из наших непрофессиональных видео лекцией, которую мы снимали для себя. Думаю в каждом коллективе наступает такой момент, когда что-то может идет не совсем так, как хотелось бы. Хочется каких-то изменений и лучше прежде всего начинать их с себя. Как говорится — если хотите изменить мир, то стоит это начать прежде всего с Вас самих же и Вашего ближайшего окружения.
Для удобства сделал субтитры к видео, чтобы смотреть его было проще. Замечу лишь, что это не профессиональная видео лекция и лектор нигде эту методологию не читает специально. Дина Насырова (Тим Лидер из Fujitsu) пришла к нам в знак уважения, чтобы помочь наладить процесс работы коллектива и заодно поделилась своим собственным богатым опытом. Встреча прошла год назад — с тех пор много воды утекло. Но спустя время до сих пор вспоминаю ее, так как информация представленная в ней мне очень сильно пригодилась.
Отрывок расшифровки видео лекции (субтитры)
Дина: Откуда вообще все пошло. Мы сидели, пили чай и выяснили, что Вам нужен project manager. Правильно?
Команда: Да!
Дина: Вот и я спросила: «А точно нужен, так?». И я обещала прийти и почитать лекцию. Как я себе вижу, что такое Scrum и как вообще можно разрабатывать без начальника. Кто-нибудь из Вас знает, что такое Scrum?
Команда: Я читал. Ссылку Виктор скинул. Заметки с передовой
Дина: Вот, короче, и я здесь, тоже разместила ссылку на эту книжку. С моей точки зрения — это одна из лучших таких книжек, без лишних таких вступлений — зачем этот Scrum, бла-бла-бла. Просто ты берешь, как бы tool, да, и применяешь. Вот этим она и мне нравиться. На ее основе я сделала вот такую вот небольшую презентацию. Я сама, конечно, тоже читала Хенри Книберга и вот эту книжку только. Этой книжки реально хватает, чтобы начать. Почему разработка без начальника, да? Потому что — по сути такого понимания как team leader или project manager или кто-то в такой вот роли, который вот стоит наверху, да, и с такой вот палкой нет. И вот это вот, (показывает) делает как это мотивацию, да. Представляете какая будет мотивация да? Покажу на картинке (рисует). Такой сотрудник вот, ослик. Похож на ослика, нет? Как его можно мотивировать? Можно такую вот морковку добавить. Побежит он вперед? Побежит, наверное, да? Можно другим способом мотивировать. Такой волшебный пендель. Побежит вперед? Побежит. Есть
еще один вид мотивации, когда такая морковка изнутри его мотивирует. Изнутри человека жжет. С моей точки зрения самая правильная мотивация.
Но это я отвлеклась, на самом деле речь совсем не о том. Речь о том, что если программисты достаточно зрелые, команда сложилась, то эта вот штука сверху с палкой она нужна опционально по сути. И сейчас я буду рассказывать, как можно изнутри команды распределить ответственность таким образом, чтобы и разработка шла как можно быстрее и, соответственно, все были счастливы. Так вот Роберт Челдини говорит про то, кто такой scrum мастер и просто команда. Кстати сколько Вас человек сейчас?Команда: Нас. Ну 9. А программистов из них 5.
Дина: 5-6 программистов. Это в принципе команда — самый идеальный вариант для Scrum. Потому что 4 как-то непонятно, да. 4 человека всегда могут договориться. И никакая методология не нужна. А 10 — это уже много. Потому что я по себе знаю. Человека, который вблизи — ты уже не видишь. Не держишь в поле внимания.
Нужно прописать все, до последней буквы как вы будете разрабатывать. Почему — это займет именно столько и сказать — на посмотри — вот заказчик. Будет так работать? Это то, что тебе нужно, да? Заказчик скажет – ну, наверное — это то, что мне нужно, и Вы садитесь разрабатывать. Приходите в свое помещение и разрабатываете. Через полгода приходите и говорите — «на». Поработали, разработали и протестировали. Заказчик говорит — ну клево конечно, но мне это не совсем уж и надо, наверное. Уже не совсем то надо. А Вы говорите — ну посмотри. Мы же с тобой договаривались? Вот что договаривались — то и сделали. Это вот waterfall модель. Сначала собираются требования. Потом Вы значить их approve. Ребята у кого как с английским? Мне стоит переводить? Требования — согласование с заказчиком. Потом значит разработка, потом тестирование и потом все — на этом разработка заканчивается.
При этом, что у заказчика вот в эти полгода происходило? Может у него вообще все изменилось — Вас это вообще не касается? Он заплатил, хороший аванс дал — нормально. Есть такое понятие как Scrum, да? Он зачем? Вот мне кажется в Вашем случае — это оптимальная модель. Потому что — это итеративная разработка. Вот эта вся вот лабуда (показывает), да? Она происходит много-много-много-много раз за жизнь и время разработки. Почему — потому что, вообще-то все может измениться — особенно у Вас. Да, вот почесал репу заказчик, пришел-сказал — блииин, вот я такую клевую штуку нашел. Давайте ее имплементировать. Оценивать вот. И Scrum — он именно для таких команд и для таких вот быстро развивающихся и меняющихся проектов. Когда заказчик может в принципе играть с ценой проекта. Да? То есть он может понимать… сейчас лучше покажу. Начнем да. С чего начинается Scrum? Scrum начинается с того, что Вы создаете Product backlog. Это по сути список требований заказчика. Сажаете его перед собой и говорите — давай рассказывай, что тебе нужно. Конечно, в этой книжке по-другому, написано, но — с моей точки зрения требования должны выглядеть именно следующим образом. Пользователь, что-то делает и система как-то реагирует. То есть пользователь заходит и вводит логин-пароль. Система его аутентифицирует или говорит, что логин-пароль не правильный. Вот этот как бы user story. И она должна быть сформулирована именно с точки зрения заказчика — это business story, там не должно быть, что коннектиться в базе данных и использовать такой temple — это не правильно — это про бизнес хотелки, вот с классическим продуктом. Хитро улыбается — громко кричал, что он в команде, а на самом деле (показывает на руководителя проекта). User story. После того как эти user story записаны. Нужно для каждой из них сделать идентификатор стандартный. У каждой из них должно быть имя, именно в таком виде, что пользователь заходит, и система как-то отвечает…
Видео-лекция
Лектор — Дина Насырова (Dina Nasyrova), software & solution team leader, FUJITSU Global Delivery Center, Russia.
Она разрешила мне использовать видео материалы лекции и презентацию
Презентация
Вместо заключения
Представленная лекция вызвала большую дискуссию у нас. И на долго запомнилась у меня в памяти. Некоторые элементы мы стали применять, какие-то нет. Но речь сейчас не об этом. Дело в том, что мы впервые получили возможность ознакомиться с представленной моделью ведения разработки от практика своего дела. И тем полезнее было услышать мнение эксперта. Применять Scrum или нет, это дело исключительно каждого. Но его наличие невозможно не отрицать. Буду рад, если представленный материал будет кому-то полезен и позволит поменять процесс разработки в новую сторону.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий