Agile вики: Agile — Systems Engineering Thinking Wiki

Agile — Systems Engineering Thinking Wiki

Agile (на русский обычно не переводится, хотя иногда говорят о “гибких методах”) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.

В системной инженерии “железных” систем методы agile пока используются мало, но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы практики, зарекомендовавшие себя при разработке ПО.

Гибкое моделирование

Метод описания архитектуры программной системы, который следует идее того, что содержимое важнее представления. Это обеспечивает простоту, понятность, достаточную точность и единообразие создаваемых моделей.

Простота документа гарантирует активное участие заинтересованных сторон в моделировании артефактов. Более подробно этот подход рассматривается в книге Скотта Амблера «Гибкие технологии: экстремальное программирование и унифицированный процесс разработки» (J. Wiley, ISBN-10: 0471202827, ISBN-13: 978-0471202820; Питер, ISBN 5-94723-545-5, 0-471-20282-7).

Критика

• При agile-подходе часто пренебрегают созданием плана («дорожной карты») развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.
• Считается, что работа в agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов.

Ссылки

Примеры внедрения agile и других гибких методов в системной инженерии:

• организация хода разработок в компании SpaceX. Главная там фраза — focus on tools not rules. А потом test rigorously and often.
• производство автомобиля: видеорассказ, описание автомобиля, eXtreme manufacturing, TDD for hardware. Главное там было — обеспечить высокую скорость изменений, и указывались примерно те же механизмы, что и в SpaceX (обмен информацией через сеть вместо традиционных control boards, даже была оговорка, что ещё лет пять назад это было бы невозможно по причине недоразвитости сетевых сервисов, а лет десять назад всех этих сервисов вообще не существовало).
• lean systems engineering – «бережливая» системная инженерия
• «Kanban and Scrum. Making the most of both» – пример связи подходов lean и agile.
• Впечатляющий пример – как стадион разбили на 12 секторов, и пока один сектор проектировали, предыдущий строили, а пред-предыдущий отделывали (6й сезон 14й фильм из замечательной серии телевизионных документальных фильмов про мастерство инженеров).

См. также

Авторы Agile-манифеста . Гибкое управление проектами и продуктами

В феврале 2001 года в местечке под названием Сноуберд в штате Юта собрались 17 специалистов (консультантов и практиков), чтобы обсудить легковесные методики разработки. В результате родился документ «Манифест гибких методологий разработки» (Agile Manifesto). Позволю себе привести список авторов манифеста и краткую информацию о них.

Кент Бек – создатель разработки через тестирование и экстремального программирования. Автор нескольких книг на эти темы и соавтор JUnit.

Майк Бидл – основатель и генеральный директор e-Architects Inc., консалтинговой компании, которая специализируется на разработке распределенного ПО. Он также является соавтором книги

Scrum, Agile Software Development, написанной совместно с Кеном Швабером.

Усовершенствованная водопадная модель разработки ПО

Эйри ван Беннекум – участвовал в разработке методологии DSDM с 1997 года. До этого активно работал над быстрой разработкой (Rapid Application Development).

Алистер Кокберн – известен исследованиями проектных команд и участием в разработке семейства методологий Crystal.

Уорд Каннингем – основатель Cunningham & Cunningham, Inc. Он также широко известен своим огромным вкладом в развитие объектно-ориентированного программирования, экстремального программирования и в концепцию вики.

Джеймс Греннинг – тренер и консультант по гибким методологиям. Является специалистом в области разработки и тестирования встроенного программного обеспечения и автором книги Test Driven Development for Embedded C.

Стивен Меллор – специалист в области разработки программного обеспечения, соавтор метода ООАП Шлаера-Меллора, работал над UML в составе Object Management Group.

Мартин Фаулер – главный исследователь в компании Thoughtworks. Автор многих работ и книг по паттернам анализа, UML, рефакторингу и экстремальному программированию.

Джим Хайсмит – ведущий разработчик методологии Adaptive Software Development и автор соответствующей книги.

Эндрю Хант – соавтор книги Pragmatic Programmer: From Journeyman to Master и других работ, связанных с разработкой ПО.

Рон Джеффрис – владелец сайта XProgramming.com, консультант в компании Object Mentor и соавтор книги Extreme Programming Installed.

Джон Керн – участвовал во многих проектах по исследованиям и разработке в области авиастроения.

Он также является евангелистом объектно-ориентированного программирования с начала 90-х годов.

Брайан Мэрик – программист и консультант по тестированию программного обеспечения. Основной вклад Брайана заключается в исследовании процессов тестирования ПО в гибких методологиях разработки.

Роберт Мартин – работает в отрасли разработки ПО с 1970 года. Он является президентом и основателем фирмы Object Mentor Inc., которая специализируется на консалтинге в области экстремального программирования, гибких методологиях разработки, консалтинге по архитектуре ПО и т. д. Он также является соавтором книг по программированию и разработке программного обеспечения.

Кен Швабер – президент компании Advanced Development Methods (ADM), которая занимается улучшением методов разработки ПО. Он является опытным разработчиком, менеджером продуктов и консультантом. В начале 90-х годов он работал с Джеффом Сазерлендом над первыми версиями Scrum. Он также является соавтором книги Scrum, Agile Software Development.

Джефф Сазерленд – технический директор (CTO) компании PatientKeeper, которая занимается созданием ПО для медицинских учреждений. За свою карьеру был техническим директором (или вице-президентом по технологиям) в девяти компаниях. Известность приобрел как изобретатель методологии Scrum.

Дейв Томас – верит, что сердце проекта по разработке – не методология, а люди. По этой причине он является соавтором книги The Pragmatic Programmer.

5 простых лайфхаков для пользователей Confluence

Confluence от Atlassian прекрасно справляется с организацией всех бизнес процессов и документов, и мы предлагаем 5 простых лайфхаков, которые помогут еще больше упростить работу с ним.

Confluence от Atlassian прекрасно справляется с организацией всех бизнес процессов и документов, и многие его поклонники уверены, что с его помощью работа в команде становится более эффективной и творческой, ведь все члены команды могут создавать, делиться и обсуждать созданный контент в едином пространстве интранета. Вас не будет смущать количество всей доступной информации, поскольку контент организован по специфической иерархии, так что каждый сотрудник найдет нужный документ и отредактирует его с помощью встроенных шаблонов. Поэтому управление знаниями значительно упрощается, а совместная работа с другими сотрудниками становится более прозрачной.

Несмотря на то, что Confluence, основанный на принципах вики-системы, очень хорош для организации всей имеющейся информации, многие удобные и простые в использовании функции в Confluence часто остаются без внимания. Мы предлагаем несколько простых лайфхаков для пользователей Confluence, которые помогут в редактировании страниц и работе в Confluence в целом:

Как пользоваться готовыми шаблонами страниц

Как изменить стиль текста (если ничего не меняется)

Это решение подойдет для текстовых элементов в Confluence, особенно для ссылок, к которым не удается применить различные стилевые настройки.

Чтобы исправить это, можно поместить их в SPAN или DIV макро и поработать с макро командным стилевым оформлением, но это работает не для всех текстовых элементов.

В таком случае нужно найти, какой именно встроенный CSS элемент управляет ими, и затем создать новый стиль для выбранных элементов в Global Stylesheet.

Вы можете установить в браузер код вьювер, с помощью которого можно определить какой именно CSS стиль управляет отображением гиперссылок в Confluence. Можно также найти всю необходимую информацию на официальном сайте Atlassian Confluence.

Как убрать страницу из дерева страниц (page tree)

Если страница в Confluence должна входить в другую категорию, ее можно скрыть из дерева  страниц. Для этого найдите Space tools и кликнете по Content tools. В списке инструментов выберите Reorder Pages. Теперь перетащите страницу, которую вы хотите скрыть в позицию “над” вашей домашней страницей (Space homepage). Все ссылки по-прежнему будут работать, а страница будет скрыта из дерева страниц.

Как редактировать прикрепленные файлы

Еще одна причина, по которой вы можете прокрастинировать в Confluence — это редактирование прикрепленных к странице файлов. Но Atlassian разработал решение, которое сэкономит ваше время. Теперь все пользователи могут редактировать прикрепленные файлы и сохранять изменения, не скачивая и не загружая документ обратно на сайт. Просто нажмите на кнопку “Edit with” в правом верхнем углу и добавьте изменения в сам файл.

Как упомянуть кого-то с помощью @

Как и в Facebook, Instagram и Twitter, можно использовать знакомую из социальных сетей функцию и в Confluence. Это отличный способ привлечь внимание других членов команды к необходимому вопросу или контенту. Чтобы упомянуть кого-то, поставьте перед именем пользователя знак “@”, и все. Таким образом вы получите ответ намного быстрее, чем если бы вам пришлось писать человеку на почту. И наоборот, в куче входящих писем пользователь может потерять нужную ему информацию. Упомяните пользователя через “@”, и он быстрее найдет нужное письмо. Упоминая таким способом ваших сотрудников , можно также поручать им новые задания.

Надеемся, что после прочитанных советов, вы узнали что-то новое о Confluence, и теперь будете пользоваться им с большей уверенностью. Если вам необходима дополнительная консультация по работе с Confluence, основным принципам Agile и ITSM, эксперты Polontech всегда рады вам помочь. Мы предлагаем различные онлайн и оффлайн тренинги по Confluence, на которых вы получите практические навыки по работе с этим вики инструментом.

 

Atlassian Confluence — обзор Wiki системы на русском

Корпоративная вики-система с открытым кодом. Позволяет организовывать рабочие пространства для совместной работы, файлохранилища, дискуссии, блоги. Имеет отличные возможности для интеграции и более 100 плагинов. Хорошо совместима с MS Office

2011. JIRA и Confluence доступны в виде SaaS сервиса
Компания Atlassian запустила SaaS сервис Atlassian OnDemand, в который вошли ее популярные (и в России, и в мире) инструменты для управления проектами разработки ПО: JIRA (issue-трекер), Confluence (wiki), GreenHopper (Agile управление проектами), Bonfire (баг-репортер), FishEye (менеджер кода), Crucible (рецензор кода) и Bamboo (интеграция). Все продукты в SaaS версии по функциональности не уступают инсталлируемым аналогам. Есть лишь минимальные ограничения по интеграции и использованию собственных плагинов. Инструменты можно подключать или отключать по мере необходимости. Ценообразование сервиса — уже традиционное для Atlassian — «все по $10 за 10 юзеров». Напомним, что компания уже давно продает эти свои продукты (в инсталлируемом варианте) по цене $10 за лицензию на 10 пользователей. Т.е. вы можете либо купить продукт за 10$, либо взять его в аренду за 10$/месяц. ***

2009. Магический квадрант по корпоративному Социальному ПО 2009

Аналитики Gartner представили второй по счету Магический квадрант по рынку корпоративного Социального ПО. За прошедший год на этом рынке выделились 3 лидера — в квадрате Лидеров, который в прошлом году был пустой — обосновались Microsoft (Sharepoint), IBM (Connections, Quickr, WebSphere Portal) и Jive Software (SBS). Их преследуют Atlassian (Confluence) и Open Text, который в этом году выпустил социальный модуль Social Workplace для своей ECM платформы. Не далеко от него и главный конкурент на ECM рынке — EMC (Documentum). Отметим стремительное появление в магическом квадранте Google со своими революционными продуктами Google Wave и Google Buzz. В целом, рынок Социального ПО до сих пор в глазах Gartner выглядит как броуновское движение непонятных вендоров.

2009. Atlassian Confluence 3.0 атакует SocialText

Уже довольно много отечественных компаний знают и пользуются системой управления инцидентами Jira производства Atlassian. А вот второй знаменитый продукт этой компании — социальная интранет wiki-система Confluence — почему-то пока не завоевала такой популярности. Хотя она постоянно присутствует на первых местах во всех западных рейтингах Enterprise 2.0 приложений, рядом со своим главным конкурентом — SocialText. В конце прошлой недели увидела свет версия Confluence 3.0, которая обогатилась несколькими полезными (и предсказуемыми) фичами. Предсказуемыми, потому как недавно такие же фичи появились и в SocialText. Модуль микроблоггинга ***

2009. Рейтинг CMS решений для интранета

Блог Intranetblog провел глобальное исследование систем управления контентом (CMS), используемых для создания корпоративных интранетов. В отличии от рынка систем для совместной работы, в сфере управления контентом  MS Sharepoint не имеет подавляющего преимущества, хотя и является лидером. Доля Sharepoint — 20%. Ближайшие преследователи Interwoven, Documentum и Vignette владеют лишь по 4%. Кроме того, исследование показало, что организации, использующие Sharepoint, также дополнительно используют популярные Enterprise 2.0 приложения SocialText, Confluence и MediaWiki. Вот еще некоторая статистика: ***

Мы создаем лучший в мире телекоммуникационный сервис

DINS — это центр разработки американской компании RingCentral, ведущего разработчика и провайдера облачных коммуникационных услуг для бизнеса. Мы работаем в Санкт‑Петербурге с 1998 года, сейчас штат компании составляет 1200+ сотрудников, большая часть из которых инженеры.

Лидер Gartner UCaaS Magic Quadrant в течение последних 6 лет (июль, 2020)

Лучше всего о продукте расскажут цифры

Мы участвуем в разработке и поддержке UCaaS-платформы с большим набором функций: голос, видео, текст, факсы, конференции, онлайн-митинги, контактный центр и корпоративный чат.

31

дата-центров на 5 континентах

99.999%

доступности сервиса

>2 млн

абонентов

>125 тыс

звонков одновременно

>1400

интеграций по API

>120

изменений на продакшн в день

Некоторые технические подробности

	Клиентские приложения для MacOS, Windows, Android, iOS.
	Система автоматической сборки и тестирования, реализующая разработку ПО по принципу continuous integration.
	Базы данных со сложной архитектурой на основе СУБД Oracle, Vertica, Mongo DB. Репликация данных между базами осуществляется с помощью технологий GoldenGate. Oracle Coherence и GridGain используются для оптимизации работы с данными в памяти.

	Разработка ведется в дружных командах по методологии Agile/SCRUM.
	Технология обработки данных Hadoop.
	Java-backend, предоставляющий программный интерфейс для доступа к системе на основе SOAP.
	Языки разработки: Java (Backend), JavaScript (Web-сервисы), C++ (телефония, VoIP), PL/SQL, скриптовые языки — Python, Perl, Ruby (автоматическое тестирование, инструменты для мониторинга сервиса и т.п.).

COVID-19

Вы можете поблагодарить нас, либо оставить свои пожелания по улучшению условий безопасной деятельности организации.

Чистый Agile. Основы гибкости читать онлайн Роберт Мартин (Страница 3)

История Agile

Когда зародился Agile? Вероятно, более 50 тысяч лет назад, когда люди впервые решили работать совместно ради общей цели. Идея постановки небольших промежуточных целей и измерения продвижения после их достижения у человека проявляется на подсознательном уровне, поэтому вряд ли это какая-то настоящая революция.

Когда впервые появился Agile в современном мире? Трудно сказать. В моем представлении, первый паровой двигатель, первая мельница, первый двигатель внутреннего сгорания, первый самолет были созданы с помощью методик, которые сейчас можно отнести к Agile. Я считаю так, потому что предпринимать небольшие измеряемые шаги очень естественно для человека, сложно представить, что это происходит иначе.

Так когда же Agile появился среди программистов? Хотел бы я быть мухой на стене у Алана Тьюринга, когда тот писал свою книгу в 1936 году [Turing A. M. 1936. On computable numbers, with an application to the Entscheidungsproblem [доказательство]. Proceedings of the London Mathematical Society (Труды Лондонского математического общества), 2 (изд. 1937), 42(1):230–65. — Лучший способ ознакомиться с этой работой — прочитать произведение Чарльза Петцольда: Petzold C. The Annotated Turing: A Guided Tour through Alan Turing’s Historic Paper on Computability and the Turing Machine. Indianapolis, Indiana: Wiley, 2008.]. По моим догадкам, многие свои «программы» он написал, разбивая работу на мелкие этапы с изобилием отладки по исходному тексту вручную.

Я также хорошо представляю, что первый код, который он написал для автоматической вычислительной машины (Automatic Computing Engine, ACE) в 1946 году, был написан постепенно, маленькими этапами, с частым проведением ручной отладки по исходному тексту и даже с небольшим тестированием в действии.

В первые дни существования программного обеспечения можно найти много примеров решения задач, которые сейчас бы отнесли к Agile. Например, программисты, писавшие код для управления пилотируемым космическим кораблем «Меркурий», работали по этапам с интервалом в полдня с перерывами на модульное тестирование.

Об этом периоде есть много материалов. Крэг Ларман и Вик Базили написали историю, которая кратко изложена в «вики» Уорда Каннингема [«Вики» Уорда, c2.com — сайт оригинальной «Википедии», первый день появления в сети Интернет. Пусть поддержка длится как можно дольше.], а также в книге Лармана Agile & Iterative Development: A Manager’s Guide [Larman C. Agile & Iterative Development: A Manager’s Guide. Boston, Massachusetts: Addison-Wesley, 2004.].

Однако существовал не только Agile. Действительно, есть конкурирующая методология, которая пользовалась значительным успехом в производстве и промышленности в целом: научная организация труда.

Научная организация труда — это командно-административный подход с иерархической структурой. Менеджеры применяют научную организацию труда, чтобы определять наилучший набор процедур для достижения цели и отдавать распоряжения всем подчиненным для выполнения плана с точностью до буквы. Другими словами, сначала планируется крупная задача, затем проводится тщательная и подробная проработка плана.

Научная организация труда, вероятно, такая же древняя, как пирамиды в Египте, Стоунхендж или прочие подобные работы древних времен: с трудом верится, что можно работать по-другому. Еще раз замечу, идея повторять успешный опыт настолько глубоко подсознательно заложена в человеке, что ее сложно охарактеризовать как революционную.

Научная организация труда получила свое название из работ Фредерика Уинслоу Тейлора, написанных в 1880-х. Тейлор сформировал этот подход, придав ему коммерческую ценность и сделав состояние на консультировании по управлению. Метод получил широкий успех и привел к значительному повышению эффективности и производительности в последующие десятилетия.

И так случилось в 1970-е, что мир разработчиков программного обеспечения разделился на два лагеря — сторонников того или иного метода. Прото-Agile (Agile, еще не получивший название «Agile») предлагал предпринимать в зависимости от обстоятельств небольшие случайные шаги, которые можно измерить и выделить, для того чтобы идти в правильном направлении к наилучшему исходу. Научная организация труда призывала откладывать действие до тщательного анализа и проработки заранее подготовленного плана. Прото-Agile прекрасно подходил для проектов с низкой стоимостью внесения изменений, которые решали частично определенные задачи с произвольно поставленными целями.

Научная организация труда лучше всего подходила для проектов, которые решали четко определенные задачи с весьма определенными целями. И в них стоимость изменений уже возрастала. Какими были проекты в отрасли разработки программного обеспечения? Была ли в этих проектах стоимость изменений высока? Были ли задачи определены четко? Или стоимость изменений была низкой, а цели были поставлены произвольно?

Не вчитывайтесь слишком внимательно в предыдущий абзац. Насколько я знаю, никто не задавался такими вопросами. Иронично и то, что путь, выбранный в 1970-х годах, кажется, был обусловлен, скорее, волей случая.

В 1970 году Уинстон Ройс в своей работе [Royce W. W. 1970. Managing the development of large software systems. Proceedings, IEEE WESCON, August: 1–9. URL: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf.] описал идеи для управления крупномасштабными проектами по разработке программного обеспечения. В этой работе присутствовала схема (рис. 1.1), которая наглядно изображала его план. Ройс не был автором этой схемы и не продвигал ее в качестве плана. В действительности график представлял собой изображение соломенного человечка и помогал Ройсу ориентироваться в последующих страницах своего труда.

Рис. 1.1. Схема Уинстона Ройса, которая стала источником вдохновения для разработки каскадной модели

Схема была расположена на видном месте. А учитывая, что люди делают логические выводы о содержании статьи, посмотрев схему на первой или второй странице, это привело к резкому сдвигу в отрасли программного обеспечения.

Схема, первоначально составленная Ройсом, гораздо больше напоминала ручей, стекающий вниз со скалистого хребта, чем ныне известную каскадную модель.

Каскадная модель стала логическим продолжением научной организации труда. При использовании этой модели на первый план ставится тщательный анализ, составление подробного плана, а затем уже доведение этого плана до завершения. Хотя Ройс и не рекомендовал такой подход, но именно эту концепцию вынесли из его работы. А потом эта концепция главенствовала в отрасли более трех десятков лет [Стоит отметить, что мое толкование этой временной шкалы подвергли сомнениям. См.: Bossavit L. The Leprechauns of Software Engineering: How Folklore Turns into Fact and What to Do About It, Ch. 7. Leanpub, 2012.].

Как раз тогда и начинается моя история. В 1970-м мне было 18 лет, я работал программистом в компании A.S. C. Tabulating, расположенной в Лейк Блафф, Иллинойс.

У компании был компьютер IBM 360/30 с памятью на магнитных сердечниках 16 килобайт, IBM 360/40 с памятью 64 килобайта и микрокомпьютер Varian 620/f с памятью 6 килобайт. Я писал программы для семейства 360 на COBOL, PL/1, Fortran и ассемблере. Для 620/f я писал только на ассемблере.

Важно помнить, каково в то время было программистам. Мы писали код в программных формулярах с помощью карандашей. У нас были операторы, работающие за перфоратором, которые наносили программы на карты. Мы передавали тщательно выверенные перфокарты операторам ЭВМ, которые проводили компиляцию и тестирование в третью смену, поскольку днем, когда работа кипела, компьютеры были постоянно заняты. От начала написания кода до первой компиляции зачастую проходило несколько дней, каждый цикл разработки вследствие этого занимал, как правило, сутки.

Для меня 620/f выглядел несколько иначе. Эту машину выделили нашей команде, поэтому мы могли работать на ней столько, сколько вздумается. Мы проводили два, три, иногда даже четыре цикла разработки и тестирования за сутки. Вместе со мной в команде были люди, которые, в отличие от большинства программистов того времени, умели печатать. Поэтому мы могли штамповать свои собственные колоды перфокарт, а не зависеть от капризов операторов, работающих за перфоратором.

Какую методологию мы использовали на протяжении того времени? Это, конечно, была не каскадная модель. У нас не было концепций или подробных планов. Мы просто писали код каждый день, компилировали, тестировали и устраняли ошибки. Это был бесконечный цикл без структуры. Также это был не Agile и даже не прото-Agile. В ходе работ мы не придерживались каких-либо правил организации. Тогда не было каких-либо пакетов программ для тестирования и измеряемых временных интервалов. Просто надо было писать код и фиксить баги. День за днем, месяц за месяцем.

Впервые я узнал о каскадной модели из профессиональных журналов около 1972 года. Мне она казалась даром свыше. Неужели мы могли бы проанализировать задачу, потом предложить ее решение, а затем реализовать замысел? Реально ли было на самом деле разработать график, основанный на трех перечисленных этапах?

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

Судя по всему, я был не один, потому что многие другие программисты и центры программирования тоже вошли в кураж. И, как я уже писал, в нашем мышлении начала преобладать каскадная модель.

Она преобладала, но не работала. В течение последующих тридцати лет мои коллеги, я, братья и сестры по программированию по всему миру неустанно старались получить право на проведение анализа и проектирование. Но каждый раз, когда мы думали, что получали желаемое, оно ускользало из наших рук на этапе реализации. Месяцы тщательного планирования пошли прахом из-за необходимости сделать безумный рывок, в итоге мы сорвали сроки под свирепыми взглядами менеджеров и заказчиков.

Несмотря на практически нескончаемый поток неудач, мы все равно настаивали на состоятельности каскадной модели. В конце концов, почему возникали неудачи? Почему тщательный анализ задачи, внимательное проектирование решения и последующая реализация нескончаемо терпят зрелищный крах? Никто даже подумать не мог, что дело было в самой стратегии. Задача должна была лечь на наши плечи. Как бы то ни было, что-то мы делали не так.

Сервисы для совместной работы и управления проектами

1

Система для совместной работы в малой или средней компании любого профиля. Помогает повышать продажи, управлять сотрудниками и работать удаленно. В комплекте: CRM, выставление счетов, контроль сделок, таск-менеджер, файловый сервер, внутренняя почта, форум, модуль для работы с персоналом.

2

Wrike позволяет создавать задачи, группировать их по проектам и отслеживать ход их выполнения. Основное преимущество сервиса — более продвинутая по сравнению с конкурентами функциональность для совместной работы Содержит сетевой график и отчеты по проектам. Позволяет устанавливать напоминания и логировать время выполнения задач. Мобильные приложения. Есть русский интерфейс.

3

Простой и удобный сервис для управления задачами и проектами. Интеграция с Email. Мобильные версии. Бесплатен для команд до 30 человек. Есть русская версия

4

Простая для всей команды система управления и общения. Для общения: каждая задача — это чат, есть персональные и групповые чаты. Для планирования: agile-доски, TO-DO листы, “мои” задачи, дедлайны, приоритеты, гибкая настройка прав и еще 78 полезных функций. Для руководителя: любые отчеты, сводки, система онлайн-мониторинга.

5

Сервис для управления проектами в виде перечня списков, заполненных карточками, используемыми вашей командой или непосредственно вами. Можно перетаскивать карточки между списками, чтобы показать прогресс.

6

Русскоязычная онлайн-система для управления проектами. Содержит dashboard, задачи с комментариями, календарь, хранилище файлов, систему учета времени, тэги. Поддержка SSL, FTP пользователя, субдоменов пользователя. Отличается простотой и доступностью.

7

Простая и эффективная система управления проектами. Содержит задачи, календарь, дискуссии, профайлы, вики-документы, файлы, лог проекта. Легко позволяет организовать совместную работу с клиентами и партнерами. Поддерживает мобильный доступ.

8

Российская комплексная информационная система, которая покрывает все процессы проектного управления и автоматизирует работу всех участников проектов. Настраивается под особенности бизнеса без программирования. Заменяет решения на базе MS Project Server + Sharepoint + BI + Excel и других аналогов. Гарантированно внедряется за 2 месяца. Отраслевые и функциональные решения для крупных и средних компаний. Интуитивно-понятный интерфейс.

9

Сервис для совместной работы и управления проектами. Содержит инструмент Workflow и конструктор приложений, удобные дашборды.

10

Корпоративное решение для планирования проектов, распределения задач и ресурсов по исполнителям, бюджетирования и мониторинга выполнения проектов. Предоставляет windows-приложение и сервер (MS Project Server) для совместной работы и онлайн доступа. Тесная интеграция с MS Sharepoint и Outlook

11

ПланФикс — это система управления коллективной работой. Мы помогаем организовать совместную работу людей и управлять ею (это важное уточнение). Что это будет за работа — зависит только от ваших потребностей: ПланФикс одинаково хорошо подходит для бизнеса и некоммерческих организаций, общественных объединений или любой другой группы людей, работающих над общим делом.

12

Сервис для управления проектами по методологии Agile. Пользователи могут создавать задачи, описывать их, назначать исполнителей и наблюдателей, а также комментировать ход решения вопроса в карточке задачи. Гибкие настройки прав доступа. Высокая производительность

13

Сервис для планирования проектов и организации совместной работы в составе Office 365. Интеграция с другими сервисами Microsoft

14

Функционально насыщенный сервис с календарем, органайзером, хранилищем и редакторами документов, отчетами, форумом, мессенджером, wiki, планировщиком встреч, тайм-трекером. Удобная система для совместной работы в реальном времени. Интегрирован с другими сервисами Zoho. Импорт из MS Project. Есть бесплатная версия на 1 проект. Есть русский интерфейс

15

Иерархическая система управления проектами с несложным веб-интерфейсом. Полностью русифицирована. Встроенные вики, форумы, управление задачами с поддержкой исполнителя и ответственного. Быстрая, стабильная система с возможностью установки сервера на любую платформу. Подробная документация. Есть бесплатный SaaS сервис на 5 пользователей. Версия для установки на свой сервер доступна для скачивания на сайте и также бесплатна для 5 пользователей.

16

Доступная, понятная система управления проектами для небольших компаний. Даёт возможность создавать проекты, задачи, чек-листы (наконец-то!), писать комментарии, прикреплять документы и логировать все действия пользователей.

17

Онлайн система для совместной работы и управления проектами. Возможности: учет задач, учет времени, возможность вести обсуждения, сохранять файлы, заметки по проектам, задачи можно отобразить в виде диаграммы Ганта, канбан-доски, 8 видов отчетов, шаблоны задач. Есть трекер времени для Mac, мобильные приложения для IOS, Android.

18

Отечественная вэб-система для управления проектами. Позволяет создавать проекты и задачи, ставить задачи сотрудникам, контролировать состояние задач. К задачам можно прикреплять файлы и писать комментарии. Есть напоминания на ICQ и Jabber. Есть инсталлируемая версия

19

Agile-система управления проектами, с контролем бюджета. Поддерживает Kanban и SCRUM

20

Онлайн сервис для управления проектами для малого бизнеса. Функциональность включает персонализированную контрольную панель, задачи, отчеты, напоминания, таймтрекер, диаграмму Гантта, планирование бюджета, календарь, систему прав доступа, обсуждения и заметки. Интеграция в Outlook, AutoCAD, MS Project. Предоставляет API для разработчиков.

21

Легкое в использовании вэб приложение для управления проектами и задачами. Содержит календарь (с поддержкой iCalendar), сетевой график, хранилище для файлов, профайлы пользователей, систему управления правами доступа, отчеты. Отличная интеграция с Email

22

Простой и удобный органайзер для совместной работы над задачами и проектами. Drag and drop интерфейс, сортировка задач по приоритету, объединение задач в группы, календарь, напоминания, встречи, чат между участниками проекта. Есть платные и бесплатная версии.

23

Кросс-платформенный таск-менеджер, который синхронизирует задачи между компьютерами и мобильными девайсами. Позволяет ставить задачи другим пользователям, а также создавать совместные проекты. Есть интеграция с электронной почтой (оповещения и создание задач по email), встроенный календарь, комментарии и файлы к задачам.

24

Система управления задачами и проектами. Специальные функции для: Веб-студий, SEO-компаний и Фрилансеров. Есть бесплатная версия

25

Система управления проектами для G Suite. Позволяет создавать канбан-доски. Основная функциональность — бесплатна

26

Система управления задачами, проектами и бизнес-процессами любой сложности с возможностью очень глубокой кастомизации в облаке, доступная по стоимости и внедрению компаниям любого размера. Есть множество готовых конфигураций, возможность настройки системы под любую задачу.

27

Система управления задачами для небольших команд. AB-TASKS позволяет менеджерам, разработчикам и клиентам собираться в одном месте для работы над проектами.

28

Система управления проектами на основе гибких методологий Scrum, Kanban.

29

Простейший онлайн сервис для управления задачами и проектами с excel-подобным интерфейсом

30

Серверное приложение для планирования, контроля и управления проектами, задачами и персоналом в рабочих группах, офисах, компаниях и организациях.

31

Система управления задачами, которую можно установить на свой сайт и использовать для обработки интернет запросов клиентов. Простой web-интерфейс. Древовидная система задач, отчеты для руководителя, развитые средства оповещения.

32

Простой таск-мессенджер. Позволяет управлять проектами и общаться в команде.

33

Онлайн-инструмент для эффективного управления проектами с интуитивным интерфейсом. В сервисе легко создавать задачи и подзадачи, назначать на них ответственных и управлять ресурсами, что позволяет четко знать, кто и над какой задачей работает в определенный момент. Оставляйте комментарии к задачам и прикрепляйте к ним файлы, делитесь проектами или же экспортируйте их в популярные форматы.

34

Онлайн сервис по управления проектами. Обеспечивает управление проектом по методологиям Agile и Критическая Цепь из Теории ограничений Сиcтем (ТОС) Элияху Голдрадтта. Применяемый в BIPULSE куб решений содержит все ответы на все вопросы руководителя проектов.

35

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

PRINCE2 Agile® wiki

PRINCE2 Agile — это относительно новая концепция от AXELOS (владелец PRINCE2 ^® ), впервые опубликованная в 2015 году. Это адаптированная форма PRINCE2, подходящая для Что такое Agile? среды, такие как Scrum. PRINCE2 Agile не содержит гибких методов доставки, а вместо этого поддерживает существующие.

Руководство

PRINCE2 Agile описывается в официальном руководстве с тем же названием, которое доступно в печатном виде и в формате PDF в интернет-магазине TSO и других книжных интернет-магазинах, таких как Amazon.

Экзамен PRINCE2 Agile Practitioner — это открытая книга, но кандидаты могут использовать эту книгу только во время экзамена.

Модель процесса

Обозначения:

Примечания:

• На изображении выше предполагается, что Scrum используется на уровне доставки, что не является обязательным.
• Количество этапов, выпусков и спринтов является лишь примерами, а также исключением на третьем этапе.
• Схема является схематической, многие детали не показаны.

Этапы, выпуски и итерации

Этапы НЕ являются итерациями Agile, но, как и обычная установка в PRINCE2, устанавливаются на основе потребностей управления проектом. Каждый этап содержит один или несколько «выпусков», и каждый «выпуск» содержит одну или несколько «итераций». Следуя терминологии DSDM, итерации в PRINCE2 Agile обычно называются «временными рамками».

Планы

Планы создаются как обычно, с обязанностями по умолчанию. Тогда рабочие пакеты станут основой для создания планов выпуска и планов итераций (командных планов), в то время как их высокоуровневые аспекты были определены в плане проекта и планах этапов с самого начала.

Самоорганизация

Члены группы доставки имеют право принимать решения о незначительных изменениях, если они не влияют на базовые продукты управления. В противном случае будет запущен обычный процесс управления изменениями с эскалациями на основе целей. Следовательно, ограниченный уровень адаптации существует на уровне доставки, и адаптация более высокого уровня будет происходить на более высоких уровнях, и особенно в процессе управления граничным процессом стадии.

Фиксированное время, проекты с фиксированным объемом

Предлагаемый подход в PRINCE2 Agile заключается в том, чтобы иметь фиксированное время и стоимость для проекта, аналогично DSDM.Следовательно, Контракты будут иметь фиксированную цену. Когда клиент запрашивает новую функцию, он должен поменять ее на одну (или несколько) из начальных функций, упомянутых в контракте, с таким же размером.

Agility

PRINCE2 Agile определяет, что такое Agile? как набор моделей поведения и практик, а не использование адаптивного жизненного цикла, и, следовательно, руководство сосредоточено на предоставлении общих рекомендаций по общему поведению в средах Agile, а не на обеспечении полной интеграции между моделью процесса PRINCE2 и жизненным циклом Agile.

Принципы PRINCE2 в гибких проектах

Принципы не должны быть адаптированы в PRINCE2. На следующих страницах объясняется только то, как каждый принцип будет интерпретироваться в гибких средах:

Адаптация тем PRINCE2 для гибких проектов

Все темы должны быть адаптированы для использования в гибких проектах. На следующих страницах описаны некоторые общие соображения по их адаптации:

Адаптация процессов PRINCE2 для гибких проектов

PRINCE2 Agile не добавляет, не удаляет, не объединяет или не разделяет какие-либо из исходных процессов PRINCE2, но дает описание того, как они могут быть адаптированы для Agile-проектов:

Tailoring Management Products for Agile Projects

PRINCE2 Agile упоминает некоторые дополнительные (артефакты), такие как пользовательские истории, но не делает их официальными и, например, не предоставляет для них описания продуктов.

Ниже приведены официальные продукты управления в PRINCE2 и PRINCE2 Agile:

• Базовые показатели:
• Записи:
• Отчеты:

Изменения в базовых продуктах управляются формально, а другие изменения (например, в пользовательских историях) являются неофициально управляется уровнем доставки. Подробнее об этом в разделе «Изменить тему».

Роли в PRINCE2 Agile

Все роли PRINCE2 по умолчанию все еще существуют в PRINCE2 Agile, и их обязанности не сильно изменились, за исключением рекомендации по расширению возможностей группы доставки.

Хотя в PRINCE2 Agile часто упоминаются роли Scrum, такие как владелец продукта и мастер Scrum, как если бы они были фиксированной частью системы, однако он не рассматривает их как роли по умолчанию и использует более общие роли, упомянутые ниже. Подробнее об этом на странице темы «Организация».

• Исходные роли
• Дополнительные роли

Исходные таблицы обязанностей PRINCE2 не были скорректированы для включения новых ролей. Новые роли даже не упоминаются в руководстве, и неясно, как они должны использоваться и как они связаны с остальной методологией.

Extra Concepts

PRINCE2 Agile представляет следующие дополнительные концепции, которые полезны в Agile-средах:

Certifications

Существует два уровня сертификации PRINCE2 Agile:

• PRINCE2 Agile Foundation : не предполагает никаких знаний PRINCE2 и Agile, и охватывает их оба на базовом уровне. Для сдачи экзамена нет предварительных условий.
• PRINCE2 Agile Practitioner : предполагается, что кандидат знаком с PRINCE2 и Agile, и фокусируется на адаптации PRINCE2 для гибких сред.Кандидаты должны иметь сертификат PRINCE2 Foundation, PRINCE2 Practitioner или PRINCE2 Agile Foundation перед сдачей экзамена.

Оба экзамена доступны в Интернете, и кандидаты могут сдать их после прохождения аудиторного обучения, электронного курса (например, этого электронного курса от автора этой вики) или даже после самостоятельного обучения. Ваучеры на экзамен можно купить непосредственно в PeopleCert (экзаменационный институт для сертификации AXELOS) или в одной из аккредитованных обучающих организаций (например, Management Plaza), что обычно более доступно из-за скидок, предоставляемых обучающими организациями.

Что такое Agile? | Atlassian

В то время как традиционный «водопадный» подход предполагает, что одна дисциплина вносит свой вклад в проект, а затем «бросает ее через стену» следующему участнику, Agile требует совместных межфункциональных команд. Открытое общение, сотрудничество, адаптация и доверие между членами команды лежат в основе Agile. Хотя руководитель проекта или владелец продукта обычно отдают приоритет выполняемой работе, команда берет на себя инициативу в принятии решения о том, как работа будет выполнена, самоорганизуясь вокруг детализированных задач и назначений.

Agile не определяется набором церемоний или конкретных методов разработки. Скорее, Agile — это группа методологий, которые демонстрируют приверженность жестким циклам обратной связи и постоянному совершенствованию.

Исходный Agile Manifesto не предписывал двухнедельных итераций или идеального размера команды. Он просто изложил набор основных ценностей, которые ставят людей на первое место. То, как вы и ваша команда реализуете эти ценности сегодня — будь то схватка по учебнику или смешивание элементов канбана и XP — полностью зависит от вас.

Команды выбирают Agile, чтобы быстро реагировать на изменения на рынке или отзывы клиентов, не нарушая годичных планов. «Достаточное» планирование и доставка небольшими частыми шагами позволяют вашей команде собирать отзывы о каждом изменении и интегрировать их в планы на будущее с минимальными затратами.

Но это не просто игра с числами — в первую очередь, это игра о людях. Как описано в Agile Manifesto, подлинное человеческое взаимодействие важнее жестких процессов.Сотрудничество с клиентами и товарищами по команде важнее заранее определенных договоренностей. А предоставление рабочего решения проблемы клиента важнее гипертрофированной документации.

Гибкая команда объединяется под общим видением, а затем воплощает его в жизнь так, как они знают лучше всего. Каждая команда устанавливает собственные стандарты качества, удобства использования и полноты. Их «определение выполненного» затем сообщает, как быстро они выполнят работу. Хотя поначалу это может показаться пугающим, руководители компаний обнаруживают, что, когда они доверяют гибкой команде, эта команда испытывает большее чувство сопричастности и поднимается, чтобы оправдать (или превзойти) ожидания руководства.

Использование Wiki для управления знаниями в гибкой разработке программного обеспечения: бизнес и управление Книга Глава

Аннотация

Движение к гибкости — одно из самых значительных изменений в промышленной разработке программного обеспечения за последнее десятилетие. В практике гибких методологий существуют разные типы знаний, которые создаются, передаются и потребляются. В интересах заинтересованных сторон существует острая необходимость в управлении этими знаниями как во время разработки, так и после развертывания программной системы.В этой главе предлагается структура, включающая связанные концептуальные модели в качестве средства для понимания использования Wiki для управления знаниями при гибкой разработке программного обеспечения. При этом Wiki рассматривается не только как технология или инструмент, но и как средство распространения знаний и помещается в более широкий контекст среды социальной сети. Для практичности приведен ряд иллюстративных примеров и выделены последствия развертывания Wiki. Наверх

Общие сведения

В этом разделе представлены соответствующие сведения и предыдущая работа, связанная с гибкой разработкой программного обеспечения, управлением знаниями и Wiki.

Ключевые термины в этой главе

Agile Methodology: Методология разработки программного обеспечения, основанная на Agile Manifesto.

Вариант использования: последовательность действий, выполняемых системой, которая дает наблюдаемый результат ценности для субъекта этой системы.

Артефакт: документ или модель, созданная во время разработки программного обеспечения.

Веб-инженерия: дисциплина, связанная с установлением и использованием надежных научных, инженерных и управленческих принципов, а также дисциплинированных и систематических подходов к успешной разработке, развертыванию и обслуживанию «высококачественных» веб-приложений.

Модель: Упрощение по отношению к какой-то цели.

Wiki: Веб-приложение, разработанное совместно сообществом пользователей, позволяющее любому пользователю добавлять, удалять или изменять информацию.

Социальная сеть: Предполагаемая эволюция Интернета в направлении, движимом «коллективным разумом», реализуемым с помощью информационных технологий и характеризующимся участием пользователей, открытостью и сетевыми эффектами.

Программная инженерия: применение систематического, дисциплинированного, поддающегося количественной оценке подхода к разработке, эксплуатации и сопровождению программного обеспечения; то есть приложение инженерии к программному обеспечению.

User Story: Изложение требований высокого уровня, которое содержит минимально достаточную информацию для получения разумной оценки усилий по его реализации.

Пользовательский опыт: восприятие и реакции человека, возникающие в результате использования и / или ожидаемого использования продукта или услуги.

Вики по шаблонам «Agile Practice» обновляется

На XP2006 Амр Эльсамадиси анонсировал новый вики-сайт для сбора шаблонов Agile Practice. Их пока немного, но вы уже можете найти результаты с ChiliPlop 2006 и XP2006 на сайте.И действительно, прошло всего несколько дней, и это вики, поэтому любые практикующие, у которых есть опыт, могут там сотрудничать. Вот уже готовые страницы и шаблоны: Плохие требования
Результаты ChiliPlop 2006
Перекрестное тестирование
Несогласованность между разработчиками и менеджерами
Страх потери контроля
Бесстрашные изменения
Частые выпуски
Итерация
Изучите, а затем поделитесь
Много ошибок, обнаруженных заказчиком
на месте Заказчик
Заказчик на месте
Боится поделиться Похоже, что на сайте используется несколько шаблонных форм…. возможно, самым простым шаблоном является форма Уорда Каннингема «Следовательно-Но», наиболее часто используемая в оригинальной вики-версии C2.

---

Предыстория:

Паттерны — это способ фиксировать знания и абстрагироваться от них, сводя их к существенной и ясной форме, которая может помочь кому-то другому решить аналогичную проблему. Шаблоны — это не просто идеи, записанные в определенной форме. Анализ шаблонов — это отдельный процесс: авторы шаблонов в AG Communication Systems используют интеллектуальный анализ шаблонов, чтобы получить идеи для шаблонов, которые они затем улучшают в мастерской писателей.

Паттерны перешли из области архитектуры в основное направление объектно-ориентированного проектирования программного обеспечения с появлением оригинальной книги «Паттерны проектирования: элементы объектно-ориентированного программного обеспечения многократного использования». Это неудивительно, так как «Заметки о синтезе формы» архитектора Кристофера Александра требовалось прочитать исследователям информатики на протяжении 1960-х годов. Со времени выхода этой первой книги многие люди использовали это устройство для решения проблем проектирования программного обеспечения — его популярность предполагает, что это полезный способ думать и общаться.

Впоследствии шаблоны стали использоваться и в других областях мира программного обеспечения: «Организационные шаблоны гибкой разработки программного обеспечения» Коплиена и Харриса рассматривают человеческую сторону разработки программного обеспечения, «Бесстрашные изменения: шаблоны для внедрения новых идей», автор Rising и Manns рассматривают основные проблемы. человеческие проблемы организационных изменений (не только в ИТ), а «Программное обеспечение для вашей головы: основные протоколы для создания и поддержки общего видения» Маккарти и Маккарти предлагает шаблоны, специально предназначенные для совместной работы в команде.

К вашему сведению: если вам интересна эта тема, возможно, вы захотите узнать, что здесь тусуются специалисты по шаблонам. Хорошо, когда они онлайн 🙂

Наша команда приобрела расширение Wiki от Agile Extensions и планирует предоставить встроенные возможности Wiki

Джозеф

Wiki находится в публичной предварительной версии, и вы можете проверить ее сегодня!

Мы твердо убеждены в том, что динамичная экосистема расширений имеет решающее значение для создания лучшего в своем классе продукта DevOps.Он не только органично приносит новые технологии и решения, которые ищут наши клиенты, но и создает сообщество вокруг нашего продукта, что является огромным вкладом в успех любой платформы.

Недавним примером такого партнерства и успеха является расширение Wiki, которое хорошо зарекомендовало себя на Marketplace. Мы изучали различные способы привнести больше «социального» опыта в Team Services, и стало ясно, что для полной реализации этого видения потребуется Wiki, которая долгое время находилась в очереди в работе команды.

Сегодня мы рады сообщить, что приобрели расширение Marketplace, «Wiki», у Agile Extensions.

Это решение вызвано долгосрочным планом предложить встроенные возможности Wiki для Team Services вместо того, чтобы требовать от людей установки расширения из Marketplace. Для этого мы воспользуемся существующим расширением в качестве отправной точки и прекратим поддержку списка Marketplace, как только мы будем готовы выпустить наше встроенное решение. Приобретение расширения — наш первый шаг, и я привожу некоторые дополнительные мысли ниже.Если я что-то упустил или у вас остались вопросы без ответа, не стесняйтесь оставлять здесь комментарии или писать мне в Твиттере @JoeB_in_NC

Я клиент «Wiki», как это повлияет на меня?

В краткосрочной перспективе это приобретение не повлияет на вас, и никаких действий не требуется. Расширение будет отображаться как опубликованное другим издателем, Microsoft DevLabs, а не Agile Extensions, но вы сможете продолжать его использовать без перебоев. В долгосрочной перспективе мы откажемся от списка Marketplace и дадим клиентам возможность перенести свой контент Wiki во встроенные возможности.

Почему бы не создать свой собственный

и , сохранив другие возможности Wiki на Marketplace?

Наши издатели являются расширенным членом нашей команды, их успех — это наш успех, и наоборот. В случае с Wiki наша команда работала в тесном сотрудничестве с Agile Extensions над их опытом. Во время этого процесса наша команда осознала, что нам нужно встроенное решение. Agile Extensions так хорошо начали свое расширение, что имело смысл покупать то, что они уже создали, особенно после столь тесного сотрудничества с ними.

У вас есть дополнительная информация о ваших встроенных вики-планах?

У нас нет конкретных сроков, чтобы поделиться с вами, но команда занята подготовкой дизайна и определением направления, в котором мы хотим двигаться с Wiki. Одним из важнейших вкладов в этот процесс является набор отзывов, полученных текущим расширением Wiki. Мы собрали все это, и Agile Extensions очень помогли в обеспечении того, чтобы эта информация не была потеряна. Вот некоторые из наиболее важных моментов, которые мы слышали от пользователей Wiki и которые мы рассмотрим:

1. Страница приветствия: есть врожденное желание иметь настраиваемую домашнюю страницу, которую команды могут создавать
2. Навигация : По мере роста вики поиск нужной страницы становится проблемой, поэтому нам нужно будет правильно ее найти
3. Просмотр : заказ определенной страницы желателен, но проще, а создание упорядоченного списка страниц болезненно и очень ценно
4. Авторы : Страницы создаются не только разработчиками, но и авторами контента и менеджерами проектов, ключевым моментом в которых является простой механизм авторинга

Это элементы, которые, как мы знаем, получены из отзывов, но мы всегда к ним прислушиваемся.Пожалуйста, если у вас есть дополнительные мысли о Wiki и о том, что вы хотите видеть в Team Services, оставьте комментарий!

Джозеф Борн

Старший менеджер программ, Azure DevOps — конвейеры / репо

Подписаться

Создайте вики-страницу с идеальной пользовательской историей — Написание Agile-документации: пользовательские истории и приемочные тесты

https: // vimeo.com / 254496362

Как мы видели в прошлом уроке, мы часто создаем «функции», которые разбиваются на набор пользовательских историй. Мы создали вики-страницу Feature (для функции, называемой «Викторина») в прошлом уроке, а в этом уроке мы создадим вики-страницу User Story. По формату они очень похожи.

Как вы помните, мы создали таблицу пользовательских историй на нашей вики-странице викторины.

На нашей вики-странице функций был список пользовательских историй и ссылок.

В этом уроке мы создадим вики-страницу пользовательских историй для пользовательской истории под названием «Повторная викторина».

Конечно, для полного набора документации нам нужно будет создать все 14 страниц пользовательских историй, но как только вы сможете создать одну страницу пользовательских историй в правильном формате, создание остальных пользовательских историй станет лишь вопросом времени и практики. .

Формат страницы пользовательской истории

Теперь сконцентрируемся на идеальной странице пользовательской истории. Он состоит из следующих разделов:

1. Фон

2. Скриншоты

3. Приемочные тесты

4. Дополнительные ссылки (если есть)

Теперь мы создадим эту вики-страницу для пользовательской истории Retake Quiz, который выглядит следующим образом:

Как студент, который не прошел тест, я хочу иметь возможность повторно пройти этот тест через 24 часа.

Фон

Фон должен дать небольшую общую информацию об этой пользовательской истории. В то время как «фоновый» раздел для этой функции в основном говорит о высокоуровневом описании викторины, фоновый раздел для повторной викторины должен обеспечивать высокоуровневое описание повторного прохождения викторины. Вот пример:

Для прохождения викторины требуется набрать 70%. Вполне возможно, что ученики не пройдут тест.

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

Таким образом, им не разрешается проходить курс повторно в течение 24 часов. После этого они могут пройти курс еще раз, но если они проиграют второй раз, они не смогут пройти тест снова.

Сертификаты будут выдаваться только студентам, которые выполнили все викторины и задания, а это означает, что этот студент больше не может проходить этот курс.

Скриншоты

На странице вики-страницы функции только что была представлена ​​пара скриншотов для того, как выглядит викторина. Но для пользовательской истории мы должны попытаться предоставить все необходимые скриншоты для этой пользовательской истории .Например, «Повторная проверка викторины» может содержать скриншоты для:

1. учащийся прошел тест

2. учащийся не прошел тест (недавно в течение последних 24 часов)

3. учащийся не прошел тест (более 24 часов назад)

Три снимка экрана (с небольшими пояснениями) упрощают визуализацию требований

Приемочные испытания

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

Вот то, что у меня есть в качестве приемочных тестов для повторной викторины:

Приемочные тесты для пользовательской истории «Повторная викторина»

Вы могли заметить, что указание правила (зеленая строка в таблицах выше) помогает провести приемочные тесты (которые являются примерами этого правила) легче читать и понимать.

Переформатирование пользовательских историй

Иногда, когда вы записываете приемочных тестов, вы понимаете, что было бы лучше добавить или удалить пользовательскую историю.

Если приемочные тесты для одной истории, кажется, сильно пересекаются с тестами для другой пользовательской истории, вы можете захотеть объединить пользовательские истории (это означает, что вы немного переписываете свои пользовательские истории).

Пользовательские истории должны быть независимыми, согласно модели INVEST. Иногда только при написании приемочных тестов мы понимаем, что все будет чище, если мы добавим / удалим одну или две пользовательских истории.

Давайте рассмотрим этот сценарий в следующем уроке.

(PDF) На пути к пониманию использования Wiki в гибкой разработке программного обеспечения

Wiki может служить средством получения обратной связи от

заинтересованных сторон Agile-проекта. Шаблон Wiki может позволять

поддерживать интерактивные формы, встроенные в документ.Форма

, согласно разметке Wiki, может использоваться для комментирования

(например, информации, содержащейся в) agile-артефакта.

Комментарий после подачи (и, возможно, утверждения) может быть

общедоступным. Этот комментарий может содержать детали

, его автора, дату и время и может быть добавлен к артефакту agile

, тем самым расширяя исходный артефакт.

Эти отзывы могут привести к открытию новых знаний

и / или пересмотру старых знаний.Проявлением этого,

, очевидно, является реализация контура обратной связи на рис. 2. Изменения состояния знаний

могут быть полезны как во время

, так и после закрытия гибкого проекта.

IV. ОГРАНИЧЕНИЯ WIKI ДЛЯ УПРАВЛЕНИЯ ЗНАНИЯМИ

В РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

В этом разделе рассматриваются различные виды ограничений Wiki для

управления знаниями в гибкой (и даже не гибкой) разработке программного обеспечения

.Эти ограничения,

, очевидно, контекстуализируют WKMASD и могут быть эфемерными

или существенными, могут быть техническими или нетехническими, или могут быть

, унаследованными от наследия Интернета, или быть уникальными для социальной сети

.

A. Обучаемость

Как правило, для эффективной установки, администрирования и использования Wiki

в профессиональных целях требуется глубокое понимание

ряда областей, включая архитектуру предприятия

, дизайн взаимодействия и социальную информатику.

Однако эти темы в настоящее время не входят в учебный план

многих текущих программ по разработке программного обеспечения.

Следовательно, или даже иначе, нет априори

гарантии того, что гибкая команда должным образом подготовлена ​​в этих

областях. Действительно, для эффективного использования Wiki может потребоваться

каркасов [23].

B. Творчество

Создание артефактов гибких проектов требует наличия

и поддержки определенных технологий.В разметку Wiki можно встраивать

различных типов мультимедиа,

, включая изображения и анимацию. Однако

в настоящее время невозможно использовать Wiki в качестве средства для создания нетекстовых носителей

, необходимых во время гибкого процесса. Wiki

может действовать как заполнитель, но это не полная среда разработки

. Например, ради аргумента, система Wiki

не может служить генератором диаграмм выгорания, средством проверки модели

или редактором языка программирования.

Следовательно, в настоящее время полезность Wiki как платформы разработки

по своей сути ограничена, и использование группой Agile

нескольких инструментов помимо Wiki является неизбежной необходимостью.

C. Качество

Wiki сама по себе не предоставляет средств поддержки для

, гарантирующих качество знаний. Например, аннотация или отзыв

сами по себе могут быть, а могут и не быть полезными.

Несмотря на их полезность, надежность

общедоступных и редактируемых вики-сайтов, таких как Википедия [24],

подвергалась сомнению на протяжении многих лет.Основными проблемами являются отсутствие информации о происхождении

, возможность

вандализма, несанкционированного, автоматического, манипуляции ботами,

и так далее, хотя нежелательные изменения обратимы.

Следовательно, определенная степень мониторинга и контроля

Wiki, особенно если она разрешает внешний доступ, может быть

неизбежной. Фактически, многие системы Wiki предоставляют средства для ведения журнала

, защиты от спама и очистки ввода и вывода.

V. ЗАКЛЮЧЕНИЕ И НАПРАВЛЕНИЯ НА БУДУЩЕЕ

ИССЛЕДОВАНИЯ

Сообщалось о нескольких случаях использования Wiki для

«обычного» проекта разработки программного обеспечения. Но именно совместная

эволюция понятий гибкости и Wiki, а также

определенных общих черт в человеческом и социальном измерениях этих концепций

однозначно способствуют тому, что

делают Wiki подходящим ресурсом для гибкой разработки. проект. Wiki,

, обеспечивая необходимый социальный контекст, может способствовать

созданию, обмену и потреблению различных типов

знаний на каждом этапе гибкой разработки программного обеспечения.

Локально установленная или удаленная Wiki может опираться на

успех других Wiki. Более того, это может обеспечить

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

социальной сети. WKMASD обеспечивает общее понимание

для таких усилий.

Тем не менее, для желаемого результата остается важным

, чтобы включение любых информационных технологий в разработку программного обеспечения Agile

для любых целей согласовывалось с принципами

Манифеста Agile, а WKMASD не

исключение.Воспринимаемые преимущества приверженности Wiki

сопровождаются определенными побочными эффектами и соответствующими затратами

, которые необходимо учитывать.

Есть несколько направлений для будущих исследований, которые

вытекают из работы, представленной в этой статье. За последние

пару лет автор представил Wiki в своих проектах

, связанных с информатикой и программной инженерией. Зимой 2013 года автор руководил опросом

, основанным на расширении модели принятия технологий

(TAM) [25], об использовании мобильных социальных веб-приложений

примерно 30 студентами бакалавриата в их замковых проектах

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

и предполагали, что студенты с производственным опытом

были значительно более знакомы с

, а

использовали Wiki. Было бы полезно провести

аналогичных эмпирических исследований в промышленных условиях.

Качественный или количественный анализ социальной сети

, сформированной гибкой командой, может быть полезен в

для понимания степени участия и вклада знаний

в гибкий проект, как в рамках одной итерации

, так и через несколько итераций гибкого процесса

.В анализе социальных сетей (SNA) [26] социальные отношения

состоят из узлов (представляющих отдельных субъектов

в сети) и связей (представляющих отношения

между отдельными участниками). Показатели социальной сети

в целом подразделяются на следующие категории:

Подключения, распределения и сегментация. SNA, основанная на этих показателях

, может предоставить ценную информацию о

паттернах (1) индивидуального поведения членов agile-команды

и (2) взаимодействия между членами agile-команды

, приверженной Wiki .

No related posts.