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

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

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

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

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

12. Учиться

13. Читать

14. Слушать

15. Пробовать

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

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

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

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

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

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

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

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

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

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

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

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

40. Этапы

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

42. Артефакты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

142. Выход:

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

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

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

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

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

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

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

156. Гибкость

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

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

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

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

163. TestDrivenDevelopment

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

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

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

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

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (6)

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

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

Mehr von WRider

Mehr von WRider (11)

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