|
В главе "5: Роли agile" http://www.intuit.ru/studies/courses/3505/747/lecture/26297?page=2 есть упоминание: Скримшир [Scrimshire сайт] но нет адреса сайта. Укажите пожалуйста адрес в тексте лекции. Или речь о человеке James Scrimshire? |
Автор: Bertrand Meyer
Форма обучения:
дистанционная
Стоимость самостоятельного обучения:
бесплатно
Доступ:
свободный
Документ об окончании:
Вам нравится? Нравится 59 студентам
Уровень:
Для всех
Длительность:
13:09:00
Студентов:
2371
Выпускников:
378
Курс посвящен быстрым методам разработки программных систем – методам agile.
Курс создан по книге Бертрана Мейера "Agile! Прекрасный, ужасный, шумный". Дается обзор: XP, Scrum, Lean, Crystal. Анализируются принципы agile, применяемые практики и инструменты, отмечаются блестящие находки, и недостатки.
Курс представляет взвешенную оценку современных приемов разработки программного обеспечения.
Темы: Программирование, Менеджмент
ISBN: 978-5-9556-0174-8
Дополнительные курсы
План занятий
Занятие
Заголовок <<
Дата изучения
Лекция 2
50 минут
Разбор agile текстов
В своем походе к преобразованию мира agile литература прибегает к различным средствам, некоторые из которых, скажем прямо, интеллектуально не безгрешны. При подготовке к детальному изучению agile методов эти средства следует знать и быть готовыми к их правильному восприятию. Начнем с типичного примера, а затем перейдем к детальному анализу.
Оглавление
-
Лекция 3
1 час 8 минут
Враг: предваряющий анализ
Для оправдания ситуации необходим "злодей". Злодеями agile назначает "водопад", "методы, основанные на процессе", "прогнозируемый процесс" и "предваряющий анализ"Подход, критикуемый сторонниками agile, часто сокращенно именуют BDUF (Big Design Up Front), понимая под этим предшествующий созданию кода большой этап проектирования, одним из результатов которого является создание документа требований. В данном контексте, не найдя лучшего перевода, мы используем термин "предваряющий анализ" для именования подхода, критикуемого в agile. В предваряющий анализ включают этапы построения требований и проектирования. Боем и Тернер в заголовке своей книги пытались примирить agile с традиционными подходами программной инженерии, используя для последних термин "дисциплина". Однако они заметили, что дисциплина требуется и для agile подходов, поэтому в содержании самой книги для классических методов использовали термин "основанные на планировании" – совсем неплохое определение.
Эта глава обобщает главные характеристики методов, "основанных на планировании", сосредотачиваясь на тех, которые обычно вызывают возмущение у agile сторонников. Полное рассмотрение потребовало бы отдельной книги. Здесь же мы рассмотрим эти характеристики "с высоты птичьего полета", останавливаясь только на принципиальных идеях.
Оглавление
-
Лекция 4
1 час 49 минут
Принципы agile
Изучая специфические практики и артефакты agile разработки, можно найти несколько общих принципов – методологических правил, выражающих общий взгляд на то, как должно разрабатываться ПО. Начнем рассмотрение этих принципов – основы agile подхода.
Оглавление
-
Лекция 5
29 минут
Роли agile
Один из наиболее осязаемых и непосредственных эффектов методов agile связан со свежим взглядом на обязанности и права членов проекта. Разработка agile переопределяет в частности роли менеджеров, потребителей и членов команды разработчиков.
Начнем с роли менеджера, продолжим ролью команды и ролью потребителей, затем проанализируем другие важные роли, специфицируемые некоторыми или всеми методами agile.
Оглавление
-
Лекция 6
49 минут
Практики agile: производственные процессы
Принципы agile влияют на весь процесс разработки проекта, не только на введение специфических ролей, изучаемых в предыдущей главе, но и на множество конкретных практик, таких как ежедневные встречи, парное программирование, разработка, управляемая тестами.
Что, кстати, следует считать практикой в программировании? Практика должна быть деятельностью или режимом работы, но с некоторой особенностью – повторяемое действие. В отсутствии повторения можно иметь интересные приемы, но это не практика, если эти приемы не применяются регулярно (в случае деятельности) или не являются систематическими требованиями (в случае режима работы).
Scrum использует для практик более претенциозное имя – церемонии.
Начнем эту главу с рассмотрения практик, влияющих на организацию проекта и управление. В следующей главе будут рассмотрены технические практики, отражающие специфику программирования.
Оглавление
-
Лекция 7
49 минут
Практики agile: технические
Помимо практик, рассмотренных в предыдущей главе и посвященных способам управления проектами, agile принципы влияют и на технические приемы разработки проектов. Проведем обзор этих практик.
Возможно, вы заметили в предыдущей главе сильное влияние agile метода Scrum. В противоположность этому в данной главе будут преобладать практики, предлагаемые в XP – экстремальном программировании. Распределение ролей понятно. Scrum – это некоторое расширение общих методов управления. XP был спроектирован программистами для программистов.
Число приемов, рассматриваемых в этой главе, невелико. Фактически основной вклад agile связан с технологией, и относительно немного идей имеют программную специфику. Но некоторые из них важны, в особенности последняя, изучаемая в данной главе, – "вначале тест-разработка", которая уже оказала сильное воздействие на индустрию.
Оглавление
-
Лекция 8
1 час
Артефакты agile
Для поддержки своих практик agile подходы определили несколько артефактов, некоторые из них конкретные, как "карточки историй", другие виртуальные – чисто концептуальной природы. Начнем с главных виртуальных артефактов: работающий код, тесты, пользовательские истории, баллы за историю, скорость, определение сделанного, бэклог продукта. Потом перейдем к рассмотрению конкретных артефактов: рабочего пространства, карточек истории, задач, панели историй, диаграмме выполненных работ. И в заключение рассмотрим пять артефактов, четыре из которых виртуальные, а один конкретный, фигурирующие постоянно во всех обсуждениях agile – хотя и негативно, как ловушки, которых следует избегать: помехи, технические долги, затраты, зависимости, диаграммы зависимостей.
Оглавление
-
Лекция 9
35 минут
Методы agile
Методы agile, такие как Lean Software (с вариантом Kanban), XP, Scrum, Crystal, представляют особую комбинацию компонент, описаннных в предыдущих главах: принципов, практик, ролей, артефактов. Это не произвольная смесь, а разумная конструкция с собственным отличающимся взглядом на разработку программных продуктов. В этой главе дадим обзор ключевых характеристик каждого из четырех упомянутых методов.
Рассмотрение методов отделено от его описания в книгах, написанных его создателями. В каждом случае метод и соответствующие книги связаны довольно сложным образом. Книги несут на себе печать личности автора, они передают дух метода. Учитывая это, описание каждого метода в этой главе включает короткий обзор текстов, лежащих в основе метода.
Оглавление
-
Лекция 10
12 минут
Работа с agile командами
Прежде чем перейти к заключительным оценкам, проведем краткую экспертизу, позволяющую понять, как работать в вашей организации с группами, которые восприняли agile идеи.
Оглавление
-
Лекция 11
23 минуты
Ужасный, шумный и прекрасный: оценка agile подхода
Мы изучили основные принципы, роли, практики, артефакты, составляющие канон agile. Пришло время оценить вклад agile: какие из его идей должны осуждаться, какие не имеют особого значения, какие действительно помогают.
Разделы этой главы в отличие от перечисления, вынесенного в заглавие данной книги, будут использовать не три категории, а четыре, отделяя просто хорошие идеи от идей блестящих. Пороки методов agile вполне реальны, но подход не заслуживал бы нашего внимания, если бы не включал гениальные предвидения, поэтому так важно закончить эту книгу предъявлением жемчужин.
Оглавление
-
Алексей Задойный
Павел Плахотник
|
http://www.intuit.ru/studies/courses/3505/747/lecture/26293 Сделайте пожалуйста вопросы более корректными. Это сложно конечно. Но надо четко понимать что именно имеется в виду. По предварительному анализу, водопаду, документам требований вообще не понятно что имеется в виду. Возможно надо будет изменить авторский текст, но всё же ясность и конкретность важна. А её нет.
|