Software Development Projekt
Проект в рамках курса Software Development. Задача: сконцепировать, задокументировать и реализовать приложение. Дано: шесть человек, сформированных преподом в группу. Скучать не приходится!
На самом первом занятии по проекту препод сказал, что принимать участие в нем следует только тем, у кого есть опыт программирования и попросил всех желающих написать ему письмо с оценкой собственных знаний и опыта. По итогам этого он типа распределил нас по группам. Групп получилось три, в моей шесть человек (в этот раз мне достались все немцы), и почему-то из них трое – девушки. Единственные три девушки со всего этого курса у нас в группе! И из шести человек трое не имеют вообще никакого опыта в разработке, вообще никак. Один парень с Wirtschaftsingineurwesen и две девушки с Wirtschaftswissenschaften, толку с последних пока воообще никакого нет. Причем из шести человек двое (в том числе я) получат за этот проект три ECTS-пункта (Leistungspunkte, Credit Points), а остальные четверо – пять, при этом объем работы должен быть выполнен всеми одинаковый! Это он подчеркнул отдельно. Тот факт, что один пункт дается кагбэ за 30 часов работы, вообще его не парит!
Эта разница в пунктах получается из-за того, что мы двое учимся дальше на бакалавра, а остальные четверо либо на диплом, либо на другом направлении, где им дается за это больше пунктов. Просто нет слов.
Задание весьма нехилое, оно состоит в разработке приложения для врачей, которые могут использовать его на приеме пациента для просмотра медицинских Leitlinien (это что-то типа описания болезни, ее деталей, видов, а также рекомендаций к лечению, не знаю как это по-русски называется, поскольку никогда с этим дело не имела), а также оно должно содержать несколько приложений в себе типа расчета BMI (Body-Mass-Index, коэффициент отношения веса и роста), пересчета каких-то показателей крови из одной системы в другую, ввод данных развития плода беременной женщины и построение на их основе графика развития, и еще опросник, на основе ответов которого рассчитывается какой-то коэффициент депрессии после родов. Третья часть задания – нужно также запрограммировать возможность вызова данных пациентов из базы данных, которая есть у препода и сравнение новых данных со старыми для прогноза (как развивается состояние пациента). При этом надо сначала разработать документацию и архитектуру, потом запрограммировать, и в идеале еще протестировать и тоже всё задокументировать. Неплохое задание для студентов, не правда ли?
Первым делом мы выбрали руководителя проекта. Сначала предложили это мне, но я отказалась, о чем теперь жалею. Выбранная на эту роль Лиза не имеет совершенно никакого представления ни о разработке, ни об управлении проектом, но что хуже всего – по какой-то причине даже не изучает этот вопрос в теории (это видно по тому, что она делает).
Сначала мы с группой вроде бы воодушевленно принялись за дело, сходили на встречу с “заказчиком” в лице препода и еще какого-то невероятно напыщенного чувака с кафедры, который явно занимается каким-то проектом в этой сфере, записали требования заказчика (слава Богу, я записывала слово в слово, не полагаясь на других) и начали работу над спецификацией. И тут началось – всё, что я предлагала в плане содержания спецификации, всё им не то. “Ich finde es zu viel”, “Ja, so viel zu dokumentieren brauchen wir nicht”, потом на все мои замечания по содержанию – “Das brauchen wir nicht/Das will der Kunde bestimmt nicht”, на что я каждый раз обалдевала и отвечала: “но у меня черным по белому записано со встречи, что он это сказал!” – “а, да? ну ладно” и так далее, и так далее. Потом началась борьба по поводу оформления Use cases¹ – я взяла образец по памяти со своей работы, сократила его втрое (!), предложила его группе, на что получила “это слишком подробно, я считаю, нам это не нужно” и требование предоставить ссылку, где написано, что это стандарт, по которому нужно делать. Прописного стандарта по оформлению, конечно, нет, поэтому пришлось оперировать выдержками из книг, стандартов ISO и моих тренингов, которые я проходила раньше на работе. На это мой главный критик отреагировал довольно вяло.
После этого они сели за разработку самих Use Cases в виде текста и диаграмм. В тот день я не смогла пойти с ними, потому что у меня были лекции в это время, в итоге они сотворили полную фигню. Я переделала всё это, загрузила в нашу общую систему и написала, что они не совсем поняли, что конкретно и как надо сделать и предложила посмотреть мой вариант. После чего начались возмущения, что как это так, почему я делаю второй вариант вместо того, чтобы переработать их вариант. Я попыталась вежливо еще раз объяснить, что переработать то, что сделано с начала и до конца неправильно, не имеет смысла, в итоге ситуация начала накаляться и Лиза поспешила собрать нас на очную встречу. К этому моменту меня уже реально бесило то, что они не желают воспринимать новую информацию только потому, что они не знают как с этим работать. Изначально я не хотела рассказывать, что я работаю с этим уже три года, какие у нас проводились тренинги, какую сертификацию я проходила. Но к этому дню мне не хотелось провалить проект из-за упертых коллег, доставшихся мне, поэтому пришлось рассказать, почему я делаю какие-то предложения по работе и что они основаны не на пустом месте – в отличие от критикана, который на мои предложения мог ответить только, что он считает, что это слишком подробно и много.
После этого мы начали работать конструктивно – и слава Богу. Стали делить задания, а не делать их все вшестером, потому что это ерунда, а не работа, трата времени, кто-то делает много, кто-то ничего и так каждый раз. Не думала, что придется тратить время еще и на такую фигню.
Но в любом случае, я тоже не могу охватить все стороны такого проекта, да и не хочу, естественно, поэтому планирование проекта должна делать Лиза. В итоге вышло так, что на очередной презентации всех групп преподу наша группа была хуже всех – не написано ни строчки кода, не сделана важная диаграмма классов, толком не проработана архитектура. Выступающий сказал преподу “вот я сделал Sequenz-диаграмму, но не очень понимаю зачем, сделал, потому что Вы сказали”. (Это еще один из типов диаграмм). На это препод покраснел, позеленел, посинел и битых пятнадцать минут объяснял, что диаграммы делаются не для того, чтобы порадовать его, а для разработки архитектуры, для понимания программы и для того, чтобы разработчик мог прочитать это и понять, что от него требуется. Мне хотелось просто провалиться под землю от такого заявления “потому что Вы сказали”. После окончания занятия препод отпустил две другие группы и подсел к нам с вопросом, в чем конкретно у нас проблемы, потому что мы отстаем по плану и он видит, что у нас есть непонимание в работе. Мы все поговорили с ним на эту тему, потом он ушел, и наша Лиза говорит: “я предлагаю сдать работу в начале февраля вместо конца марта”. (Варианты были до сессии, т.е. в начале февраля и после сессии и каникул в конце марта, препод сказал, что ему всё равно, мы должны только сообщить ему когда). Я говорю: “почему вдруг раньше, чем планировали?” – “мне было бы так удобнее”. Остальные: “да, давайте сдадим раньше”. Я подумала, что мне попались просто непроходимые идиоты, говорю: “это на ДВА месяца раньше. Мы уже сейчас отстаем от других. У нас не написано еще ни строчки кода. На носу Рождество, где никто не будет заниматься проектом. Я считаю, что такое сокращение срока нереально”.
В итоге они согласились не менять срок сдачи не потому что поняли, что не успеем, а чтобы я не возникала. Ну вот как так?….
С моим критиканом Клеменсом мы теперь начали работать нормально. Он больше не отрицает безосновательно всё подряд, а мы это обсуждаем. Диаграмма классов общими усилиями была создана и, что немаловажно, понята. На сегодняшний момент уже даже написана маленькая подпрограмма (BMI-расчет), правда, не на том языке программирования, на которой собирались писать :D Поэтому Рихарду придется ее переделать. Клеменс, Тиджан и Рихард будут программировать, я взяла на себя всё тестирование с документацией (если будет что тестировать вовремя, если нет, придется впрягаться в программирование и забить на тесты), а вот что делают Антье и Лиза – хороший вопрос. Ничего. Хотя не, Антье придумала название нашей программе.
- Use Case – сценарий использования – спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности) в Унифицированном языке моделирования (UML) (Википедия)
Das Bild für diesen Post kommt von hier
