эволюция методологий управления (водопад, Rup, Agile) башакин

1. Эволюция методологий управления (водопад, RUP, agile)Дмитрий Башакин, Михаил КумсковУчебный Центр Luxoft

2. О докладчикеДмитрий Башакин (DBashakin@Luxoft.com)

3. Михаил Кумсков (mkumskov@luxoft.com)

4. Luxoft, группа компаний IBS

7. Кто виноват?Нет, не так: что делать?Базис большинства проблем с проектами по разработке ПО:Молодость отрасли – десятки лет

8. «Детская болезнь» – попытка подходить к ИТ-проектам как к разновидности «классических» проектовПричины уникальности программных проектов:Сложность

9. Изменчивость

11. Так что же, все-таки, делать?Знать и учитывать уникальность отрасли «разработка ПО»

12. Учиться

13. Читать

14. Слушать

15. Пробовать

16. Thereisnosilverbullet*, но есть значительный индустриальный опыт, методологии и лучшие практики

18. Определения:Процесс и методологияПроцесс разработки программного обеспечения – это структура, согласно которой построена разработка ПО

19. Определяет набор выполняемых активностей и принципы их увязывания в определенную систему

20. Иерархия процессов

21. Методология (от греч. μεθοδολογία – учение о способах) – система базисных принципов, методов, методик, способов и средств их реализации в организации и построении научно-практической деятельности людей6Copyright © 2009Учебный Центр Luxoft (www.Luxoft-Training.ru)

22. «Железный треугольник»АлистэрКоуберн («Процесс как четвертое измерение», 2003):«Когда речь заходит о руководстве проектами, мы постоянно сталкиваемся с пресловутым Железным Треугольником. В этом треугольнике три вершины, которые описывают параметры проекта: объем работ, время и ресурсы. Можете жестко задать любые две из них, но не все три. Третья величина фиксироваться не должна. В противном случае проект окажется перегружен ограничениями »7Copyright © 2009Учебный Центр Luxoft (www.Luxoft-Training.ru)

24. «Железный треугольник»АлистэрКоуберн («Процесс как четвертое измерение», 2003):«Некоторые из нас все же обнаруживают, что участвуют в проектах, где все три вершины "железного треугольника" уже заданы. Например, нам говорят, что нужно разработать определенную функциональность за 18 месяцев с бюджетом 15 миллионов. Один из моих друзей постоянно получает задания, типа "у тебя есть четыре человека и три месяца, чтобы разработать вот такую функциональность". И, пусть с небольшими поправками, мы это делаем! »9Copyright © 2009Учебный Центр Luxoft (www.Luxoft-Training.ru)

25. «Железный треугольник»АлистэрКоуберн («Процесс как четвертое измерение», 2003):«Секрет в том, что существует еще одна вершина, которую пока еще не оценили по достоинству: процесс разработкиВ большинстве организаций процесс разработки настолько неэффективен, что можно без особого труда увеличить продуктивность работы команды на 30%, всего лишь упростив его. Так мы сэкономим время и ресурсы, что даст нам возможность завершить проект (почти) в срок и (почти) уложиться в бюджет »10Copyright © 2009Учебный Центр Luxoft (www.Luxoft-Training.ru)

27. Процесс. И никакого страха!«Правильный» процесс:продуман и упорядочен

28. задокументирован

29. его знают и ему реально следуют

30. способствует улучшению ситуации

31. не является «обузой»

33. Модели процесса разработки ПОДве основные модели построения процесс разработки ПО:Водопадная (каскадная или последовательная) модель

35. Водопадная модель.Суть и условия возникновенияЗаимствована из классического производства

36. В ИТ возникла в среде, где:

37. требования четко определены заранее и не изменяются

38. надежность ПО является критическим фактором

39. Суть модели:

40. Этапы

41. Переходы между этапами

42. Артефакты

45. Водопадная модель.ДостоинстваПростота и понятность

46. Очевидность для людей из «классического бизнеса»

47. На каждом этапе формируется законченный набор проектной документации, полный и согласованный

48. Работы разных этапов могут выполнять разные команды, в т.ч. территориально распределенные

49. Полнота документирования требований позволяет провести качественное тестирование

51. Водопадная модель.ПроблемыХорошо работает для систем с известными и стабильными требованиями

52. В реальных проектах часто возникает потребность в возврате к предыдущим этапам с целью:

53. учета изменений в требованиях

57. Основное противоречиеИзменения – враг разработчиков ПО

58. Однако изменения – неотъемлемая часть бизнеса заказчика и самого процесса разработки ПО

60. Итеративная модельИтеративная, эволюционная, спиральная, …

61. Мартин Фаулер (2004): «Итеративную разработку называют по-разному: инкрементальной, спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны, как противостояние итеративного метода и метода водопада»

63. Итеративная модель.Основные принципыЖизненный цикл разработки ПО – последовательность относительно коротких частей (итерации)

64. Итерация – маленький «водопад»

65. Требования – стабильность в рамках итерации

66. Результат – работоспособная версия системы с дополнительной функциональностью (инкремент)

67. Поставка результата Заказчику, учет его отклика для планирования следующей итерации

71. Итеративная модель.Достоинства (1)Цена внесения изменений существенно ниже

72. Вероятность успеха существенно выше

73. Не нужно формулировать все требования до начала разработки

74. Можно приоритезировать требования

75. Можно начать пользоваться системой рано

77. Итеративная модель.Достоинства (2)Можно рано адресовать технологические риски

78. Ключевая функциональность тестируется лучше всего

79. Сохраняется высокий уровень документирования

80. «Заставляет» использовать автоматизированное тестирование

82. Что такое RUP (1)Методология разработки ПО. Лучшие практики:Итеративность

83. Архитектуро-центричность, компонентность

84. Движущая сила – требования в форме прецедентов использования (use cases)

85. Активное использование визуального моделирования

86. Постоянная проверка качества

88. Что такое RUP (2)Процессный продуктОписание ролей и активностей

89. Шаблоны и примеры заполнения артефактов

90. Руководства по выполнению активностей

92. Суть RUPЦикл разработки системы делится на набор релизов, передаваемых в промышленную эксплуатацию

93. Цикл разработки каждого релиза делится на некоторое количество итераций

94. Каждая итерация:

95. имеет критерий оценки успешности

96. выполняется по согласованному плану

98. Виды деятельностив рамках релизаБизнес-моделирование

99. Сбор требований

100. Анализ требований, архитектура, проектирование

101. Реализация и тестирование

102. Развертывание

103. Управление конфигурацией и изменениями

104. Управление проектом

106. Основные задачив рамках релизаПонять, что именно нам нужно разработатьОпределить, как мы будем вести разработкуРазработать и протестировать продуктПередать продукт в эксплуатацию31Copyright © 2009Учебный Центр Luxoft (www.Luxoft-Training.ru)

109. Итеративная модель(классика) – что не так?Потеря полноты и согласованности проектной документацией

110. Поздняя определенность бюджета проекта

111. «Разбухание» методологии

112. Сложность внедрения методологии

113. Итеративный процесс существенно дороже «водопада»

114. Доработка артефактов всегда дороже разработки «с нуля»

115. Затраты на рефакторинг

117. Плата за универсализмПроекты любого уровня сложности и масштаба

118. Проекты любогоуровня ответственности

119. Команды любогоразмера и распределенности

120. Команды любого уровня профессионализма и сработанности

121. Отношения с Заказчиком любого уровня формализма / доверия и «прозрачности»

123. И что теперь?Нужна гибкость!АлистэрКоуберн («Процесс как четвертое измерение», 2003):«Секрет в том, что существует еще одна вершина, которую пока еще не оценили по достоинству: процесс разработки. (…) Вторая часть этого "секрета" состоит в том, что это ни для кого не секрет. (…) старожилы часто рассказывали мне, как они давным-давно использовали то, что сейчас называется "гибкими методологиями", чтобы выполнить невыполнимый проект в срок»36Copyright © 2009Учебный Центр Luxoft (www.Luxoft-Training.ru)

124. Суть гибких методологийЗачем платить за универсализм? Ключевые моменты:

125. отказ от избыточного формализма

126. исполнение проекта

127. (относительно) небольшой …

128. самоорганизующейся командой …

129. состоящей из высокопрофессиональных специалистов …

130. «широкого профиля» …

131. работающих «плечом к плечу» …

132. (скорее всего) уже не первый год

134. «Облегченные»«тяжелые» методологииRUP XP – 2002, совместная разработка Object Mentor Inc. и Rational Software Corporation

135. 2 варианта RUPначиная с версии 7.0:

136. RUP для больших проектов (Classic RUP)

137. RUP для небольших проектов (RUP for Small Projects)

138. 2 варианта MSFначиная с версии 4.0:

139. MSF для процесса CMMI

141. Выбор методологииЛюбая методология может привести к неудаче и, в конечном счете, к провалу проекта

142. Выход:

143. Учет специфики конкретного проекта

144. Выбор оптимальной методологии (если возможно), или

146. Выбор пропорции «методологического коктейля»Критерии выбора:проект (сложность, критичность и ответственность проекта)

147. команда (размер, степень распределенности, "качество", стабильность - текучка, переход к поддержке)

148. проектные требования (степень определенности и изменчивости

149. отношения с Заказчиком («качество» отношений, степень вовлеченности в исполнение проекта)

151. Сильные стороны классических итеративных методологий (RUP)Применимость в более широком диапазоне ситуаций («любой проект»)

152. Внимание проработке архитектуры

153. Внимание документированию требований и отслеживанию связей требований с другими артефактами

155. Сильные стороны гибких методологийВнимание «человеческому фактору» (отношения, коммуникации, мотивация, лидерство)

156. Гибкость

157. Главное для всех в команде – успех проекта (а не успех выполнения отдельной задачи)

158. Упор на постоянное взаимодействие с Заказчиком

159. Самоорганизация и самоуправление команд

160. Кроссфункциональность членов команд

162. Обратить внимание:инженерные практики XPРефакторинг

163. TestDrivenDevelopment

164. Непрерывная интеграция

165. Коллективное владение кодом

167. Обратить внимание:Управленческие практики ScrumЕжедневные краткие статусные митинги

168. Демонстрация результатов итерации Заказчику

169. Внутренний анализ хода итерации в команде (ретроспектива)

170. Ревью хода итерации совместно с Заказчиком

эволюция методологий управления (водопад, Rup, Agile) башакин

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to эволюция методологий управления (водопад, Rup, Agile) башакин (20)

More from WRider (11)

эволюция методологий управления (водопад, Rup, Agile) башакин