Как прыгнуть из водопада в Agile и не сойти с ума
•Download as PPTX, PDF•
0 likes•557 views
Доклад Любови Вахитовой на конференции Analyst Days-6 www.analystdays.com
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (7)
More from SQALab
More from SQALab (20)
Как прыгнуть из водопада в Agile и не сойти с ума
- 1. Прыжок из Waterfall в Agile Вахитова Любовь Solanteq
- 2. Модели разработки ПО Waterfall • Процессы и инструменты • Всеобъемлющая документация • Жесткие договорные ограничения • Следование четкому плану Agile • Люди и их взаимодействие • Готовый продукт • Сотрудничество с заказчиком • Готовность к изменениям
- 3. Аналитик в Waterfall • «Стена» между разработчиками и заказчиками • «Сначала деньги, потом стулья» • Длительный процесс сбора требований • Большой объем документации (архитектура, спецификации) • Разработка: «Шаг вправо, шаг влево - расстрел»
- 4. Аналитик в Agile • Связующее звено между разработкой и заказчиком • Итеративная разработка требований • Необходимый минимум документации • «Быстрее, выше, сильнее»
- 5. Инструменты • Баг/таск трекеры (TFS, YouTrack) • Word/excel • Системы разработки и управления требованиями (TopTeam Analyst, ReqView, JIRA)
- 7. Youtrack
- 8. Инструменты • Баг/таск трекеры (TFS, YouTrack) • Word/excel • Системы разработки и управления требованиями (TopTeam Analyst, ReqView, JIRA)
- 9. Почему нет
- 10. Подводя итоги • Выход коммуникаций на первый план • Принцип переиспользования • Повышение скорости • Использовать нельзя откладывать
- 11. Спасибо за внимание Любовь Вахитова Solanteq vakhitova.lyubov@gmail.com
Editor's Notes
- Добрый день, коллеги! Прежде всего хочу представиться, меня зовут Вахитова Любовь, я работаю аналитиком уже 6 лет, год назад я сменила работу и так получилось, что у меня резко сменилась и модель разработки и предметная область. Как вы можете понять из названия доклада в предыдущей компании, в которой я работала была каскадная модель, а компания в которой я сейчас руководствуется принципами Agile. Поэтому сегодня я хочу немножко поделиться своими наблюдениями на этот счет, возможно кому-то они окажутся полезными. Итак, давайте начнем.
- Все мы знаем ключевые навыки, которыми должен обладать аналитик, их достаточно много, на слайде представлена часть из них. Зачем я здесь про них говорю? Я хочу, чтобы вы посмотрели на них немножко под другим углом. Можно ли сказать, что работая аналитиком мы в полной мере обладаем этими навыками? Мы сейчас не говорим о людях, которые только начинают свою карьеру, мы сейчас о хороших профессионалах, которые успешно работают несколько лет. Так вот, я считаю, что нет, мы обладаем этими навыками в рамках той компании, в которой работаем в текущий момент, таким образом переходя на новую работу мы так или иначе учимся все это делать заново. Да, мы уже знаем правила игры, да, нам нужно на это меньше времени, но в той или иной степени нам все равно нужно время, чтобы адаптировать все свои имеющиеся навыки под новые рамки и чем более кардинальные перемены, тем сложнее это сделать, а смена модели и предметной области, поверьте мне, это кардинальные перемены Так как же сделать это с наименьшими потерями?)
- Начнем со смены предметной области, понятно, что здесь нет какого-то универсального рецепта, поэтому тут совсем коротко о том, что помогало мне. Хороший аналитик– это аналитик, который хорошо знает предметную область, от этого нам никуда не деться, поэтому вникать нужно быстро В моем случае я сменила разработку ПО для служб занятости и социальной защиты населения на разработку в банковском секторе. Если и есть что-то общее в этих областях, то крайне мало С чего начать? Лично у меня, когда я пришла в первый день на работу и в той и в другой компании был разговор с непосредственным руководителем, думаю так происходит практически везде и по-моему разговор этот носит обычно сумбурный характер У тебя в голове крутится перечень имен коллег, с которыми тебя только что познакомили, месторасположение твоего нового рабочего места, парочка вводных и еще какое-нибудь очень важное мнение о чем-нибудь)) А твой руководитель, у него вообще непростая задача, о чем рассказывать, и про то, как устроен отдел и компания, и про проекты, и про полезные ресурсы, и про твои обязанности, и про твои задачи на ближайшее время и как-то коротко А ты еще такой сидишь, слушаешь, киваешь, да, мол все понятно, мы тут умные вообще-то, опыт есть и все такое В общем, что я хочу сказать, в результате этого разговора в голове как правило не появляется прям вот так сразу какой-то четкой структуры всего-всего, а появляется какое-то плохоупорядоченное количество новой информации, причем какая-то может быть вполне понятной, а что-то могло только упоминаться и на объяснения уже не было времени, потому что время руководителя не резиновое. Так вот, на мой взгляд главное после этого разговора сразу пойти и записать какие-то ключевые моменты, какие-то недопонятые моменты, я называю это «раскидать якоря», что-то к чему можно потом вернуться и покопать в эту сторону, спросить, почитать и т.д. Ключевое слово здесь «СРАЗУ», иначе потом не вспомните. Что может быть «якорями»? Какая-то нормативка, термины, заказчики. Раскидывать якоря можно и на листке бумаги, конечно, и возвращаться к нему все время, но мы же все-таки IT и вообще 21 век на дворе, так что я советую использовать для этих целей MindMap, очень удобная штука для таких задач, если кто еще не пользовался внизу слайда картинка, как это выглядит. После того, как «якоря раскиданы» можно начинать копать и углубляться, тут нам в помощь все доступные ресурсы и документы в компании, как правило всегда в доступе есть спецификации, архитектуры, user guides. Ну и последнее, если вы уже закопались по самые уши, а понятней все равно не становится, то пора обращаться за помощью к коллегам Для меня наверное это самый сложный пункт :) Если вы пришли с приличным багажом и привыкли к тому, что спрашивают у вас, то придется немножко побороться с собой и начать спрашивать самим Мне еще всегда хочется разобраться самой и не хочется отвлекать коллег от работы, а еще непонятно, а вдруг это просто, а ты сам не разобрался, неудобно как-то, ну в общем смело выкидывайте эти глупости из головы и спрашивайте и переспрашивайте. В конечном итоге все от этого только выигрывают и коллеги ваши в том числе, потому что вы быстрее вникаете в суть дела и можете часть работы взять на себя. Но совсем, конечно, не надо засыпать вопросами, когда я сама была куратором у вновь прибывших сотрудников, когда после многих плюс-минус толковых вопросов мой подопечный спросил меня, а какие кавычки нужно использовать в документации, я думала взорвусь
- Итак, переходим к самому интересному. Как же влияет на аналитика смена модели разработки и влияет ли вообще? На слайде наверное уже до боли всем известные, кто хоть как-то касался этой темы, принципы каскадной модели и Agile. Мы не будем их сейчас обсуждать, просто вспомним о них и постараемся посмотреть на них именно с точки зрения работы аналитиком в той и в другой модели. Сразу же оговорюсь, что я не буду говорить что какая-то модель хуже, какая-то лучше и не буду говорить, что какие-то характерные черты всегда проявляются одинаково, я расскажу как было у меня – 2 компании, 2 модели. Все-таки все компании разные и прям использования «чистых» моделей наверное практически нет.
- Итак, аналитик в каскадной модели. В предыдущей компании, в которой я работала, аналитики всегда были немножечко «стеной» между разработчиками и заказчиками. Разработчики и заказчики друг про друга мало что знают и ты сначала долго обсуждаешь с заказчиком его боль, а потом пытаешься донести это разработчику, который говорит тебе, что ты придумываешь сложности, на самом деле все хорошо. Надо сказать, что у нас были случаи, но это прям исключения, что разработчику приходилось общаться с заказчиком, ну не прям так выяснять требования у него, а ездить, например, на внедрение нового продукта с аналитиком вместе, и честно говоря это сильно меняет дело. Разработчик сразу видит этих людей и сам начинает чувствовать боль заказчика и тебе уже не нужно ему доказывать что-нибудь из разряда, что эту процедуру нужно оптимизировать, это у нас она быстро работает, а на их оборудовании ну невозможно дождаться Пока аналитик не выяснит и окончательно не согласует все требования с заказчиком, разработка ничего делать не начнет, ну не переделывать же потом в самом деле В связи с этим процесс сбора требований очень сильно растягивается, ведь мало того, что ты должен все согласовать, ты еще должен написать подробную документацию – нарисовать архитектуру, кусочек схемы БД может, описание новых табличек, расписать в терминах объектной модели алгоритм. Поскольку, если ты этого не сделаешь, то получишь ты в итоге от разработки совсем не то, что хотел, ведь разрабатывается все буква в букву по твоему описанию, ведь насколько мы помним разработчик мало, что знает о заказчике и его проблемах В общем есть плюсы и минусы у этого подхода, думаю они вполне очевидны, не будем на них останавливаться, перейдем сразу к тому как изменилась моя миссия, как аналитика, в компании с принципами Agile :)
- Почему я все время говорю компания с принципами Agile? На самом деле, пока я работала в каскадной модели я себе плохо представляла как же работает этот магический Agile, о котором все говорят Мне казалось, что в каскаде все логично и понятно и плохо представлялось, как может быть по-другому, Agile ассоциировался в основном со скрамом почему-то, хотя я теперь уже знаю, что я такая не одна и меня до сих пор часто спрашивают, когда я говорю, что работаю по Agile, «ааа, у вас там спринты и скрам-мастер?» :) И когда я пришла в компанию, мне никто не говорил, «Привет, у нас тут Agile», поэтому первое время честно говоря мне казалось, что я попала в какой-то хаос :) И мне даже хотелось все приводить к своему уютненькому каскаду, в котором все просто и понятно и до сих пор иногда хочется, на самом деле, но теперь я могу остановиться и спросить себя, действительно ли так будет лучше или просто я так привыкла. Так вот у нас нет какой-то одной четкой модели, типа Скрам или Канбан, есть принципы Agile, которые работают, а так всего по-немногу, у части разработки например есть спринты и ретроспективы, в некоторых проектах есть Agile Boards, опять же сразу оговорюсь, что компания молодая, всего 3 года будет и бурно развивающаяся, поэтому я думаю мы еще в поиске сейчас каких-то конкретных инструментов, приемов, думаю на эту тему когда-нибудь можно будет сделать отдельный доклад а пока сосредоточимся на том, что так или иначе мы все-таки руководствуемся принципами из всеми нам известного Agile-манифеста Итак, когда я пришла на новое место работы, честно говоря я была очень удивлена, когда осознала, что разработка вполне себе участвует в обсуждениях с заказчиком, быстро понимает суть проблемы, когда ты начинаешь о ней говорить и вообще общение с заказчиком не вызывает со стороны разработки никакого отторжения в духе «О чем мне с ними говорить, они ничего не понимают и вообще это не моя зона ответственности», поэтому аналитик тут выступает скорее неким связующим звеном, т.е. в основном ты, конечно, выясняешь и согласовываешь требования, но всегда можешь при необходимости достаточно безболезненно привлечь разработку. Надо сказать, что и на стороне заказчика мы сейчас работаем с технически- хорошо подкованными специалистами. На предыдущем месте работы мне приходилось зачастую работать с конечными пользователями без технического бэкграунда и в такой ситуации сложно представить какое-то сильно продуктивное их общение с разработкой Поскольку важен готовый продукт, требования разрабатываются итеративно, а разработка начинается сразу, не дожидаясь финальных требований, опять же в связи с этим ведется необходимый минимум документации и очень важны коммуникации между людьми в команде. Если раньше я очень долго и подробно описывала задачу и после этого больше в принципе не общалась с разработкой, то сейчас я скорее коротко описываю задачу, а потом уже в ходе общения можно уточнить какие-то детали. Опять же начальные требования могут видоизмениться в результате тесного обсуждения с заказчиком и разработка к этому готова, что возможно придется переделать. На предыдущем месте работы, если что-то приходилось переделывать, это всегда вызывало негатив из разряда «Что ты сразу не мог подумать как следует, а мне тут переделывай теперь» Ну и что было самым странным и самым приятным для меня, как это все работает без такого четкого разделения зон ответственности, как в каскаде, работает какой-то принцип всеобщей самоорганизованности и ответственности. Выводы, как говорится, делайте сами Разница есть, а раз есть разница в организации процесса, то наверняка есть разница и в инструментах работы, давайте немного поговорим и о них
- Если мы вспомним первый сегодняшний слайд про навыки аналитика, одним из них там значился «Навыки работы с соответствующим ПО». Что же это за соответствующее ПО? На первом месте наверное стоят баг/таск теркеры, это пожалуй наш с вами основной инструмент работы, их существует огромное множество, лично мне удалось поработать с двумя, это TFS и Youtrack, мне как аналитику работать было удобно и там и там, все необходимые мне функции есть и в том и в другом, так что сами трекеры сравнивать не возьмусь, расскажу немного о разнице в работе с ними в разных моделях. (следующие 2 слайда) Support системы, опять же если мы говорим о переходе в новую компанию, при наличии support системы она может стать хорошим помощником в процессе изучения предметной области и стиле общения с заказчиком, если такой системы нет, а переписка находится в почте у разных сотрудников, тут начинаются сложности, это как раз то, с чем пришлось столкнуться мне. В предыдущей компании была хорошая support система под названием kayako, в ней велась вся переписка с заказчиком, таким образом каждый сотрудник мог посмотреть по конкретному проекту какие открытые вопросы есть на текущий момент, у кого они в работе, какие вопросы закрыты, по каким созданы задачи на модификацию, там же велась база знаний с разделением прав доступа, заказчик видел одно, сотрудники компании более расширенную версию, были шаблоны ответов, новые сотрудники могли написать ответ и подождать его валидации более опытными сотрудниками при необходимости и т.д. в общем очень много полезных штук, простой почтой этого, конечно, не заменить. Почта работает, когда общения с заказчиком немного и до какого-то определенного очень небольшого количества человек в компании, а потом начинается бесконечная пересылка цепочек сообщений всем заинтересованным и не только и разобраться с ними со временем становится все сложнее и сложнее. Word/excel, наверное только начав работать по Agile я в полной мере поняла, что нельзя вести требования в Word и Excel, ну не предназначены они для этого, да с каскадом это еще как-то возможно, когда один конкретный аналитик заранее обговаривает и согласовывает все требования и потом их описывает, тогда для работы с ними и истории они могут храниться и так. Но когда требования все время видоизменяются со всех сторон и все время согласовываются пересогласовываются, тут нужна система, причем удобная и для заказчика и для компании, чтобы предельно быстро можно было говорить на одном и том же языке и об одном и том же, а не обмениваться бесконечными версиями документов. (слайд 10) Я честно говоря пока в поиске такой системы сейчас, их довольно много, но правда в основном они все под Windows.
- Поскольку в каскадной модели процессы и инструменты играют большую роль, у нас было строгое описание жизненного цикла тасков/багов, которому все следовали, представлен на слайде в упрощенном виде – для каждого нового требования заводилось требование в TFS, под него линковались конкретные задачи, после заведения задачи аналитик передавал ее руководителю разработки, который в свою очередь передавал его конкретному разработчику, тот разрабатывал и возвращал аналитику, аналитик смотрел в первом приближении и отдавал руководителю службы тестирования, тот распределял ее на конкретного тестировщика, тестировщик после тестирования возвращал ее либо разработчику либо аналитику, каждый человек должен был менять статус у задачи, когда работает над ней, в общем целый процесс со своими правилами.
- Что я делаю сейчас? Пишу задачу и все, и для меня это была просто магия какая-то поначалу, ты ни на кого не назначаешь задачу, а ее все равно кто-то берет и делает и потом просто указывает в какую версию это вошло Также, новым для меня было использование Agile Boards, на слайде представлено как это выглядит в Youtrack. С помощью доски можно визуализировать повседневную деятельность – группировать задачи, создавать спринты и указывать их продолжительность, также можно создавать разные колонки для представления различных стадий процесса разработки и задавать минимум/максимум задач в стадии выполнения для каждой колонки, чтобы контролировать количество задач на любой стадии разработки.
- Если мы вспомним первый сегодняшний слайд про навыки аналитика, одним из них там значился «Навыки работы с соответствующим ПО». Что же это за соответствующее ПО? На первом месте наверное стоят баг/таск теркеры, это пожалуй наш с вами основной инструмент работы, их существует огромное множество, лично мне удалось поработать с двумя, это TFS и Youtrack, мне как аналитику работать было удобно и там и там, все необходимые мне функции есть и в том и в другом, так что сами трекеры сравнивать не возьмусь, расскажу немного о разнице в работе с ними в разных моделях. (следующие 2 слайда) Support системы, опять же если мы говорим о переходе в новую компанию, при наличии support системы она может стать хорошим помощником в процессе изучения предметной области и стиле общения с заказчиком, если такой системы нет, а переписка находится в почте у разных сотрудников, тут начинаются сложности, это как раз то, с чем пришлось столкнуться мне. В предыдущей компании была хорошая support система под названием kayako, в ней велась вся переписка с заказчиком, таким образом каждый сотрудник мог посмотреть по конкретному проекту какие открытые вопросы есть на текущий момент, у кого они в работе, какие вопросы закрыты, по каким созданы задачи на модификацию, там же велась база знаний с разделением прав доступа, заказчик видел одно, сотрудники компании более расширенную версию, были шаблоны ответов, новые сотрудники могли написать ответ и подождать его валидации более опытными сотрудниками при необходимости и т.д. в общем очень много полезных штук, простой почтой этого, конечно, не заменить. Почта работает, когда общения с заказчиком немного и до какого-то определенного очень небольшого количества человек в компании, а потом начинается бесконечная пересылка цепочек сообщений всем заинтересованным и не только и разобраться с ними со временем становится все сложнее и сложнее. Word/excel, наверное только начав работать по Agile я в полной мере поняла, что нельзя вести требования в Word и Excel, ну не предназначены они для этого, да с каскадом это еще как-то возможно, когда один конкретный аналитик заранее обговаривает и согласовывает все требования и потом их описывает, тогда для работы с ними и истории они могут храниться и так. Но когда требования все время видоизменяются со всех сторон и все время согласовываются пересогласовываются, тут нужна система, причем удобная и для заказчика и для компании, чтобы предельно быстро можно было говорить на одном и том же языке и об одном и том же, а не обмениваться бесконечными версиями документов. (слайд 10) Я честно говоря пока в поиске такой системы сейчас, их довольно много, но правда в основном они все под Windows.
- Мне очень нравится эта картинка, ее я нашла у одной из компаний, занимающихся как раз-таки разработкой системы для управления требований, по-моему она очень наглядно отражает, почему MS Excel и Word не подходят для этого После каждого очередного внутреннего митинга или конфколла с заказчиком или очередного письма, появляется какая-то новая версия требований, причем параллельно их появляется несколько разных, потому что информация может поступать разным членам команды, в итоге собрать это все в одно становится очень сложно. В документе появляется куча комментариев, даже если мы используем Track Changes через некоторое время разобраться в них становится невозможно ни команде, ни заказчику.
- Ну и скажу еще пару слов о разнице в тестировании в разных моделях, так или иначе аналитик как правило принимает в нем участие. В каскаде тестируется готовый продукт, тестируется на полное соответствие описанию в задаче и требованиям, у нас даже баги были двух видов – баг аналитика и баг разработчика, баг разработчика, это когда реализация не соответствует описанию в задаче, а баг аналитика, когда реализация соответствует описанию в задаче, но работает все равно неправильно (не полностью отражает суть требования, например). В каскадной модели как правило по имеющейся документации тестировщик может сразу написать подробные тестовые сценарии, аналитик только провалидировать при необходимости. При работе по Agile тестируют по сути все и все время, продукт постоянно может меняться, очень важно регрессионное тестирование, чтобы не сломать имеющуюся функциональность, как правило аналитик пишет план тестирования, который постепенно обрастает деталями и также аналитик может даже накидывать какие-то основные тестовые сценарии.
- И совсем коротко о документации. К счастью у нас есть документаторы и я как аналитик, мало участвую в процессе написания такой документации, как User Guides, например, но основные принципы думаю итак понятны. Поскольку сейчас нам важно минимизировать затраты на ведение документации, мы стараемся делить документацию на мелкие блоки, которые можно потом повторно переиспользовать и планируем использовать систему ведения документации, в которой потом можно из разных блоков генерировать необходимые формы документов.
- Итак, мы поговорили сегодня о разных составляющих работы аналитика в двух моделях – каскаде и Agile на примерах двух компаний, и я готова ответить на оставшиеся у вас вопросы.