• Пожаловаться

Алистэр Коуберн: Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения

Здесь есть возможность читать онлайн «Алистэр Коуберн: Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения» весь текст электронной книги совершенно бесплатно (целиком полную версию). В некоторых случаях присутствует краткое содержание. год выпуска: 1999, категория: Программирование / Деловая литература / на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале. Библиотека «Либ Кат» — LibCat.ru создана для любителей полистать хорошую книжку и предлагает широкий выбор жанров:

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

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

libcat.ru: книга без обложки

Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения: краткое содержание, описание и аннотация

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

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

Алистэр Коуберн: другие книги автора


Кто написал Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения? Узнайте фамилию, как зовут автора книги и список всех его произведений по сериям.

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

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

Тёмная тема

Шрифт:

Сбросить

Интервал:

Закладка:

Сделать

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

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

Проблема 2. Они вполне могут обойтись и без нас, и при этом успешно создавать программное обеспечение. Такой процесс повторялся еще несколько раз, и я окончательно разуверился в своей способности "видеть то, что происходит на самом деле". Я мог сказать лишь, что в разработке проекта есть какой-то очень важный аспект, который мы никак не можем вычислить. Не так давно я попробовал решить эту проблему, работая в паре с этнографом. Мне нужна была помощь просто для того, чтобы дать название происходящему [Ho]. Вообще, консультанту хорошо работать вместе с этнографом, однако на этот раз мы едва ли смогли начать работу. Проблема была очень простая и непреодолимая: невозможно сказать, что ты видишь, до тех пор, пока у тебя нет для этого подходящего названия. Было очевидно, что нашему словарю не хватает адекватных понятий.

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

Таблица 1. Проекты и методологии, которые я изучал. Информацию в таблице, разумеется, приходится давать в сокращенном виде. Здесь я указываю год, рабочее название проектов и краткое замечание о каждом из них. Некоторые из проектов описаны в другой литературе. Ссылки на источники указаны в квадратных скобках. 1980 . "CT5". Успешно завершен. 26 человек, 3 года (на год позже, чем нужно), имел для компании решающее значение. Изучен в процессе стажировки, четко определенный макропроцесс, микропроцесс отсутствует.

1986 . Проекты "Cleanroom" [Mi]. Успешно завершены. Федеральный сектор IBM, большие команды разработчиков. Неоднократный успех при использовании тяжеловесной методологии, требующей большой дисциплины. 1986 . Проекты "Sherr" [Br] Успешно завершены. Процесс можно описать следующим образом: "сделай так, что все заработало, но не работай сверхурочно". Основной упор на нестандартные креативные решения, процесс не определен. 1980 . "Broooklyn Union Gas" [Co98]. Успешно завершен. Новая ОО технология, 150 человек, проект для решения критически важных задач. 1992 . "Tracy" [Co98]. Провал. Небольшая команда разработчиков слепо следовала методологии, согласно которой нужно было "моделировать мир, а потом превратить модель в программный код". Был доступ только к случайным пользователям и необученному персоналу. 1992 . "BlackKnight". Успешно завершен. Небольшая команда разработчиков, успешно сочетающая использование пояснительных заметок и активное общение 1992 . "Manfred" [Co98]. Провал. Небольшая команда разработчиков, хромает дисциплина, облегченная методология. "Это мы разработаем потом", провал работы из-за постоянного создания прототипа. 1992 . "CSPITF". Успешно завершен. Небольшая команда разработчиков тщательно контролировала итерации. Облегченный процесс, все сидят рядом. Успешная совместная работа руководителя технического процесса и руководителя проекта. Технический руководитель остался, чтобы реструктурировать внутреннюю структуру кода для следующей команды. 1992 . "OTI" [Co98]. Успешно завершен. Маленькие команды разработчиков. "Дайте хорошему работнику хороший инструмент и оставьте его в покое". Неоднократный успех при работе с облегченной методологией, ориентированной на человека. 1993 . "Reginald" [Co98]. Провал. Команда из двух разработчиков выросла до трех команд в двух разных графствах. Одна из этих команд слепо следовала тяжеловесной методологии с обилием документации, и так и не написала ни строчки кода до закрытия проекта. 1993 . "Ingrid" [Co98]. Успешно завершен. 26 человек, 2 года. Инкрементный макро процесс, микро процесс отсутствует. Первый инкремент потерпел неудачу. Заменили всех программистов, с течением времени выработали облегченную методологию, с упором на коммуникации. 1993 . "Synon in NZ". Успешно завершен. Руководитель проекта утверждал, что успех был обеспечен тем, что "четыре человека работали в одной комнате и использовали быстрый итеративный инструментарий", и что это не подходит таким проектам, где разработчики не могут свободно общаться между собой. 1994 . "Udall" [Co98]. Успешно завершен. Поначалу работала большая команда разработчиков, и потерпела неудачу. Успех обусловлен тем, что "начали с нуля и сделали из плохой большой команды маленькую, но хорошую". 1995 . "Winifred" [Co98]. Успешно завершен. 45 человек, 20 месяцев. Успех обеспечили "инкрементность разработки, хорошо поставленная коммуникация и несколько очень хороших работников". Использовался макро процесс, микро процесс отсутствовал. Успешное применение средней по весу методологии, ориентированной на коммуникацию. 1996 . "Reel". Провал. 150 человек, которым было велено обновлять всю документацию при каждом изменении в проекте. Проект закрыт. Один из участников разработки подвел итог: "Сколько не старайся, плохая методика все равно даст плохой результат". 1997 . "Caliper". Провал. 90 человек, проект имел для компании решающее значение. Прошло уже шесть лет, но даже первая основная версия проекта до сих пор не сдана. Слишком смелые ожидания, новые технологии, отсутствие инкрементной разработки, на всех позициях персонал, не обладающий адекватными рабочими навыками. 1997 . "NorgesBank". Опрошено шесть команд разработчиков. Все повторяют приблизительно одно и то же: "Успех обеспечен хорошей коммуникацией, как в самой команде разработчиков, так и между разработчиками и пользователями". 1998 . "C3" [C3]. Успешно завершен. После первого провала 26 человек решили заменить восьмью. Extreme Programming [EP]. Успешное применение в небольшой команде методологии, требующей высокой дисциплинированности от сотрудников. Основной упор - коммуникация. 1998 . "NB Banking". Успешно завершен. Проект, изначально рассчитанный на трех человек и два месяца работы, неожиданно вырос до 10 человек, которые проработали 14 месяцев. Связь при помощи видео. Не понравилась. Макро процесс, микро процесс отсутствовал. Успеха удалось достичь при помощи "инкрементных разработок, правильно подобранных людей и хорошей коммуникации". 1998 . "M.A.D". [Ch]. Успешно завершен. Небольшая команда разработчиков занималась изучением окружения конечных пользователей и использовала прототипы. Удачное использование методологии, основывающейся на создании прототипов и коммуникации. 1998 . "Insman". Успешно завершен. В команде шесть человек, использовалась методология "Crystal(Clear)" [Co00]. Успеха удалось достичь благодаря особому упору на "тесном общении, моральном духе команды, итерациях длиной в три месяца и обучении разработчиков". 1999 . "Cinch". Продолжается в настоящее время. 40 человек работают вместе, однако при этом еще требуются формальные сдачи работ. Все осознают цену написания документации, однако пока не могут перейти на более индивидуальный подход (непонятно почему - из-за личных качеств, по привычке или же в этом виновата культура?). 1999 . "Hill AFB TSP1" [Web]. Успешно завершен. Семь человек, CMM 5-го уровня, используется PSP/TSP. Небольшая команда успешно использовала ориентированную на процесс методологию, в которой требовалось соблюдение строгой дисциплины.

Читать дальше
Тёмная тема

Шрифт:

Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения»

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


Отзывы о книге «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения»

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